+- RoboDK Forum (//www.sinclairbody.com/forum)
+-- Forum: RoboDK (EN) (//www.sinclairbody.com/forum/Forum-RoboDK-EN)
+--- Forum: RoboDK API (//www.sinclairbody.com/forum/Forum-RoboDK-API)
+--- Thread: Waiting for real robot in online programming (/Thread-Waiting-for-real-robot-in-online-programming)
Waiting for real robot in online programming-pnnayyeri-12-13-2021
Hi there,
I'm using online programming to 3D print.
I've generated RoboDK programs using the 3D print configuration module. Also, I'm using a serial connection between my computer (windows) and the extruder controller (Marlin firmware on a RAMBo board) to send G-Codes for the extruder control.
Since I need to establish a serial connection to Marlin, I've used a separate Python program to send G-Codes. Consequently, I used an 'Extruder.py' program in RoboDK to get callbacks from the RoboDK program and dump them into a database which then will be read by that separate Python program.
Now, my problem is that when I start running the main RoboDK program, RoboDK does not wait for the actual robot to finish the linear moves then send the extruder commands. This makes everything out-of-sync.
As can be seen in the attached photo, the sequence of execution of a part of the program (for one layer of a 4-segmented path) is like this: MoveL54 moves the robot to the beginning of the layer, then there's an extrusion command and MoveL55 command for the 1st segment of the path. But the problem starts when there's no wait after MoveL55, and RoboDK sends another extrusion command corresponding to the 2nd segment of the path. Once all these three commands (denoted as 2 in the photo) are executed, RoboDK waits for the robot to complete the movement and then executes MoveL56 and the 3rd extrusion command. And it continues out-of-sync like this.
My approach is to add a command/instruction before Extruder() callbacks to wait for the robot to finish the task. I used WaitBusy(), WaitMove(), and WaitFinished() methods of the Python API but couldn't implement the expected behavior.
I appreciate it if you can help me out with this problem. I'm struggling with it for weeks. it's really frustrating to be this close to printing with the Kuka robot but not do it properly. Let me know if more information is needed.
Thanks,
Poe
RE: Waiting for real robot in online programming-Jeremy-12-15-2021
Can you read my answer to your previous question before I get into this one?
Jeremy
RE: Waiting for real robot in online programming-pnnayyeri-01-04-2022
(12-15-2021, 11:00 PM)Jeremy Wrote:Can you read my answer to your previous question before I get into this one?
Jeremy
Hi Jeremy,
Thanks for your other answer.
I know the offline programming approach might be more promising. But I developed everything for online programming and there's only this problem that makes it out-of-sync.
Do you have any idea how to make RoboDK wait to complete a robot move before calling a callback function (as described in my first post)? That would instantly advance my project as I can successfully 3D print objects and move on to the next step of my research...
Thank you
RE: Waiting for real robot in online programming-Jeremy-01-04-2022
Did you understand why 3D printing CAN'T be achieved with the driver?
RE: Waiting for real robot in online programming-pnnayyeri-01-04-2022
(01-04-2022, 09:05 PM)Jeremy Wrote:Did you understand why 3D printing CAN'T be achieved with the driver?
No one ever has said 3D printing with the driver is impossible. It might not be smooth cuz of handshakes, I don't mind non-optimal results now. If this problem in the execution sequence of RoboDK is solved, why can't it be achieved? Is there any other reason that makes it impossible?
That's exactly like using a computer to run a GCode on an FDM 3D printer through a USB cable...
RE: Waiting for real robot in online programming-Albert-01-10-2022
You should be able to accomplish 3D printing, on the other hand, you may not have smooth edges due to the limited look-ahead functionality.
The most optimal results may be accomplished if you map the Extruder commands to an external axis that is managed by the KUKA controller. To do so, you should modify the SRC driver file to read the E number passed via the Extruder call and update it with your next linear movement command.
If you want to block movements you can try setting the ADVANCE variable to 0 and removing the C_DIS flag from the movement commands.