Smoothieboard doesn't work?

[sir-buckyball]

report from Chrome Web Store: Hi! I have smoothieboard running a cnc mill. Your software is great, but the only problem i have is that when i have sen't the code the mill will stop after a few lines and i have to manually press "Stop waiting for OK". Is there a way around this? I don't know if it's your app or the smoothieboard but the gcode is running ok on repetier for example.

Application version: 2014.10.17.0 Client version: 5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36

[Prime-Eight]

a laser plotter i have running custom firmware that ran great , just started doing same as the OP . my symptoms are the same . the firmware was made to match what this app used to send .

i also see the preview window is not rendering file correctly now and older .nc and .txt gcode files that once render perfect now fail to render correctly . it is as if it getting G00 and G01 confused.

app version : 2015.9.7.0 Chrome on W7 .

[sir-buckyball]

Prime-Eight: Can you provide a sample file which demonstrates the errant behavior so I can test against it.

What rendering difference do you expect between G00 and G01? G01 is a linear interpolation to an absolute or relative point (eg., a straight line drawn). G00 is "rapid move" which tells the machine to move to a point as fast as possible. Most cartesian machines move the tool in a straight line for this comment, though at a different acceleration curve (same rendering). The machine controller however is allowed to move the tool as fast as possible for that machine (eg., it could use a manhattan path and that would be valid). I made the arbitrary decision to render rapid moves as a dashed straight line.

If you've noticed the change that was pushed on Monday, the code will now wait for an 'ok\n' after sending a carriage return character (\r). Previously it would not treat those lines specially, which resulted in buffer overruns on some machine controllers.

[Prime-Eight]

ah , my custom firmware was built to your old specs , it was only sending a 'ok' , as some other home brew CNC 's dont append the OK witha '\n' , i bet that solves the stopping issue.

re render , sorry it not the G00 and G01 specifically , it that it renders solid lines and dotted lines in ways it never . + plus it seems now when it hits a unrecognized command, it halts trying to render vs how it used to just ignore.

• it needs a option to skip over unknown commands , possibly just warn but not stop processing .
  example the '%' char used to just trigger warnings , but it would be skipped past and sender would render what it could. Now it halts as if nothing else in the file. again these file used to render and be sent fine to my laser.

and when it does render now ,render wise , this now just renders as tool moves , like rapids, it used to render solid frames with the rapids dotted . ( generated by SolveSpace Cad ) G00 X38.01 Y0.75 G01 Z-0.20 F6001.00 G01 X38.01 Y27.75 F6001.00 G01 X1.01 Y27.75 F6001.00 G01 X1.01 Y0.75 F6001.00 G01 X38.01 Y0.75 F6001.00 G00 Z5.00 G00 X33.01 Y7.75 G01 Z-0.20 F6001.00 G01 X6.01 Y7.75 F6001.00 G01 X6.01 Y22.75 F6001.00 G01 X33.01 Y22.75 F6001.00 G01 X33.01 Y7.75 F6001.00 G00 Z5.00

that the smallets example i have the the preview look wrong but still renderrs somethign vs what it used to. the render used to detect the changes in Z as tool up and down . seems not to now.
any how i will update my firmware to be sure it is sending a full 'ok\n' .

my yt video here shows the gears render correctly , now they just render as rapids in the correct shape . ( generated by InkScape plugin ) https://www.youtube.com/watch?v=t3mBGVfjdxE

code pad of that g code as it long : http://codepad.org/oEcnmcmJ

hope this helps . I will check what happens in my firmware regarding the old 'ok' vs 'ok\n' update : seems my firmware is sending a '\n' any how . Serial.println(F("ok"));
must be something comming form the sender that halts my, and other parsers . just looking again , println() puts a CrLf at the end 'ok\r\n' . hmm . i will test something .

[Prime-Eight]

think i found why some CNC stop on first file streamed move command. some CNC only look for a new line chr to trigger command received , see this from my firmware : if(c=='\n') { // entire message received ... where c is the last char in from serial.

im testing a small change in my parser , but it seems your no longer sending the '\n' in your streamed form file commands.

yep , you jog commands work fine as they put a '\n' at the end , but commands streamed from file only have a '\r' on the end vs what ever you used to have . That will be why some CNC machines will hang on the first line of from file streamed g code, as they are waitting for a '\n' that never comes. suggest you make sure file streamed g code ends with '\r'+'\n' or such , or put a small EOL option in setup page . some CNC seriously skip '\r' that come in only looking for '\n' .

i can hack my firmware , as it was written to work with your previous version specifically , as it was the cleanest sender.

~ just need a option to skip unknown commands in gcode (like the comments and block start and end some use ) , and sort the render out , so it looks how it used to .

so to fix the g code file streaming i made it so '\r' and '\n' can trigger a command received state . see here : http://codepad.org/8uC302dm

thanks .

[sir-buckyball]

So for another bug, the '\r' character was used alone without an '\n' to represent repeating the same command with different parameters. Do your files use "\r\n" between lines instead of just "\n"? I think windows machines still do that. I'll try adding a test for that later tonight when I have time to dig into this.

Thank you for sending all of this information. It will be useful.

[Prime-Eight]

yep , windows uses CRLF or "\r\n" between lines.

np , i was just having a look in your src . I have never built for Chrome , and mainly use c/c++ , so java is not too hard for me to read.

what i can tell you is , according to NotePad++ windows text EOL is CRLF . you app , sends only a '\n' at the end of your GUI button generated commands , and that's fine , and works with most CNC i think , but text streamed from file , is only terminating with '\r' now . i can re-code and upgrade my firmware , but others might not be able to edit their CNC controller.

it could be best solution to allow user to set EOL option for commands sent to CNC , and and option to warn your app what EOL format their files use .
something like the radio buttons some terminal apps have . then you stay pretty OS friendly .

and the ability to skip unknown commands , and continue parsing for the render , but still pass the file as it is to CNC will be very helpful for continuing to support many g code formats or flavors if you will . I like that is warns , but not that the render now aborts on first "%" it sees , or such . some times inkskape plugins and other g code generators use "%n" for block and cycle sections.

im going to test EOL conversion on my g code to just '\n' and see if the make the renders work . yeah it seems if i use notepad++ to change the EOL of the Gcode files to just a '\n' its renders ok .

so possibly have have a option for user to set the EOL format of their file system. Then you only need to filter/convert it out once on load . but i do suggest allowing users to select the termination of commands sent to their CNC controllers.

! im going to test if it still hangs on unknown commands when the EOL is convert to UNIX/OSX style. Yep , if i convert to UNIX EOL format ( that's "\n" only ) the render works fine and skips unknown commands.

so for now i can just load in NotePad++ and convert the EOL to UNIX/OSX format . but other users may still need the option to set the EOL your app sends commands with .

[sir-buckyball]

I've just pushed the 2015.9.9.0 release (takes a few hours to propagate) which should hopefully fix your problems. Please let me know (or file new bugs).

The fix was to properly handle '\r\n' sequences and not confuse them with stray '\r' characters. The confusion bled into the rendering because in the presence of a command ending with \r, the code would copy the command assuming the next line wouldn't have one (kept the code simple).

There's a test for '\r\n' sequences now, and I checked that the raw file from http://codepad.org/oEcnmcmJ renders properly.

[Prime-Eight]

i'm stuck at work now , but i will test when i get home .

cool i'll test all my old files render well as they did originally . I expect so .

[Prime-Eight]

Works good on even my most complex files now , and some how its streaming faster to/with my laser .(that speed increase will need to confirm , but it feels faster ) any how here is pic of it talking fine and looks cleaner .. in the console. this is at the start of gcode stream and early in this shot . this is one of my more complex shapes, full of arcs and lines. i just cut out part of the render page , but you can see its fine again .