program doesn't exist, but it's there...

Hello all,

KSS 8.6.10.

I have one program (ProgX) and multiple library modules, that depend on some program variables, inside a sub folder inside the Program folder.

/R1/Program/LIB/L1.src

/R1/Program/LIB/L2.src

/R1/Program/LIB/L3.src

...

/R1/Program/LIB/Ln.src

And the program /R1/Program/ProgX.src + dat

Of course, if I remove the program all libraries are marked with a red cross showing errors as they can't find the variables in the active/loaded program.

When I copy the program back into the /R1/Program folder all the errors disappear.

This strategy worked fine with at least 6 robots at my customer (and in multiple other robots out there).

With this robot, though, when I power on the system, I can see libraries show the red cross (analysys error) even the program is in the folder.

When this happens, if I try to select the program, I get a message saying that /R1/ProgX doesn't exist.

This is strange as the program itself is not in the /R1/ProgX folder.

It is in /R1/Program/ProgX folder.

If I cut the rpogram from the /R1/Program folder, move it into an external folder C:/Shared (i.e.) and then I move it back to the /R1/Program/ folder, everything starts working again.

This is a safety risk since the operator could easily select a different program and create a collision problem. Again, in all the other robots I programmed this is not happening.

Maybe I've done something wrong.

Any idea of what is going on here?

As always, thank you in advance.

Hi panic mode ,

Thanks for answering.

I know, the folder where I move the file is the repository of programs in a network folder outside of the /R1 folder.

It works properly because, as you say it recompiles the file when it's pasted back to the R1/Program folder. The strange thing here is that an unchanged program just works well after moving it back to the programs folder.

I know libraries should not depend on programs, but, when you have a shared logic that is the one that handle the cell behavior, you have two options: repeat the code in every program or put the code in a library, that way your main routine in the program can call the main shared cell routine and you have the same code working for all the programs, pallet handling, alarms handling... and all those things work perfectly well without repeating a single line of code then. Been using this approach for years without any problem.

About permissions, I moved the file from Expert and Administrator and in both cases the same happened., in any case, I don't know where to look for permissions in a program, could you explain the steps to do so?

If I don't get a better approach from KUKA service tomorrow, I'll propose my customer to make that minor change every time he restarts the robot, this has the risk of a syntax error, but at least the operators can't copy the wrong program.

Thank you again!

More on the proposed option:

If I open the program, add a space, and close the program to save the changes, the program can't just reach libraries then.

Renaming the file doesn't help.

Only moving it out of the programs folder and moving it back there helps.

I already found what was happening, that robot came from KUKA Germany, a technician from Spain came to make the final touch and adaptations...

And that guy configured the controller to stop without hibernating.

He changed the robot name (to something different than the customer standard, wrong), the fact the robot is hanging in the ceiling (good), he did not install the bought technologies (wrong) and for who knows why, he changed this setting (wtf).

OK, at the end the problem is solved, now that I know what it was going on, it was a really easy thing. All working as usual.

Hibernation: the computer stores everything in RAM into the HDD before shutting down. Then, at boot, it reloads everything again in RAM.

This means that, after the operator loaded one program the first time, he will have the program working until something fails and they need to cold start the robot (which almost never happens).

In any case, if this happens then their maintenance department will just recover the file using the depicted steps and everything will be OK again.

You don't have the complete picture: the program itself stores program local variables (used by the libraries) (i.e. limits of the pallet table for that model) and of course, those variables are not there if the program is not there... and, following with the example, the pallet control library won't find those variables...

That also happens with a few functions (and as far as I know KRL doesn’t offer late binding).

But this is another story, I can explain you how the design was done years ago (by a group of programmers with master degrees) and why this was the best solution (given KRL limitations) but this has nothing to do with the problem itself and I’m sure no one has time for that.

What it was not acceptable was to go through the risk of relying on a human being every morning.

Now, if they need technical support an expert will come and follow the simple steps to reload a program file, but in a daily basis the problem is solved. As I told in previous posts this structure has been working in plenty of robots for years without any issue.

In any case, thanks for posting and for helping people here panic mode, you do a terrific job in this forum.