Soft-Limits in some cases not correct

[BigAl]

Hi together,

I'm using the latest official version of UCCNC (1.2029). I have two problems with the software limits:

Problem 1: The software limits are not accurate when the axis are moved by G-code. If I have for example a limit of Xmax = 500 and I send via MDI "X600" the the axis starts to move. As soon the software limit is reached, the axis show a message, that the software limit was reached. But the axis now starts to stop via the configured ramp. This means the axis crashes - in my case - to the hardware limit. Normally an activated software limit should be respected under all circumstances. Therefore the axis should stopped at the software limit by start breaking early enough to not overshot the limit...

Problem 2: When I move two axis simultaneously via keyboard and one axis is at the software limit then the other axis (that is not at the limit) stops immediately, without using the breaking ramp. My axis are very heavy and this is physically not possible on my machine. This means I "loose steps".

Does nobody (have the same issues? I searched this forum but I found no post about...

Alex

[cncdrive]

Hi,

I'm not sure about point 1., but I remember that point 2. was fixed, but was not officially released yet.
Could you please try the latest test release to see if point 1. issue still exists? Point 2. is sure already resolved in the latest test release.
viewtopic.php?f=2&t=240&start=30

[BigAl]

Hi,

thank you for your answer. Today I will try out the newest (not yet official) release on my machine. I already tested the demo version without any controller connected. It seems you are right and the second problem is solved. But the first one - I think - is not solved yet. If you try it out as follows:

1. Set the X-axos to a very slow ramp (e. g. X-Accel. = 10 units/s²)
2. Set the limit (e. g. Xmax = 500)
3. Try to move from any point lower the limit through the limit (e. g. "X1000")
4. Soft-Limits are on.

In this case the axis starts with the configured ramp and moves toward the target. As soon the limit is reached the axis stops now immediately without any breaking ramp. In the older version the axis was stopped using the braking ramp. In my opinion the axis should break in advance and never travel over the limit. But this was only a "dry test" without connected motion controller. But I'm sure it is the same situation in real.

Thank you

Alex

[cncdrive]

I looked after the mentioned issue and you are right, it works like how you've described, that when g-code not jogging stops the motion on the softlimits then the stop happens only when the limit is reached and then the axis deccelerates and moved back to the softlimit point.
This is the a current limitation in how the softlimit handling is implemented.

The issue is that the controller currently does not precheck the interpreted g-code to see in advance if the softlimit will be reached, it simply stops if the limit is reached.
The prechecking is only implemented with jogging, when the axis starts the decceleration to stop on the softlimit coordinates.

So, currently this is a limitation and I will have to talk to my collegue and ask him when can we implement the precheck thing.

For now what you can do is you can set your softlimit a bit further than the physical endpoint or you could even program the home position a bit offset, so the limit switch will not getting triggered from that little overtravel when reaching the softlimits from g-code. I know you will loose a little bit of workspace, but there is no other solution at the moment.

[ath1200@free.fr]

I'v also a problem with softlimits, the program doesnt care about G53 into a gcode file !!!!

[BigAl]

I think the soft-limits must be checked overall in the software. This is an essential thing that must work, because this could damage machines. I checked some other software from other suppliers and some of them handle this very easy: If a target position is behind the software limit an error will be displayed and the command will be rejected. This can be handled on the software-side and is not necessarily be placed in the controller.

Especially for me it would be got to have safe software limits because I'm programming a lot of macros at the moment. If I'm not careful or if a value is not as expected it is always possible that I drive through the limits.

And again: For me this is the biggest issue at the moment of UCCNC. Beside this I found no better software for a reasonable price (and I tested a lot of machine control software packages).

Alex