Possible bug using multiple WCS in one program

[dhanger]

I searched back about 3 years in the bug forum but found nothing related, so not sure if this is a bug or some quirk of my profile or ???

UCCNC 1.2112
UC400ETH
Windows 10

Yesterday for the first time I attempted to run a program using G54 as well as G55 to run the same code in 2 different locations. Upon a fresh start of UCCNC and homing, code would execute normally, terminating with M30 to rewind. On the next run, G54 is read and the G54 button on the screen is lit, but the machine clearly heads off in the wrong direction. I assume it was actually heading for G55 instead but I did not want to let it continue running just in case something really weird was going on. In some cases I could get the software to cooperate just by re-homing, but more often it would require a complete shutdown and restart of UCCNC.

Profile attached.

Thanks,
Dan

[Delco]

I use all g54-59 regularly , and it works fine , sounds like you did not save your offsets before shutting down . They are not automaticcaly saved so you need to save them or redefine your work coordinates upon a restart.

[dezsoe]

There must be something in the g-code that you run. Is it public, can we check it?

Delco, the offsets are always saved when you exit UCCNC.

[dhanger]

Attached is example program.

Delco, this is not happening after a shutdown, in fact it takes a shutdown to correct the problem. It happens when I try to run the program more than once in succession, immediately after M30 (rewind).

TOOLPATH GROUP-5.txt

(2.02 KiB) Downloaded 742 times

[dhanger]

I set up a different program that seems to highlight something weird, see attached. Don't just examine the code, try running it in my version (1.2112), maybe another version works fine.

Summary:
Program starts in G54 and drills 2 holes, then changes to G55 and drills the 2 holes.
Program ends and rewinds with M30.
Screen shows that G55 is activated per the last part of the program.
Re-starting the program keeps the screen button for G55 activated (even though G54 is specified in the beginning) and drills the first hole in G55, then drills the second hole in G54, then moves back to G55 for the last 2 holes.

If I manually activate G54 before re-starting everything works fine.

[ger21]

You should always try the latest version before reporting bugs, which is 1.2113.
Nothing in the description suggests that this will make a difference, but it's good practice. If it is fine in 1.2113, there's no point in trying it in 1.2112.

[dhanger]

Perhaps I should not have posted in 'report a bug' forum? As best I can determine 1.2113 is still listed under the test releases.

[dezsoe]

No problem: it will not work in any version. It is a known bug: when you load a line with a lot of commands then the execution sequence is not correct. The line which has the problem:

Code: Select all

G0 G90 G54 X1.595 Y.5825 S600 M3


This should be:

Code: Select all

G90 G54
G0 X1.595 Y.5825
M3 S600


Also, it's a bit strange that the g-code turns on the spindle BEFORE it moves the Z axis to any position!

So, if you have a code with ugly lines like these, split them. G54..G59 is known to execute in a wrong place in the queue.

[dezsoe]

Dan and Gerry,

You are both right. Always the latest version will be fixed, but we cannot force the users to install develpoment versions. If you, Dan, have the latest development version on your PC and report a bug with that version, then it's easier for us. If you have only the latest stable version then we have to test the issue, as it happened some minutes ago.

[dhanger]

Okay, thanks Dezsoe for confirming and providing a solution.

Dan