UC300ETH skipping G-code (G3 - full circles)

[jawneelogik]

Recently while cutting a bunch of 3/8" plates each containing a number of 7/8" holes, I encountered a strange, but consistent error phenomenon. The parts were arranged on a 4x8' sheet in an array built using Sheetcam. The first column of rectangular plates started cutting from the lower left corner of the 4x8' sheet then proceeded up one side of the sheet along the Y axis. The first of four holes cut properly in each part, but the second and third hole would only pierce, do the lead-in then a very short arc before flaming out and moving over to the forth hole which cut correctly. The square plate cut correctly as well.

It happened on each plate along the left side of the sheet. When the first column was complete, the torch moved over and began cutting the next column moving back to zero along the Y axis. Every plate was cut correctly with no holes skipped. The same was true of the third column moving back up along the Y axis. Because of the number of parts required for the job, it was necessary to place four more parts along the far right edge of the sheet, but turned 90deg to the right in order to fit. I simply made another duplicate of the first original part (lower left corner) then turned it and placed all four from lower far right on up, along the Y axis. These four plates suffered the same fate as the first eight. Again, the first hole cut correctly then the second and third holes were skipped, but the forth cut correctly.

At the time I didn't spend much time trying to figure it out as I have access to an "Iron Worker" so was able to simply place the incomplete plates on the press and punch out the remaining holes. It was only when moving to another phase of the job where I discovered the "interesting phenomenon." I was cutting some 12x12x3/4" plates with a single 1-1/2" hole in its center that I saw the same problem. As there is no hole punch on the Iron Worker big enough to punch that size of hole, I decided to do a dry run with the torch turned off. I couldn't believe my eyes when I saw the same behavior! This was a serious problem for me as the customer had given me a tight deadline to get 16 of these plates cut for a job he was doing. I decided to try a different software version. (I was running 1.2104 at the time.)

I downloaded and installed 1.2106 thinking that it would make the problem go away. Nope! Still there. Now what. I don't know exactly why, but after closely examining the code and finding absolutely nothing in it that would explain the problem, I decided to try a little experiment. Sheetcam seems to favor all X or all Y motion as defaults for setting up lead-ins for circles. This time was no different so "Hmmm", I thought, "let's try something different." I changed the circle lead-in so that it was running on a diagonal instead of orthogonally then regenerated the code. I loaded it up then did another dry run. Yee hah! It worked! No more holes skipped. I was able to complete the job of cutting 16, 1 foot square by 3/4 inch plates and my customer was happy.

Now can someone please explain why? If anyone is interested I will upload the offending .tap files.

BTW, this is a problem I had experienced numerous times when still running Mach3. It was probably THE main reason I decided to purchase a US300ETH and UCCNC. Very disappointing/discouraging to see the same problem continue to rear its ugly head.

My current setup:
- 4x8' table
- UC300ETH
- Gecko G540 drive module
- UCCNC software v1.2106
- P.O.S. pc running Win XP
- Hypertherm powermax85

Thx. John

[cncdrive]

This issue was discussed on our forum a few times already.
It is a mathematical/logic problem and is kind of unresolvable. It is not really a bug.
The issue can happen if it is a full circle and there is a stop, a resyncronisation right before the circle.
The problem is that the g-code syntax for arcs is that the starting point is the current coordinates and only the endpoint is programmed in the g-code.

If the starting point is not exactly a multiplication of the steps per value. E.g. your machines axes steps per value is 100 then the axes can step 0.01 units, because that is the size of one step or in other words that is the resolution of the axis. If the ref point was e.g. 0 then your machine can't step on e.g. the coordinate 0.005, because it is in between 2 steps and your motor can't make the machine to step on that point.
Now the problem is that if the startpoint of the arc e.g. in the above situation is 0.005 and after the machine moved there and there is a syncronisation, e.g. a macro, a G4 wait etc. then the controller resyncronises the coordinates, because it is required for several other possible operations. And so the coordinate the software side will know is the closest step value which is then 0.01 and no more 0.005, because that coordinate is impossilbe for the axis to stand on. Now the full circle is coded, but the starting point is no more 0.005, but 0.01 and therefor this small difference can cause a full circle to become a very small arc or a very small arc to become a full circle.
The solution is:
1.) To not code full circles, but e.g. half or quarters. (SheetCAM can do that.)
Or
2.) To make sure to not program codes between the starting point of arcs and the arcs itself which codes requires coordinates resycronisation.

[jawneelogik]

2.) To make sure to not program codes between the starting point of arcs and the arcs itself which codes requires coordinates resycronisation.

There are NO codes (G, M or otherwise) between the start of an arc and the arc itself.

What I'm wanting to know, and what I asked, is: "Why did changing the direction of the lead-in from a 90deg cut (either all X or all Y) to a 45deg cut make the problem disappear?"

The result of that change in "lead-in" direction did not change the order of the generated G-code, only the coordinates. In my mind, it doesn't seem to correspond to the problem you describe. It seems like something else is going on. But what do I know. I only know what my lyin' eyes are telling me.

[cncdrive]

Yes, you need some mathematical knowledge and numerical control to understand what I've described, without that it is hard to understand unfortunately.
I think I drew a sketch earlier for better understanding, but I can't locate that forum topic now.

Changing the direction of the lead in can eliminate the issue, because the step over the startpoint can become different.
If you can post your code I would be happy to check it out. Please post the one which has the problem. Maybe it is a different issue than what I'm thinking of, but without seeing the code it is impossible to tell.

[Robertspark]

Balazs, I am just wondering (as my plasma cutter has 100 steps per unit, so maximum resolution is 0.01units/step as per your example)

If I changed the post processor to output motion coordinates to 2 decimal places (instead of the "default" 3 decimal places) would it solve the problem because the X,Y,I & J coordinates will never be 0.00x then?

Thanks as always

[cncdrive]

Hi Rob,

The resolution (steps per) does not change anything, because mathematically a very small 0.000000000...1 etc. difference will also cause the same issue.

[jawneelogik]

Balazs,

I believe this is the post you are referring to: http://www.forum.cncdrive.com/viewtopic.php?t=1195

There is something that I'm not sure I made clear. This behavior was observed on 2 different part files and the holes that were skipped were quite different in size from one part to the other. On one part the holes (4 - two were skipped and two were cut) were 7/8" (22.225mm) and on the other part, the single hole was 1.5" (38.1mm). By your explanation it would seem to me that the smaller the hole, the more likely the code will be skipped?

I am currently on a bit of a road trip, but as soon as I am able, I will send the offending files for your examination.

BTW, my time zone is UTC-6.

[Robertspark]

Sorry, I don't think I'm getting it.

If my post processor outputs co-ordinates with two 2 decimal places (0.01) accuracy
And my steps per unit match that precision (100 steps / unit, therefore smallest step size = 0.01 units)

The end of any previous move will always be a number which matches the current step, and no rounding error will occur.

Then there are no rounding errors that when a resyncronisation is done could create an error.

If the starting point is not exactly a multiplication of the steps per value. E.g. your machines axes steps per value is 100 then the axes can step 0.01 units, because that is the size of one step or in other words that is the resolution of the axis. If the ref point was e.g. 0 then your machine can't step on e.g. the coordinate 0.005, because it is in between 2 steps and your motor can't make the machine to step on that point.

However, if my machine does not match the output from the post processor, then yes there will be rounding errors that if the machine resets its co-ordinates and looses the error, then the start and destination positions will be very close.

So the fix is actually to make sure that the post processor outputs co-ordinates which match (or are greater than) the step resolution of your machine.

(Ill read that linked post)

[Robertspark]

Reading the first post in that other thread:

Hi - please see attached cut file. It looks like the UC100 doesn't see or recognize the G02 command. Any ideas why? I tried posting the machine profile, but I cant for some reason - the steps per are:
x axis - 354.4845801
y axis - 1017.924028
z axis - 21586.36453
The Kernel speed is set to 25000 in both Mach3 and Uc100. Please advise
thx

Is it not clearly the problem that the steps per unit are odd ball numbers that will always have rounding errors ?

Where as if it had rounded numbers and gcode outputing numbers that co-ordinate with those numbers the issue would not occur?

[cncdrive]

Rob,

The problem is when for example the startpoint of the arc for example on X is 0.001 and your machine does not step the multipication of than, e.g. it steps 0.01 or it steps 0.00123 etc. and so the machine can't step on the 0.001 coordinate.
Now this is not an issue when there is a continous code execution, e.g. there is G0 or G1 code for the movement to the start of the arc and then the arc is programmed, then there is no issue.
There is an issue if there is the movement to the start point of the arc and after there is a syncronisation command, e.g. a macro execution in the g-code and then is the arc programmed.
Why is there an issue then?
Because the coordinate syncronisation will update the coordinate to the exact real position which will be not 0.01 as your axis can't step on it, but it will be a multiplication of the 0.00123 or whatever steps per value and so the real coordinate where your machine axis is standing is different than the programmed starting point of the arc.
Why the syncronisation is done is because there are several operations which require that to work properly and so when stopped or macro is executed then the coordinate has to be syncronised.

It is enough that the starting point differs with a very small value, e.g. 0.000001 and then a full arc can become a close to null arc and a null arc can become a full arc. Just think how the g-code of an arc works.
It tells the software only the endpoint and the current point is the starting point. If for example the arc starting point is at the bottom and is a full arc then the difference will cause the starting point and the end point to be different so it is no more a full arc. And if the arc starts e.g. from the bottom and e.g. to CW then if the start point shifts to the right then to move to the endpoint only a very short distance is required instead of making a full circle. And so programmatically the arc became a very small arc from a full circle.