forum.cncdrive.com

Balazs,

Is there a field from which the blended velocity can be obtained (via macro &/ plugin query)?

Such as Mach3 DRO 813
https://www.machsupport.com/forum/index.php?action=dlattach;topic=19482.0;attach=27839

Is there are way the blended distance traveled by the X and Y axis could be obtained (via macro &/ plugin query)?
Like >> Statistics >> Total Run Distance, Sum of X+Y
Or maybe to allow flexibility, any other axis combination?

And finally, Stop with Deceleration... could I ask for a bit of explanation here.
I know with THC, and ArcOK, if the ArcOK is lost, the machine will stop with deceleration and then backup to the point the ArcOK was lost.
Is this a normal function of Stop with deceleration? i.e. if I ask for a Stop with decel, will the machine backup to the position that the stop was received?

Many thanks for your time in advance,

Hi Rob,

Currently there is no DRO for the travel distance.
The path traveled is not really the sum of the axis. Take a simple example that axis X and Y travels one-one unit the same time, e.g. cords are X0 Y0 and G0 X1 Y1 is executed,
then X and Y both traveled 1 units, so the sum of that is 2units, however the path traveled by the tool is only about 1.414 units.
The travel values in the Statistics window are basicly to know when an axis has to be maintaned, those values are not the vectorial distance sum of the path, but the distances moved by each axis shown separately.

The stop with decceleration is made if the Stop button code is called, in this case the axis is stopped using the decceleration settings and stopping with deccelerating down to 0 speed.
The other case is when the machine is stopped instant, this happens when the reset condition occurs, the reset button code is called by button call or by a limit or e-stop input.

The machine moves back to the stopped position only when in THC mode and when an arcOK signal is lost, it does not move back to the stop position in any other cases.

The stopping with decceleration we think is a must when pressing Stop, because stopping instant when a machine travels with high speed is very risky can be destructive to the mechanics and can cause lost steps with open loop steppers.
We are used to build large scale machines in the range of about 500kgs to 5tons with many meters of workspaces.
We built machines where the moving gantry had around one ton of weight and you can guess stopping that axis instantly when it travels with rapid is not very healthy to the machine mechanics.
Ofcourse it has to stop on reset as fast as possible, but not when it is simply commanded to stop.

And stopping instant is a must if a reset event happens since that is an emergency event when the machine must stop as soon as possible, possibly immediately and then it is adviced to re-home the machine if it has open loop control system.

Thanks Balazs

.... Yup kind of forgot about x^2 + y^2 =z^2....

What happens when having an idea, but actually working on something else and failing to multitask....

Thanks for the explanation on stop and stop with deceleration.

Hi Rob,

Yep, the travel distance can be calculated with trigonometric functions.
I think it is already calculated in the motion controller, so probably we only have to expose it to the API and the UCCNC to get this info available.
Will ask my collegue if I'm correct about this...

Hi Balazs,

While on this matter, now would be a good time to ask your colleague if it would be difficult to implement a new feature.

As you said earlier, when THC is enabled and Arc OK is lost, the motion will halt with deceleration then reverse to the position where Arc OK was lost.

For the purpose of restarting a plasma cut, we normally do a dry run along the already cut path, then firing the torch a few mm before un-cut metal (the flameout point). However that requires us to go to the beginning of the current gcode block which could be be quite a long distance in the case of a straight line or a large arc.

A great feature would be if the user could enter TWO distance values which represent positions along the already cut path, and which are minus values from the flameout / Arc OK loss position. The first position is the dry run restart position and the 2nd position is the torch fire position.

If these values could then be put into a macro with a screen button called “Mid Cut Restart” or something like that, and UCcnc would “know” this is a mid cut restart.

Other parameters we could pass this macro are the dry run feedrate and the distance after the flameout point that this temporary slower feedrate lasts. Terry taught me about that one and he uses the temporary lower feedrate on thicker steels because the metal is cold and a running re-start at normal feedrate may not be successful.

It could go something like this:

1. Flameout occurs. UCcnc stops motion with deceleration and reverses along cut path to flameout position.
2. User presses screen button “Mid Cut Restart”
3. A data entry box pops up where the user can enter:
a. Dry run motion start position (distance before flameout)
b. Torch fire position (distance before flameout)
c. Temporary feedrate
d. Temporary feedrate distance after flameout point
4. Finally the popup box has a Restart button.

After pressing "Restart" the torch reverses up the cut path to the dry run start position, starts moving at the temporary feedrate, the torch fires at the fire position, then motion stays at this temporary lower feedrate (if set lower) until the set number of mm after the flameout position, then finally the feedrate goes back to normal.

The macro could also automatically disable THC (if it was previously set) and then re-enable it once the cut is running at normal speed.

I don’t know if any other cnc package would have such a fantastic plasma cutting feature. A lot of guys struggle with doing mid cut restarts and this would make it easy and fast, and completely eliminate the need to go all the way to the beginning of a long distance gcode block. That could be painful if you are cutting thicker material and the feedrate is slower.

Keith.

That was sort of where I was going with some of that, by calling the last line, and run single line, with a stop after xdistance travelled, to input the x and Y dro as the torch refire postition, and the run single line again back to the start point. (or that was the attempt... I can see quite a few issues though)

Robertspark wrote: I can see quite a few issues though

Cmon Rob spit it/them out

Now is the time to talk about any potential problems with this idea, and Balazs can tell us if they can be easily overcome. Balazs/Cncdrive will be the ones who say if it's possible or not.

Keith.

Ok, problems (as a layman) see them
- macro handover plus divot... Getting a macro to fire the torch on the fly and then hand back to the run gcode is going to create a hesitation after the m10... Slight divot.

- stepping back one line of gcode.... No guarantee that it will travel a sufficient distance for the refire position or the torch restart position, hence may require extra steps

I've seen how terry put his macro together and the refire position was interesting (I'd never thought about it before ... Simplistic solution to a pia problem).... Create a crossing window box (square) with a +x, -x, +Y, -y set of coordinates and refire the torch with m10 when it crosses the box .... The error is slight +40% if it happens to be a diagonal motion move .... Probability is probably about 10-30% chance at a guess)

I'm not one for divot chasing... I cut too little to worry about a divot and I don't do artwork but I'm always curious by the math and how stuff works

Good points Rob, this is what I love about brainstorming.

Divots:
Well that is not a new problem created by this new feature. We use the M3 button to start manually in any case. Now when I say "macro" it doesn't necessarily have to be in a macro. This feature could become a core part of the UCcnc coding and does not run in a macro. I would imagine the UCcnc coding would send the necessary moves to the external motion controller buffer. The suggested pop-up box could have a tick box to use M10 for the torch fire, then for those (like you and me LOL) who have created an external hardware method of taking advantage of M10, we can have synchronous torch fire. No pause, no divot.

- stepping back one line of gcode.... No guarantee that it will travel a sufficient distance for the refire position or the torch restart position, hence may require extra steps

Many cases will have gcode blocks (lines) which are short distances. Therefore in this case the torch would simply reverse run the required distance regardless of the number of gcode blocks that took. At the end of the day the feature suggestion is based on being able to reverse run a user defined distance, whether that is a fraction of a single long distance gcode block, or several short gcode blocks.

Keith