I think we asked before, but just double checking. These are genuine Arduino's (TM) - not ebay specials (might not have standard firmware on the 16u2 if it came from some unofficial channel) https://docs.arduino.cc/retired/hacking/software/DFUProgramming8U2/
I have a genuine Arduino Uno R3 purchased through Amazon, I suppose it could be counterfeit though ( I also have a Elegoo clone clone that I have been using lately too if that matters) Both do exactly the same thing. FWIW- I just ordered another Official Arduino Uno from Amazon- with the seller listed as Arduino. I will be here tomorrow morning. so I'll try it when it comes.
Didn't think about that- I'll see if the "official" R3 works, but I have my doubts that it will change anything
What are you changing? Ps, for steps per mm, forget decimals. Its Steps per mm. Step being the lowest physical increment the machine can move. Decimals are handled by piling them up until they add up to a full step then added to the planner, so not increasing accuracy.
I am using integers for steps/mm. I need 40 for my machine on X-axis. I was able to get it to run w/o error when I changed the X-axis steps/mm to something greater than 91. The reason I tried non-integers was to see if it made any difference once I got it to run without error 33. I just kept dividing the difference between where it worked and where it didn't in half until I got the two numbers I cited earlier. I also, just reprogrammed the 16U2 and while it already had the latest firmware in it, I flashed it with the latest firmware again per the last set of links you provided. No difference in operation. About a week ago, I also hand edited the gcode to command a G0 with an X and Y that are equal to where the last X and Y were. I placed this G0 right before the G3 command that errors out. I just repeated that and it still results in correct operation. I tried inserting a G4 dwell, thinking it might need a longer dwell after the G38 probe, and that made no difference. The only thing that results in no Error 33 has been repeating the last G0 command after the G38 and before the G3. That fixes it, but that is not an acceptable fix if I make something more complicated than a few pierces.
I took the 1010 default grbl settings and changed them to match what the machine I built calls for. (the file I've posted earlier runs fine with the default grbl settings the 1010 machine loads.) So after loading the grbl settings for the 1010 machine I carefully went back and changed those settings that are different for my machine to match my machines' needs. Now I did it one setting at a time, each time rerunning the gcode, until I finally determined via trial and error that only the X-Axis steps/mm causes the error 33 ( at least with the gcode posted earlier) So my conclusion is as of this moment, there is something about having the grbl setting for X-Axis scale factor < 91 that causes the error to occur- again, I need 40 in $100 for my machine to scale properly. I hope that all makes sense now- if you look at some of my earlier posts you can see the grbl settings my machine uses. I doubt it will help, but I should have another Arduino Uno R3 sometime tomorrow to give me more hardware to try
Our Acros runs around that low too (high speed belt drives) OpenBuilds-CONTROL/app/js/grbl-settings-defaults.js at f3c9b79ecdea7bac5a151a3fbd776d5272162c6d · OpenBuilds/OpenBuilds-CONTROL So maybe test with the Acro profile Are you JUST changing Steps per mm? I am more asking about advanced settings like arc tolerance etc. The stock profiles work, so question is whats the change. Post a failing Grbl Settings backup, i can load it on a Blackbox here for a test?
There are several differences between the default 1010 settings and my machine. namely: $3 I have 5 1010 has 4 This sets the direction of x,y& z $23 I have 0 1010 has 3 This sets homing direction $24 I have 25.000 1010 has 100.000 Homing feed rate $27 I have 2.000 1010 has 5.000 Homing pull off distance $100 I have 40.000 1010 has 199.100 X Axis steps/mm $101 I have 10.000 1010 has 199.100 Y Axis steps/mm $102 I have 200,000 1010 has 199.100 Z Axis steps/mm $110 I have 5000.000 1010 has 2500.000 X Axis Max Rate $111 I have 5000.000 1010 has 2500.000 Y Axis Max Rate $112 I have 1000.000 1010 has 2500.000 Z Axis Max Rate $121 I have 1000.000 1010 has 150 X Axis Max Acceleration $122 I have 1000.000 1010 has 150 Y Axis Max Acceleration $123 I have 1000.000 1010 has 150 Z Axis Max Acceleration $130 I have 1000.000 1010 has 810.000 X Axis Max travel $131 I have 1000.000 1010 has 730.000 Y Axis Max Travel $132 I have 100.000 1010 has 90.000 Z Axis Max Travel All other grbl settings are the same between my machine and the 1010 defaults For completeness: My Machine's grbl settings : $0=10 ; Step pulse time, microseconds $1=255 ; Step idle delay, milliseconds $2=0 ; Step pulse invert, mask $3=5 ; Step direction invert, mask $4=1 ; Invert step enable pin, boolean $5=0 ; Invert limit pins, boolean/mask $6=0 ; Invert probe pin, boolean $10=1 ; Status report options, mask $11=0.010 ; Junction deviation, millimeters $12=0.002 ; Arc tolerance, millimeters $13=0 ; Report in inches, boolean $20=0 ; Soft limits enable, boolean $21=0 ; Hard limits enable, boolean $22=0 ; Homing cycle enable, boolean (Grbl) / mask (GrblHAL) $23=0 ; Homing direction invert, mask $24=25.000 ; Homing locate feed rate, mm/min $25=1000.000 ; Homing search seek rate, mm/min $26=250 ; Homing switch debounce delay, milliseconds $27=2.000 ; Homing switch pull-off distance, millimeters $30=1000 ; Maximum spindle speed, RPM $31=0 ; Minimum spindle speed, RPM $32=0 ; Laser-mode enable, boolean $100=40.000 ; X-axis steps per millimeter $101=10.000 ; Y-axis steps per millimeter $102=200.000 ; Z-axis steps per millimeter $110=5000.000 ; X-axis maximum rate, mm/min $111=5000.000 ; Y-axis maximum rate, mm/min $112=1000.000 ; Z-axis maximum rate, mm/min $120=1000.000 ; X-axis acceleration, mm/sec^2 $121=1000.000 ; Y-axis acceleration, mm/sec^2 $122=1000.000 ; Z-axis acceleration, mm/sec^2 $130=1000.000 ; X-axis maximum travel, millimeters $131=1000.000 ; Y-axis maximum travel, millimeters $132=100.000 ; Z-axis maximum travel, millimeters 1010 machine's grbl settings: $0=10 ; Step pulse time, microseconds $1=255 ; Step idle delay, milliseconds $2=0 ; Step pulse invert, mask $3=4 ; Step direction invert, mask $4=1 ; Invert step enable pin, boolean $5=0 ; Invert limit pins, boolean/mask $6=0 ; Invert probe pin, boolean $10=1 ; Status report options, mask $11=0.010 ; Junction deviation, millimeters $12=0.002 ; Arc tolerance, millimeters $13=0 ; Report in inches, boolean $20=0 ; Soft limits enable, boolean $21=0 ; Hard limits enable, boolean $22=0 ; Homing cycle enable, boolean (Grbl) / mask (GrblHAL) $23=3 ; Homing direction invert, mask $24=100.000 ; Homing locate feed rate, mm/min $25=1000.000 ; Homing search seek rate, mm/min $26=250 ; Homing switch debounce delay, milliseconds $27=5.000 ; Homing switch pull-off distance, millimeters $30=1000 ; Maximum spindle speed, RPM $31=0 ; Minimum spindle speed, RPM $32=0 ; Laser-mode enable, boolean $100=199.100 ; X-axis steps per millimeter $101=199.100 ; Y-axis steps per millimeter $102=199.100 ; Z-axis steps per millimeter $110=2500.000 ; X-axis maximum rate, mm/min $111=2500.000 ; Y-axis maximum rate, mm/min $112=2500.000 ; Z-axis maximum rate, mm/min $120=150.000 ; X-axis acceleration, mm/sec^2 $121=150.000 ; Y-axis acceleration, mm/sec^2 $122=150.000 ; Z-axis acceleration, mm/sec^2 $130=810.000 ; X-axis maximum travel, millimeters $131=730.000 ; Y-axis maximum travel, millimeters $132=90.000 ; Z-axis maximum travel, millimeters
yup, seeing the same behavior when your settings are loaded. Will check later against the BB X32 as well, and maybe run it on my router (belt drive) to see how it likes it. Though it is easy enoguh to add a G0 line after the probe and before the arc, I am curious as to what it happening inside GRBL that is causing this behavior. @terjeio any ideas?
I strongly suspect that you're running into accuracy limits within GRBL that are inherent in the move that the machine is being asked to make with the resolution of movement available. The basic issue is that the machine is being asked to move in an 0.25mm radius arc in steps of >0.025mm. The machine can only move in discrete steps. I don't know the detail of how GRBL calculates arcs, but assume that it uses the exact X moves, calculates the ideal Y position and then moves to the nearest step. (The Y steps count down, sorry.) Example with 40 steps /mm Example with 39 steps /mm It may be coincidental that the error exceeds 0.01mm as the steps per mm go from 40 to 39, but in any case, the calculation gets increasingly inaccurate which will likely trigger some sort of error within GRBL. You could try disabling smoothing for the toolpath within F360 (which tends to introduce arcs when it can) and/or chosing a larger lead-in radius (do you even need one for a plasma cutter?). Also, there is an option somewhere (in the POST?) regarding arcs and line segments - make sure this is set to encourage the use of line segments in the toolpath to take the arc calculation outside GRBL.
I will look deeper at this later but so far I can see that his gcode thinks the tool diameter is 1.38 inches. Code: ( Tool 3: Plasma Cutter Diam = 1.377inch) Thus if 'linearize small arcs' is turned on just about all the arcs in this file should be linearized which would avoid using small arcs entirely, which is a good idea in this case. I will try it later when I get to my Fusion machine. I will also run the code through my actual machine which has a steps/mm of 40 and I have never had a problem like this with it so this should be interesting. Still, a 0.01" radius arc is small in GRBL's world and it has struggled with small arcs for the last 10 years that I have been messing with it, here's hoping grblHAL will improve on this.
Yes, I did download the previous F360 files. The tool has a nozzle diameter of 1.377" but a kerf width of 0.06" which actually does the cutting. I've never used plasma cutting in F360, but, as far as I can tell, the nozzle diameter is only used to prevent collisions. The simulation of the toolpaths looks funky as the nozzle ploughs through the top of the stock, but I'm not familiar with how a plasma cutter simulation should behave.
Out of curiosity, I created a new plasma cutter tool (just copied the Autodesk default plasma cutter) and now the simulation behaves exactly as I would expect from 3D milling. This is with the OP's Fusion file (model & tool paths) as uploaded previously: OP's same file with tool changed to a new plasma cutter, copied from Autodesk library: This may be totally unrelated to the GRBL error, but something is clearly funky with the F360 file. I suggest the OP tries to create a new tool and see what problems persist. (I just followed the same process as the video below).
David, I'm glad you duplicated the error with your setup, maybe we can get to the bottom of this. FWIW- Misterg, I did follow his instructions, although since I have a Z axis probe, I have to set the Top Height to the cut height, and the Pierce Clearance to the Pierce height for my plasma cutter- Also, my torch is 1.377" wide even though the nozzle is much much smaller than that. The 1.377" is necessary to avoid crashes while cutting. I'm not sure if there are other settings I should change in Fusion, but I will try turning off smoothing- even though it's recommended to be turned on in every tutorial I've seen on the subject.
New "official" Arduino made no difference in performance. It was in a sealed box and sure looks like a legit item. I'm going to say, it's not the Arduino that is causing the issue
Does the toolpath simulate correctly on your F360 installation? I didn't change anything in your 'Top Gantry plate v6.f3d' file except the tool and got different results (and more in keeping with expectations). Like I said, though, this may / may not be related to the problem. Smoothing in F360 tries to fit G2 and G3 arc moves into the toolpath in place of linear moves whenever possible to reduce the size of the gcode file. Turn it off in case it is generating the small radius arc moves that are causing the error. For 2D contours this is hardly necessary, anyway (IMHO). Do you still get the error if you use a larger lead-in radius?
I just created a file that ran w/o error. Not sure this is a fix, as the Top Height and Pierce Clearance aren't right for my set up, but it ran. After just turning off smoothing didn't work I did the following. 1. New plasma tool started with the default plasma cutter and changed the kerf width to 0.06", Nozzle Diameter to 0.1" Head Clearance to 0.03937in 2. Top Height 0.05" 3. Passes Tolerance 0.0001" 4. Smoothing turned off 5. Linking No lead in or lead out 6. Pierce clearance 0.05" Attached is the fusion file, the gcode file and my grbl settings. While it worked this time, I don't think it solves my issue as this won't cut the plate the way I need it cut, but at least it generated a gcode file that ran on the official Arduino Uno R3 on my desktop. Note: the Fusion file has two (edit Operations) now and two NC programs. The ones that worked and generated a good file are Profile 2 and NC Program 2
The file simulates just fine. I did play with the lead in radius, and finally just turned off lead in and lead out completely - see above. I can try a larger radius and see if that makes a difference. what do you suggest? Obviously if it's bigger than the diameter of the circle I'm trying to cut it won't work I'm trying to cut various sized holes in a rectangle to get some idea of the accuracy of my machine
One setup, two operations. The first simulates as previously on my F360 (i.e. oddly!), the second simulates as expected (suppress the first toolpath within F360 to see the real picture for the second). I'm sure you'll be doing it anyway, but now add back in a reasonable lead in radius (~1mm / 0.04") and see what happens. [Edit - posts crossed, but hopefully still makes sense!]
Operations- Yes, sorry for the error in description. Changing the Lead in to 0.04" no other changes from the above settings. Well that was interesting, It "cut" all the holes just fine, but when it went to start the outline ( the last pierce and cut) Error 33 popped up again. Not posting the whole log, but here's the last bit of it from the last probe until the failure occurs. [11:10:40] [ [ PROBE ] ] Probe Completed. [11:10:40] [ G38.2 Z-3.937 F6 ] [PRB:1050.650,1698.800,129.015:1] [11:10:40] [ G38.2 Z-3.937 F6 ] ok [11:10:40] [ G10 L20 Z-0.0787 ] ok [11:10:40] [ G0 Z0.05 ] ok [11:10:40] [ M3 ] ok [11:10:40] [ $G ] [GC:G0 G54 G17 G20 G90 G94 M3 M9 T0 F152 S1000] [11:10:40] [ $G ] ok [11:10:41] [ G4 P0.6 ] ok [11:10:41] [ G1 F1524 ] ok [11:10:41] [ ] error: 33 - The motion command has an invalid target. G2, G3, and G38.2 generates this error, if the arc is impossible to generate or if the probe target is the current position. [ G3 X6.0405 Y4.0327 I0 J-0.04 F60 ] [11:10:41] [ ERROR ] error: 33 - The motion command has an invalid target. G2, G3, and G38.2 generates this error, if the arc is impossible to generate or if the probe target is the current position. [ G3 X6.0405 Y4.0327 I0 J-0.04 F60 ] [11:10:41] [ G3 X6.0405 Y4.0327 I0 J-0.04 F60 ] error:33
Just had a successful gcode file generated. Attached is my fusion file and gcode files So what's different? Going through the Fusion 2D setups Heights : Top Height is now 0.06" This should work for my plasma cutter setup Passes: Tolerance 0.0001in. Seems pretty ridiculous to me to have it that tight, but if it works, I guess I'm ok with that Smoothing: not checked Linking: Lead in and lead out checked, Lead in radius 0.001in 100 degree sweep angle Pierce clearance 0.12" And I set a ridiculous plasma tool setup- Nozzle Diameter 0.01in Kerf width 0.001in. I can probably compensate for those last two when I dimension the holes with the next design, and I might try setting them to something closer to realistic and re-generate the gcode. but I have a file that should run on the actual machine now.
Just updated the cutting tool to 0.06" kerf and 0.5" width, re ran the gcode and got a working file. Not sure this is the final solution, but i at least have generated a file that works Thanks for all the help guys- hopefully, this will all help someone else too. See Setup 2, Profile 3 and NCProgram 3 for the working version
Hmmm, found some interesting things in the plasma processing.... go here GitHub - OpenBuilds/OpenBuilds-Fusion360-Postprocessor: Post Processor for Fusion 360 for use with OpenBuilds Machines running Grbl 1.1 and grab the latest postprocessor code (the big green Code button) V1.0.40 should produce Gcode that will avoid this arc error by both inserting a G0 position force statement after the probe and correctly linearizing small arcs for plasma (a small bug involving the difference between tool.tooldiameter and tool.kerfWidth for plasma tools). Though there are things the postprocessor can do to avoid arc issues I now believe that GRBL has a real bug in the calculation of small arcs when the steps/mm is small since my X32 also displayed this odd arc error when the arc parameters are in fact, ok. This surprised me as the ESP32 has much better floating point calculations than the atmel328p.
David, Thank you so much, Success, I have tried a couple of designs that were giving me fits, and this new Post Processor indeed fixes the Error 33 problem I've been struggling with - even though it's probably not the preferred solution, the inserting of a G0 position force statement clears the error and I can no proceed with characterizing my machine when I get back to it late next week- Again, I can't thank you enough for making this work!
