Note to self DOn't cut large circles with arcs use segmented code

Um - why? I don't follow the logic.
After all, there is very little difference in the step/dir instructions going to the CNC.

Cheers

If it helps your argument out any Terry, I too have had crazy movement like that. My parts were like... with a 2 inch or so circle. Hit cycle start, watch it go! woohoo! change part in vise, rinse/repeat, rinse repeat. Then all of a sudden the train veers of course for some unknown twilight zone moment, and scraps a part. Mach knew exactly what it was doing, too, as it represented the whacked out movement in the toolpath view. Those times are few and far between, but I CAN say it has happened.

Note to self DOn't cut large circles with arcs use segmented code

Why on earth would you want to go to the darkside like that. That is NOT The Way, Terry.  The force is strong with G2/G3.
Besides, I thought you and Vader were kickin' it old school down at the tracks anyhow? 

Thinking totally out of the box....

The torch is loose and at that point in the work the cabling/hose gets tight, moves the torch - when the cabling/hose gets loose again the torch returns to it's correct position. 

Tweakie.

Hmm....out of the box also for what it's worth,

- code - maybe try coding using arcs but an code arc / cicle for 4 quadrants
this comes to mind
  It is not good practice to program radius format arcs that are nearly full circles or are semicircles (or nearly semicircles) because a small change in the location of the end point will produce a much larger change in the location of the center of the circle (and, hence, the middle of the arc). The magnification effect is large enough that rounding error in a number can produce out-of-tolerance cuts.
Nearly full circles are outrageously bad, semicircles (and nearly so) are only very bad. Other size arcs (in the range tiny to 165 degrees or 195 to 345 degrees) are OK.

- Not much knowledge of plasma, but when my friend uses his welder "sometimes  and not repeatable" it realy can do a number on the running machine, in fact has corrupted his pc or needed to reboot as Mach did goofy things.
This is an RF problem / noise and has to do with existance of a field of right intensity hanging around ( non-technical explaination  ).

FWIW,
RICH

Torch is tight, overhead cable trolley no bind.

It has NEVER FAILED (so far)with segmentd code ONLY ARC code larger than 12"radius

THe Arc code is IJ not R. It is always with a simple circle code. I think something is hiding in the code somewhere. I have been looking /fearing for it over a year now. IT occurs and then somehow corrects itself back.  I found that out by just letting it run one time to SEE where it ended up. VERY surprised to see it correct when it got back to the start.

It is very simple cutting simple leadin/out NO TC or offsetting no fixtures changes G54 only. MOST coding is done with SheetCam. NOW it does always happen in the Y axis it seams AND that is a slaved axis.    The gantry would REALLY have to rack out of positon to get that much offset in the cut.  I never see anything starnge about that part. BUT?

Not  a biggy BUT a 30" diam piece of 1/4 or 1/2 " plate gets pricey from time to time.


RF interference?  GOOD suggestion BUT it would have just offset the entire rest of the circle cut.


Darkside? (;-)

Thanks Guys, (;-) TP

RF interference?  GOOD suggestion BUT it would have just offset the entire rest of the circle cut.

I suggested back before to try with a pen. I think other also. RF interference is very difficult to understand. I read a lot before and still do not understand many details of it. I had for example, a plasma source that caused a lot of interference before.
You say that happens 1 in 10 times. Maybe it happens on a particular part of your work table, that is closer to the plasma supply, or maybe you have more cables close, or, or, or ... If you try with a pen you would know (at the end you need to narrow the possibility's) and would not waist any plates, only paper.
What drives are you using and motors?

I think something is hiding in the code somewhere. I have been looking /fearing for it over a year now. IT occurs and then somehow corrects itself back.

I'll stick my neck out here and say that it will NOT be the code. If it was, you would get it EVERY time, and you would NOT end up at the right starting point.

Once away from the extreme N end the circle looks clean. You cannot get that with faulty code, and it is VERY hard to see how you could get that with interference in the control signals, since you end up with a proper circle elsewhere.

That looks mechanical to me. Try a pen.

Cheers

I'll stick my neck out here and say that it will NOT be the code. If it was, you would get it EVERY time, and you would NOT end up at the right starting point.

Not sure if by "code" you're referring to Mach3, or Terry's G-code.  There is certainly no reason to believe it is NOT being caused by a bug Mach3.  And, in fact, very good reason to believe it IS a bug in Mach3.  A bug in the G-code would manifest first time, every time, IF the controller (Mach3) was executing it in a consistent, repeatable manner.  The chances of a bug in either the G-code or the hardware manifesting in the exact same way, at the exact same position in the work, AND getting back on-track afterwards is exceeding small.  There are LOTS of things that can go wrong in Mach3 that would make the problem occur only randomly.  It can be a race condition in the code, or other timing problems, requiring two or more asynchronous events to occur in just the right order, with just the right timing, in order for the bug to manifest.  And, in fact, this is precisely the kind of bug Mach3 has had more than a few of over the years.  I have been through it many times with Mach3.

Regards,
Ray L.

Not sure if by "code" you're referring to Mach3, or Terry's G-code.

Terry's g-code.

There are LOTS of things that can go wrong in Mach3 that would make the problem occur only randomly.

That would require that Mach emit X data well ahead of Y data by hundreds of position updates, but not lose any Y data and catch up later. I find this hard to imagine, given my 40 year's experience with programming Real-Time computer control systems. OK, not 100% impossible, but very, very difficult to imagine.

We need more data. Some questions follow.
* can we compare several failed cuts of the same circle diameter to see how they compare?
* Can we get several pen plots from the machine of the failure and also of success.
* Does failure ever happen with a pen plot when the torch is disconnected?

fascinating problem.

Cheers


  It can be a race condition in the code, or other timing problems, requiring two or more asynchronous events to occur in just the right order, with just the right timing, in order for the bug to manifest.  And, in fact, this is precisely the kind of bug Mach3 has had more than a few of over the years.  I have been through it many times with Mach3.

Regards,
Ray L.
[/quote]

IT would SEEM and this is ONLY  a SWAG and the only thing that makes sense is that MACH3 is applying either and offset or SCALE to the ARCcode  somewhere somehow. Then it corrects the offset. Notice that for the most part it is running FINE then deverts to a smaller radius continues cutting on an arc and then returns back to the original radius.  ??

AND again it has always done it in the SAME quadrant. AND the Gcode always starts at 3 oclock with a leadin and ends with a leadout.

THe electronics are CandCNC, steppers. 

I will do some testing when I get caught up . Just dry run some LARGE circles all day to see IF it will show up again.

(;-)TP