grbl stops at some CamBam-generated gcode

Post Reply
pmodiano
Posts: 60
Joined: Mon May 06, 2013 11:09 pm

grbl stops at some CamBam-generated gcode

Post by pmodiano » Mon Nov 11, 2013 5:28 pm

I have been trying to make an enclosure for my Shapeoko electronics and I have run into a snag. I created the box shape using inkscape with the T-slot Boxmaker extension. This is what it looked like in Inkscape:
11-11-2013 12-08-54 PM.png
11-11-2013 12-08-54 PM.png (72.65 KiB) Viewed 2558 times
I then saved it as a DXF (the only format common to Inkscape and CamBam) and loaded it in CamBam where I reoriented it, added some things and removed some things. When I started the cutting job it started out alright but when it got to the 3mm holes, it would travel, plunge start the hole but then eventually the X, Y and Z axis would stop moving, even while the gcode sender would be scrolling furiously (like it does when the computer loses connection to the Arduino). If I click stop on the gcode sender and then try to tell it to move X, Y or Z it does not do so. $ still shows settings but movement seems to be disabled by something in the gcode while cutting out that 3mm hole.
11-11-2013 12-12-45 PM.png
11-11-2013 12-12-45 PM.png (42.57 KiB) Viewed 2558 times
I do note that CamBam recognizes the circle as a polyline. The profile settings are ordinary enough and identical to one that cut another shape properly: 1.5875mm tool diameter, .5mm depth increment, -7mm target depth, etc.

Having tried this several times, I am convinced that grbl is becoming movement-disabled by something in the gcode that is generated but what and why, I don't know. Attached is the gcode starting out creating the "hole of grbl death":
box-300-100-bottom-sidesB.zip
(72.34 KiB) Downloaded 84 times
Any insight into what is causing this failure would be very much appreciated.

Thanks,

Paul.
Shapeoko #1075 1000mm y axis, 500mm X axis, Dual Y motors, ACME screw Z axis upgrade, DW660. http://machinesonthemind.blogspot.com/

pmodiano
Posts: 60
Joined: Mon May 06, 2013 11:09 pm

Re: grbl stops at some CamBam-generated gcode

Post by pmodiano » Sat Nov 16, 2013 2:15 am

Okay. I was barking up the wrong tree. There was nothing in the gcode that was causing the problem. The problem was that my computer would disconnect from the Arduino/grbl at varying points. This only would happen during the slow time where the CamBam-interpretation of the DXF file would render a circle-shaped polyline that was composed of a gazillion gcode lines.

So my latest theory is that there is some kind of latency/flow control issue where many micro moves, executed so quickly would mess up the job. Everything worked right before the gazillion line gcode holes started cutting.

So my question to you more experienced users are these:

1. Might it be better to lower the baud rate between my computer and Arduino? (now the fastest)

2. What other issues might cause disconnections (USB cable length?, interference?, static electricity?, what else? it was working fine before those holes.)

Thanks in advance,

Paul.
Shapeoko #1075 1000mm y axis, 500mm X axis, Dual Y motors, ACME screw Z axis upgrade, DW660. http://machinesonthemind.blogspot.com/

Improbable Construct
Posts: 997
Joined: Tue Apr 10, 2012 3:21 am
Location: Fairhope, AL
Contact:

Re: grbl stops at some CamBam-generated gcode

Post by Improbable Construct » Sat Nov 16, 2013 2:25 am

I am not an expert in this but as a quick answer:
Interference in the USB cable has caused many people problems.
Try to keep the USB cable as far from other wires (power and especially the stepper motor wires) as possible.
A good quality shielded USB cable and/or ferrite magnets may help as well.
You could also try converting those circles to bezier curves or circular arcs.
I don't know how your software would feel about those options though.
This may or may not help but its a place to start.
cvoinescu will probably be able to give you a better answer, but its after midnight in England...
Shapeoko #Classified some of the bolts may be original parts.
Shapeoko 1 # ???? Stainless plates, still in the box.
Shapeoko 2 # 3926 not stock
Shapeoko 3 # 0003
Store:
http://ImprobableConstruct.com
Twitter:
https://twitter.com/ImprblConstruct

pmodiano
Posts: 60
Joined: Mon May 06, 2013 11:09 pm

Re: grbl stops at some CamBam-generated gcode

Post by pmodiano » Sat Nov 16, 2013 3:03 am

Thanks IC, as always.

Just what I think I have a handle on predictability of a process -- whether it be CNC milling or 3D printing -- another variable injects itself into the process to collapse my hubris.

Another weekend, another family-excusable chance to spend time figuring this stuff out!

Paul.
Shapeoko #1075 1000mm y axis, 500mm X axis, Dual Y motors, ACME screw Z axis upgrade, DW660. http://machinesonthemind.blogspot.com/

DanMc
Posts: 257
Joined: Fri Apr 13, 2012 3:34 am

Re: grbl stops at some CamBam-generated gcode

Post by DanMc » Sat Nov 16, 2013 3:16 am

As IC was suggesting, CamBam may not be outputting the circles as arcs but as a series of tiny lines. I just checked a file I ran today, 5.5mm holes about 3mm deep and it took less than 20 lines of code. If thats the case, what I have done on occasion is just to put a locus at the center of the circle and redraw as a circle in CamBam. Not sure if that is what is bogging your machine down but could be something to try. You can see if the gcode contains arcs by perusing for G2 or G3 lines

cvoinescu
Posts: 4442
Joined: Thu Jul 19, 2012 6:50 pm
Location: Camberley, UK
Contact:

Re: grbl stops at some CamBam-generated gcode

Post by cvoinescu » Sat Nov 16, 2013 10:33 am

I'm not aware that there is any inherent problem with sending lots of tiny moves to GRBL. In my experience, it's about as likely to die at any point in the G-code, but if arcs are 90% of it, it's very likely to die during an arc. Reducing serial speed does not help -- the problem is in the USB side of things, not serial, and that runs at a fixed speed (12 Mbps). A better USB cable routed away from sources of noise helps, and for some people that cured the problem completely. I had to use optical isolation (optocouplers) to get it to work -- once there was no electrical connection between USB and the machine (not even ground), there were no more interruptions, even reverting to the original crappy unshielded long USB cable. Another idea is to skirt USB completely and use an actual serial port connected to pins D0 and D1, but you need a USB-to-TTL level translator (MAX232 IC). At 9600 bps, RS232 is good for at least 5 m, and fairly immune to noise (several of the terminals of the DEC PDP-11M clone we had in high school were more than 30 m away, and they used 9600 bps RS232 -- admittedly over good quality shielded cables).
Proud owner of ShapeOko #709, eShapeOko #0, and of store.amberspyglass.co.uk

pmodiano
Posts: 60
Joined: Mon May 06, 2013 11:09 pm

Re: grbl stops at some CamBam-generated gcode

Post by pmodiano » Sat Nov 16, 2013 2:19 pm

it's about as likely to die at any point in the G-code, but if arcs are 90% of it, it's very likely to die during an arc.
cvoinescu, That is undoubtedly true. This gcode file has over 10,000 lines, many thousand unnecessarily dedicated to a couple of small holes consisting of a multitude of tiny lines, as DanMc suggests.

I will go out today an buy a shorter, better shielded USB cable and start from there.

My plan is to finish this enclosure and stuff it with the Arduino/grbl connected by a very short USB cable to a Wifi-enabled Raspberry Pi, on which I have installed a gcode sender and XRDP, allowing me to remote into it from any machine or tablet.

I'll report on the results of using a shorter/better shielded USB cable.

Thanks for the advice.
Shapeoko #1075 1000mm y axis, 500mm X axis, Dual Y motors, ACME screw Z axis upgrade, DW660. http://machinesonthemind.blogspot.com/

pmodiano
Posts: 60
Joined: Mon May 06, 2013 11:09 pm

Re: grbl stops at some CamBam-generated gcode

Post by pmodiano » Sun Nov 17, 2013 2:12 pm

Okay, I replaced my cheap USB cable that was touching many areas of the power cable and transformer with a fancy, overpriced, well-shielded USB cable, carefully routed to avoid proximity to power sources.

The results were the same: it tries to spit out around 2000 lines of gcode to make a 3mm hole before grbl disconnects. I tried it several times with identical results.

I am now starting to believe that the disconnection relates to multitude of tiny gcode steps that constitute that profile cut.

My next step will be to do as DanMc suggests: replace the 3mm hole polylines with CamBam circles. Let's see what happens then...
Shapeoko #1075 1000mm y axis, 500mm X axis, Dual Y motors, ACME screw Z axis upgrade, DW660. http://machinesonthemind.blogspot.com/

pmodiano
Posts: 60
Joined: Mon May 06, 2013 11:09 pm

Re: grbl stops at some CamBam-generated gcode

Post by pmodiano » Mon Nov 18, 2013 12:24 am

DanMc, your suggestion was successful. I replaced those trillion-line polylines with circles. The gcode size dropped to 1/10th. Best of all, everything was cut properly (for the most part - but that's another post). Now I know what to do with future CamBam-interpreted DXFs.

Thanks to all!

Paul.

P.S. I will document my entire grbl/Raspberry Pi electronics setup shortly for those who are interested.
Shapeoko #1075 1000mm y axis, 500mm X axis, Dual Y motors, ACME screw Z axis upgrade, DW660. http://machinesonthemind.blogspot.com/

Post Reply