Serious issue with 1.2037 and UC-300USB

[Derek]

Upgraded a machine that I run the same code on almost every day. Right away noticed something strange in the movement. It seems that it is combining multiple lines of code into one motion or CV is really getting ahead of itself.

G00 Z3
X10 Y4

Combines itself into one movement. This is on X,Y,Z and A axis movements. It doesn't seem to be a problem on the UC300ETH

Rolled back to a really early version and the problem disappeared.

[cncdrive]

Hi Derek,

I copyied your example code to a file, loaded it and ran it, but the movements seems to all happen correctly.
This was the code:

G00 Z3
X10 Y4

And what I'm doing is I loaded the UCCNC with a UC300-5LPT USB version and then I press the gotozero and run the code and first the Z moves to 3 and after the X10 and Y4 movement happens like how it should.

My question is: are you running the UC300-5LPT USB version of with a different motherboard?
And the other question is if you could reproduce the mentioned issue like I described? Or you doing something differently? If so then please describe the steps for me to le me reproduce it.

[Derek]

it's running a M44 motherboard on a C32 BOB

I can't test this moment as it's in production. I can tell you though what got my attention was I have a A axis rotation move with the Z axis at a safe level. It then does a Y move then a Z move and then starts drilling. Now it may be because there is a drilling cycle that the look ahead is picking up.

Here is a snip of the exact code I observed it on.
G99 is active.

Code: Select all

N3611 G00 Z4.9211
N3612 (M53) ( this is a clearance macro I disabled it in this example)
N3613 G00A95.

N3615 G00A90.
N3616 (drill #29 rotate 90)
N3617 (Offset #36)
N3618 M08
N3619 G00 Z3.1850
N3620 X0.5945 Y3.9088
N3621 G81 X0.5945 Y3.9088 Z1.2191 R1.9441 F22. Q0.125
N3622G80

It did line 3613, 3619 and 3620 all at the same time.

[Derek]

IS that code from a Gcode program or a MACRO ?? or a MDI ??

(;-) TP

It was from a program but I just posted the complete code. It does it on a lot more than just this on instance. I'm starting to think it's related to drill cycles.

[Derek]

Are you doing teh Drill cycles in G98 or G99 mode ?

(;-) TP

G99

[cncdrive]

I've also just tested your code and I don't see a problem.
The movements happening in the correct order.
I think what you (Derek) probably saw is the CV control blending the movements.
If you are in G64 mode then the A axis will be CV controlled together with the other axes, I mean all axes are CV controlled which can be a problem if the A axis is bending your table and if the drilling cycle pullout point is close to the table, because then the radius created on between the Z and the A axis after the Z cycle can be problematic.
I don't see if you are in G64 or not, but I can only think about this yet as the root for the problem.

Terry: I don't see any strange feedrates on the A axis. Can you share a line of code with me please with which you see this?

[Derek]

Well this is on the Alliant mill that I've literally run at least 8000 - 10,000 parts on with UCCNC. All I did was upgrade from 1.2021 to 1.2037. No other changes. Yes I'm running G64 but I've always run G64. I went back to my 1.2021 version and it's been running all day like it always has. The only reason I upgraded was to run a new screen set that Terry did for me.

[cncdrive]

Hi Derek,

OK, but I still don't know what the issue is, because your code runs just fine here on an UC300-5LPT USB.
Maybe the issue was not with this particular code part because for example it is absolutely not possible that lines 3613 is CV blended with line 3619 etc. and it is not possible because there is a M08 between them.
The M8 is a non syncronous command when the PC software side empties all the motion buffer which means all motion must be totally finished before the M8 is executed on the PC side.
If it was not done this way then the M8 could not be timed correctly, could not happen when it should. All text macros wait for the buffer to empty before execution and this is one serious reason why those lines are sure not blended and must happen as totally separate motions, otherwise the M8 would be out of syncron so much that it would happen in the very beginning of your example g-code program if there was no wait for the buffer to flush.
So, the CV issue which I've mentioned could happen between lines 3611 and 3613 only.
If the issue is something else then I think it happened somewhere else in other parts of your code which I do not see yet.

Code: Select all

N3611 G00 Z4.9211
N3612 (M53) ( this is a clearance macro I disabled it in this example)
N3613 G00A95.

N3615 G00A90.
N3616 (drill #29 rotate 90)
N3617 (Offset #36)
N3618 M08
N3619 G00 Z3.1850
N3620 X0.5945 Y3.9088
N3621 G81 X0.5945 Y3.9088 Z1.2191 R1.9441 F22. Q0.125
N3622G80

[cncdrive]

And I will test the same with the M44 too soon, can do that only tomorrow, however I don't expect any difference, because the code parts which influances these kind of motion behaviours are all unified, the same codes execute for all motion controllers.

[Derek]

I'll load 1.2037 and run it again. I pulled that section of code because I was standing there with my finger on the stop button going WTF is this:)

There were other instances of it happening I pulled this one because I was certain.

Is there a scenario where the firmware might not have updated properly?