Height Override

At the beginning of the thread, I was going to suggest 1V... mostly because that's what I always thought it did anyways, and the fidelity of the voltage readout is in 1V increments.

Changing by the voltage threshold seems like a logical choice as well. As a bonus, the default is 1 anyways, so I think that will work well!

The only thought I would have is that when the threshold is not 1V it does not directly correlate to the value in "height per volt".

For example (in dinosaurs): 1V = .004" height adjustment. at a .5V threshold, one click now = .002" height adjustment. Which is fine, just something to keep in mind. If you have a .7V threshold, then I require a calculator...hang on... you move .0028" per adjustment.

Either way is fine with me, and should be easy for the publishing house to capture

One other thought...

Am I correct in assuming that "height per volt" ONLY affects this override?

If that's the case, and we change the override increment to the value in THC Threshold, should we change the "height per volt" to "height per Threshold increment"

Or something less wordy, but hopefully you get the idea... make sense?

rodw wrote:

snowgoer540 wrote:

If you have a .7V threshold, then I require a calculator...hang on... you move .0028" per adjustment.

Which is the point I was trying to make. increments of 25.4/0.753 dinosaurs is gunna get confusing real quick if tied to existing variables if they are not round figures...

Yea, I kind of like the idea of having 1V override increments, since that is the fidelity of the arc voltage display, and then you have a clear "height per volt" value. It's not confusing then.

As I believe "height per volt" only affects this override, you can change it to be however big or small you want it to be.

EDIT: Per the PlasmaC manual for "Height Per Volt": This sets the distance the torch would need to move to change the arc voltage by one volt. Used for manual height manipulation only.

So that said, I think it makes sense for the override to be 1V increments, and it will change your torch height by the Height Per Volt value. I think that's what the docs say it does currently, its just that it was recently discovered to not be the case

We change the height by changing the THC target voltage. When there is a height change request detected then we do a quick initial height change to put it in the ballpark.
Currently we use the rule of thumb 0.1mm per V (0.004" per V) for that initial movement. If we go with Threshold as the voltage change per incremnet/decrement then we could multiply that by the Height Per Volt so folk that go to the trouble of measuring their Height Per Volt can get a more accurate initial height move.
Having said that the initial move may not be required as THC will compensate anyhow. It would just give you an earlier look at the change in cut quality depending of course on where in the Threshold window the voltage was when the change was requested.

rodw wrote:

Also, another good feature would be clicking on the word override clears the override value as Phill did with the sliders....

I've never been a fan of hardcoding any values in programs I write. I've been caught too many times. Why couldn't there be a default that could be overridden in the ini file? Next week, someone decrees 0.5 v threshold is the new normal on his super accurate machine and he can't match the GUI to that...

I think we are back to THC Threshold voltage is a good enough value for override increments. Then it becomes "height per threshold" instead of height per volt. Or something more wordsmithy. Phill is good at that, I am usually too wordy.

Nothing is hard coded then.

And easy to document as well I reckon.

rodw wrote:

Also, another good feature would be clicking on the word override clears the override value as Phill did with the sliders....

It may send you into void lock depending on the direction and value.

I've never been a fan of hardcoding any values in programs I write. I've been caught too many times. Why couldn't there be a default that could be overridden in the ini file? Next week, someone decrees 0.5 v threshold is the new normal on his super accurate machine and he can't match the GUI to that...

The only thing hard coded is the initial move, I don't see any issue with that.

rodw wrote:

phillc54 wrote:

We change the height by changing the THC target voltage. When there is a height change request detected then we do a quick initial height change to put it in the ballpark.
Currently we use the rule of thumb 0.1mm per V (0.004" per V) for that initial movement. If we go with Threshold as the voltage change per incremnet/decrement then we could multiply that by the Height Per Volt so folk that go to the trouble of measuring their Height Per Volt can get a more accurate initial height move.
Having said that the initial move may not be required as THC will compensate anyhow. It would just give you an earlier look at the change in cut quality depending of course on where in the Threshold window the voltage was when the change was requested.

I think we are getting too complicated. The speed at which the THC can compensate exceeds the rate at which the GUI can update the value by a long way so why add the initial movement?

Without it you may not get any height change depending on where in the window the current arc voltage is and the angle of the material.

In any case, cutting thicker plate should see the voltage oscillate as the anode spot moves from the top of the material to the bottom during cutting. There is a whole other conversation around that phenomena and THC tracking but the point is you can't usefully narrow the threshold below this natural oscillation.

Nor the amount of "noise" in the measured voltage.

Jammo beckons, I gotta go...