Guys, I am trying to make the simplest of parts and if you take

Try the exact same cutting paths that you were having problems with, but change the post processor in your CAM application to output line segments instead of arcs. That way you’re comparing apples to apples. What CAM software do you use?

I am using cut2d and my post processor is tinyg" inch" postp , if you need me to i can send you my postp.

@Kurt_Schuppert Spindle - I believe you said in video that spindle not running now. Look in this file for settings I use https://dl.dropboxusercontent.com/u/50261731/2015-9-9_17t32t31_tinyG_440.18.conf I find that with the controller and motor I have, setting phase to 1.0 as you have it will not spin up the motor, but I can usually manually start it. My settings may/may not help; there is no standardization among the controllers available.

Parameters: Set the value of $hp to =1.0.
Reference: https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97#system-group
I have never seen $hp not equal to 1 (or 2 or 3 when running tinyG2), so have no idea what having its value = 0 might do. Otherwise, your parameter values look OK in comparison to mine, given the differences in our machines.

I suggest a reboot of tinyG after changing $hp=1 just to be sure it ‘takes’ correctly.
BTW I don’t have limit switches, your switch settings look OK.

OK. Here’s what’s going on - as far as I can tell.

In the arc changes made in 440.18 and 440.19 the arc planner was also updated to reject arcs that fell out of tolerance according to the LinuxCNC Gcode specs:
http://linuxcnc.org/docs/html/gcode/gcode.html#sec:G2-G3-Arc

Specifically, this bullet about arc radius tolerances:
“It is an error if:
When the arc is projected on the selected plane, the distance from the current point to the center differs from the distance from the end point to the center by more than (.05 inch/.5 mm) OR ((.0005 inch/.005mm) AND .1% of radius).”

Kurt’s cut2d file fails the 0.1% test. When I relaxed the tolerance to 1% it ran fine. So I think the arc planner will need to do that and accept arcs that are slightly out-of-tolerance according to Linux CNC. But I need to take a closer look at the side effects of doing this.

Also, it’s probably better if the planner throws the system into an alarm state and rejects the rest of the job if an error is actually found.

I’ll make these changes and post a 440.20 soon

Carl, I used your spindle settings and they worked like a champ . all good there !
So i made a new file for the part i was going to make and i am still having the same problems i was having before , i can cut squares and circles just fine but when i try to run this file it will not work , if you guys could take a look at it and see if there is anything wrong? https://www.dropbox.com/s/8w3ay5b0mpvblzq/quite%20cut%20912-15.gcode?dl=0

@Kurt_Schuppert Spindle - grood news.
Other news - If I read Alden’s comment above correctly, cut2d is generating Gcode that demands (calls for) greater precision than the Linux CNC standard interpretation supports.
Do you have the option to reduce the precision cut2d is generating at least as an experiment? I have no idea what knobs you have to adjust in the interface.

what scale should i us ?

I have no idea what options you have, but Alden mentins that increasing tolerance by a factor of 10 made the issue go away.
So, try 0.01. rather than 0.001, etc.
This is an experiment, may/may not yield useable results

i just tried to change the amount of cuts from 1/32 to 1/8 and then tried it again and the same thing happened again . I do not get why I can make this part a week ago and now I can not recreate this part to save my life , I am now surfing the vectric forum trying to find out how to change the accuracy , i do not think that i can .

@Kurt_Schuppert Did you do the 440.18 FW upgrade between the “worked” and “does not work” event? My read is that 440.18 explicitly declares the Linux CNC violation a “do not attempt” this move", but continues to process the follow-on Gcode, prior FWs probably would have acted differently.

I did not do a FW update between the time that I first cut and the second time I tried the second try I have had the 440.18 for at least a month before I even thought of making this . I did not even have my quite cut spindle in tell about two weeks ago . I have download Inkscape and I will try to recreate the part and export it out and try it again.

OK, that is odd if a Gcode file that ran a week ago stopped running. That would seem to imply that a parameter change induced tinyG to trigger the violation calculation Alden mentions above. Another experiment might be to change your X and y microsteps to 4 ($_mi=4) to see if that change in motion quantization affects it.
And yet another experiment that you could try is to generate your Gcode in mm rather than inch. That should not affect the end product. TinyG does all its internal calcs in mm, so this eliminates the inch to mm conversion internally.

Hmmm, I may have just run into the same or related issue with an uber-simple job of my own.
In my case, Two G03 circles would not cut, but changing them to G02 circles ran fine. Is there any way to tell cut2d to only use G02 (CW) arcs? That might work. Keep an eye on https://www.synthetos.com/topics/fw-440-18-cwccw-bug/

You can not change any of these settings, but could you not change the tinyg post processor that I use when I export from cut2d ?

I do believe that the correct answer is to relax the radius tolerance checking to accommodate the arcs being generated by cut2d (see my earlier post). I will try to post 440.20 with this change this evening. In the mean time see if you can ask the CAM to generate the code as line segments with no arcs.

Kurt, Please try build 440.20. You can find it here:

It should also show up in the updater application

Carl, Do i need to run the aurdude.exe please see screen shot of where i am . i think that i am starting to get close to install. https://www.dropbox.com/s/qctt0pzf33o0yac/image.png?dl=0

Looks like you are ready to hit reset on tinyG then launch the avrdude command line, copy and paste it to cmd line. hit reset then while SpinDir is still flashing, hit enter to execute avrdude

Reminder: unlike the SPJS updater (which is working great for me on Linux), using this procedure you have to initiate the downloader by manually restarting tingG with the reset pushbutton

Do you know how to connect to tinyg in chllilipeppr without running SPJS , i have forgot how to do this last part
?