Problem with lag in communications

I’ll start right off saying this problem is on my side but was hoping someone could help. Sending the gcode to the smoothieboard works perfectly fine through pronterface.

I don’t think it matters, but I’m running the firmware in 6-axis. This machine was set up a few years ago to use additional 3 motors to autoload stock into the CNC. Because of this, I had to write a special g-code sender to: A) have gcode commands to load the stock on to the table, B) send the codes to cut the stock, the C) eject the stock. The software has the option to tell it to cut X copies. The cutting is fairly simple circles so the gcode file is quite short.

I want to do a few projects on this machine that have more complicated cuts. There are tons of delays in the cutting where it is stopping on the shorter cuts like it’s waiting for commands to get queued. From my understanding, to send gcode, you just send the line, wait for an OK, and send the next. Obviously something isn’t right if pronterface is working properly.

This is done in vb.net (sorry it’s in vb!) Here’s how the com port is set up.

        SerialPort1.BaudRate = "115200"
        SerialPort1.Parity = Parity.None
        SerialPort1.DataBits = 8
        SerialPort1.StopBits = StopBits.One
        SerialPort1.Handshake = Handshake.None
        SerialPort1.RtsEnable = False
        SerialPort1.ReceivedBytesThreshold = 1
        SerialPort1.DtrEnable = True

And then the code loops through each line in the gcode and call this SendGCodeFunction. The key part is the beginning area where I send the line of gcode to the smoothie, then just wait in a loop until I get the OK back. I didn’t think it would have enough memory to just get code rammed down its neck.

I would appreciate any feedback. Thanks!

Public Function SendGCode(GCode As String) As String
Dim Response As String
If SerialPort1.IsOpen Then
readBuffer = Nothing
SerialPort1.DiscardInBuffer()
SerialPort1.WriteLine(GCode)

        Do While readBuffer Is Nothing And Timeout = False
            If Timer1.Enabled = False Then Timer1.Enabled = True
            Do While SerialPort1.BytesToRead > 0
                readBuffer = SerialPort1.ReadLine
                SerialPort1.DiscardInBuffer()
            Loop
        Loop

        If Strings.Left(readBuffer.ToUpper, 2) = "OK" Then
            Response = "OK"
        Else
            Response = readBuffer
        End If
        readBuffer = Nothing
    Else
        Response = "ALARM"
    End If

  Return Response

End Function

I can’t really understand your code, but the basic idea is: Send command, wait for “ok”, when “ok” is received, send other command. You don’t have to worry about memory at all, the protocol is there so you don’t have to ( amongst other things ).

You would probably benefit from looking at the Serial part of the source code for Pronterface or Smoopi, it’s all Open-Source so take advantage of that.

1 Like

Thanks for the reply. I stripped out all my threading code and I got it working. Of course I don’t have a kill job button since the app is basically frozen dumping info to the serial port. At least I know what to focus on. PS. looking forward to v2!

1 Like

Very cool that you got it to work. Any modern programming environment should let you have a thread to stream the Gcode and another for the interface, I’m sure if you search further you can find solutions to implement that.

1 Like

Yeah, I’m sure I can do it…it’s taking the time to do it. :wink:

1 Like

The “wait for ok after each command” method is very reliable but can limit the maximum feed rate on very short segments. Usualy this is not a problem for milling.

For situations (like laser engaving) where you want very high feed rates on very short segments you can use a method calld “fast streaming”, where you just send all the gcode-lines without waiting for ok’s. Smoothieware cares about the handshaking between his serial buffer and the serial driver on your PC. The only downside of this method is, that you will not be able to interrupt the execution of the commands from your sorftware after the gcode is sent (ctrl-x might still work). But you could connect buttons for abourt, pause, resume to the smoothieboard.

1 Like

Yes. Also note an example of fast-streaming can be found at https://github.com/Smoothieware/Smoothieware/blob/edge/fast-stream.py

1 Like