Having successfully updated my INTERFACE to 1.43 and 1.45, I am now a bit confused as I try to load GCODE files via the USB. I have been generating my GCODE files via SketchuCAM because the DXF export from my CAD does not appear to play nicely with the Openbuilds CAM solution. I have successfully run my 1010 using this GCODE from CONTROL on my HP laptop for several files now. However, if I disconnect the laptop and boot up the INTERFACE to run the system, when I attempt to load the same files into INTERFACE, I get an error that says a character of some sort makes the GCODE un-runnable. Here's the file header and first few lines: % (Generated by SketchUcam V1.5-0803db9) (File: 1010_EPP_Clamp.skp) (Bit diameter: 1/8") (Feed rate: 30"/min) (Plunge Feed rate: 20"/min) (Material Thickness: 1/2") (Material length: 27" X width: 27") (Overhead Gantry: true = Conventional Cut) (Multipass enabled, Depth = ~ 1/16") (RAMPING with no angle limit) (Plunge Depth first) (Optimization is ON) (Arc Feedrate scale is ON) (www.PhlatBoyz.com) G90 G20 G49 G17 F20 G53 G00 Z0.0 G00 X0 Y0 M3 S15000 G00 Z0.5 So, my question is, what do I have to change in the GCODE file to make it acceptable to INTERFACE?
Try removing the % sign at the top of the file. Its not valid gcode. Control auto removes it. We had to update the Fusion 360 post processor to remove it as well.
Interface just sends it along, untouched. Grbl dislikes the "%" in the first line. "%" is not a accepted GCODE command It's a remnant from when CNC machines ran on tapes and was used as a start and end of file indicator We do "filter" out common mistakes like that in CONTROL, but Interface cannot filter the gcode, just doesn't have the resources, it would expect the files to only contain valid lines (gcodes, commands, comments) so Grbl gets what it needs For now, please edit it out And tagging @David the swarfer can we get that out of SketchuCAM too please
Thanks! I had seen references to the % for the Fusion 360 but didn't know it applied to INTERFACE as well.
Just to re-iterate, but Interface, really doesn't play into this. Interface takes the file off the USB drive, reads the first line into memory, and directly sends it over to Grbl. Grbl does what it has to (run, or error) and returns the result (an OK, or an Error). Interface then checks, if it got the OK, it sends the next line, or if got an error, it displays it on screen. Interface does not check, change, or care about the characters in the file. It is GRBL that sends the error, because Grbl does not accept the character because its not in the GCODE Spec
Got it. Good thing that there are people who have this straight because coming into it from outside can get twisty with the details of what influences what.
