Distinguish a cold start from a download of a modified program from WorkVisual

As far I can tell, there isn't a way to tell the robot if a program was edited internally (from SmartPad) or externally (from WorkVisual or any other editor).

Since I don't know the code running at your robot, I'm just guessing, but looks like the variables overwritten when You download the program in the robot controller are declared on the .dat file that compose that particular program module.

A good way to avoid this would declare these variables globally somewhere else. On as specific file, or at $config.dat itself.

Quote from massula

A good way to avoid this would declare these variables globally somewhere else. On as specific file, or at $config.dat itself.

Mmmm... but doing a Project Deploy in WoV sends every file, including $CONFIG.DAT. So moving those variables to a different file won't protect them if the gripper state has changed in between the Upload of the project that is being edited, and the Deploy of the edits.

Probably the formally correct way to do this would be to go to the robot, stop the robot, Upload the active project, insert the changes, then Deploy, then resume the robot. As long as the changes being added don't overwrite any of the memory variables, this should work.

The trick is to ensure that the project being Deployed has the same memory state as the real state of the gripper. Or, don't do full-Project Deploys, and only push changes to a single module (if the module being pushed includes the memory states of the gripper, then making a special standalone Global module that only contains the gripper memory states might be worthwhile)

all you can do in this case is use external memory. something that is not affected by WoV. why not use small PLC that handles gripper and provides feedback to KRC of current state?

not sure of any variable that tells if and when WoV project was deployed.

did not think much abut it but i am inclined to follow Registry path as seen in the archive:

\LocalMachine\SOFTWARE\KUKA ROBOTER GMBH\WorkVisual

it contains key CurrentProjectName etc.

this can be exported to a text file using reg command for example

https://docs.microsoft.com/en-…ndows-commands/reg-export

and the text file can be read by CWRITE

this is just to illustrate that there is a way though it maybe long wound or unconventional

and this part works:

reg export "HKLM\SOFTWARE\KUKA ROBOTER GMBH\WorkVisual\CurrentProje

ctName" filename.txt

or better

reg export "HKLM\SOFTWARE\KUKA ROBOTER GMBH\WorkVisual\CurrentProje

ctName" filename.txt /y

Quote from SkyeFire

Or, don't do full-Project Deploys, and only push changes to a single module (if the module being pushed includes the memory states of the gripper, then making a special standalone Global module that only contains the gripper memory states might be worthwhile)

If I understood correctly, OP is having problems downloading single programs in the robot, not complete WoV projects.

When I wrote specific file on may previous message, I was meaning a global .dat just for the gripper states, as You mentioned above.

A thing to be observed is if the robot has more than one program, and all these programs have local variables with same name, this approach will need the creation/renaming of some variables.

if transferring individual files rather than deploying WoV project, it is enough to move declarations to a separate DAT file

The formal, correct best-practice way to handle this is to have the gripper report its state in real time, and always check that state before commanding any action. As a rule, relying on memory states is considered poor practice (not that that stops some designers), and your current situation is a case in point.

So, making the memory states less vulnerable to being reset by a Project Deploy would be a partial fix, the kind we're often stuck with b/c the bean counters refuse to fund the correct solution. But the real solution would be to put sensors on the gripper that report its position, and the presence/absence of a part in the gripper, at all times.

i second that.... having sensor is always the best possible option.

sometimes having sensor on the EOAT may not be practical for variety of reasons... but even then having sensor is still the best option. an example is gripper that goes into oven. no sensor would endure the heat that turns gripper red hot, but sensor does not need to go in there. can be external and still do its job from the safe place - robot can bring part/gripper to sensor for inspection.