(Solved) PlasmaC new config Z going up when probing

phillc54 wrote:

The usual reason for not reading zero is the calculations are incorrect or they are made incorrect by the divider being incorrect. Did you follow through the testing Rod suggested here:
forum.linuxcnc.org/plasmac/39562-help-wi...smac?start=50#175793
.

Ok Thanks Phill for checking the hal files we made the adjustments and the probing is now working fine

Now the -ve voltage problem and THC
.

Rod quoted : You need to work thru this progressively. But if you have a negative 0 volt reading its a software issue becasue 0 volts on the THCAD is a positive number (3637.5)

Use halshow to check that the encoder count is near 3637.5 when not cutting. Does that look right?

The calculated number are. Scale: 0.007539 Offset: 3637.5
On my machine that is working one. The encoder count is a -ve number but on the other machine it is +ve
Also the encoder position numbers mine is +ve and the other machine is -ve

In both hal files these are the same setp hm2_7i96.0.encoder.00.scale -1
changing this from -1 to 1 make the volts be zero when not cutting and +ve when cutting

This make the voltage displayed correct at 0 and when cutting and what the 45Xp displays

But the THC still does not work

I would swap the encoder scale from negative to positive. Its possible the input is stuck in the wrong sign.

phillc54 wrote:

Clive wrote:

The calculated number are. Scale: 0.007539 Offset: 3637.5
On my machine that is working one. The encoder count is a -ve number but on the other machine it is +ve
Also the encoder position numbers mine is +ve and the other machine is -ve

In both hal files these are the same setp hm2_7i96.0.encoder.00.scale -1
changing this from -1 to 1 make the volts be zero when not cutting and +ve when cutting

This make the voltage displayed correct at 0 and when cutting and what the 45Xp displays

Is it possible the polarity is wired incorrectly to the input and/or output of the THCAD? I have no idea if that does make a difference or not.

But the THC still does not work

Is it in Auto or On mode in the run panel settings?
Is it enabled in the run panel cut parameters?
What do the LEDS show while cutting?
What does is not do?

Is it in Auto or On mode in the run panel settings? ... Yes
Is it enabled in the run panel cut parameters? .... Yes
What do the LEDS show while cutting?... I don't want to muddy the water so will report back.

Should The encoder count be a -ve number (on mine it is) OR should it be +ve as the problem machine is.
Should encoder position numbers be +ve or -ve

What would be a sane value for the height per volt under config?
I am pretty sure the the THC is wired correctly.

Any suggestions where to start looking. I will get a short Vid later on today

Is it in Auto or On mode in the run panel settings? ... Yes
Is it enabled in the run panel cut parameters? .... Yes
What do the LEDS show while cutting?... I don't want to muddy the water so will report back.

Should The encoder count be a -ve number (on mine it is) OR should it be +ve as the problem machine is.
Should encoder position numbers be +ve or -ve

What would be a sane value for the height per volt under config?
I am pretty sure the the THC is wired correctly.

Any suggestions where to start looking. I will get a short Vid later on today

Update it seems to be working now. We had to change the THC delay to 0.3 secs and the PID gain from 10 to 20
now it cuts uphill without problems

Re this:
Should The encoder count be a -ve number (on mine it is) OR should it be +ve as the problem machine is.
Should encoder position numbers be +ve or -ve

On this machine we had to change the setp hm2_7i96.0.encoder.00.scale -1 to 1

There is a possible cause of encoder count direction differences/instability:

If you are using a standard firmware configuration (not a plasma config with multiple
'A' pins on the encoder input), the encoder 'B' input state determines the count direction

This is because when the encoder is set into counter mode. it functions as an up/down
counter with the 'A' input being the clock and the 'B' input setting the direction.

For noise immunity, the THCAD connections should be differential (so the encoder 'A'
input should be jumpered for differential mode) BUT the 'B' input should be jumpered
for TTL mode as only this mode has a defined state when unconnected (count down)

You can also jumper the 'B' input for TTL mode and ground the 'B' input for
count up mode

PCW wrote:

There is a possible cause of encoder count direction differences/instability:

If you are using a standard firmware configuration (not a plasma config with multiple
'A' pins on the encoder input), the encoder 'B' input state determines the count direction

This is because when the encoder is set into counter mode. it functions as an up/down
counter with the 'A' input being the clock and the 'B' input setting the direction.

For noise immunity, the THCAD connections should be differential (so the encoder 'A'
input should be jumpered for differential mode) BUT the 'B' input should be jumpered
for TTL mode as only this mode has a defined state when unconnected (count down)

You can also jumper the 'B' input for TTL mode and ground the 'B' input for
count up mode

Very interesting thank you. I have a feeling that they are both set for differential I will check

Clive wrote:

What would be a sane value for the height per volt under config?
I am pretty sure the the THC is wired correctly.

Any suggestions where to start looking. I will get a short Vid later on today

Update it seems to be working now. We had to change the THC delay to 0.3 secs and the PID gain from 10 to 20
now it cuts uphill without problems

Re this:
Should The encoder count be a -ve number (on mine it is) OR should it be +ve as the problem machine is.
Should encoder position numbers be +ve or -ve

On this machine we had to change the setp hm2_7i96.0.encoder.00.scale -1 to 1

I have bumped this: As the above questions seem to have fallen through the net. Although the machine is working.

Just needs the water table.