alden

I have a version that corrects the issue, but am still testing. I’ll post a test version later. Thanks for your patience.

The file contains G40, G41 and G43 commands that are not supported by TinyG. Also, the lead-in O00000 is not supported. I made an edited version that seems to run, but I’m not sure it it’s entirely correct.

https://www.dropbox.com/s/1nrlcp18aaymp6e/pieza%201%20edit-001.nc?dl=0

Can you disable cutter radius compensation and tool length offset? We actually do have tool length offset in test – but it’s the G43.1 variety, not the G43 variety that requires a tool table to be pre-set.

It’s a good idea. In general, we should have more control over persistence. It’s possible to turn “auto-write” off, then have a “write” command. This would also address the issue of having to pause for 30 – 50 ms between each config during configuration sequences.

The g2 code base is available now on the Synthetos github, g2 repo. Currently there is no Synthetos board for sale that runs it, but it runs on the Arduino Due. A gShield will provide 3 motors, but all 6 axes are available on the Due.

The 0.98 version is available for TinyG v8 boards, but it is still in the edge branch and should be considered under development.

Thanks for the update and the info. Please send shipping info for the replacement board to synthetos at gmail dot com.

All your responses seems reasonable. No idea why Z failed. Odd. Does it look like there are shorts on the board? Perhaps the Vref was maxed out? What was the Z motor green LED doing? Was it lit while this was occurring? I’ll take a closer look when I get your board back.

I use the Atmel-ICE programmer for everything now, including real-time debugging with Atmel Studio 6.2 (must be most recent version!). I have half a dozen of them and sometimes the die – so beware. Also, the Micro USB B is really easy to rip off the board, so be careful.

Check to see if your USB ground and power supply ground have a differential on them. That’s the only thing I can think of regarding the FTDI getting hot.

Thanks for your help in locating the errant line. The fix is in the tinyg github and updater as master-candidate-440.19. Please let me know how this works for you. It passed all the tests for the files you gave me.

I ran the file and did not find a runaway, but I’m not 100% sure of that. There were a few challenges to overcome.

I do not have a table with an X dimension of 24″. I’m testing on a Shapeoko2 with an effective X dimension of 11.5 inches (after you take the size of the X carriage into account). So I turned the X motor power way down, disabled limit switches, and let it crash in X. This may mask a runaway in X if the runaway did, in fact, return in short order.

I did not find a runaway move in 3 runs (Coolterm) against different builds (master, edge (444.16), and my current experimental branch). I might have missed a move error due to the X dimension problem as it could have happened when X was crashed.

I run numbered files, so I numbered yours if you are interested:
https://www.dropbox.com/s/sbht5ybiwcqbvwh/wwerrorGcode-NUMBERED.nc?dl=0

Would you mind dry running the file again, and perhaps generate a file with 10″ wingspan I can run? If it fails again can you record the approximate line number and some description of the failure. It may be a Chilipeppr line number but that’s close enough.

Sorry for your issues.