Many movement points woven with functions - optimization

[Altrinis]

Hello,

I seem to have stumbled upon an issue with krl coding requiring a broader knowledge than mine.
I'm in the process of developing 3D printing technology, since quality is what I'm after the density of points in tool path is very high. Problems with file size quickly arose and Kuka PRC function "Reduce Filesize - Skip Redundant Position" was invaluable.
However, as I went further it became necessary to run a certain subprogram before each movement (g1.src) to check the robot velocity with $VEL_ACT and calculate the speed of extrusion. It's because our extruder uses servo motor rather than a stepper motor and needs to synchronize with robot slowing down on detailed tool path - a command is sent via EthernetIP with correct rotation speed, hence slimak=(...).

The appearance of any command woven between motion positions seems to prevent Kuka PRC from optimizing the code and redundant positions (such as external axis) are no longer removed: see "example_with_intersecting_functions" compared to "example_without_intersecting_functions(optimized)"

Solution that I'm after consists of two elements:

• Possibility to retain skipping of redundant positions even with interwoven functions
• A better solution to the robot-servomotor synchronization

I had some ideas that with Your help might prove valid:

• Load all the movement points (although there could be as much as 100 000) into an array and execute them one by one with a WHILE function
• Run a function in background (is it possible?) which at fixed time intervals would send a proper extruder speed based on current robot velocity
• Set another global variable which is being transmitted every 1 second to extruder
• Using submit interpreter

One thing I should mention is that the robot movements need to be stutter free. For instance, from what I have gathered a conditional function could cause interrupts in advance run.

I'm most grateful for any guidance in the matter.

Best regards,
Michael.

[Johannes @ Robots in Architecture]

Hello,

Yes, KUKA|prc only optimizes uninterrupted lists of movements, a Custom-KRL in-between will not allow it to reduce the toolpath.

A simple workaround would be to simply replace every "C_DIS" with
"C_DIS
CONTINUE
g1()"
You could do this either in another software, or output the KRL code via the Analysis component and do it in Grasshopper.

You can run stuff in the background, the so-called submit interpreter, which you also mentioned. Unless you have got a very new KSS 8.5 controller or a special techpackage, you can only run one instance of it, usually the sps.sub file. However it is recommended to never put movement-related commands in there. Note that the submit interpreter is running at the robot's cycle time. So if you are actually sending commands (e.g. via the serial port) that may be too much data for the receiving PC. Consider counting up with a variable to reduce the amount of data sent.

Best,
Johannes

[Altrinis]

Thank you for your hints, the problem is solved.

I did make use of the submit interpreter in a manner you had suggested (counting up using built in counters so the variable isn't sent too often). It's a very simple nest of IF statements with a "heart" of a WHILE ($OUT[1]) { ... } function, so that the variable is not sent unless the extruder is running. It's a very exciting solution that gives much space for expansion.
Once the g1() function was no longer needed after every movement point, blocks of code became optimized/minimized by KUKA|prc again.

I did however encounter some odd behavior from group commands component. The issue is, grouping and ungrouping commands causes the tree to flatten or, under certain circumstance, lose null placeholders. I attach a documented example presenting what I assumed to be a bug. I have reasons to believe that Custom KRL Code Component might be susceptible to the issue as well.

Best regards,
Michael.

[Johannes @ Robots in Architecture]

Hello,

Great!
Regarding the Group question, I can see that keeping the tree structure would be convenient. That was mostly an omission by myself, but quick to fix. I'll send you a link to test via PM.
The Custom KRL component works on an "item" basis, so it should reliably keep its path. Have you come across any problems? I would recommend using multiline strings, maybe that is causing problems?

That doesn't change the behavior towards Null items, though. Null items cause problems, so they are usually filtered out. If you want to use a placeholder, I'd suggest something else.

Best,
Johannes

[Altrinis]

Hi,

Many thanks, the updated version of Group component does retain the tree structure as expected! As I work with KUKA|prc on daily basis I will thoroughly test and report if any anomaly catches my eye. Regarding the null items, I agree that the easiest way would be to replace them with custom token for the time they're processed inside KUKA|prc components.

Thank you once again, I very much appreciate your support.

Kind regards,
Michael.

[Johannes @ Robots in Architecture]

Great! Thanks for the feedback!
Best,
Johannes