Messages

That's fantastic and much appreciated!

Kind regards,
Michael.

Thank you for the quick reply! I have only now found the time to properly test file sizes and minimization.

I can confirm that a KRL file with original size of 27.5mb caused an error "no more user memory available" when copying to R1 folder, but did not cause this error when redundant positions (only the ", A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0" fragment) have been removed. Size after the reduction was 14.6mb, so still very near the top limit.

Kind regards,
Michael.

Hello,
First of all, thank you for the hard work put into KukaPRC, it's a great tool!
I did notice that in newest version, there's one function missing that we needed most dearly: settings->advanced->code ->Reduce Filesize - Skip redundant positions.
We produce programs with high-precision toolpaths and amount of redundant positions is quite high (the external axis), enough to double the size of our code, to extents where it can no longer fit into (hard to understand) memory limits of a Kuka robot.

If you could add this setting back in the next release we would be most thankful. Until then, we will use the previous version.

Kind regards,
Michael.

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.

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.

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.

Thank You for the reply, I value Your input very much.
I'm curious of the project by Architectural Association that You have mentioned - if by any chance there's a link or reference to a research paper at Your reach I would be very glad to have seen it. 

Nonetheless, the process of equipment acquisition will take some time, I treat the current post as a "sanity check" before going further with KUKA.
I will report as events unfold.

Kind regards.

Hello,
I would be very thankful to receive Your opinion in the following matter:
We are planning to add an external horizontal axis to our current Kuka robot. It's naturally meant to be controlled with Kuka PRC.
The goal is to perform milling on cylindrical blanks (at least 1.5 m long however not exceeding more than 300kg), so precise synchronization is top priority.
After contacting Kuka, it was suggested that the KP1-MDC single-axis modular drive unit with counterbearing could possibly satisfy our needs.

1. Would Kuka PRC communicate with that equipment? Is it processed just as rotary table, but flipped sideways?
2. Do You have any better recommendation on hardware / solution (as in, to build the axis ourselves, other manufacturer etc.)?

Best regards.

I did not expect there would be such a simple and (after testing) efficient solution, many thanks.

Kind regards,
Michael.

Hi,

I managed to pinpoint the exact moment and cause of unplanned stops. It was hidden in plain sight:

Code Select Expand

LIN {X 82.582,Y 97.199} C_DIS
LIN {X 86.222,Y 93.781} C_DIS
LIN {X 90.261,Y 90.846} C_DIS
LIN {X 94.636,Y 88.441} C_DIS
LIN {X 99.279,Y 86.603} C_DIS
LIN {X 104.115,Y 85.361} C_DIS
LIN {X 109.068,Y 84.735} C_DIS
LIN {X 114.061} C_DIS
LIN {X 119.015,Y 85.361} C_DIS
LIN {X 123.851,Y 86.603} C_DIS
LIN {X 128.493,Y 88.441} C_DIS
LIN {X 132.869,Y 90.846} C_DIS
LIN {X 136.908,Y 93.781} C_DIS
LIN {X 140.548,Y 97.199} C_DIS
LIN {X 143.731,Y 101.046} C_DIS
LIN {X 146.406,Y 105.262} C_DIS
LIN {X 148.532,Y 109.78} C_DIS
LIN {X 150.075,Y 114.528} C_DIS
LIN {X 151.01,Y 119.433} C_DIS
slimak=21
;ommit
$VEL.CP=0.03
$OUT_C[1]=TRUE
LIN {X 150.136, Y 124.416, Z 44.8, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0} C_DIS
LIN {X 149.832,Y 129.25} C_DIS
LIN {X 148.925,Y 134.008} C_DIS
LIN {X 147.428,Y 138.615} C_DIS
LIN {X 145.365,Y 142.998} C_DIS
LIN {X 142.77,Y 147.088} C_DIS
LIN {X 139.682,Y 150.82} C_DIS
LIN {X 136.151,Y 154.136} C_DIS
LIN {X 132.233,Y 156.983} C_DIS
LIN {X 127.988,Y 159.316} C_DIS
LIN {X 123.484,Y 161.1} C_DIS
LIN {X 118.793,Y 162.304} C_DIS
LIN {X 113.987,Y 162.911} C_DIS
LIN {X 109.143} C_DIS

The "slimak=21" is a variable sent to extruder via ethernetIP. This causes the robot to stop for a fraction of time. What I would need is a way to send this numeric value as you can send digital output with parameter "continous". Is it possible?

By the way, I had solved the problem of sending single value through ethernetIP by using "KRL command" component from KukaPRC. I could not find any other component that could send values (the same way you have suggested with $Advance variable).

Kind regards,
Michael.

Hi,
Thank you for the reply - I forgot to mention I did set the $Advance to 5 beforehand. This is what the header of my program looks like:

Code Select Expand


;FOLD INI
;FOLD BASISTECH INI
GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )
INTERRUPT ON 3
BAS (#INITMOV,0 )
;ENDFOLD (BASISTECH INI)
;ENDFOLD (INI)
;FOLD STARTPOSITION - BASE IS 4, TOOL IS 4, SPEED IS 40%, POSITION IS A1 0,A2 -77,A3 127,A4 0,A5 -51,A6 0,E1 0,E2 0,E3 0,E4 0
$BWDSTART = FALSE
PDAT_ACT = {VEL 40,ACC 100,APO_DIST 50}
FDAT_ACT = {TOOL_NO 4,BASE_NO 4,IPO_FRAME #BASE}
BAS (#PTP_PARAMS,40)
PTP  {A1 0,A2 -77,A3 127,A4 0,A5 -51,A6 0,E1 0,E2 0,E3 0,E4 0}
;ENDFOLD
;FOLD LIN SPEED IS 0.1 m/sec, INTERPOLATION SETTINGS IN FOLD
$VEL.CP=0.1
$APO.CDIS=3
$ADVANCE=5
;ENDFOLD

Is there any abnormality?
Would it be possible that the command is not accepted by the robot?
We have a KR C4, with modern 8.3 kuka system software.

Kind regards,
Michael.

Hello,

I am trying to enhance my algorithm for single wall (corkscrew) 3d printing with an option to vary robot's speed according to length of the printed curve. Mapping went fairly easily and Kuka PRC component "linear movement" accepted the grafted data fine.

The problem is, whenever the speed changes, robot briefly stops. That's very unwanted behaviour because our extruder keeps going, resulting in a blob (the latency of extrudate would be too big to try to stop it for such a brief moment anyway)/

I have tried to adjust the interpolation settings in following ways:

• set higher interpolation value in interpolation by distance
• reduce distance between points on curves which have different speeds
• change interpolation type to "by velocity"
• tried to use spline movement component, unfortunately the file size is larger then our robot can process (we already use the "reduce filesize" option)

During the robots work, the KRC informs at the problematic point that the toolpath could not be approximated (translated from my native language).

Is there a general "blend movement" solution?

Here's a screenshot for better visualisation of the problem https://i.imgur.com/HRyiLeu.png.

Kind regards,
Michael.