This will definitely not work. You would also have to adapt the signature accordingly. How the safety signature is generated only KUKA knows. This is on purpose like this to prohibit manual editing and changing of safety configuration. Safety needs to be manipulation safe.
Fubini
Of course, as mentioned before you can always talk to KUKA. Usually they are eager to help in cases like yours and provide the software. Most of the time even free of charge if they find in their databases the software was already licensed for your robot. Otherwise you are not allowed to install any software anyway may it come from whatever dubious source.
As already mentioned before usually the installers and deinstallers are on drive d, so check there on what you can find.
Fubini
QuoteAll right, thanks a lot, I think windows XP embedded is not to hard to find in the end if any formating done.
You are aware that Xp embedded is not a out of the shelf version but specially modified by kuka prepared to run a dual os system with xp and VxWorks.
I would try to talk to KUKA. Usually they can provide the needed software. Even if you bought the machine from someone.
Open bas.src lookup where these variables are used and figure out to what system variable (variables starting with $) and how they map. Afterwards lookup the system variables manual to understand it completely.
Ok skyefire Beat me to it. 😂
Fubini
The sign decides whether the motor turns left or right and hence defines the axis direction and not the often mistaken $AXIS_DIR which also stands for axis direction but is not in this type of sense.
Gear Ratio is defined by $RAT_MOT_AX (ratio motor/axis) in R1/$machine.dat as a fraction.
Fubini
Then download them from kuka xpert, see forum read first ...
Lin_rel {z - 300} ; run 300 mm in negative z direction starting at the current position
Fubini
Sorry, I do Not get your question. In any movement command all axes start and end simultaneously unless an axis is set to asynchronous. But in the latter case they would be programmed using asy_ptp not lin.
Fubini
This error is not issued by the standard robot controller as can be seen from the error number and the HPU source. So probably has nothing to do with $robcor.dat or r1/$machine.dat. You said the robot came from a medical facility (maybe accuray?). I know that most medical development facilities modify the standard system with additional self developed technology packages. So you should consider talking to the seller or at least lookup all installed tech packages.
Btw. you should post exact software and hardware controller versions, see forum read first if you do not know where to find this info. Only robot type and krc 2 as can be seen on the screenshots is not sufficient. It might also be a special version released only for medical applications.
Fubini
decl real myVel = 0.5
...
$vel.cp = myVel
Lin xp1
...
Slin xp2 with $vel.cp = myVel
...
Read system integrators manual. This is explained in detail there.
Inline forms store the programmed values individually for each motion command in the dat file, so this can not be changed by a single variable. Lookup $bas.src on how data of inline forms is transferred to motion commands.
So you must use touch up functionality ( open inline form, change what you want to change and then save). But you can mark a whole section of inline forms if you want to change more than on inline form at a time to the same values.
Fubini
How about using the builtin oscilloscope (aka trace)? Use WorkVisual to configure and plot it.
Fubini
For me that sounds like a problem with positioning back onto the commanded path after being kicked of from it due to the emergency stop not being handled path preserving. This usually triggers a ramp stop leaving path tangential. If your robot is a 5 axis palletizer this can lead to losing palettizing position by a to far drifting axis 5. At least the comment on $Palmode in the error message suggests this.
For further clarification it would be helpful to know the motion type the robot was in when emergency stop was triggered.
Fubini
First of all stop yelling at us and then consider reading READ FIRST... .
Otherwise I can only state that A4 might be behind its limits. And now guesswork starts: turn issue?
Talk to KUKA. You need a license to be able to use it. Also it's not available for all robot types. Hence another reason to talk to Kuka. Also I think you need to have at least a 8.6. But I am not totally sure of this. So yet another reason to talk to Kuka.
These values do not exist. Kuka uses a dynamic model to determine acceleration and deceleration. Hence it depends on load, position, velocities, ... and the defining values are torque not acceleration.
Cartesian tool acceleration and deceleration are programmed by the user in his program. The robot will always try to realise those but this might lead to torque violations of the axes and therefore can generate errors during motion execution.
Open bas.src and lookup where it is used and how. You should find some spot in there where this information is used to set some system variables. Then lookup the documentation on the system variables.
E.g. I am pretty sure IPO_FRAME will lead you to the system variable $IPO_MODE. Looking up $IPO_MODE you should find info on the differences whether the robot holds the workpiece or the tool.
Fubini
it runs on the PC. The PC is shared by Windows and VxWorks.
Kernel System usually means the software running inside the VxWorks realtime operating system.
