Nan - voltage

see i read it and re read it.. and then read it again.. and thats how i interpreted it..

but i read things in funny ways. load in corners? i have noooo idea what the has to do with any of it now

either way.. non-consequential, its not relevant to the Nan issue? is it?

Tesremos wrote: see i read it and re read it.. and then read it again.. and thats how i interpreted it..

but i read things in funny ways. load in corners? i have noooo idea what the has to do with any of it now

either way.. non-consequential, its not relevant to the Nan issue? is it?

Sorry I got it a bit wrong. Load is one of the onputs to lowpass.comp
linuxcnc.org/docs/2.8/html/man/man9/lowpass.9.html
It really should be called enable.

Gain is what I should have said. It creates a corner which determines the filter cutoff.

I did a bit of digging looking for info on THCAD and lowpass filters before Plasmac. (searched for THCAD lowpass > 12 months old). The best reference could find is this thread.

forum.linuxcnc.org/27-driver-boards/3321...vider-settings#98086
Which might also explain why I have a lowpass of 50 set in Plasmac. It is to filter out any 50 Hz AC induced ripple from AC to DC conversion in the plasma inverter. That was a problem for me once...

OK. This is just a theory...
Something has changed in the linuxcnc core because this has not been reported before.

I think the nan issue could be a bug in NML messaging reported by automation-assist in a thread I posted earlier. Linuxcnc updates the screen using NML messages. He found a bug in NML which resulted in a nan sometimes and proposed a fix. So its possible that the nan is just affecting the screen refresh. I would encourage you to have halshow or even better halscope while cutting to monitor the arc voltage from a hal pin.

Try monitoring
plasmac.arc-voltage-out (volts)
plasmac.arc-voltage-in (frequency)

The other are this NML bug could bite is if the GUI uses NML to send gui pins back to hal (dunno if it does) . If that were the case, it might occasionally send a nan or a zero back to plasmac.comp for the scale or offset values which then passes through to the arc voltage.

Normally a nan (not a number) is caused by a divide by zero or something similar but I can't see how that could happen in Phill's code
github.com/LinuxCNC/linuxcnc/blob/master...ts/plasmac.comp#L503

The other thing that you could do is to use this component to calculate the arc voltage outside of plasmac
forum.linuxcnc.org/plasma-laser/32585-scalethcad-component
Then set the offset to 0 and the scale to 1 in the Plasmac GUI.
But the problem with this is that it is still dependent on GUI variables so it could still bite.

Or you could compile a run in place version of linuxcnc and make automation-assist's suggested code change.

duplicate, deleted

rodw wrote:

rodw wrote:

Tesremos wrote: see i read it and re read it.. and then read it again.. and thats how i interpreted it..

but i read things in funny ways. load in corners? i have noooo idea what the has to do with any of it now

either way.. non-consequential, its not relevant to the Nan issue? is it?

Sorry I got it a bit wrong. Load is one of the onputs to lowpass.comp
linuxcnc.org/docs/2.8/html/man/man9/lowpass.9.html
It really should be called enable.

Gain is what I should have said. It creates a corner which determines the filter cutoff.

I did a bit of digging looking for info on THCAD and lowpass filters before Plasmac. (searched for THCAD lowpass > 12 months old). The best reference could find is this thread.

forum.linuxcnc.org/27-driver-boards/3321...vider-settings#98086
Which might also explain why I have a lowpass of 50 set in Plasmac. It is to filter out any 50 Hz AC induced ripple from AC to DC conversion in the plasma inverter. That was a problem for me once...

OK. This is just a theory...
Something has changed in the linuxcnc core because this has not been reported before.

I think the nan issue could be a bug in NML messaging reported by automation-assist in a thread I posted earlier. Linuxcnc updates the screen using NML messages. He found a bug in NML which resulted in a nan sometimes and proposed a fix. So its possible that the nan is just affecting the screen refresh. I would encourage you to have halshow or even better halscope while cutting to monitor the arc voltage from a hal pin.

Try monitoring
plasmac.arc-voltage-out (volts)
plasmac.arc-voltage-in (frequency)

The other way this NML bug could bite is if the GUI uses NML to send gui pins back to hal (dunno if it does) . If that were the case, it might occasionally send a nan or a zero back to plasmac.comp for the scale or offset values which then passes through to the arc voltage.

Normally a nan (not a number) is caused by a divide by zero or something similar but I can't see how that could happen in Phill's code
github.com/LinuxCNC/linuxcnc/blob/master...ts/plasmac.comp#L503

The other thing that you could do is to use this component to calculate the arc voltage outside of plasmac
forum.linuxcnc.org/plasma-laser/32585-scalethcad-component
Then set the offset to 0 and the scale to 1 in the Plasmac GUI.
But the problem with this is that it is still dependent on GUI variables so it could still bite.

Or you could compile a run in place version of linuxcnc and make automation-assist's suggested code change.

[/quote]

Redundancy ?????

Actually this might be better

unlinkp these plasmac.comp pins

setp them to the values used in your gui.
This would take NML out of the equation as values are not set by gui variables.
If it still happens, then its most likely a plasmac bug and you have isolated that to the lowpass code.