Page 1 of 1
Soft limit handling in 1.2042
Posted:
Sat Jul 08, 2017 12:04 pm
by Derek
Just tried it out. Right now it just starts machining and then blows past the soft limit point and hit's the hard limit. In effect it's just turning off soft limits for that session.
I'm assuming this is to try and find a work around for soft limits and work offsets in Gcode. Would it be possible to just have a warning window with override option? If there was an override with the default being yes on the enter key then you would have a warning and then have the option to easily override it by hitting the enter key.
Thanks
Derek
Re: Soft limit handling in 1.2042
Posted:
Sat Jul 08, 2017 12:36 pm
by cncdrive
Hi Derek,
How the softlimit function works was not changed in this version.
The only thing what was changed is what happens if the Softlimits are enabled, but the g-code precheck is disabled and the axes reach the softlimits from g-code execution.
This scenario was not handled properly which was fixed now. In other words the only thing what was changed is how the API notifies the UCCNC and what actions the UCCNC makes then to stop the code execution.
We have tested it with several different settings and it works fine here.
Please remember that the softlimits are in machine coords, so if the axes blows over the softlimits might be a home position problem.
Also please note that when executing g-code currently the UCCNC not precalculating for the softlimits (like it does when the softlimits are reached with jogging) and this means that the softlimit reach is detected only when it is really reached and then the axis/axes deccelerate, so they going over the softlimit point with the decceleration path length and then the axes move back to the softlimit coords.
If your hardlimit is closer to the softlimit point than the decceleration path that will be a problem, because then the axes will crash into the hardlimits when they deccelerate from the softlimit point.
We working on different things now and so the precalculation of the softlimit points will be not made soon, we have it planned, but it would take too much time and there are currently more important things for us to develop, so making this development is now on the bottom of the list. The solution for now is to define the softlimit point far enough from the hardlimits, more far than the decceleration path length with the fastest feedrate of the axes.
I don't understand the override suggestion. Could you please describe?
Re: Soft limit handling in 1.2042
Posted:
Sat Jul 08, 2017 1:17 pm
by Derek
Hi Balazs
Right now with the pre check on I get a warning window if the gcode wants to send an axis past the limits. If that window gave me the option to ignore it then if I was sure it was ok then I would click on override. The only time I have issues with soft limits and Gcode is with multiple work offsets and or G53 in code. Most times I like having the pre check since the majority of the time I'm running a single work offset and no G53 in code.
So when I push run and the code wants to send the machine out of limits or the code had multiple offsets or a G53 then the popup warning box would be exactly like it is except you would have the ability to override if you wanted. Then I could choose what to do.
Having the override default to yes on enter would be best for me since I would get the warning every time I ran that code.
Re: Soft limit handling in 1.2042
Posted:
Sat Jul 08, 2017 1:29 pm
by cncdrive
OK, I understand the basics of what you want.
And yes G53 is currently problematic with the g-code precheck, but it should work fine with the API softlimits.
We will try to implement the proper G53 and different offsets and softlimits precheck in g-code, but it requires lots of code changes, so we did not start working on it yet.
Some questions:
- Do you want to override the g-code precheck or the API softlimits? Or both? Or separate options for both?
And I've attached a short video, a screen capture of what should happen when the softlimits are enabled and the g-code precheck is not.
The softlimit+ on the x-axis is set to +20 and the offset is 0, so the axis stops on the +20 coordinates when the 20 coordinate is reached with g-code execution.
The thing is that the axis starts deccelerating at the exact softlimit point and so the movement overshoots a bit can be also noticed on the video.
Re: Soft limit handling in 1.2042
Posted:
Sat Jul 08, 2017 1:57 pm
by Derek
I Don't get that window when it reaches the soft limit point. That may be because it's rolling past the hard limit switch and at that point the BOB is probably overriding.
I only want the ability to override the soft limits when they are in code. I always want the jogging soft limits to stay on unless I go to config and turn them off.
G53 works fine as long as it's not in code. I want to know if there is a problem before the machine moves not when it gets to the problem.
Re: Soft limit handling in 1.2042
Posted:
Fri Jul 21, 2017 3:39 pm
by Battwell
i use g53 in a lot of my code for end of run positioning, probing, tool changer etc.
would it be better if i put all these moves into macros?
Re: Soft limit handling in 1.2042
Posted:
Fri Jul 21, 2017 7:51 pm
by Derek
Battwell wrote:i use g53 in a lot of my code for end of run positioning, probing, tool changer etc.
would it be better if i put all these moves into macros?
If you use soft limits you will need to. At least I'm having to. This is one area that has given me fits from the very beginning.