Hello Guest it is May 21, 2019, 05:12:51 PM

Author Topic: ONE of THOSE days (;-(  (Read 7647 times)

0 Members and 1 Guest are viewing this topic.

Re: ONE of THOSE days (;-(
« Reply #20 on: February 05, 2012, 09:17:03 PM »
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

Offline BR549

*
  •  6,865 6,865
    • View Profile
Re: ONE of THOSE days (;-(
« Reply #21 on: February 05, 2012, 10:10:19 PM »
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
« Last Edit: February 05, 2012, 10:13:00 PM by BR549 »
Re: ONE of THOSE days (;-(
« Reply #22 on: February 05, 2012, 10:36:38 PM »
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
Re: ONE of THOSE days (;-(
« Reply #23 on: February 05, 2012, 11:59:47 PM »
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.
Regards,
Ray L.
Re: ONE of THOSE days (;-(
« Reply #24 on: February 06, 2012, 12:02:38 AM »
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.
« Last Edit: February 06, 2012, 12:06:33 AM by HimyKabibble »
Regards,
Ray L.
Re: ONE of THOSE days (;-(
« Reply #25 on: February 06, 2012, 12:27:15 AM »
Quote
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

Re: ONE of THOSE days (;-(
« Reply #26 on: February 06, 2012, 01:27:05 AM »
Quote
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.
Regards,
Ray L.
Re: ONE of THOSE days (;-(
« Reply #27 on: February 06, 2012, 01:54:00 AM »
Quote
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

Offline BR549

*
  •  6,865 6,865
    • View Profile
Re: ONE of THOSE days (;-(
« Reply #28 on: February 06, 2012, 05:24:15 PM »
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