fusion360 g code errors

[hareandmoon]

Hi being new to this game I'm well out my depth here, but ill try and explain my problem. Just finished up-grading my CNC router and all the software. Now using Arduino uno, shield, three steppers and am on GRBL 1.1. Got everything working, including limit switch noise problems sorted and homing. Happy days. BUT when trying to run a file that used to work on GRBL 8 i just kept getting errors. After a bit of digging i found that files generated on Easel had no problem but all fusion360 files were full of errors. here is a section of code from the GRBL when trying to run a simple 2D contour.

error: Invalid gcode ID:36: Unused value words found in block.

Z-1.4F333 G2X70.3Y49.9Z-1.5I0.1 G1X70.4Z-1.5F1000 Skipping command #63 ok G3X70.5Y50J0.1 ok ok X65.7389Y55.4501I-5.5 ok ok G1X65.739Y55.45Z-1.25 ok ok ok G3X63.7412Y55.354Z-1.25I-0.7389J-5.4501 ok

Pausing file transfer.

error: Invalid gcode ID:35: G2 and G3 arcs require at least one in-plane offset word. error: Invalid gcode ID:36: Unused value words found in block.

I hope this makes sense. Ray Palfreyman Palfray Guitars

[chamnit]

@hareandmoon : Grbl v0.9 and later added full error checking to each g-code line sent to it. Fusion 360 has a known issue with G2 and G3 arcs. It fails the error-checking in certain instances, even though the error check is very lax and is what is used in LinuxCNC. From what I understand, Fusion 360 fails to convert their CAM output to inches mode correctly. If you run it in mm mode, it has been shown to work fine in nearly all instances. I believe this has to do with precision round-off somewhere in their code.

[tklus]

I am using Fusion 360 in inch mode and it does work fine for me. What post are you using?

[chamnit]

That's right. I think I recall the default posts don't have enough precision in the inches conversion and modified posts that increase it fix the problem. I don't use Fusion 360 so I can't say for sure.

[vMeph]

Did you select the post processor for grbl in fusion 360

[hareandmoon]

Hi, yes use the grbl post processor from fusion( also tried an alternative edited on I found) both export code that Camotics visulizer shows no problems. I always use mm in designs so the inches thing does not apply. Hoping someone can give me a solution so I can get work done Cheers Ray

www.palfray.co.uk

Tel: 07479467562

On 13 Jun 2017, at 15:26, Meph1 notifications@github.com wrote:

Did you select the post processor for grbl in fusion 360

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[chamnit]

Have Fusion 360 export G1 command, instead of G2/3 arcs. There should be a setting somewhere. It's a fairly standard option on most CAMs.

[neilferreri]

Hi Ray, Can you share a Fusion 360 file that you're having trouble with? That may make it easier to see what's going on.

[hareandmoon]

Hi Neil

sure this is the file from Fusion360, i added line 14 and 314 when i was on the older system to stop the tool dragging across the surface at the start and return the tool to my zero , at a the end. but other than that its standard fusion using their GRBL post.

On 13 Jun 2017, at 16:14, neilferreri notifications@github.com wrote:

Hi Ray, Can you share a Fusion 360 file that you're having trouble with? That may make it easier to see what's going on.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/213#issuecomment-308149777, or mute the thread https://github.com/notifications/unsubscribe-auth/AZYPnkjz-lL1aDBfLQIAiMjGM8yGQsTeks5sDqddgaJpZM4N4iNB.

rpalf@blueyonder.co.uk

[hareandmoon]

Sorry, now with the file…..DUH

On 13 Jun 2017, at 16:14, neilferreri notifications@github.com wrote:

Hi Ray, Can you share a Fusion 360 file that you're having trouble with? That may make it easier to see what's going on.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/213#issuecomment-308149777, or mute the thread https://github.com/notifications/unsubscribe-auth/AZYPnkjz-lL1aDBfLQIAiMjGM8yGQsTeks5sDqddgaJpZM4N4iNB.

rpalf@blueyonder.co.uk

[hareandmoon]

Hi, I can't see anywhere in fusion to change g2/3 to g1?

www.palfray.co.uk

Tel: 07479467562

On 13 Jun 2017, at 16:03, Sonny Jeon notifications@github.com wrote:

Have Fusion 360 export G1 command, instead of G2/3 arcs. There should be a setting somewhere. It's a fairly standard option on most CAMs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[chamnit]

@hareandmoon : I don't see a file. You'll need to drag and drop the gcode file (possibly as a .txt file type) into the web interface. I'm not sure if Github's email response protocol will allow a file or not.

I did a quick Google search for Fusion360 and disabling G2 arcs. It came up with this

[hareandmoon]

control panel.txt

had to save the .nc file as txt

while i've been on i changed a few fusion/grbl post setting and am checking files now, its looking pretty good. mostly changed the circle sizes. heres a bad screen picture of this.

[neilferreri]

You can get a public link to your Fusion 360 design. https://www.autodesk.com/products/fusion-360/blog/share-a-public-link-of-your-fusion-360-design/

[hareandmoon]

hi ive made that file public

http://a360.co/2s7p8sh

ray

[swarfer]

@hareandmoon , you said

Hi Neil sure this is the file from Fusion360, i added line 14 and 314 when i was on the older system to stop the tool dragging across the surface at the start and return the tool to my zero , at a the end. but other ...

which illustrates a fundamental setup problem on your machine.

If you have homing switches this would not happen (the dragging) because Z homes to the TOP of travel (and G28 defaults to the same place, machine 0,0,0). Then you set work coordinates for part 0,0,0 and G28 Z0 is safely above the work.

With no homing switches, you can get the same effect by simply turning on or resetting the GRBL controller with Z at the top of travel. Then set work co-ordinates are usual, ensure G28 is set to 0,0,0 and the Fusion post will work correctly without modification since G28 will be in a safe place.

[hareandmoon]

Yeah, the scraping was on ver8 when I wasn't using homing as I did not have limit switches. I now have homing, limits G28 etc etc so am hoping I won't have to edit the start and end of the files. But I still have not got to the bottom of the conflict between fusion post files and Grbl 1.1.

Ray

www.palfray.co.uk

Tel: 07479467562

On 13 Jun 2017, at 22:49, David the Swarfer notifications@github.com wrote:

@hareandmoon , you said

Hi Neil sure this is the file from Fusion360, i added line 14 and 314 when i was on the older system to stop the tool dragging across the surface at the start and return the tool to my zero , at a the end. but other ...

which illustrates a fundamental setup problem on your machine.

If you have homing switches this would not happen (the dragging) because Z homes to the TOP of travel (and G28 defaults to the same place, machine 0,0,0). Then you set work coordinates for part 0,0,0 and G28 Z0 is safely above the work.

With no homing switches, you can get the same effect by simply turning on or resetting the GRBL controller with Z at the top of travel. Then set work co-ordinates are usual, ensure G28 is set to 0,0,0 and the Fusion post will work correctly without modification since G28 will be in a safe place.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[neilferreri]

@hareandmoon I tried generating the gcode straight from your Fusion file and I ran the txt file you attached earlier. Both ran fine, no errors. What UI are you using to send your gcode to the machine? Also, have you tried ramping the toolpath? It'll help save time and end mills.

[tklus]

Grbl panel is probably my favorite!

[vMeph]

UGS Platform my favorite

[hareandmoon]

My path is :- mac laptop running 10.5.3, (Using fusion360or Easel), GRBL 1.1 , UGS interface ,arduino uno (clone!!), proctoneer shield v3, DRV8825.

I have also run the 'panel' as well but it makes no difference.

I do remember having lots of trouble getting the arduino set up ( possible cause it's a clone?) and reading somewhere about the fact that the new Grbl uses every scrap of its memory. Could I have a data speed/ buffer problem as when I post process the file with 'looser' setting for chords and min circles everything seams to run OK.

Perhaps I should buy a genuine arduino!

Thanks for the ramp suggestion , never done it before but I'll give it a shot.

Ray

www.palfray.co.uk

Tel: 07479467562

On 14 Jun 2017, at 01:21, neilferreri notifications@github.com wrote:

@hareandmoon I tried generating the gcode straight from your Fusion file and I ran the txt file you attached earlier. Both ran fine, no errors. What UI are you using to send your gcode to the machine? Also, have you tried ramping the toolpath? It'll help save time and end mills.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[chamnit]

@hareandmoon : I also verified that Grbl parsed and executed your posted gcode (text)file just fine. No unusual errors. Only common inconsequential errors related to lines with a % character and M6 command.

Can you provide me with your $$ Grbl settings and your $I build info output? This will help me test a clone setup.

With your clone Arduino, they can be problematic if they use a CH380 (or non-FTDI or non-Atmel) chip for their USB serial converter. These CH380's have poor buffering and corrupt data if they are sent too much at one time, which is hard to control. Otherwise, your clone should be fine. People use them all of the time for Grbl.

[109JB]

I have done a lot of checking of the CH340 chips on many of the clones and I personally would not use a clone using a ch340 USB chip on a running machine. I use them all the time for testing and for other non-critical stuff though. Having said that, I do use clones that have the 16u2 chip. You have to be cautious when buying them on e-bay if looking for one with a 16u2 chip. The sellers will advertise it having a 16u2, but the fine print or the pictures actually say/show a ch340. So, you have to be cautious. You can read about this in the "USB to Serial Transmission errors" in the "Known Issues" section of the WIKI. https://github.com/gnea/grbl/wiki/Known-Issues

@chamnit - A small thing that I have not brought up before, but it is a CH340, not a CH380 chip on the clone boards.

[hareandmoon]

Hi, will send tonight when I get home. I'm really thinking that it is the clone because I remember having to get a special driver off someone on the net and there was some warning about poor transfer rates😕 Thanks for all your time, you guys are the real thing😎

Ray

www.palfray.co.uk

Tel: 07479467562

On 14 Jun 2017, at 15:55, Sonny Jeon notifications@github.com wrote:

@hareandmoon : I also verified that Grbl parsed and executed your posted gcode (text)file just fine. No unusual errors. Only common inconsequential errors related to lines with a % character and M6 command.

Can you provide me with your $$ Grbl settings and your $I build info output? This will help me test a clone setup.

With your clone Arduino, they can be problematic if they use a CH380 (or non-FTDI or non-Atmel) chip for their USB serial converter. These CH380's have poor buffering and corrupt data if they are sent too much at one time, which is hard to control. Otherwise, your clone should be fine. People use them all of the time for Grbl.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[109JB]

If you had to download a driver it was likely a ch340 chip. The top of the USB to serial chip will have the chip model printed on it.

When buying you can tell the difference by the size/shape of the chip.

This is an UNO with the 16U2

and this is a clone with the ch340

[hareandmoon]

hi, hope this is all the info you asked for,

The odd driver for clone Arduino that i got off e bay (which had i known it would be this much trouble i would have not bought ) …. http://kig.re/2014/12/31/how-to-use-arduino-nano-mini-pro-with-CH340G-on-mac-osx-yosemite.html http://kig.re/2014/12/31/how-to-use-arduino-nano-mini-pro-with-CH340G-on-mac-osx-yosemite.html

and yes checked just now its definitely a clone with a CH340, see photo.

My current $$ file:-

$0 = 10 (Step pulse time, microseconds) $1 = 10 (Step idle delay, milliseconds) $2 = 0 (Step pulse invert, mask) $3 = 0 (Step direction invert, mask) $4 = 0 (Invert step enable pin, boolean) $5 = 0 (Invert limit pins, boolean) $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 = 1 (Hard limits enable, boolean) $22 = 1 (Homing cycle enable, boolean) $23 = 3 (Homing direction invert, mask) $24 = 25.000 (Homing locate feed rate, mm/min) $25 = 250.000 (Homing search seek rate, mm/min) $26 = 250 (Homing switch debounce delay, milliseconds) $27 = 1.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 = 25.000 (X-axis travel resolution, step/mm) $101 = 25.000 (Y-axis travel resolution, step/mm) $102 = 100.000 (Z-axis travel resolution, step/mm) $110 = 500.000 (X-axis maximum rate, mm/min) $111 = 500.000 (Y-axis maximum rate, mm/min) $112 = 200.000 (Z-axis maximum rate, mm/min) $120 = 10.000 (X-axis acceleration, mm/sec^2) $121 = 10.000 (Y-axis acceleration, mm/sec^2) $122 = 10.000 (Z-axis acceleration, mm/sec^2) $130 = 500.000 (X-axis maximum travel, millimeters) $131 = 620.000 (Y-axis maximum travel, millimeters) $132 = 70.000 (Z-axis maximum travel, millimeters) ok

$i [VER:1.1f.20170131:] [OPT:V,15,128]

cheers Ray

On 14 Jun 2017, at 17:28, 109JB <notifications@github.com mailto:notifications@github.com> wrote:

If you had to download a driver it was likely a ch340 chip. The top of the USB to serial chip will have the chip model printed on it.

When buying you can tell the difference by the size/shape of the chip.

This is an UNO with the 16U2

https://user-images.githubusercontent.com/10978476/27143586-70d826a8-50f4-11e7-9e66-0162b1d98178.jpg and this is a clone with the ch340

https://user-images.githubusercontent.com/10978476/27143599-8200824a-50f4-11e7-8207-9a7e8c82b889.jpg — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/213#issuecomment-308485548, or mute the thread https://github.com/notifications/unsubscribe-auth/AZYPnu26ROacXktuThd2wO63UeorbL4Pks5sEAoegaJpZM4N4iNB.

rpalf@blueyonder.co.uk mailto:rpalf@blueyonder.co.uk

www.palfray.co.uk http://www.palfray.co.uk/ info@palfray.co.uk mailto:info@palfray.co.uk

[chamnit]

@hareandmoon : I checked your uploaded gcode file again with the settings you posted. No errors again. Did you change your Arduino when you upgraded to Grbl v1.1? To one that has the CH340 chip (thanks @109JB)?

Or is it the same one you had with v0.8? If it's the same, do you recall which version of v0.8 you had? If possible, the $I build info string would help a lot to track down what changes would cause an issue like this.

[hareandmoon]

Hi It's the same arduino as I used with ver 8,which I can't remember the exact issue. What is the $l? And how do I get it?

I have got everything working by lowering the 'chord' and 'min circle' values, and will do an actual cut tonight( just cut air last night). Thanks Ray

www.palfray.co.uk

Tel: 07479467562

On 15 Jun 2017, at 16:25, Sonny Jeon notifications@github.com wrote:

@hareandmoon : I checked your uploaded gcode file again with the settings you posted. No errors again. Did you change your Arduino when you upgraded to Grbl v1.1? To one that has the CH340 chip (thanks @109JB)?

Or is it the same one you had with v0.8? If it's the same, do you recall which version of v0.8 you had? If possible, the $I build info string would help a lot to track down what changes would cause an issue like this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[chamnit]

@hareandmoon : No problem. It's more likely the Fusion360 settings is the culprit. I bet there are some very small arcs or poorly posed arc being generated and Grbl may not like them. This likely means that I'll need to do some arc conditioning checks in the parser to help avoid this situation in the future. I'll put it on my development notes for future versions.

[neilferreri]

@hareandmoon @chamnit For what it's worth, I generated toolpaths & gcode straight from the Fusion 360 file and tested it on a CH340 Arduino. I used, and typically always use, the generic GRBL post processor in Fusion.

[hareandmoon]

Sonny, thanks again for all your help, you and the guys rock.

Ray

www.palfray.co.uk

Tel: 07479467562

On 15 Jun 2017, at 17:44, Sonny Jeon notifications@github.com wrote:

Closed #213.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hareandmoon]

I know this might be left field Niel but are you using a Mac or a pc?

Cheers Ray

www.palfray.co.uk

Tel: 07479467562

On 15 Jun 2017, at 18:38, neilferreri notifications@github.com wrote:

@hareandmoon @chamnit For what it's worth, I generated toolpaths & gcode straight from the Fusion 360 file and tested it on a CH340 Arduino. I used, and typically always use, the generic GRBL post processor in Fusion.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hareandmoon]

So sorry guys but I've been away for a while. but I'm still getting errors with (some) Fusion360 files but not easel files. Can we have a show of hands for me getting a real genuine Arduino to stop these problems? My gut feeling is that fusion files have tighter tolerances, hence more dense data transfer and my Chinese clone can't handle ....just a thought. Also if I do get a genuine one do I need to remove that driver for the 340 chip? Im on a mac.

ray

[X3msnake]

Try using smoothing on the tool generation to see if it fixes the dense data

http://help.autodesk.com/view/fusion360/ENU/?guid=GUID5A951723-4797-4F5F-A7A3-45DCBCA2D26F

No dia sábado, 1 de julho de 2017, hareandmoon <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> escreveu:

So sorry guys but I've been away for a while. but I'm still getting errors with (some) Fusion360 files but not easel files. Can we have a show of hands for me getting a real genuine Arduino to stop these problems? My gut feeling is that fusion files have tighter tolerances, hence more dense data transfer and my Chinese clone can't handle ....just a thought. Also if I do get a genuine one do I need to remove that driver for the 340 chip? Im on a mac.

ray

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/213#issuecomment-312455137, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-jvH-KfuXC0e_psLsPB9AGarV1Dvks5sJrKYgaJpZM4N4iNB .

-- Com os melhores cumprimentos, Vinicius Silva

[neilferreri]

@hareandmoon What postprocessor in Fusion are you using? I've run some complex jobs with no issues. I am using a PC, though. How are you sending your gcode to the machine?

[hareandmoon]

Thanks for the smoothing suggestion I will defiantly give that a try. Ray

www.palfray.co.uk

Tel: 07479467562

On 2 Jul 2017, at 13:41, X3msnake notifications@github.com wrote:

Try using smoothing on the tool generation to see if it fixes the dense data

http://help.autodesk.com/view/fusion360/ENU/?guid=GUID5A951723-4797-4F5F-A7A3-45DCBCA2D26F

No dia sábado, 1 de julho de 2017, hareandmoon <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> escreveu:

So sorry guys but I've been away for a while. but I'm still getting errors with (some) Fusion360 files but not easel files. Can we have a show of hands for me getting a real genuine Arduino to stop these problems? My gut feeling is that fusion files have tighter tolerances, hence more dense data transfer and my Chinese clone can't handle ....just a thought. Also if I do get a genuine one do I need to remove that driver for the 340 chip? Im on a mac.

ray

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/213#issuecomment-312455137, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-jvH-KfuXC0e_psLsPB9AGarV1Dvks5sJrKYgaJpZM4N4iNB .

-- Com os melhores cumprimentos, Vinicius Silva — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hareandmoon]

I'm using a MacBook Air, fusion360 generic Grbl post processor to generate . nc file, then import into UGS . Computer to arduino is USB.

Ray

www.palfray.co.uk

Tel: 07479467562

On 2 Jul 2017, at 13:57, neilferreri notifications@github.com wrote:

@hareandmoon What postprocessor in Fusion are you using? I've run some complex jobs with no issues. I am using a PC, though. How are you sending your gcode to the machine?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[vMeph]

I use fusion 360 with the post process grbl that is include in fusion, but i use in metric, with no issues

[neilferreri]

@hareandmoon I'd try something other than UGS to rule that out. I've had no issues with Fusion 360's CAM gcode generation on a cheap ch340 clone.

[hareandmoon]

Thankyou for all the info , so far I've tried just about every suggestion , Smoothing looked good for a while , but alas no, still getting problems. While running this program (a guitar fretboard) file here, http://a360.co/2sndoB9 , all the tricky tool-paths (to me anyway) performed great, the fret markers, the fret slots, the outside contour. BUT errors appeard in the Radius of the board programs, (parrallel) both the roughing and the smoothing. I have made the program available and am trying to include a few screen captures of the erroros. They always have something to do with G2/G3 arcs.

hoping against hope

Ray

[X3msnake]

Try strooms post processor it uses ijk instead of g2 g3

https://github.com/Strooom/GRBL-Post-Processor

No dia terça-feira, 4 de julho de 2017, hareandmoon < notifications@github.com> escreveu:

Thankyou for all the info , so far I've tried just about every suggestion , Smoothing looked good for a while , but alas no, still getting problems. While running this program (a guitar fretboard) file here, http://a360.co/2sndoB9 , all the tricky tool-paths (to me anyway) performed great, the fret markers, the fret slots, the outside contour. BUT errors appeard in the Radius of the board programs, (parrallel) both the roughing and the smoothing. I have made the program available and am trying to include a few screen captures of the erroros. They always have something to do with G2/G3 arcs.

[image: error 1 copy] https://user-images.githubusercontent.com/26611614/27842464-3ac6b1a6-6102-11e7-853b-2861e77ec3cf.jpg [image: error 3 copy] https://user-images.githubusercontent.com/26611614/27842465-3ac71696-6102-11e7-8cc9-da7ef43f8682.jpg [image: error 2 copy] https://user-images.githubusercontent.com/26611614/27842466-3aca654e-6102-11e7-92bf-8eada5c76966.jpg

hoping against hope

Ray

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/213#issuecomment-312950823, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-vaIisJKcoeTLoyAshjEqAaGeBhBks5sKqVjgaJpZM4N4iNB .

-- Com os melhores cumprimentos, Vinicius Silva

[hareandmoon]

Yep, just tried that. No difference.

Ray

Sent from my iPad

On 4 Jul 2017, at 23:10, X3msnake notifications@github.com wrote:

Try strooms post processor it uses ijk instead of g2 g3

https://github.com/Strooom/GRBL-Post-Processor

No dia terça-feira, 4 de julho de 2017, hareandmoon < notifications@github.com> escreveu:

Thankyou for all the info , so far I've tried just about every suggestion , Smoothing looked good for a while , but alas no, still getting problems. While running this program (a guitar fretboard) file here, http://a360.co/2sndoB9 , all the tricky tool-paths (to me anyway) performed great, the fret markers, the fret slots, the outside contour. BUT errors appeard in the Radius of the board programs, (parrallel) both the roughing and the smoothing. I have made the program available and am trying to include a few screen captures of the erroros. They always have something to do with G2/G3 arcs.

[image: error 1 copy] https://user-images.githubusercontent.com/26611614/27842464-3ac6b1a6-6102-11e7-853b-2861e77ec3cf.jpg [image: error 3 copy] https://user-images.githubusercontent.com/26611614/27842465-3ac71696-6102-11e7-8cc9-da7ef43f8682.jpg [image: error 2 copy] https://user-images.githubusercontent.com/26611614/27842466-3aca654e-6102-11e7-92bf-8eada5c76966.jpg

hoping against hope

Ray

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/213#issuecomment-312950823, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-vaIisJKcoeTLoyAshjEqAaGeBhBks5sKqVjgaJpZM4N4iNB .

-- Com os melhores cumprimentos, Vinicius Silva — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hareandmoon]

I can even tell now when it will throw up errors just by looking at the 'visulizer' picture in GRBL 1.1. See the crazy jagged arc at the bottom of travel. Everytime i see a weird radius or arc i know thats were it will crash....any ideas.

[vMeph]

maybe poste here your fusion draw? for someone do the g code file for you and see if comes up some error?

[X3msnake]

Can you please post the offending NC here?

Have you tried another sender beside the UGS just to check out that it is not a sender problem?

2017-07-05 1:12 GMT+01:00 Meph1 notifications@github.com:

maybe poste here your fusion draw? for someone do the g code file for you and see if comes up some error?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/213#issuecomment-312969195, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-qhSkEGQQjkSNwwE0ckqWSLg6i79ks5sKtTkgaJpZM4N4iNB .

-- Com os melhores cumprimentos, Vinicius Silva

[X3msnake]

Couple of old threads/ ideas to check

Check that your $12 setting is not set at a wierd number https://discuss.inventables.com/t/resolved-g2-g3-arc-issue-with-chilipeppr-grbl/9104/12

Check that no M6 command is being sent on the PostProcessed file https://github.com/vlachoudis/bCNC/issues/27

2017-07-05 1:21 GMT+01:00 Vinicius Silva x3msnake@gmail.com:

Can you please post the offending NC here?

Have you tried another sender beside the UGS just to check out that it is not a sender problem?

2017-07-05 1:12 GMT+01:00 Meph1 notifications@github.com:

maybe poste here your fusion draw? for someone do the g code file for you and see if comes up some error?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/213#issuecomment-312969195, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-qhSkEGQQjkSNwwE0ckqWSLg6i79ks5sKtTkgaJpZM4N4iNB .

-- Com os melhores cumprimentos, Vinicius Silva

-- Com os melhores cumprimentos, Vinicius Silva

[neilferreri]

@hareandmoon Used your Fusion model, generic GRBL postprocessor, PC - Win7, cncjs (really slick sender) on an Arduino clone with a CH340 USB Serial chip...no errors. Again, try something other than UGS. If you don't know what else to try, I highly recommend cncjs.

[109JB]

Just a note.

The errors encountered with the ch340 chip are completely random and are a result of a firmware problem that can't be fixed since the firmware isn't available to edit. The errors have nothing to do with the sender, or the code being sent. Just because you can send a code to a ch340 equipped arduino and not get an error on one run means absolutely nothing.

Depending on the code, the frequency of status requests, and pure luck, you may be able to send a code without error, but I assure you that the problem is there. For example, I have a 3D profiling test code that has no problems and it can be run with a 16U2 arduino without errors ever occurring. On a ch340G arduino with the same version of Grbl, I have never completed complete run without errors. It might result in an error in the first 100 lines, or it might not get the error until 800,000 lines in, but it will result in an error.

You are free to do as you please, but I would NEVRrun my actual machine with a ch340g equipped arduino because the errors WILL occur. I use them all the time for testing my GUI programming and other non-critical tasks, but not on the machine anymore.

[hareandmoon]

thanks 109JB, i'm definatley going to purchase a genuine Arduino as the more i use this clone the less confidence I have in it. Again thanks for all your patience and help guys. Ray

[hareandmoon]

Just as an observation. I tried Neilferreri suggestion of using cncjs and ran two 'error prone' programs, and quess what----ran with no problem, more than once??? One thing Neil, how do I change Grbl settings in that program? I can do it easy in UGS but can't figure out in cncjs. Its a fine sender though. Ray

[neilferreri]

@hareandmoon Great! I had a feeling. In the newest build, the serial terminal is meant to look like an actual terminal. Just click in the black area and type what you need. $$ will bring up current settings, and if you're changing a lot is nice to expand the terminal to fill the window.