1.2102 G-Code Processing

[alex_s]

Hi,

here is a very simple program

Code: Select all

G90
G0 G53 Z0.

(Drill1)
T7 M6 (drill D=4.2 4,2mm worm)
G61
G54
G43 H0
G0 X15. Y75.
Z15.
Z5.
G98 G81 X15. Y75. Z-15.87 R5. F350
X45.
X75.
Y45.
X45.
X15.
Y15.
X45.
X75.
G80
Z15.
G53 Z0.

if i load it and let it eun via cycle start it goes into error at

Code: Select all

G98 G81 X15. Y75. Z-15.87 R5. F350
X45.

the Z axis movement is just jerking around

however if i type in the program line by line in the MDI it works as expected until

Code: Select all

G80

which does not change UCCNC back from G81 so every move in X or Y still results in the specified G81 Z movement

got a UC300-ETH with 1.2102 running

please have a look

cheers
Alex

[cncdrive]

Hi,

What do you mean by "it goes into error"?
What do you mean by the "Z axis is just jerking around"?

I ran your code with 2.2102 and I do not see any issues, but maybe I just don't understand what to look for, because I don't understand what the error you describing is.

[cncdrive]

And your g-code looks like at me as on the picture attached and it goes through the drawn path as it should making the drills.

[alex_s]

it goes into error because the transmitted travel does not match the physical travel.

and in the programm without hardware it runs fine, but not in the real world

as i wrote when i load the program and run it via cycle start so the look ahead and all fiddle with the physical movements it jerks off the Z movement and when it retracts it retracts further than specified because it did not move the propper z depth

however when you run the program via MDI as in type it in line by line it works fine in the programm and the real world, except the G80 does not end the G81 cycle so all x/Y movements also move the Z axis

the problem only exist in UCCNC, mach 3 or linux cnc with another breakout board move the hardware as expected.

for me it seems that there is a problem somewhere in the processing of the g-code when you run the program as a whole, and a problem that G80 does not end the G81 Cycle

[cncdrive]

Thanks for the explanation.

If the g-code processing would be not OK then the TCP marker on the screen would not run through the path.
If it runs through the path crosses out the possibility of bad g-code processing.
So, does the TCP yellow marker on the screen runs through the exact path which is drawn?
At me it runs though it and it reaches the Z endpoints too.

I'm still not understanding what " jerks off the Z movement" means? Do you mean by that that the downward movement is shorter than it has to be? That the axis stucks before it reaches the endpoint and so the retract point is then higher than it has to be, because the axis already lost steps on the downwards movement? Is this what you mean?
Isn't it possible that your acceleration setting is too high so the Z-axis loosing steps when it tries to deccelerate to the endpoint?

And one more thing is to check the latency test on the configuration/profiles tab page and the statistics button.
Check especially when you Cycle starting and when the cycle is running then what does the graph shows?
Does it jumps anytime up to the maximum 20msec? If yes then that will be the problem. If the latency is bad can cause strange problems. Max.20msec latency is required for the software to properly work.

And also could you please post your profile file?
Then I will ask my collegue to capture the step/dir signals with logic analyser and to count them too, so we can see if there is any error in them.

[Dan911]

remove the X,Y positions from canned cycle line, the G0 gives first hole position.

G98 G81 Z-15.87 R5. F350

[alex_s]

the acceleration setting and such are the same in mach, linux cnc and uccnc, so if there is a problem with the settings it should still be uccnc related, and the same movements when entered in the MDI or in single line mode work flawless except the G80 that does not work at all.

i run very low setting for the hardware a max of 6000units/min and 800units/s² and 500units/s² on Z hardware is capable of multitude of this

as for jerking it seems to not move the full Z depth so it retracts higher then expected in reality in software all is fine, this only happens in uccnc and only if the program is executes as a whole, on single line or via MDI the movement is fine

do you only need the profile file or the corresponding folder as well ?

[alex_s]

remove the X,Y positions from canned cycle line, the G0 gives first hole position.

G98 G81 Z-15.87 R5. F350

that is only true in this short test code the Canned cycle can and should be able to be defined with X /Y for first hole

[cncdrive]

And one more important thing is that the G81 is processed as a bunch of G1 codes.
I mean that when the step/dir signals are generated from the G81 command then there is no specific G81 command, but the API receives a bunch of G1 lines processed from the G81.
If the drawing is correct and the TCP marker runs through the drawing then it is sure that the bunch of G1 lineas generated from the G81 is correct.
And then the only problem could be if the step/dir signals generated from the bunch of G1 lines would be incorrect,
however this would also mean that the whole step/dir generator is not working properly, because as said the step/dir signals are generated from G1 codes previously built from the G81,
so then the G1 linear movements should also not work correctly in this case, not only the G81.

So, if you have some time to test it can you replace the G81 if a downward G1 movement and an upward G1 movement to see if that works or not?
I think it should also not work and that the problem will be something in the settings, I suspect the acceleration value is too high for the axis or the latency is too long causing issues.

[cncdrive]

as for jerking it seems to not move the full Z depth so it retracts higher then expected in reality in software all is fine, this only happens in uccnc and only if the program is executes as a whole, on single line or via MDI the movement is fine

OK, so on the screen you see the yellow TCP marker to be on correct height. You can visually watch the travel height, because it takes some time to travel from one to another and that travel happens on the correct height on the toolpath viewer? But not on the machine? Is this correct?

do you only need the profile file or the corresponding folder as well ?

I only need the .pro profile file.