Probing/Ohmic faults.

I recently observed  2 faults with robing and ohmic combined. Maybe they have been resolved

I always adjust as much hysteresis as I can out of the float switch..

Fault 1 
with low probe hysteresis, the probe fired close to the same time as the ohmic sensor. QTP errored with a probe triggered when it shouldn't error and stopped. We had to increase the float switchhysteresis to mkae it work,,,

Fault 2 
With ohmic probe retry set to 3 x, one spot on the sheet was not conductive. it would probe and fail 3 x ohmic before letting the float switch set the height. Shouldn't it just see the probe hit on the first attempt and say oh, we have to use the float switch and set the probe height based on the float switch? eg. not do all 3 attempts of ohmic probing...It seems really time consuming to do 3 x probing for no reason.

Thanks, You are lucky my float switch has been broken for years so I've not annoyed you with stuff like this before.
I guess you can ignore me now I've sold my plasma table but....

Float switch hysterises is the enemy  of production output as it affects job speed. I added an adjustment screw so  could dial out hysteresis.

It seems to me both instances are subomptimal.

#1 if ohmic has fired, the float switch could be disabled in the interest of production speed. We have a valid material height trigger so it should be left to run its course as it will be moving up in its own time, We know that letting the float travel soak up overtravel when probing at speed is a valid strategy. Let it be and no harm will ocurr.

#2 The ohmic process should not be independent to float switch as it is now. If the float triggers with Ohmic enabled. shouldn't it be respected?
Where a float switch is triggered and ohmic isn't, then it should proceed to a float switch probing process and ignore the ohmic cycles as it makes no sense to keep flogging a dead horse.
Where an ohmic sensor is triggered then let ohmic take its course.

Some of the early decisions we made are not logical in my view. I know I've put a paw in this area before and some improvements have been made but we can still improve on the process....

 

rodw wrote:

The ohmic process should not be independent to float switch as it is now. If the float triggers with Ohmic enabled. shouldn't it be respected?

It is if the Ohmic Retries value is set to zero, which is the default.

Where a float switch is triggered and ohmic isn't, then it should proceed to a float switch probing process and ignore the ohmic cycles as it makes no sense to keep flogging a dead horse.

Then leave the Ohmic Retries value at zero.

I think re #1 if it bites, you have to reset probing so its a lot more than a few milliseconds.
It was the first time in a few years I had a ohmic sensing fault. Just a dirty bit of steel laying on the machine. Of course knocking over an oilcan sitting on it did not help.

Even on a half sheet table, we were doing 500-600 pierces in a single run so every second counts. 1 second extra piercing time is 10 minutes in the run and there usually there are multiple sheets cut in 3 sections so 2 full sheets = 1 hour.

Piercing is a really citical process that should be optimised to shave off those milliseconds....

Considering the number of probes that PlasmaC/QtPlasmaC has done (probably in the millions) and this situation has been reported once I don't think that we have too much of a problem. I have never seen this happen even when probing at full Z axis speed.

When this occurred had the Z axis slowed down to Probe Speed or was it at full Z axis velocity?
What was the actual Z axis velocity when this occurred?
What was the Float Travel parameter when this occurred?
What did you change the Float Travel parameter to?
Was Float Travel the only parameter that you changed?

Edit: Oops, I forgot to ask what is the Z axis max acceleration setting?
 

Probe height was 10mm
Probe speed 300 mm/sec  and it was active
Float Switch Travel = 0.9999999999999996
(wonder why it wasn't 1.0?)
Float switch travel was not calibrated at the time

I appreciate this is a corner case, and the solution is to increase the float switch hysteresis.
But Qtplasmac generated an unnecessary error. It confused me becasue I've never seen it before (cos I never had a working float switch before)
I've probably done a few million pierces here and never observed it either. In fact my float switch has probably never worked since I installed QTplasmac. Sorry I've just tested out this area for you.... 

I might add its possible that the hypersensing with THCAD-5 could be a factor becasue its so quick to respond with no relay hysteresis in the system.
In fact, its probably a testament to the hypersensing that I ran all this time without ever needing a float switch as backup.

The example I quoted was a real life example of a recurring production job cut on my table and you trivialise it. That is not respectful.

Its really pointless continuing the conversation. You clearly have  no interest in incremental improvements to qtplasmac anymore.

I don't have any interest in QTplasmac anymore because I have sold my plasma and it left the building  today.
But the point is QTplasmac is manufacturing an error for no valid reason. This infers a lack of understanding of the parameters at play when it was originally coded. I know some of my suggestions to improve probing speed were incorporated but this one seems to have been missed.

I know I see things differently because of the many hours I spent getting to understand how plasma worked back when there was no viable plasma config. Who else plotted 16000 realtime readings from halscope and analyised the data statistically and graphed the results? I look for the exceptions to see what can be improved. One example is the spotting algorithm which came from observing behaviour after accidentally doing something similar. Others might have missed it but I didn't and now its in QTplasmac.

It has been a good journey and a lot of my ideas and suggestions have been absorbed into the project since I was probably the second user to adopt it using Phil's original private repo. All I can say is to don't give up on incremental improvements or the project will become stale against other options.

I may return to the fold cos I have a fully built Mesa control panel and a complete Z axis torch lifter

I also want to explore ethercat solutions using 220v AC servos with abolute encoders and custom homing code because it should be possible to almost totally eliminate wiring on a table by using $45 ethercat IO modules mounted on the gantry and a single 24v power lead.