Serious issue with 1.2037 and UC-300USB

[cncdrive]

Hi Derek,

The firmware must be updated, otherwise the software would not run, I mean on each runs the firmware version and CRC error check codes are readout and if any of them not matching then the software tries to update the firmware, if it can't or if the firmware update fails with even one bit of difference then the software would not run but would start a firmware update again and again until the firmware is updated properly. The bootloader is what takes care of this process and that works properly, have never had any problem with it. That part of the software was built very robust, because if that would not work properly would be a catastrophe.

Because I ran your code several times now and was observing the happenings and do not see anything I would like to ask you that if you will have some time then please try to run the code again with version 1.2037 and please observe the problem again and give me the code which sure causes it. Then I will make further testruns on it and hopefully will become more smart about what is going on.

[Derek]

Ok
Further testing reveals it is the M53 macro. Here is the code.

Code: Select all

exec.Code("G00 G53 Z14"); // G53 replacement
exec.Wait(200);
while(exec.IsMoving()){}

Terry wrote this for me early on because G00 G53 Z14 won't work ( and still doesn't) in code. It kicks up a soft limit warning because soft limits and G53 commands are broken. The problem is UCCNC is factoring in the Z axis work offset into it soft limit calculations and throwing an error. This is not a new problem. My error message says that max travel is 14.2 (correct) and it needs to go to 21.195 which is incorrect. My current work offset on Z 7.195. 7.195 + 14 = 21.195. This has been a problem all along. I've come up with kludges in all my code to work around it but I've finally been beaten by this latest update so I'll roll back to 1.2021 until there is a fix. Hopefully this is enough info for you to get a handle on this as it's really been irritating an a bit of a time vampire.

Thanks
Derek

[cncdrive]

Hi Derek,

I don't undertand it, sorry.
How is this macro causing the problem which you described in this thread?
I don't get it how this blends movements together?

Yes, I know about the softlimits with G53 issue, but the same is in all UCCNC versions including the 1.2021 which you've mentioned to rollback, so it will not resolve this problem in my opinion.
And it is a complex problem is why it was not resolved yet.

[Derek]

Hi Balazs
If I run the code without the M53 it works as it should. If I add M53 back to the code where it is in the example then I get the funky movement.

Make a macro M53 with the code (script?) I supplied and make M53 active in the G-code and see what you get.

[Derek]

Hi Derek,

Yes, I know about the softlimits with G53 issue, but the same is in all UCCNC versions including the 1.2021 which you've mentioned to rollback, so it will not resolve this problem in my opinion.
And it is a complex problem is why it was not resolved yet.

Yes but the only reason I'm running this macro is because of the G53 issue so it would solve it for me:)

[Derek]

Question about the G53 issue. Since it will work (or used to) when calling it from a macro is there a way to turn off the soft limit warning ( not soft limits ) yet still have soft limits work. I'll accept a simple no:)
If I had to choose between having a workspace limit warning and an operational G53 I would rather have the G53, provided the soft limits are still honored when running G-Code.

Just some observations:

I was just playing around with my other mill trying to get a feel for how soft limits and G53 works. Using MDI if my soft limit is set at 10.00 and I run G00 Z11 the axis overshoots by about .25" and then corrects back to Z10.00 The DRO reflects it so it's not some sort of servo overshoot. It also does it in offline mode. Is this normal?

If I load G-code that That is G00 G53 Z11 and click run I get the soft limit work space warning. If I go right over to the MDI and type in G00 G53 Z11 the axis goes to Z10.2XXX and then returns to Z10.

Thanks
Derek

[cncdrive]

Question about the G53 issue. Since it will work (or used to) when calling it from a macro is there a way to turn off the soft limit warning ( not soft limits ) yet still have soft limits work. I'll accept a simple no:)

Currently not possible, but this is exactly what I thought about, to separate the softlimits coordinates check in g-code and the continous softlimits reach checked by the API.

I was just playing around with my other mill trying to get a feel for how soft limits and G53 works. Using MDI if my soft limit is set at 10.00 and I run G00 Z11 the axis overshoots by about .25" and then corrects back to Z10.00 The DRO reflects it so it's not some sort of servo overshoot. It also does it in offline mode. Is this normal?

Yes, currently when running a g-code then the motion controller will detect the softlimits only when it is reached and then it will deccelerate and will revert back to the softlimit coordinate.
The precalculation of the decceleration path with the current feedrate to stop on the softlimits coord sis currently only working with jogging.

If I load G-code that That is G00 G53 Z11 and click run I get the soft limit work space warning. If I go right over to the MDI and type in G00 G53 Z11 the axis goes to Z10.2XXX and then returns to Z10.

Yes, the softlimits are only checked in the g-code program, macros and MDI not included, because macros could be changed any time, so checking in the macros actual code would require a reread of them which could create a laggy user experience. And MDI is also not checked, usually the MDI code is a single movement and that is stopped by the API software limit check when the endpoint is reached, there is no precheck of coordinates like in the full g-code file.

[cncdrive]

Hi Terry,

Thank you for the help. Now I found the problem.
And what exactly is happening is that when the macro executes the Z movement it registers the wrong coordinates, because a while ismoving is missing at the end of the macro compiler loop.
So, when the next code is an A axis only movement then the coordinate for the Z axis is the coordinate prior to the macro execution, so with that movement the Z axis rolls back to the previous coordinate.

I looked through a few versions including the 1.2021 which Derek mentioned that this code is working OK with that and I realised that this issue gets into the macro compiler when we rewrote it, when we've added the exec.Codelist function.
Now I've added the missing while ismoving to the end of the macro compiler.
So, this issue was elliminated now and will be OK in the next release which will be coming out really soon.

[Derek]

Hi Balazs, Thank you for checking into Dereks problem.

(;-) TP

Well if it's a compiler error it's everyones problem:) I'm just the lucky guy to trip over it.

This is the biggest reason I switched to UCCNC. Things get fixed.