Hi all I'm having a problem with recurring ERROR 33, mainly when doing pocket cuts. The first few times I can get through it with "Pause" then "Play" and the program resumes no problem. I've read this is a problem between the details int he drawing file and the CAM file, which is then translated to G-Code which "doesn't make sense" to the controller, so it creates an error warning. Is this the case? If so why does "Pause" and "Play" work sometimes and not all? My workshop is hot. Could it be the blackbox overheating and not processing things fast enough? Similarly, I don't have my blackbox cut off from the general dust in the workshop (i.e. in another sealed container, or PC case like many of you do). Could this be something causing an issue with the black box? All ideas welcome, I'd love to be able to trust my machine is going to cut through a whole program! thanks
Are you using the right post: Fusion 360: grbl post processor install (the easy way) Autodesks Grbl post has issues with incorrect decimals in Arcs
please give me your drawing and tell me which toolpath is the problem so I can figure out what is going on in the post.
Thank you thats very kind. I made so many changes and updates to the tool paths to get the job finished it would be a nightmare to go through. When I get the error the next time I'll send everything over to you before I make my changes. I do however have a theory that it is due to a straight cut bit catching and causing the spindle to be in a different position to the one it thought it should be in to start the Arc. I didn't get the problem before I changed the bit to a straight cut. I'm going to do some testing today with an uncut spiral and see where I get to. thanks
naaa, steppers motors dont know where they are. this is an internal error generated when the arc definition is faulty. Gcode arcs are defined as a 'move from here(1) to this new point(2), anti or clockwise direction, with the center over there(3)' g0 x2 y2 ; (1) the current point G3 X4 Y4 I2 J0 ; arc to the end point where X4 y4 is (2) the new point and I2 J0 is (3) the definition of the center point as offsets from the start point since i have just guessed at the above values that code will most likely throw an error 33 since the distance from the center point to the two end points differs, which is what the controller is detecting. GRBL can be very sensitive to the resolution of the Gcode. in inch mode, 3 digits (thousandths) will not be enough precision to properly define some small arcs which is why my post outputs 5 digits IIRC. probably the easiest thing you can do is increase the size of all your "lead in" and "lead out" arcs. anyhow, if i have the fusion file i can generate the gcode and then run it through GRBL in test mode to find the faulty arc, and then work backwards to figure out why it was generated in the first place.
Thank you. Here is one just file. Its a series of pocket cuts on the right most "Flat:1" layout of the unit. I used to set up one pocket cut and one contour cut and hope to cut the whole sheet. But since the errors started I made smaller files to be able to run the next set while I was editing the first file and removing the parts which were correctly cut. I can't remember where the error occurred, but I had to run this file 3 times to get it through to the end! (in fusion the file corresponds to "setup4 - 2d pocket 5" but I have since removed most of the holes to get the final one cut!) I hope that is all you need, if not let me know and I'll fire it over. This is very kind of you, thank you
hohum, no errors here, neither in your supplied .nc file nor in the one I generated from that operation. Did you change any GRBL settings like these ones? $11=0.020 ;Junction deviation, millimeters $12=0.002 ;Arc tolerance, millimeters those might affect the internal checks of the arcs though I don't see any really small arcs in the gcode.
then the other place to look is the fusion post. there are settings for minimum arc radius and minimum arc chord. They interact, they must not be too small, they cannot be 'just anything' (-: Make sure you have the latest version of the post swarfer/GRBL-Post-Processor Here are the defaults These are the values I settled on when debugging the post. Fusion loves to output really small arcs, even smaller than the resolution of the common hobby CNC machines! These values cause it to output straight lines instead of arcs for things smaller than these values. However, we are not sure if both things have to be smaller or just one of them, a lack of documentation has lead to ignorance (-: My notes to myself say "...set EITHER minimumChordLength OR minimumCircularRadius to a much larger value, like 0.5mm" I had the most trouble with vertical arcs used as lead-ins, the default formula is a (small) percentage of bit diameter, so the smaller the bit, the smaller the lead in arc, and they get rediculousley small If you are really at your wits end with a project that needs to get done then you can edit the post itself and prevent it ever outputting an arc command, every arc will be converted to a series of straight lines. line 51 allowedCircularPlanes = (1 << PLANE_XY); can become allowedCircularPlanes = 0; which will prevent any and all arc commands.
Great thank you. I did have a play with those settings, but I believe I made them smaller. I'll try and make them larger as you suggest. I hope to get some machine time tomorrow and work through this. Cheers Ben
Mr Error 33 has come back! files attached. The first ramp in on this .nc file also happened in the wrong place. I'm using a spiral uncut bit at the moment. Its a cool rainy day here, and machine only been running 15 minutes. So not overheating or anything. I don't have my dust vac earthed like some say I should, but my USB cable is at least 30cm away from my dust vac... so should be no interference. I"m using a 2014 macbook Pro 15 (was a beast in the day, still pretty good now). When I run open builds "control" and keep working on the computer sometimes the machine stops. Often this is fixed with a "pause / play" solution. But in the past after "pause / play" twice it would often lead to an error 33... don't know if its linked. Many thanks for your help Ben
You are literally 30 (hehe counting internal release numbers too, but still) versions behind (; screenshot shows you are on 1.0.207 We are on 1.0.237 already: OpenBuilds/OpenBuilds-CONTROL Please try to stay up to date Else we end up chasing tails on outdated versions while we test on the latest versions on this end.
Wow, you guys work hard! I only installed the program a few months ago. Sadly, I still have the same problem, even with the new control. Have you also update the Fusion plug-in? Same files, but it got further this time.
Check the git log: swarfer/GRBL-Post-Processor (last commit was sept 2019) But thanks for updating, just helps as you never quite know unless you are both testing on the same versions Did you run it through a machine-off Check Mode (see gnea/grbl) run ?
Thanks for your quick reply. Just did a check mode, everything comes out ok I believe. (see screenshot) Would you recommend doing that every time I generate a new NC file? Any other ideas?
so now you need to search that .nc file for that pair of lines, namely. Code: G1 X307.877 Y-334.554 G2 X308.196 Y-334.873 Z-11.5 I0 J-0.319 that tries to draw an arc that is 0.319 in X and -0.329 in Y and 0.319 in radius. that is really small. check those arc limits again please. if that same file succeeds in check mode then the file is ok and the USB communication is failing (which tends to send false numbers, so we think it sent the numbers shown but the microcontroller got different numbers). this is ALWAYS electrical noise <-: separate the USB cable from the motor and PSU wires. and for good measure separate the home switch wires from everything else. swap the USB cable for a good quality shorter cable. does the mac power brick have a 2 pin plug that can go in either way round? if so, try it the other way round. power bricks can be some of the electrically noisiest things in the house (I used to work in audio production, you don't want laptops anywhere near your microphone cables!) I just tried those 2 lines in a small file and got this... I reduced from 300 and sommat to 100 and sommat to speed up execution, it is the same arc though [18:05:56] [ GCODE Parser ] GCODE File Loaded, please wait while we render a preview... [18:05:56] [ GCODE Parser ] GCODE Preview Rendered Succesfully: Estimated GCODE Run Time: 00:00:31 [18:06:02] [ G21 G90 G17 ] ok [18:06:02] [ M3 S1000 ] ok [18:06:02] [ G1 z-10.0 f500 ] ok [18:06:02] [ G1 X107.877 Y-134.554 ] ok [18:06:02] [ G2 X108.196 Y-134.873 Z-11.5 I0 J-0.319 ] ok [18:06:02] [ G0 Z1 ] ok [18:06:35] [ M5 ] ok [18:06:35] [ m30 ] [MSGgm End] [18:06:35] [ m30 ] ok so, no problem there, must be the USB (dont forget to make sure that the uSB port is not going into power saving mode)
Thank you for your help. I didn't want to say this before doing it a few times, but I think the problem has gone! I've got the CNC running on an extension cable from another power circuit. Turned the power brick around and added another Ferrite block to the USB cable which came with the black box. I've cut about 5 hours and not had an error 33. thank you very much, you have brought a big smile back to my face!
