Nan - voltage

PHILL!!!

you've done it!

30/30 no nan.


edit: 100/100 no instances of nan

What that one does is look at the arc-voltage-in signal and if it sees an inf instead of a valid float then it starts a one second loop. If it sees a valid float within one second it continues on its merry way otherwise it will give an error message.

Can you get PurduePete to give it a try as well.

It may be worth an ask in the Driver Boards section as to why it could start up with an inf on the encoder output.

So infinity * 0 = 0 so how can it report a nan?
What does halshow report for encoder velocity?

You have not eliminated anything yet.
Don't have a closed mind. There is something going on here that none of us understand.

I still think its more likely that a reported bug in NML which is used by the GUI to talk to the Linuxcnc core is the culprit than the encoder output.

phillc54 wrote: What that one does is look at the arc-voltage-in signal and if it sees an inf instead of a valid float then it starts a one second loop. If it sees a valid float within one second it continues on its merry way otherwise it will give an error message.

Can you get PurduePete to give it a try as well.

It may be worth an ask in the Driver Boards section as to why it could start up with an inf on the encoder output.

When you go back to the First post and look at the screen dumps arc-voltage-in has a valid value but arc-voltage-out has a nan. The original screen dumps still don't correlate with the solution. Maybe the one second delay simply allows the system to sort itself out. eg for the system to load.

I think it should be reported as a bug on the basis that behaviour has changed in master from 2.8. Its a very cludgy work around.

rodw wrote: So infinity * 0 = 0 so how can it report a nan?

No, inf * 0 = nan

When you go back to the First post and look at the screen dumps arc-voltage-in has a valid value but arc-voltage-out has a nan.

The first screen dumps were not at the time of startup, they were after the error had been established.

Maybe the one second delay simply allows the system to sort itself out. eg for the system to load.

Exactly, it gives time for the encoder to pass a valid float.

So does receiving a number as a nan break things forever? Shouldn't it sort out the output when a valid number is received from the encoder?

It seems to me thats what should happen, but that did not seem to be the case.