[Mad_THA]

Hello,
I am currently using RoboDK to generate programs for an Elite Robots CS612 controller and I am experiencing an issue where all generated waypoints are imported as invalid (yellow) on the controller.

System
Robot: Elite Robots CS612
Controller software: 2.13.3.0 (Build 2025-03-28)
RoboDK: 6.0.4.26866 (64 bit)
Postprocessor: Elite Robots CS

---

Problem
The RoboDK simulation is completely correct.
The generated task can be imported into the Elite controller without errors, but all waypoints appear yellow and cannot be executed.
When I manually press "Set Waypoint" on the controller, the waypoint immediately becomes valid (blue).
This suggests that RoboDK generates incomplete waypoint definitions which the controller refuses to validate automatically.

---

Investigation
Waypoint generated by RoboDK
Inside

Code:

<internalPosition>

RoboDK generates:

Code:

<jointPositions joints="..." />
<toolPose X="0.0" Y="0.0" Z="0.0" RX="0.0" RY="0.0" RZ="0.0" />

There is no

Code:

<flangePose>

entry.
Also:

Code:

<Pose key="baseToFrame">
  <Position>
    <Length key="X" value="0.0"/>
    <Length key="Y" value="0.0"/>
    <Length key="Z" value="0.0"/>
  </Position>
</Pose>

---

Same waypoint after pressing "Set Waypoint" on controller
The controller rewrites the waypoint and creates:

Code:

<jointPositions joints="..." />
<toolPose X="-176.94" Y="-694.36" Z="682.71" RX="..." RY="..." RZ="..." />
<flangePose X="-176.94" Y="-694.36" Z="682.71" RX="..." RY="..." RZ="..." />

and

Code:

<Pose key="baseToFrame">
  <Position>
    <Length key="X" value="-0.1775"/>
    <Length key="Y" value="-0.689"/>
    <Length key="Z" value="0.6977"/>
  </Position>
</Pose>

After this modification the waypoint becomes valid and executable.

---

Additional observations
The generated task already contains:

Code:

<frameReference>Basis_KS</frameReference>
<tcpToolNameReference>Tool_1</tcpToolNameReference>

and the generated configuration contains:

Code:

<Frame name="Basis_KS">
  <Transform value="-177.5, -689, 697.7, 3.141592653589793, 0.0, 0.0" />
</Frame>

as well as:

Code:

<TcpTool name="Tool_1">
  <ToolShape value="0,0,0,0,0,-1.5707963267948966"/>
</TcpTool>

So the frame and TCP information seem to exist in the exported project.

---

Tests already performed

• Generated targets as Cartesian targets
  
• Generated targets as Joint targets
  
• Changed
  
  Code:

  MOVEJ_POSITION_TYPE
  from 0 to 1
  
• Tested different TCP definitions
  
• Generated a completely new RoboDK station from scratch
  
• Imported manually created controller programs and compared XML
  

The issue remains the same.

---

Question
Has anyone successfully generated

Code:

.task

programs for an Elite Robots controller running software 2.13.x?
Is there a known incompatibility between RoboDK 6.0.4 and Elite controller software 2.13.x, or is the postprocessor missing required fields such as

Code:

toolPose

,

Code:

flangePose

or

Code:

baseToFrame

values?

Attached files

• TestStation.rdk → minimal RoboDK station containing the CS612 and 3 waypoints
  
• CS_Code.txt containing:
  KI_PR.task → task generated by RoboDK
  KI_PR.configuration → configuration generated by RoboDK
  KI_PR_from_CS612.task → same task after manually pressing "Set Waypoint" on the controller
  
• Yellow_Waypoints.png → screenshot showing all imported waypoints as invalid (yellow)
  

The manually updated task can be executed correctly, while the RoboDK-generated task cannot.
Comparing both task files shows that the controller automatically inserts additional information (toolPose, flangePose and baseToFrame values) when "Set Waypoint" is pressed.

I can provide any additional files, logs or test projects if needed. The issue is currently blocking my master's thesis work, so any help would be greatly appreciated.

Any help would be greatly appreciated, as this issue is currently blocking my master's thesis project.
Thank you.

[Raphael]

Hello,

It is possible that there was an update to the Elite software since the last update of our post-processor. With all the provided information, I believe it would be possible to update it to allow easy program generation with valid targets. Please note that this might take some time. 

Raphael

[Raphael]

Hello,

Here is the updated Elite post-processor based on your feedback, please let me know if it works correctly.

[Mad_THA]

Hello Raphael,

thank you again for the updated post processor.

I installed the provided "Elite_Robots_CS.py" restarted RoboDK completely and regenerated the same test program.
Unfortunately, after comparing the newly generated ".task" and ".configuration" files with the previous output, I
cannot see any relevant change regarding the original issue.
The generated waypoints still contain:

Code:

<toolPose X="0.0" Y="0.0" Z="0.0" RX="0.0" RY="0.0" RZ="0.0" />

There is still no

Code:

<flangePose>

entry inside

Code:

<internalPosition>

.
Also,

Code:

baseToFrame

is still exported as zeros:

Code:

<Pose key="baseToFrame">
  <Length key="X" value="0.0" unit="M" />
  <Length key="Y" value="0.0" unit="M" />
  <Length key="Z" value="0.0" unit="M" />
  ...
</Pose>

This is the case even though the generated ".configuration" file contains valid frame definitions, for example:

Code:

<Frame name="Base_Process_1" isValid="true" isVariable="true">
  <Transform value="100, -833.1, 208, -3.141592653589793, 0.0, 0.0" />
</Frame>

The only difference I currently notice in the ".configuration" output is related to the TCP rotation value, but the
 waypoint structure in the ".task" still seems unchanged regarding

Code:

toolPose

,

Code:

flangePose

and

Code:

baseToFrame

.
I will also test the files on the real CS612 controller later today, but based on the XML comparison it looks like the original issue is still present.
Could you please check whether the updated post processor is expected to generate

Code:

flangePose

and non-zero

Code:

baseToFrame

values, or whether an additional RoboDK setting is required?

Best regards,
Martin

[Raphael]

Hello Martin,

You are correct, I have accidentally uploaded the old version of the post-processor and not the updated one. I am unsure if the baseToFrame needs to be updated as the frame name is updated in the instruction. Please test it and let me know, I will gladly update it if needed.

Raphael

[Mad_THA]

Hello Raphael,

thank you for the updated post processor.

I tested the new version on the real Elite CS612 controller today.

Result:
The waypoints are still imported as invalid/yellow and cannot be executed.
I also compared the generated task files again. The new post processor now adds the
"<flangePose>" tag, but it is still filled with zero values, the same as "toolPose":

Code:

<internalPosition>
  <jointPositions joints="..." />
  <toolPose X="0.0" Y="0.0" Z="0.0" RX="0.0" RY="0.0" RZ="0.0" />
  <flangePose X="0.0" Y="0.0" Z="0.0" RX="0.0" RY="0.0" RZ="0.0" />
</internalPosition>

"baseToFrame" is still exported as zeros as well.

For comparison, when I manually press "Set Waypoint" on the CS612 controller and save
the task again, the controller writes non-zero values for all three fields:

Code:

<toolPose X="-176.945..." Y="-694.364..." Z="682.707..." RX="..." RY="..." RZ="..." />
<flangePose X="-176.945..." Y="-694.364..." Z="682.707..." RX="..." RY="..." RZ="..." />

and:

Code:

<Pose key="baseToFrame">
  <Length key="X" value="-0.1775" unit="M" />
  <Length key="Y" value="-0.689" unit="M" />
  <Length key="Z" value="0.6977" unit="M" />
  ...
</Pose>

So based on this test, the controller does not seem to calculate these values automatically
during import if they are zero. The waypoints only become valid after the controller itself
calculates and writes these values using "Set Waypoint".

Therefore, I believe the post processor needs to export actual calculated values for at least
"toolPose" and "flangePose", and likely also "baseToFrame".

Please let me know if you need the newly generated task file, the controller-resaved task file,
or any additional comparison files.

Best regards,

Martin

[Raphael]

Hello Martin,

Thanks for the feedback on this. I have updated the MoveJ instruction to now properly update the baseToFrame field. Furthermore, the way joint targets are managed internally, the post-processor doesn't receive the pose for the target. If you want to have toolPose and flangePose to be updated, you need to use a cartesian target. As of right now, I have added a check to make sure that we have a pose so please let me know if this works.

Raphael

[Mad_THA]

Hello Raphael,

thank you for the updated post processor. I have now tested the latest version on the real Elite CS612
controller. The results are very promising:

• The generated waypoints are now imported as valid (blue) waypoints on the controller.
  
• The generated test program can be executed successfully.
  
• The baseToFrame values are now correctly written to the task file.
  
• toolPose and flangePose are generated for Cartesian targets.
  
  

I also identified the source of the remaining RoboDK generation warnings. The Curve Follow Project
generated paths contained MoveJ instructions whose first targets were still defined as joint targets.
RoboDK displayed the warning:

"Joint movement using joint targets is not supported. Change the target type to cartesian."

After changing these targets to Cartesian targets, the warning disappeared and the generated program
executed correctly.

At the moment I have only tested with a simplified TCP configuration. My next step is to validate the
post processor using the actual ultrasonic cutting TCP, payload and CoG settings used in my application.

So far, the results look very promising and the controller is now accepting and executing the generated programs.

I will continue testing with the full production setup and will report back once I have completed the validation.

Thank you very much for your help and the quick support.

Best regards,

Martin

[Albert]

Excellent, thank you for letting us know the latest version works.

Please let us know if we need to add any further edits. We'll make these improvements to the Elite driver public with the next release.

[Mad_THA]

The latest version has now also been validated with my actual ultrasonic cutting setup, including
the final TCP, payload and CoG configuration.

After reteaching my process frame on the controller, the generated programs execute correctly
on the real Elite CS612 controller. The generated waypoints are imported correctly and the robot
follows the programmed paths as expected.

At this point I do not see any further issues with the post processor itself.

The only point worth mentioning is that RoboDK will generate warnings if a MoveJ instruction
references a joint target where a Cartesian target is expected. Defining the corresponding
targets as Cartesian resolves this, so this is more a programming/modeling requirement than
a post processor issue.

From my side, the post processor is now working well for my application.

Thank you and Raphael again for the excellent support and the quick implementation of the
required changes. I really appreciate it.

Best regards,

Martin