Another plasma component...

Guys

I am going to kick the hornets nest a bit here.

A well established fact is that you can ruin a set of consumables with as little as one pierce that is closer to the material than the recommended pierce height. In my experience piercing from as much as 20% too high hasn't had any bad effects on consumable life. So for me that says that you never want any IHS error to leave the distance less than the recommended pierce height. So to me that says that probing should never error short. Now I know that any probing error makes any sort of automatic arc voltage determination a problem but I feel you should only use that when you are working with good probing conditions anyways. Both HT and TD make "long life" electrodes for cutting thin ( < .5") material and the change in arc length in these over the life of the electrode is minimal until end of life. I think that this minimizes the need for using automatic arc voltage detection for those that mostly cut thinner material.

John

Phill

Thank you for all the hard work you are putting into this corner case.

I compiled and tried the component version you posted last night. It behaves about the same as the previous version. The exception being that on the float switch sensing the switch offset to give the correct physical height is closer to value that my branch uses. I tried with debounce delays of both 1 and 5 with the same results except that the float switch offset to get the correct physical height changed by .015. The value of float switch offset doesn't matter (repeatability does) to me because I always set it to give the correct physical height.

I saw that you had some debug code in the component so here is the terminal output when trying to do ohmic probing with the test function.
John

phillc54 wrote:

islander261 wrote:
Please see attached screen shoot on my new screen

John,
I see you show the arc voltage as an integer. Is this normal practice for plasma?

Cheers, Phill

I think the integer display is a Gmocappy thing. The default screen from memory only permitted changes of +- 5 volts. Despite the display, I use a float behind it, particularly when sampling volts (which is so trivial to do, I never set volts manually).

Phill

Here on some thoughts about handling ohmic probing. I think that test for a valid switch release needs to be different for the float switch and ohmic probing. As I understand it the present code checks the distance traveled up from when the float switch closes or the ohmic contact goes true. The case for the float switch looks and acts like it is ok because of the largish distance of the float switch offset you are just checking if it goes too far.

The case for the ohmic probing is different. We are trying to complete a circuit with two dirty pieces of material. The copper shield is usually dirty after a couple of cuts. The steel plate surface usually has mill scale, cutting debris, water and or oil on it, not a good switch contact. I think that one needs to push the shield into the plate a little bit after first contact to help make sure there is a good connection. You always have a floating head and a float switch for safety so compliance isn't an issue. The debounce delay will also cause over travel as the motion will continue until the debounce output changes (this should be equal in both directions). So I think that the test for a completed ohmic probe distance raised should be:

switch closed position + set over travel + plate deflection (distance moved during debounce)< distance raised < switch closed position + float switch offset

If the test fails then raise to safe Z and start probing over again. If there isn't success after say 5 tries then the probing is a failure and we can fall back to using the float switch or as I do raise the torch to Z max and pause the program declaring a probing error.

The main reason my probing is in Gcode is it was easy to modify on the fly (no needing to restart the machine) so it was an empirical development process. I had previous done it for my commercial controller and that was a royal PITA as it required the old modify source code, compile/link and download to controller each iteration.

John

Rod

None of the plasma parts of my gmoccapy GUI work like example anymore. The set point is an integer because I cannot see any benefit of finer resolution. My scaled arc voltage is a float and is truncated to an integer display in the display formatting for the same reason. I just don't see the need for any increased resolution beyond integers for the GUI, flipping noise digits drive me crazy.

John

phillc54 wrote:

Trying to set up the test machine and now I cannot get DNS working...
Nothing is ever easy

Cheers, Phill.

I found sometimes the default route would choose the Mesa NIC instead of the network NIC. I played around with static routes. If you can't ping your gateway that will be the problem but if you can, then Googles DNS servers are your friend (8.8.8.8 and 8.8.4.4)

Phill

If you an't there yet manual configuration almost always works. Google and manually set ifconfig. Sorry I am not a linux/unix network admin, Debian installs always did the work for me so I only had to manually setup my NIC for the Mesa card.

John