Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: archer183 on June 27, 2010, 03:55:57 PM
-
Something goes horribly wrong in mach 3 mill when I run this code: At the bold line, it tries to make the Z move instantaneously. you can hear the stepper motor stall and watch the z value change instantly (even when setting the feed override to 10%) on the readout. I suspect something is wrong with the code that is confusing mach, but I also consider it a safety issue if mach can suddenly decide to ignore the motor tuning settings due to some quirk of gcode.
the mach version is: 3.039. If it has been fixed in a later version, then it will be worth the trouble to upgrade. Any ideas folks?
G01 Z.02
G03 X-9.8916 Y-.835 I-9.9155 J-.8588
X-9.8917 Y-.8349 Z-.06 I-9.9394 J-.8826
G01 X-9.9019 Y-.8265 Z-.0625
X-9.9136 Y-.8203 Z-.065
X-9.9262 Y-.8164 Z-.0675
X-9.9394 Y-.8151 Z-.07
G03 I-9.9394 J-.8826
G01 X-9.9494 Y-.8158
X-9.9591 Y-.818
G03 X-9.9395 Y-.8827 I-9.9493 J-.8504
G01 X-9.9394
G00 Y-.8826 Z.25
Z.5
thanks
Greg
-
I seem to remember an issue a while back with something similar to the move you are doing. It was Ray (HimyKabibble)that found it and it only happened if your Z axis was significantly slower than your other axis.
If I recall the acceleration of the Z was ignored and Mach attempted to move the axis with the rates of the faster X and Y.
Is that the case with your Z?
Hood
-
I think it's related to G64. Try it in Exact Stop mode.
-
my axes feed rates are the same (max of 13ipm). Unfortunately, exact stop mode is useless to me for what/how I cut. if I have to run in exact stop mode then I will have to switch to different software or stop using the helical interpolation routines (latter probably the better option).
I'd seen this before on a much older version of mach, and it went away when I upgraded to 3.039, but this is the first time I'd seen it here. it is not picking one of the other axes feedrates, it is quite literally instantaneously jumping (or trying to) between the start and end Z. it is trying to move the Z faster than mach can even pulse at (25khz, 32k steps per inch).
-
Is that a full circle, or an an arc that's .0001" long? If it's a really short arc, that's probably what's causing the problem.
-
it should be half of a helix.
that being said, the plot thickens.. (here is what appears to be confusing old mach, I think it may be worth the upgrade hassle). I installed the newest mach version on my non-machine attached computer. plugged in that Gcode, and actually get an error when I plug in that copied section of code:
Radius to end of arc differs from radius to startLine 1
now if I open the whole code file, it does not give that error, even though the gcode through that particular section is identical. something weird is going on.
-
You need another line of code before that one.
-
apparently. I cut out one too many lines o marked code.
G00 G17 G20 G40 G49 G80 G90
G00 Z.25
Z.5
X-9.9394 Y-.8826
Z.1
G01 Z.02
G03 X-9.8916 Y-.835 I-9.9155 J-.8588
X-9.8917 Y-.8349 Z-.06 I-9.9394 J-.8826
G01 X-9.9019 Y-.8265 Z-.0625
X-9.9136 Y-.8203 Z-.065
X-9.9262 Y-.8164 Z-.0675
X-9.9394 Y-.8151 Z-.07
G03 I-9.9394 J-.8826
G01 X-9.9494 Y-.8158
X-9.9591 Y-.818
G03 X-9.9395 Y-.8827 I-9.9493 J-.8504
G01 X-9.9394
G00 Y-.8826 Z.25
Z.5
M05
G90
M30
would you mind loading that up in mach set to absolute coordinates for circles (I am hoping that someone else can replicate the error). in my preview it now shows a vertical line connecting two arcs, not a helix as it should be. and if you run it and watch Z, you can see it jump. It really does look like the gcode is really bad, but I would like to find a way to find out before a part gets screwed up.
-
It's treating that arc as a .0001 arc, which makes it plunge straight down
-
interesting. plunge down it does, at an infinite feed rate. even if it slowed down and did that move with a normal feed rate it would work ok without screwing up the zero. At least I knda know what to look for, too bad it won't error out on me when it tries to move faster than it theoretically can.
-
I should point out that I have 3.12.040 on this PC. Different versions may behave differently.
-
does it try to instantly change in Z on your version?
-
I may be way off base here, but are you missing a Z move in this line?
G03 X-9.8916 Y-.835 I-9.9155 J-.8588
Then in next line it has to make a straight z move down to get to correct position for start of second half of helix.
Am I full of it?
Seems to me it is doing a flat arc here, not half a helix.
John Champlain
-
yes, something is wrong with the code, and getting rid of the helical interpolation solves it (or fixing the buggered up helix). the bigger issue is that when you put said code into mach, it tries to make an infinite feedrate Z move... something that it should in no way be able to do, and I consider a bit of a safety issue, since if it does this wierd "move infinitely fast in z" in response to bad code, (without warning about said code) what happens when it does it some other time and moves/tries to move unexpectedly in a bizzare manner. at the very least there should be something in the code that prevents it from trying to move faster than the setpoints in motor tuning.
-
As I said before, I think it's a bug with CV mode. I think it'll be fixed in the next version of Mach3, as it's a very difficult fix. And it very rarely occurs.
-
Greg,
I now have a better understanding of what you have discovered. It probably is a program bug, but, regardless, it should be impossible. I was able to observe it in a dry run (router off) at a very slow feed rate. It is indeed scary, and may help to explain a few of the strange (but rare) behaviors that I have experienced with some of my older gcode routines that I switched from a DOS driver to Mach3.
Perhaps Art or Brian will pick up on this thread and work to help resolve, or at least explain, this issue.
Thank You,
John Champlain
-
Hello
the problem persist, have the same problem with mach3 .
code is as fallows
No solutions ?
-
No practical solution I know of.
-
haw can we ensure that motor do not lose steps ?
let say we use solidcam, what post proccesor is best for Mach3 ?
-
You can't. If you run into this error, mach will go to an absurdly impossible feed rate, and crash into whatever is in its way or stall
-
rhetorical question
Then who uses Mach3 ?!
is probably the most prevalent software and still has an inexplicable error .
Then
How can i be sure that in my code i don`t have these type of line code.
Plese tell me, how you solved the problem
Is a solution to changed the program to something else
-
I did not solve the problem. I switched the output from the post processor in the gcode generator to disable helical interpolation. In general, I do one of the two following... avoid helical moves at all costs, or if necessary, hand code them/post them separately so I can easily test the code before use.
-
I understand, thanks.
What software for post processor has the function to disabling helical interpolation.
In Solidcam , 3D iMachining operations all process is generated automatically, with few user options, i can not find an option to not use helical interpolation.
Has something like " Classic helical cutting condition" - on or off.
-
Contact your solidcam reseller. they can modify the post processor for you or try a different default one. Not all machines have supported helical interp.