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.
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
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.
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!
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.
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.
I wanted to follow up on this as I’m still having some problems. To start, I have upgraded the firmware to the latest CNC version. I have written my on simple gcode sender too and found the sender was hanging waiting for OK at random spots. During my debugging, I’ve tried a couple of other sender programs and they were also hanging randomly. One of them even shows that it receive just the “o” before it hung.
The smoothie isn’t completely hanging since I can continue sending commands to it, but it will never respond with any kind of OK or other message once it stops returning data. The only way I can get it out of this state is to disconnect/reconnect (by the software) from the board.
I looked over the fast streaming python example. I’m not familiar with using python but it looks like it’s just dumping the GCode into the serial port and would then rely on the “hardware” handshaking? Since I don’t really care about aborting jobs I may try this. I may also try to run the file directly from the SD card which I’m assuming should work fine.
If you are getting incomplete responses you might have connection problems. I don’t think the smoothieboard is causing this. Check it with a shorter high quality USB cable or another USB port. Even try a different PC. I ofter heard that some PC’s (like older Dell Notebooks) caused USB serial problems.
