Digital Dream Technology support

Title: Suggestion for improvement to SOFT LIMIT feature [Print This Page]

Author: math_indy Time: 2018-10-13 00:28
Title: Suggestion for improvement to SOFT LIMIT feature

On a stepper CNC system like DDCSV2.1 it is always good to avoid "emergency stops" as they do not decelerate smoothly and risk losing HOME position calibration.

As such I admire the SOFT LIMIT feature very much but I think it could be improved:

I have "Soft-limit stop mode" parameter #2030 set to 0 (deceleration) and am running V2018-10-12-102.

Currently when a G01 code orders an axis to travel way-beyond the soft limit it appears that there is no deceleration phase or, perhaps, the deceleration is agressive or perhaps something different from what I have programmed into my axis-specific deceleration parameters #263-#266.

When operating in CONT mode I notice that the deceleration works but DDCSV2.1 only begins decelerating when the soft limit is exceeded.  Because of this I have to put my soft limits more than 25mm away from the hard limit switch point.  With this large 25mm buffer I can approach the limit at full speed using CONT mode and it will decelerate almost exactly to, but slightly before, the hard limit.  This operation is wasteful of table space as if forces me to give up an inch or more on each side of my table.

Since, for every axis, the DDSCV2.1 "knows" both the "current speed" and "allowed deceleration" I suggest that the soft limit feature always "look ahead" to, regardless of axis speed and operating mode, begin its deceleration in advance so that any axis that is trying to move beyond its soft limits will reliably decelerate, trip the alarm, and arrive exactly at the soft limit position.

The exact distance required to stop is, at all times, known by DDCSV2.1:
Stop Distance[mm] = 0.5 * (Speed[mm/min]/60)^2 / (deceleration[mm/s^2])

In G-Code operation this would be easy to implement as any command that orders an axis to go beyond its soft-limit could instead just-order that axis smoothly to the soft limit and then trigger soft limit alarm.

In MPG and CONT modes the DDCSV2.1 would have to always look at the "current axis speed" and "allowed deceleration" and intelligently begin deceleration so that both MPG and CONT commands, no matter what axis speed, also arrive exactly, and gracefully, at the soft limit (then trigger the alarm).

If implemented properly this would allow DDCSV2.1 users to put their soft limits very close to the hard limits--like within 1mm or 2mm of the hard limit.

TOM

Author: ytliu Time: 2018-10-13 06:49
Thanks, I will adopt your suggestion.

Author: Nikolay81 Time: 2018-10-14 17:39
I agree with math_indy. Poor working with the soft limitd, this is one of the biggest problems with DDCSV. Solve it simply.
But with manual movements and when executing G-code, the algorithm should be different.

With manual movements, the axis can rest on its ending, because it needs time to slow down.
The solution is to enter the parameter "speed limit near the ends of the axes" and "offset from the ends axes for the speed limit".
That is, we set, for example, that at a distance of 20 mm from the ends of the axes, the speed of any axis cannot exceed 300 mm / min.
And when approaching this zone, the axis slows down to the set value.

When doing G-code, you need to do it differently. The controller should not execute the program at all if there is an excess of soft limit in it.
This is logical. Since the workpiece will be spoiled.
To do this, you need to make the controller scan all the lines of G-code before execution.
But the height of the Z axis changes with tool changes. Therefore, it is necessary that he scan the G-code lines from this tool change to the next.
That is, the algorithm is as follows:
-Change tool
-After replacement - scanning the program until the next M6
-If an exceeded soft limit is detected on any of the axes - a message box is displayed "Exceeding soft limit along the axis -, in the row number ----. Continuation is impossible"
-If there is no excess - the continuation of the program.

Naturally, you need to do so that this feature can be turned on and off for each of the axes separately.

Author: ytliu Time: 2018-10-14 22:33
Ver:2018-10-12-102 Description:
1. Add G20/G21 recognition macro variable (#448): in G20 mode, #448=25.4; in G21 mode, #448=1, used to correct the bug that G28 and G153 instructions execute errors in G20 mode;
2. Correct the error that the detection command M101/M102 stops processing during the machining process;
3. Change the soft limit response mechanism in the manual mode, pre-judicate the soft limit, and increase the #2032-#2035 pre-judgment coefficient to adjust the pre-judgment bias.

The soft limit response mechanism in automatic mode has not changed temporarily. I agree with Nikolay81's idea that it should be discovered and prevented in advance. However, scanning gcode file can take a lot of time, especially for larger gcode files. Let me consider it again.

install(2018-10-12-102)-1.zip

597.16 KB, Down times: 1564

Author: Nikolay81 Time: 2018-10-15 19:36
Thanks Ytliu. The problem with the soft limit when manually moving the axes is solved. You, as always - the best.

There is an error in this firmware:
-Parameter # 448, can be equal, only 1 and 2. And you wrote that it can be equal to 25.4.

As for the soft limit in the G-code mode, I assumed that the controller might not have enough power to scan the entire program.
I have a good solution. And this solution will simultaneously solve the problem of incorrect calculation of the processing area for visualizing the tool path.
As they say in Russia "we will kill two rabbits with one shot" :-)
The fact is that perhaps the DDCSV processor is too weak for such tasks. But the power of a PC is enough to scan several thousand lines of G-code in a few moments.
I propose to implement the definition of the processing area, at the level of the postprocessor.
That is, at the beginning of any G-code file, 6 variables are defined that define the boundaries of the axes for this program.
The controller, after each M6 command, compares the machine coordinates with the value of these variables. And if they go beyond the soft limit, a message box is displayed.
Also, the value of these variables is used to determine the size of the visualization area of the tool path.
At the end of the program, the value of these variables is reset to 0.
If the variables are not defined, the implementation of the soft limit occurs by the usual algorithm.

On a PC, this is implemented as follows: a simple program is written that scans the G-code file for maximum and minimum XYZ values.
Then it appends the necessary information to the beginning of the file and overwrites the open file.
The program has no interface. All its settings are stored in the ini file. Opening a G-code file is done from the command line, or by dragging and dropping a G-code file onto a program shortcut, or from the Windows context menu (that is, all 3 methods work).

Basically, the program will be automatically executed after the postprocessor. In many postprocessors, there is a function to open the finished G-code file defined by the program. Usually, this is a notebook. And in this case, we change in the settings of the CAM system, the Windows notepad to our program. Thus, program files are created already modified, without "extra gestures."
But it remains possible to modify the files manually, by dragging the G-code file onto the program shortcut, or from the Windows context menu.

I will create the program myself if you implement this feature on DDCSV.
If you do this, the soft limit function will be implemented on DDCSV, better than on most professional CNC machines.
This will certainly interest buyers. And the visualization function of the tool path finally works fine.

Author: Nikolay81 Time: 2018-10-15 20:08
Two more errors were identified:
-When # 2031 = Yes, the acceleration-deceleration of the axes varies greatly with G1 / G0. Try running G-code.
-When M101, after the appearance of the signal Probe, usually used the command G92, which determines the new coordinates.
But, it works, only at value XYZ - 0.
That is, this code will work:
M101
G1 X100 F300
G90G92X0
G1 X-10
M102

And this is not:
M101
G1 X100 F300
G90G92X2
G1 X-10
M102

Author: ytliu Time: 2018-10-15 21:56
probe instructions
M101 or M103 is used to turn on the probe func. After turning on, in the subsequent motion, if the probe signal is found, the motion will stop. M101 differs from M103 in that the effective level of the probe signal is different.
M102 is used to turn off the probe func.
M101 or M103 must appear in pairs with M102.
E.g:
M101
G91G01Z-100F_
M102
G04P0; synchronization, where P must be 0
M103
G91G01Z100F_
M102
G04P0; synchronization, where P must be 0
G90G92Z_

First, M101 turns on the forward probe func, then the Z axis moves down 100mm at the set speed. In this process, if the level of the probe signal changes from '1' to '0', the motion stops, then M102 turns off the probe func, and Synchronize.
Next, M103 turns on the reverse probe func, and the Z axis moves up 100mm at the set speed. In this process, if the level of the probe signal changes from '0' to '1', the motion stops, and then M102 turns off the probe func. And synchronize.
Finally, execute G90G92Z_, set the Z coordinate of the current position to the set value.

Author: ytliu Time: 2018-10-15 22:02
#448 is a macro variable, not a parameter. The parser assigns it, if it is in G20 mode, #448=25.4; if it is in G21 mode, #448=1.

Author: ytliu Time: 2018-10-15 22:11
Your advice on the soft limit is very good, I will increase the corresponding processing.

Author: Nikolay81 Time: 2018-10-16 00:12
Thanks Ytliu. I got it.
I would like to adjust the function of the parameter # 2031.
When enabled, the acceleration of the axes varies greatly with G1 / G0.

Author: ytliu Time: 2018-10-16 06:15
Please tell me your relevant parameters and provide a simple test gcode . Thank you

Author: Nikolay81 Time: 2018-10-16 18:06

ytliu Posted at 2018-10-16 06:15
Please tell me your relevant parameters and provide a simple test gcode . Thank you

Sending my settings and test program.
The fact is that to accelerate-decelerate axes in G-code mode, it uses data from parameters 45-48.

As for the external program for calculating the processing area, I think you can assign another important function to it, which is very lacking in DDCSV:
Calculate the time until the end of the program and until the next tool change. The value will be written at the beginning of the program, in the form of a variable.
And knowing this data, DDCSV will be able to:
-Rightly define the processing area for the soft limit
-Rightly define the processing area for the visualization of the tool path
-Display the time until the end of the program or until the next tool change (this is very important when changing the tool manually)

Most postprocessors can run an exe file with parameters.
Complex postprocessors (such as Powermill and Solidcam) allow you to implement these features without an external program. Only by their own means.

How do you rate this idea? Do you like her?

17.rar

4.96 KB, Down times: 876

Author: math_indy Time: 2018-10-17 04:32
I tested the soft limit changes in version V2018-10-12-102-1 and I like what has been done--a big improvement for STEP, MPG, and CONT modes and I was able to safely move my soft limits much closer to the hard limits.

It is OK with me if soft limit behavior in automatic (G-CODE) operation is updated later. I am unlikely to write a program that would command to a location outside of the soft limits anyway. However, in the G-CODE case, it would be OK with me if the offending G-CODE triggered an immediate soft limit error without ever moving the axis at all. This or maybe go to the soft-limit, stop there, and trigger the alarm--either behavior would be good.

Author: Nikolay81 Time: 2018-10-29 22:02
Video of malfunction of parameter # 2031.
https://radikal.ru/video/wkq5retOtHU

Author: ytliu Time: 2018-10-30 06:30
When #2031 is set to 1, when the component of acceleration(#99) in each axis is less than #45-#48, the acceleration is determined by #45-#48.

I watched the video, I think there is no problem, the action in the video is consistent with my design idea.

Author: Nikolay81 Time: 2018-10-30 18:19
Perhaps we do not understand each other.
I have #45-#48=3 and #99=400. That is, #99 is more than #45-#48 and not less.
In the video, I execute the code:
G1 X30 F600
G1 X0
For manual movements, there must be a low acceleration in order to more accurately position the axes.
For G-code, there should be as much as possible acceleration, because:
-It reduces processing time.
-The axies must accelerate to working speed as quickly as possible, because some materials cannot be cut at low speed. This leads to overheating of the cutter, burning of the material or sticking of the material to the cutter.

If this is the case, please make it disabled. Because such a decision makes it impossible to use this setting in most cases.
Because:
With a low acceleration rate, many materials cannot be cut.
There are many such materials. For example: wood, pure aluminum, thermoplastic plastics, and so on.

Also, if you set a high acceleration speed for axes in manual mode, the axes are difficult to position.

Welcome Digital Dream Technology support (http://bbs.ddcnc.com/)