KR3 .dat file

[JadeStud]

We try to activate our Kuka KR3 with Kuka|prc. We have a KRC2 Controller for the robot.
Besides the .src file our robot needs a .dat file. Is there any chance to generate a .dat file with kuka|prc?
Thanks and best regards, Gregor

[Johannes @ Robots in Architecture]

Hello,
So that's the pretty old KR3 that looks a bit like a duck? You may need to check the box for improved compatibility with older KRC2 controllers in the Code settings.
But the *.dat file itself just stores some variables, and KUKA|prc puts all data into the *.src file. So if your files are not showing up that may be linked to an invalid project name (e.g. an empty space somewhere). Compilation errors might be solved by the compatibility option I mentioned above, it just changes a single line.
Best,
Johannes

[Xylotica]

The fact that Kuka.prc doesn't generate a .dat file means that I never bothered trying to understand what they are and how Kuka meant us to use them.
Surprisingly, I'm struggling to find simple examples and explanations...

[Johannes @ Robots in Architecture]

Hello,

I always understood DAT and SRC files as a separation between variables and logic. The SRC file contains the logic (e.g. "LIN Pos1") and all the positions etc. ("E6POS Pos1 = ...") are saved in the DAT file.
That approach is useful if you are mainly re-using saved positions (e.g. some sort of pick and place) but less relevant for processes with many individual points.

Best,
Johannes

[Xylotica]

Yes, but the mono-program approach seems to exclude a sub-routine structure as in :
If INPUT X is true, then run program "Charlie", else run program "William".
In particular, have seen this approach used in a pick-and place application with sensors at different places where pallets could be parked.
Depending on the presence or absence of pallets, the robot would exectute a different program.
Also by a robot integrator who created an interface on a Siemens PLC with the goal of allowing workshop workers to run a program or another.

[Johannes @ Robots in Architecture]

Hello,

I don't see why that would not work, take a look at the KUKA|prc settings that splits a large job into several files.
All it does is generate multiple programs that are then run for a primary file.
But yes, if you want branching decision trees Grasshopper is not the best tool, we did some very successful experiments with Unity Visual Scripting, though, for real-time applications.

Best,
Johannes