How to update from GIT

Guys
Guys thank you for all the effort, I was off selling at a market today ( I know it really sucks to have to hustle pieces to old ladies ( well I am sure that my wife qualifies as one of those)). I really need to get a few sheets of parts cuts so I can take them to the powder coat contractors on Monday. I will update my working configuration as soon as I get the urgent production cutting finished (hopefully tomorrow some time).

This is really exciting to have the arc blending problems solved. This is one of those problems that I know effects the quality of the parts I produce but the general public is oblivious unless you point out the defects.

Sorry my grammar is so poor. A big thank you to all the devs, This is now getting to the point that LinuxCNC is going to be the killer app for plasma cutting if you ignore the megabuck proprietary solutions.

Ok, I am thick. Please explain the reverse run to me. I know that presently I can't back up if there is a problem cutting without making a new cut file ( this works but is cumbersome). I really want to be able to just back up to the end of the last cut and start over without editing the cut file I know the CandCNC Command CNC port of LinuxCNC can do this but I haven't been able to figure how they made it happen. I know they use two modified source files that handle the Gcode preview window but the details are beyond my skills( PM me and I will tell you what I think I know).

John

andypugh wrote:

It is seeming very likely that external-offsets and reverse-run will be merged into master pretty soon, and then the TP fix will go in on top.

Thank you Andy. I appreciate your efforts and I am sure others do too!

Hi Islander,

Please explain the reverse run to me. I know that presently I can't back up if there is a problem cutting without making a new cut file ( this works but is cumbersome).

The reverse run is a name declared by Rob Ellenberg, the developper / programmer of reverse run.
Reverse run is in fact only an expanded "adaptive feed" function.

Currently adaptive feed is in linuxcnc available in G-code function's.
Normally the adaptive feed value is between 0 and 1.
0 = zero speed, 1 = maximum speed. And adaptive feed has to be turned on (enabled) in top of the g-code file.

The idea from Rob Ellenberg was to do a negative adaptive feed.
For maximum negative feed we use the factor : -1
The output of this value is that the machine wil go back on his current g-code pat'h until a M3 is reached. So is will not
go further back then your torch start point.

In the grotius gui the adaptive feed is alway's on. This is programmed in the user interface python code. So in g-code is has
not to be turned on. That make's the g-code file cleaner.

Using the speedwidget designed by Mr. Morley and Mr. Norbert for touch screen's, this widget can not have a negative value.
So in the speedwidget.py file we can change the minimum value to -1.

On youtube there are a few video's how negative adaptive feed is reacting in practical way. The example show's a spiral with
forward and backward's movement's.

For plasma we add a timer in the THC component. If arc fail's on pat'h we say :

Negative_adaptive_feed = -1
Timer = 2 second (what user want's)
Then,
Restart procedure.

So it's a very usefull option, and give's power to the user. User can use adaptive feed as machine speed controller.
So the program speed or the jog speed is in fact slave to the adaptive-feed. And that is nice.

Andy

Thank you for getting this into a form I can use. I had the following problems when installing the patch but I think they are just warnings:and when running "make" part of the terminal output:
Sorry I didn't run a before test. I have also done a "dry run" test to see how this patch works. The code segment displayed on the Halscope trace is:
Screen shot of path preview:


Ok, here is a Halscope output for some signals while this code is executing.


The motion.requested-vel trace is just as we want it, the output of the TP showing a constant velocity. The problem is that the motion.current-vel trace shows a slowdown at the exact point that gets a "divot" when live cutting. So for the time being I am not sure about what is going on. The other traces shown have to do with the Z axis motion, position, commands and errors to see if this is caused by Z motion, which it is apparently not.

I have run out of time for testing today so this is all until next week after market.

John

very nice work

Andy, thanks for your part in the background pushing this through. We really appreciate it.

islander261 wrote:

The problem is that the motion.current-vel trace shows a slowdown at the exact point that gets a "divot" when live cutting. So for the time being I am not sure about what is going on
John

John, I kinda think this is expected behaviour. The trajectory planner for some reason has decided it cannot honour the requested velocity and has reduced it to what can be done by the laws of physics for that line segment. But at least it has not stopped motion!

Is it the inside cut where the green line is that you are cutting? Maybe you can modify the drawing to use a rounded corner.

Bugs aside and apart from from altering the g-code, I think the only solution is to improve the acceleration profile of the machine. That might imply some expense (for high performance servos etc)....

I would trial that in a Sim by increasing the X,Y acceleration significantly from your current settings to see if the dip flattens out.

Rod

Sorry for not being specific about the cut. The cut in question is the long split in the beak that runs diagonally down the part. It is composed of two arc segments. The slowdown is centered on the junction of the two arcs. Using the eyeball method it should only take minor changes in velocity for the trajectory to stay on the path. The other strange thing is the difference in the time to accelerate everything to speed at the start of the cut and the time it takes to slow down to a stop at the end. This is a stepper system so the controller has no knowledge of the real position during the cut. The system doesn't loose any steps at the velocities and accelerations I have set.

I have done significantly more testing of this location and a couple of others. This is a blending issue because I can alter the the actual cut path and force the TP to make the whole cut one straight line by using extreme values of P and Q with the G64 instruction. I have also tried setting the arc blending to the "old" method in the TRAJ section of the .ini file with no apparent change in the results. I have run out of ideas for testing at this time. If anyone has any suggestions for things to look at I will. For now I am putting this into the "just the way it works" box and living with the results. The new TP blending fixes have cleaned up many other problem spots.

John

John, I would log it on Issue #447. Even though its closed, the right people will see it and a fix may be forthcoming.