Only thing I can think of is $red_t1. Does this have any influence? Afaik 15 % is max. It implicity factors down the override so with a value of 7 in it for example 100 % override is stripped down to 7 %. Can be found in r1/$machine.dat.
Whats $speed_limit_teach_mode? It also affects maximal t1 velocities?
This thread also shows some facts on T1 velocities:
Fubini
Some kind of glitch in Fubinis main memory
Code after resume is not executed. AFAIK.
Damn it. You are right. Stuff like this happens when you are out of the robotics business for 4,5 years. My memory is loosing my KUKA knowledge more and more. 
After the resume of interrupt_handler.
Fubini
You should take care that the advance run pointer stays inside the Interrupt. This has been discussed multiple times in this forum and is a common programming error with Interrupts.
Fubini
First of all consider reading READ FIRST... - KUKA Robot Forum - Robotforum - Support and discussion community for industrial robots and cobots (robot-forum.com)
What did you do to add the axis? Where did you make changes to add the axis? What does the machine data look like before and after? What tools did you use to make the changes (editing machine data directly, axis configurator, ...)? ...
Please be a lot more specific my crystal balls service contract ran out last week.
Fubini
What did you do before this happened? Did you change any IP adresses? If so how exactly?
Fubini
At best by not using inline forms but by implementing whatever you want to do in plain KRL. Get the system integrators manual to get started.
Fubini
Def MAIN()
YOUR_PROGRAM(Whatever parameters you have)
ENDAt best download system integrators manual for your KSS version from KUKA portal, see KUKA forum Read First. It explains KRL.
Fubini
Never heard of a message with this Text. Can you provide exact Text and message number and message prefix, or share a screenshot. Does the message come from KSS or a Techpackage or is user defined or ...
Which robot of KUKA type? Whats the robots position when this happens. Is it happening always on the same spot inside your program? What is the robot doing? Is it using any techpackages? ...
Nothing abnormal happened? That's your interpretation. How do you know this? What did you checkout to verify nothing abnormal happened? Whats shown in logs for example? ...
I think we need a lot more details to be able to help. Let me put it into perspective: what you provided so far is meaningless. It's the same quality calling your car repair shop with only info the car stopped. Did you pull hand brake, ran out of gas, crashed, ... Limitless possibilities.
Fubini
Most likely also there are limitations from the robots dynamic model. You could check whether the reachable velocity is different when load changes to check it.
Fubini
Simplest solution is as most of the times to restore your harddisk image backup. You should save the current project and deploy it again after the restore.
...
Fubini
Something like this
Was always called portal by us. There a different variants of it but basically 2 or 3 linear axes that are moving in xy and z.
Look in a $machine.dat of your choice
DECL MAIN_AXIS $MAIN_AXIS=#NR ;GRUNDACHSENKENNUNG (SS = PORTAL, CC = SCARA, NR = GELENKROBOTER)
Might be a German inspired wording. Looking it up the correct English wording would be Gantry I think.
Fubini
That has been discussed many many times in this forum. Just use forum search. In KRL one can not use variables directly inside the target position. It needs to be a declared Variable so something along the lines of
DECL FRAME myPos
myPos.X = 0.0
myPos.Y = 0.0
myPos.Z = offset_prelievo
myPos.A = 0.0
myPos.B = 0.0
myPos.C = 0.0
LIN_REL myPosFubini
Sorry SkyeFire can you elaborate on your remark. As I understood the question a xy or xyz stage aka portal should be run as robot kinematic with a KRC1. Did I miss something here?
You can run portals with as standard KRC as well. It is only a matter of having the correct machine data. E.g. $MAIN_AXIS=#SS in R1/$machine.dat is portal if I remember correctly and $WRIST_AXIS=#NOH means "No Hand". There is a documentation that explains how to configure different kinematic types in $machine.dat. This documentation is no official KUKA manual but can be requested through KUKA customer support. Maybe it is already available inside KUKA xPert. I think this document has been shared with customers in the past and is not KUKA secret.
Fubini
Lookup the submit interpreter(s). Sometimes a limitation is implemented in there.
Fubini
What joint acceleration values does the robot realistically use? In the KUKA docs I haven't found any information at all so far and I don't know if the range is something like 250-500 °/s² or more like 5000-10000 °/s² or anything in between. I only need a rough estimate to know the range I am working with.
There is no explicit bound for this. Since we are talking PTP moves here the limitations come from the robots dynamic model. The dynamic model restricts gear and motor torques. In this case $ACC_AXIS[] does not limit axis acceleration directly but the torque available to accelerate/decelerate each joint (the maximal values for torques are stored in robcor.dat inside the dyn_dat[] array. But the documentation of the dyn_dat values are a company secret of KUKA and not publicly available). How much torque there is available depends on the robots state (position, velocities, accelerations, loads, ...). Lets assume a motor can generate a torque of 40 Nm. Holding the robot and its current position (assuming for simplification positions, accelerations are zero) requires a motor torque of 27 Nm than a value of 100 in $ACC_AXIS[] means the robot will try to use 13 Nm for acceleration. Basically everything that can be used up to the maximal torque value. But since the robot is a coupled system this might not be the resulting acceleration you will see in the end. Since the calculated trajectories of the robot are time and phase synchronized over all axes it might be that another axis is the actual limiter for the overall torques. In this case all other axes are "slowed" to fit the limiting axes in such a way that all axes start moving and finish moving at the same time (this is an important feature that no matter what the user programs for VEL_AXIS and ACC_AXIS the resulting movement of the TCP in Cartesian space is always the same).
To use accelerations on joint level in rad/s^2 you would need to deactivate the dynamic model. But this is not recommended because it is than a lot easier to destroy your robot and in your use case you would also see even more unwanted oscillations.
If you want full control over how the robot accelerates and decelerates yourself the only option I can think of is using the RSI package.
Another possibility to get closer to commanding direct rad/s^2 values would be to use spline motions in combination with adding additional restrictions by means of $SPL_VEL_RESTR. If I remember correctly you can add joint specific restrictions for axis acceleration in there. In that case $ACC_AXIS is applied as percentage value to both (torque limit and joint acc limits). Joint limit acc then is defined by the $RAISE_TIME[] the time it takes to acc from stand still to maximal velocity for each axis. In KRC2 $RAISE_TIME was directly inside R1/$machine.dat but for KRC4 this changed and the info was moved with tag RampUpTimeUnderLoad into the motor configuration xml-File of the specific axis.
Of course for getting a better performance with less or minimal oscillations the would be other options using available features of the robot controller but as I take that is not what would be a feasible solution justifying a masters thesis.
Last but not least what you also could do is just "measure" the resulting accelertions by using the built-in oscilloscope function (aka trace) inside the KRC. You can record the resulting axis acc by configuring the correct channel you want to record and than plot the result using either WorkVisual or the Tracetool found in any KRC installation in the C:\KRC\UTIL folder. So use $ACC_AXIS just to "scale" the input but what the resulting axis acc you get is only defined after recording the values and looking at the trace plots.
The data sheet for the KR150 2700 extra we use states the maximum speed at 150kg is:
A1: 123 °/s, A2: 115 °/s, A3: 120 °/s, A4: 179 °/s, A5: 172 °/s, A6: 219 °/s
Am I correct in assuming that I can safely set $VEL_AXIS[] to any value that is equal or smaller to these?
The value entered for $VEL_AXIS[] is a percentage of the maximal value. So 100 means maximal velocity. The actual maximal value is given by $VEL_AXIS_MA in motor revolutions per minute inside R1/$machine.dat. If you want to calculate maximal axis velocities you need to also consider gear ratios RAT_MOT_AX[] and axis couplings $AXIS_COUP[,] inside the same file.
(its basically the same for robot axes).
This does not tell anything. The folder seems to be correct. Is there a file vor ArcTech created when trying to install or not? If yes what is its content?
Fubini
Is this arctech version for kss 8.2? Whats written inside the logfile? Each TechPackage installation creates a logfile inside C.\KRC\LOG (not totally sure about this folder. Might also been C:\KRC\ROBOTER\LOG or something similar. I currently have no access to a robot to look it up precisely).
Fubini
To which robot brand is this related? Unfortuntly you posted in the general section. This is probably different for each manufacturer.
Fubini
