Another plasma component...

Tom
Just to be clear, if we use number 2 then if arc failure timeout is set for 15 second then after torch on we wait 15 seconds for ark ok if no arc ok then turn torch off and wait 15 seconds before retrying.

Rod
I am happy to add any feature if there is a general consensus. I would prefer that we didn't add any more dependencies if possible. I am also happy for anyone to clone my repo and submit PR's. I personally am more interested in the component itself, the GladeVCP and Python extras are really just to showcase the component. I don't like the way that Glade hogs the focus when the mouse pointer is over a Glade panel but I needed the Python.

Grotius
I am also an Aussie 'b'. We are multiplying...

Cheers, Phill

phillc54 wrote:

Just to be clear, if we use number 2 then if arc failure timeout is set for 15 second then after torch on we wait 15 seconds for ark ok if no arc ok then turn torch off and wait 15 seconds before retrying.

Wait for a settable amount of time (5 to 30 seconds) for arcok signal, if no arcok then wait for 10 seconds and retry. The amount of time to wait after failure is from 1 to 10 seconds. That is the time needed to reset the internal timers in plasma cutters. The Thermal Dynamics i own does that in a single second, while the Iskra needs at least 3 to 6 seconds ( it varies ), some older ESAB ones do that in 3 to 7 seconds, Hypertherm never needs more than 3 seconds.
Having that also settable would be nice, but leaving it at a set time of 10 seconds does the job perfectly.
The config i use has that set to 10 second wait for arcok and 1 second wait for retry, it has to do the probing again so it gives it enough time to reset the timers. This was done due to slag gathering at the nozzle (from piercing) and when probing several times ( normally 2 or 3 times ) it does loosen up and fall off, thus removing the need for operator intervention.
Regards,

I have just pushed a new version with:
1. fix for arc restart attempts.
2. user configurable delay time for arc restart attempts.

Cheers, Phill.

@Phillc54
That was quick !
It works properly, thank you very much.
The acceleration issue after reverse run seems to affect only the first cut line, the following lines are not affected. Will have to investigate more.
@Rodw
The database proposal is very nice addition to Linuxcnc and should be followed through and implemented. The scope of uses is very wide, not only for plasma.

Tom wrote:

The acceleration issue after reverse run seems to affect only the first cut line, the following lines are not affected. Will have to investigate more.

Yes that is what I found as well. I checked out the rev-run-master2 branch and it showed the same behaviour.

Rod wrote:

Phill, this has now been fixed in 2.8 (master branch) and 2.7 so a rebase with LinuxCNC should solve the problem and avoid the need to work on incorporating the patch Andy shared with Islander261.

This fix has me baffled at the moment. I got a lot of conflicts when I tried to apply Andys patch so I then tried to cherry-pick the individual commits and I also got a lot of conflicts. I have just tried to merge master and get the same conflicts.
It appears that reverse run and the tp fix conflict with each other and it is above my pay grade to fix it (I did try but made a complete hash of it) so it may need robEllenberg to sort it as I think he is the author of both.
In the meantime we need to decide on one of two options until this can be fixed:
1. master with the tp fix + external offsets
2. master before the tp fix + external offsets + reverse run

Cheers, Phill.

Mauro wrote:

could you tell me how to install these changes?

cd into the folder you cloned to
git pull
cd src
make

Cheers, Phill.