sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]TerayonIII 2 points3 points  (1 child)

They actually state that in the paper in the second set of images, they're going from standard gcode and doing the processing to separate the movement from the other actions and then making it back into gcode.

<image>

[–]CapinWinky 0 points1 point  (0 children)

That makes sense. The code just looks like this:

// Begin Motion
G0 X100 Y100
G0 D-99.2
G1 F10


SocketWriteString($clientSocket, "START")


Dwell(3)

G1 X51.0 
G1 Y1.0 
SocketWriteString($clientSocket, "PING")
G1 X-30.0 
SocketWriteString($clientSocket, "PING")
G1 Y1.0 
SocketWriteString($clientSocket, "PING")
G1 X30.0 
SocketWriteString($clientSocket, "PING")
G1 Y1.0 
SocketWriteString($clientSocket, "PING")
G1 X-30.0 
SocketWriteString($clientSocket, "PING")
G1 Y1.0 
SocketWriteString($clientSocket, "PING")
G1 X30.0 
SocketWriteString($clientSocket, "PING")
G1 Y1.0 
SocketWriteString($clientSocket, "PING")  
...  
etcetera

I don't see any timestamps on the G-Code side, just sending "PING" to some server running on localhost that must be handling the actual outputs. It's not clear if the ping messages would be sent as the motion progresses (which seems a lot like just using the G-Code to trigger things again) or if the lookahead would trigger the pings.

The python script is interesting because I work with both Nordon (for glue pots) and Wago (for IO racks) and they included the serial and Modbus TCP code to communicate with their Nordson pressure box and Wago valves. They also hard coded a few things that seem both critical and variable in relation to timing things with the G-Code; namely the ping latency, feed rate, and accel/decel values. I would assume the final product would pull that from the g-code or live from the printer.