Some thoughts and some findings using PlasmaC

It works, and it does that elegantly and with style, from the wizard that is by far the easiest to use and full of features, to reducing speed for holes and making it possible to actually do usable holes of 20mm diameter on 15mm thick material!
That being said, most of what is written bellow is my fault for building very fast machines, and that brings the first issue:
-using speeds of over 3m/m for the Z axis will very often over run the soft and/or hard limits requiring to switch to joint mode and jog the Z axis down manually, then back to world mode to continue work.
-probe/floating switch is active only during auto mode, so bumping the torch into something while jogging will not stop the machine. It would be safer to have it active all the time.
-in portrait mode the jog speed is stuck at the highest value, in my case at 36m/m, while the jog slider is where it should be and moving the slider will set the speed correctly. Not sure if this is PlasmaC or Axis GUI issue, will do some more tests and report back.
Another feature already discused with Phill is ignoring the float switch from the moment the torch on singal is active till the arcok goes true. This is to awoid arc lost issues caused by unshielded and cheap proximity sensors as they are usually located near the torch and i did encounter that issue.
As for what works, well everything i did test works perfectly, THCAD tracks the material smooth and fast, Proma THC works nicely in mode 2 and the tracking speed can be adjusted to awoid "bunny hopping" the torch, materials work perfectly setting the feed rate and all the parameters, touch off button (when added) works and reloads the part in gremlin makes using a laser for edge finding a single button affair, load sheet works, change consumables works and can be set as needed, pierce/cut feature works and is very usefull for thicker material to save consumables as one can use old consumables for piercing and new ones for cutting. Yes, nozzles will get messed up when piercing, shortening their life.
Everything i did test works, so thank you Phill for the amazing work, and thanks to all who contributed and helped in developing this magnificent piece of software and hardware ( looking at you PCW ) .
Regards,
Tom.

tommylight wrote: -using speeds of over 3m/m for the Z axis will very often over run the soft and/or hard limits requiring to switch to joint mode and jog the Z axis down manually, then back to world mode to continue work.

Does that happen with Z moving down, up or both?

-probe/floating switch is active only during auto mode, so bumping the torch into something while jogging will not stop the machine. It would be safer to have it active all the time.

It is active, as is breakaway. They just don't do anything. It would be possible to issue a feed hold but I guess we would also need to pop up a warning otherwise it may cause confusion.

-in portrait mode the jog speed is stuck at the highest value, in my case at 36m/m, while the jog slider is where it should be and moving the slider will set the speed correctly.

I'll have a look tomorrow, it is probably something dumb that I did.

Another feature already discused with Phill is ignoring the float switch from the moment the torch on singal is active till the arcok goes true. This is to awoid arc lost issues caused by unshielded and cheap proximity sensors as they are usually located near the torch and i did encounter that issue.

I have done a bit of work on that but I need to figure out how to build in compatibility for users who have a combined float/breakaway switch, namely me.

I really have to agree its an amazing body of work. After joining Tommy's high acceleration club, we had a couple of instances on Friday where the plasma cutter overheated in among 1200 or so pierces and it dropped arc OK. Recovery was seamless.

Any crash sensing needs to be restricted to the float switch because any users using hypersensing will not be able to use the ohmic probe as it will see the arc voltage (by design) while cutting.

I've never had problems with the z axis but its not fast yet.

I guess I've been pretty successful incorporating suggestions in to Plasmac so thanks Phill for that.
Issues of concern for me are:
1. Upgrade process broken my config and duplicated ini file entries. Whilst it might be great for a new user starting with the release of 2.8, my config is not that old so I found that frustrating. Some pin conlficts I resolved were with (much) earlier pncconf settings.

2. Solely dependent on Phil to manage the code base. As more plasma centric features are added to Linuxcnc which potentially obsolete some of Phill's hard work, he might not want to do the rework to improve the code. He's off the hook now but I have lots of ideas on how to take what we are doing to the next level. Look out if I ever retire!

3. Lack of end points to integrate custom features. There is a lot of work to unhook stuff cleanly to extend Plasmac. At a minimum, there should be a hold THC input pin available for the user. What if Stivemaster13 wants to override torch height while cutting holes?

That will do for now, I need Phill in the morning

phillc54 wrote: Does that happen with Z moving down, up or both?

UP, during cutting, when esc is pressed, after several cuts, seems like a cumulative error.

phillc54 wrote: It is active, as is breakaway. They just don't do anything. It would be possible to issue a feed hold but I guess we would also need to pop up a warning otherwise it may cause confusion.

On my config it will disable everything requiring F2 to be pressed to continue, also an error is reported as joint3 in my case.

phillc54 wrote: I'll have a look tomorrow, it is probably something dumb that I did.

Just checked, in landscape mode it is OK.

phillc54 wrote: I have done a bit of work on that but I need to figure out how to build in compatibility for users who have a combined float/breakaway switch, namely me.

Ignoring both will not do any harm as the machine will never be moving while that ignore is active.

rodw wrote: I really have to agree its an amazing body of work. After joining Tommy's high acceleration club,

It's such a nice club !

rodw wrote: Any crash sensing needs to be restricted to the float switch because any users using hypersensing will not be able to use the ohmic probe as it will see the arc voltage (by design) while cutting.

Will not affect that as it should be ignoring signals from torch on to arc ok.

rodw wrote: 1. Upgrade process broken my config and duplicated ini file entries. Whilst it might be great for a new user starting with the release of 2.8, my config is not that old so I found that frustrating. Some pin conlficts I resolved were with (much) earlier pncconf settings.

Close LinuxCNC before upgrading or reconfiguring the configs, bumped into that a few days back. Having LinuxCNC running will mess up the config as it can not read and write stuff it needs to.

rodw wrote: 3. Lack of end points to integrate custom features. There is a lot of work to unhook stuff cleanly to extend Plasmac. At a minimum, there should be a hold THC input pin available for the user. What if Stivemaster13 wants to override torch height while cutting holes?

It already does that by itself when corner lock is active. Seen it work. If you mean to adjust the torch while cutting that is different, but then again it can be done by changing the voltage while running.

rodw wrote: That will do for now, I need Phill in the morning

Getting suspicious here !

rodw wrote: Issues of concern for me are:
1. Upgrade process broken my config and duplicated ini file entries. Whilst it might be great for a new user starting with the release of 2.8, my config is not that old so I found that frustrating. Some pin conlficts I resolved were with (much) earlier pncconf settings.

I have several different versions of configs that I keep here from PlasmaCs release until the latest version so that I can test updates. If there are no changes to standard PlasmaC files then all should go well. When you post the new config tomorrow can you post a copy of your config before updating so I can see what happens during an upgrade.