Nan - voltage

The plasmac version of lowpass is configured quite differently to the genuine component. Take care if you do it externally.
I'm going to check my config tomorrow. It was drummed into me by Dewey Garrett not to filter a process control variable.
Something I see here tonight indicates I have something set here. If thats the case it must have been set by a plasmac default.

I don't know enough about electronics but i kinda agree with snowgoer something is not right. But remember we usually use the 1/32 of the thcad frequency. But then plasmac filters the voltage, not the frequency so there is another conversion.

see i interpretered it as, it will only read the voltage 25 times / second

oppopsed to 1.4million times...

ill swap out the low pass for the lowpass, and see if that makes a difference.

im wondering wat what stage it starts checking for voltage.

if on load it starts the "check voltage" loop, at the same time the lowpass has chosen Not to check voltage, there for resulting in a ... voltage is a non-value..

but,, this is way over my head/paygrade.

brings me to the .. if i load lowpass after plasmac...i wonder what happens.

ill poke the bear more tommorrow

Tesremos wrote:

see i interpretered it as, it will only read the voltage 25 times / second

No the low pass filtered result will still be processed 1000 times per second as per the servo thread.

Be sure to read the docs and calculate the load to achieve your desired corner frequency.

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]