Streaming Gcode over Ethernet

Controllers Smoothie
1

Hello Makerforum!

Question: Is it possible to make Smootbieboard execute commands in real time that were sent over Ethernet?

Problem: Smoothieboard seems to collect a number of commands before executing them.

Background: I’m trying to make a 3D printer-attachment for a Universal Robots UR10 arm. The robot controller runs a script that moves the printer head. With every move, the robot controller sends a Gcode command to Smoothieboard to control the extrusion of the plastic. In this setup, Smoothieboard follows the timing of commands set by the robot controller by executing the Gcodes in real time.

To test if this workflow is possible, I made a test-script that runs on the robot controller. It opens a Ethernet (telnet) socket connection and sends relative extrusion commands to Smoothieboard. During the first 7 loops nothing happens, regardless of loop speed. On the 8th loop, 7 extrusions are executed on Smoothieboard. The extrusion motor spins 7 times. If I re-run the script, the same pattern repeats itself over and over. If I make the script run 7 times or less, nothing happen, even when running the script multiple times.

It seems related to the following topics, although I’m not sure it’s the cause of the problem.

  • uIP (micro IP) delayed acknowledgement, although here they’re talking about a time delay rather than the problem I described above.
  • The $J command. This command allows to bypass the queue, but it seems to be limited to motion on the XYZABC axes.
  • Command queue.
  • planner module lookahead. I didn’t find a way if it was possible to disable the lookahead function. I’m not sure if lookahead is even used for the extrusion motor.

Here is the test-script: (dashes instead of tabs)

Beforestart
——connection=socket_open(“192.168.185.222”,23)
——Loop connection=False
————connection=socket_open(“192.168.185.222”,23)
————wait: 0.5s
Robot Program
——Loop 8 times
————Wait: 0s
————Socket_send_string(“M83 G1 E3 F2000”)
————Wait: 0
——Halt

Does someone know in what direction I should look?

Thank you for your time!
Elias

2

I did 2 more tests:

1: To see if I could repeat the problem with a different workflow, I used Pronterface to send commands to smoothieboard over Ethernet. Each command had a delay of a fraction of a second, but there was no piling-up of commands going on like it was the case with sending commands from the robot controller. Enabling or disabling the setting ‘TCP streaming mode’ in Pronterface seemed to make no difference.

This made me believe the piling-up of commands must happen in the robot controller.

2: I used SocketTest to listen to the Ethernet socket connection, again on port 23.
Even with a single run of the script on the controller, the string came through:

M83 G1 E2 F2000> Client closed connection

The message appeared with a delay of over a second, but it showed that the robot controller definitely sends out each command like it should. The message about closing the connection happens after the script terminated.

When I connected pronterface to socketTest to compare the message formatting with the robot controller (I had to answer yes on SocketTest to fake make pronterface think the ‘3D printer’ was online), the commands appeared in exactly the same formatting as the ones from the robot controller.

Now I’m confused why commands from pronterface arrive and are interpreted live, and commands from the robot controller will only be executed when sent in batches of 8 or more.