Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: BR549 on February 03, 2012, 08:38:34 PM
-
Well it happened again. this is the 15th PLASMA part in the last 12 months that MACH just ATE. Look at the Gouge at the top of the outside cut. THAT is not in the Gcode. It just took a diversion and then corrected itself and returns BACK to normal by the time it got back to the satrt of the cut at the 3 oclock position.
It has always acted the same each time it has happened.
Always started the cut at 3oclock position and by the time it gets to the top of the circle it goes crazy ,then corrects itself somehow and will always end up correct when it gets to the end of the cut.
ONLY happens with circle cuts LARGER than 24 diameter NEVER smaller so far.
YEs it has cut correctly I cut 3 today (only needed 2) THe first cut perfect. Mach3 ate the second one and the 3rd cut perfect. Nothing on the machine was changed between cuts. Move into 0,0 position zero xy and push the go button.
Anyone have any ideas or clues on this one. Like I said this is #15 in 12 months
(;-( TP
-
Post the gcode.
-
Hi Terry - first off I feel your pain - this sort of sh*t can be a real PITA. HOWEVER - one thing I've learned about plasma is that it's a house of cards that can be affected by a gazillion variables. This problem could be:
Mach is failing in some way. - you could be right.
Your electronics is being spooked. An alluminium welder starting up in the next shed used to throw mine off but nothing else bothered it. (now fixed!).
Your mechanics could be sticking. >24" job takes you to a bad area on your table where as a smaller job doesn't maybe?
Your air supply is loosing pressure momentarily. Someone else in your shop just happened to use it at the same time maybe? - Or perhaps long cuts hit the air tank more than short cuts?
Your THC is quirking. None of them are perfect!!!
and probably loads more...
Just trying the voice of reason before we try to nail this problem.
Ian
-
One thing that I recommend is to replace the plasma head with a pen and draw instead of cutting.
Disconnect the plasma and other electronic tools around the machine. If it draws correctly, then the plasma cutting source (the plasma itself) can be messing with all the rest. You can take one hour changing everything, but at the end you will know what is happening.
I know because I already been there and in my case it was not Mach.
-
If it's not in the code, and the control is open loop, how can it go nuts and not stay out of whack, then get back to normal ? (just wondering)
Is it an arc motion or short segments ?
Could it be accel/decell/CV related ? Similar to rrc's recent post ?
Curious one.
-
If it's not in the code, and the control is open loop, how can it go nuts and not stay out of whack, then get back to normal ? (just wondering)
Good point Russ - I'm glad someone's awake already. The only way I can think that could happen is metal pop - you know - it get's hot and pop it suddenly kicks/expands up/down out - every which way - of course I could be talking complete bo**ox. ;D
Ian
EDIT: Then again depending on the scale of this thing (which we don't yet know) if your arc expands you could get something like this and that could happen if your air supply falters as I suggested above as a possibility. Just a thought...
-
It is always in a LARGE circle (arc code) that is MORE than 12" radius. It has never done it with segmented code. The process it does is it STARTS perfect and towards the end of the first quadrant section 0-90 it takes a diversion to a smaller radius still going in a circle then it works it way BACK to the original radius and ALWAYS makes a perfect end at the starting point of the circle.
It has also NEVER done it with LESS than a 24"circle. (so far)
It is LARGE enough a diversion that it is NOT arc quality flicker, we are talking a .500-1.00" change at times .
ALso it is a random thing NOT readily repeatable.
I think I will create a large circle and just dry run it to see IF I can get it to fail IF I run it often enough??
Something HAS to be triggering it but what ????? (;-) TP
-
open the code with the editor and go to the lines of code for that area.
go to the end of each line of code and hit enter.
that way you know you have a carriage return at the end of the lines of code.
looks like you are skipping lines from reading the returns.
mach will sometimes read a line without a return and sometimes won't.
bill
-
You know, looking at that pic with magnification, I reckon I can see several steps in the Y axis movement, as marked below.
None in the X axis, and the circle returns to what it should be when Y gets smaller.
But the errors are small - possibly within the limits of the following error of the driver IF it is a servo system rather than a stepper.
If I didn't know any better, I would be looking at stiction at the limits of the Y axis. I would not be looking at Mach as the circle completes.
Yeah, a few dummy circles of about that diameter with a pen would be the trick.
Cheers
-
The circle is 28.5" in diameter that is more than a few steps. IF it were lost or gains steps then the rest of the cut would be OFF as well and it woul dfinish as offset. But it does not it does correct itself somehow and by the time it is finished it is spot on with position compared to teh startpoint.
When I get timeI will setup a test program and just let it dry run to see IF it will show up in a controlled version and get it to repeat itself.
Note to self DOn't cut large circles with arcs use segmented code (;-)
(;-) TP
-
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? 8)
-
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. ;D
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 :D).
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
-
Terry
Can you cut the gcode program down in size to just the big circle? If so, I can have a look at it if you want.
Cheers
Roger
-
Not much to see be here it is without the inside cut just a circle outside cut.
N0000 (Filename: 30in Circle.tap)
N0010 (Post processor: MP3000-DTHC-SmlArcFix#3.scpost)
N0020 (Date: 02/03/12)
N0030 G20 (Units: Inches)
N0040 G54 G90 G40
N0050 F1
N0060 (Part: 30in Circle)
N0070 (Process: Outside Offset, 0, T3: Plasma, 0.06 in kerf)
N0080 M06 T3 F60 (Plasma, 0.06 in kerf)
N0090 G00 X30.1260 Y14.9040 Z0.5000
N0100 G28.1 Z0.50
N0110 G92 Z0.0
N0120 G00 Z0.1370
N0130 G92 Z0.0
N0140 G00 Z0.1200
N0150 M03
N0160 G04 P.2
N0170 X30.1260 Y14.9040
N0180 G01 Z0.0800 F100
N0190 G02 X30.0300 Y15.0000 I0.0000 J0.0960 F160.0
N0200 G03 I-15.0300 J0.0000
N0210 G02 X30.1900 Y15.1600 I0.1600 J0.0000
N0220 M05
N0230 G00 Z0.5000
N0240 X0.0000 Y0.0000
N0250 #650 = 94.838 #651 = 1
N0260 M05 M30
(;-) TP
-
Hi Terry
Yeah, well, without a plasma cutter it is a bit tricky to run that :-)
And with a single g3 for the entire circle, there's not much to look at anyhow!
The motion path looks very clean on my scree, although the preplan shows corners all around. I think the latter is an artifact of how Mach shows the preplan - I THINK.
Basically, that was a washout imho. Sorry.
Cheers
Roger
-
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.
[/quote]
Which is quite easy for it to do, since the trajectory is planned based on high-level commands (e.g. a G2) that can produce thousands of position updates. All it requires is that Mach screw up on calculating one arc, and get back on track later in the path. Mis-calculating a single arc segment can do this, and since the end points of each segment are fixed, it is entirely possible for it to go off-course, then recover in time to be on-track at the start of the next segment. This kind of error is going to be created in the high-level trajectory planning, not at the low-level step pulse output stage.
Regards,
Ray L.
-
Terry,
Obviously, there's zero chance it's an error in the G-code, given that that circle is cut by a single line of completely unambiguous code. I don't see what this can be other than a Mach3 bug. Are you using any kind of motion controller, like a SmoothStepper, Galil, etc? If so, it could also be the culprit, though it's less likely.
Regards,
Ray L.
-
All it requires is that Mach screw up on calculating one arc, and get back on track later in the path. Mis-calculating a single arc segment can do this, and since the end points of each segment are fixed, it is entirely possible for it to go off-course, then recover in time to be on-track at the start of the next segment.
Two problems with that, I think.
* I would think that Mach will be buffering the output data by clock-tick record: something like X,Y,Z,A,B,C,t . I have a problem imagining how that record access could go wrong.
* That error would have to happen randomly over runs, but at a fixed point on the Y axis, and be recoverable. That stretches my imagination.
If I am wrong, so be it. No sweat. But I think we need some experimental data with a pen.
Cheers
-
All it requires is that Mach screw up on calculating one arc, and get back on track later in the path. Mis-calculating a single arc segment can do this, and since the end points of each segment are fixed, it is entirely possible for it to go off-course, then recover in time to be on-track at the start of the next segment.
Two problems with that, I think.
* I would think that Mach will be buffering the output data by clock-tick record: something like X,Y,Z,A,B,C,t . I have a problem imagining how that record access could go wrong.
* That error would have to happen randomly over runs, but at a fixed point on the Y axis, and be recoverable. That stretches my imagination.
If I am wrong, so be it. No sweat. But I think we need some experimental data with a pen.
Cheers
No, you're missing the point. The trajectory planner takes the G-code commands, and creates a trajectory, which is a series of fairly simple, low-level motion commands - like move in a straight line from coordinates x0, y0, z0 to coordinates x1, y1, z1 at velocity v1. Then make an arc move, at velocity v2, from x1, y1, z1, on an arc whose center is at xc, yc, zc, ending at x2, y2, z2. A single line of G-code can create several of these commands, as the trajectory planner needs to figure out the necessary acceleration and velocity change points, and break each path into individual segments each having a constant velocity or acceleration. That is the level of command that is passed down to the driver to actually generate the pulses. The trajectory planner knows nothing about steps, and the driver knows nothing about the overall path, it is simply blindly executing very simple, low-level motion commands. If the trajectory planner screws up on just one of those path segments, it will tell the driver to create motion along the wrong path. In this case, it may well break the G2 that defines that circle into several smaller arc segments, and it could well be passing the driver that one segment with correct start and end points, but an incorrect arc center coordinate. That would exactly explain what Terry is seeing. There is for sure nothing in his G-code that could conceivably explain the problem.
Regards,
Ray L.
-
If the trajectory planner screws up on just one of those path segments, it will tell the driver to create motion along the wrong path. In this case, it may well break the G2 that defines that circle into several smaller arc segments, and it could well be passing the driver that one segment with correct start and end points, but an incorrect arc center coordinate.
Yes, I understand that of course. I have programmed industrial robots from scratch back in the 90s. What really makes me doubtful is what I said before:
* That error would have to happen randomly over runs, but at a fixed point on the Y axis, and be recoverable.
Data: we need experimental DATA!
Cheers
-
Like I said when I get time I will load up a program on the machine and let it loop all day to see IF I t will occur mor e than just in random fashion. Normall I do not cut much stuff that big in diam. SO may if I did a LOT of them in a row it may show up more often.
COuld be somehow the G92 is buggy deep down or ???????
(;-) TP