Possible bug in PID library

1

There’s a possible bug in the PID library code, I didn’t notice this while testing real hardware so not sure how relevant it will be to real-world implementations, but it became a problem when doing “loopback” testing using the “defer-number” node to feed controller output back to the input.

Because of the way the input value to the controller is fed to the three PID calculating blocks, where unused blocks are disabled by setting their input constant to zero, and the fact the PID controller patch node uses a divide node internally for its derivative term, which doesn’t have any domain checking in its implementation, it’s possible to get a situation where a 0.0 / 0.0 divide operation is attempted.

In C++ IEE754 floating point SOMENUM / 0.0 returns either BIGNUM or -BIGNUM, depending, which while probably not sane values for actual work, are at least representable as an Xod “Number” of maximum positive or negative value and can be passed around to other nodes like any other “Number”.

But 0.0 / 0.0 returns “NaN” which I’m pretty sure is going to be some kind of undefined behavior when fed into downstream nodes expecting a numeric floating-point value.

1 Like
2

Thanks for sharing your mind!

Division by zero seems impossible since the denominator in PID is time delta. The defer-number postpones value propagation until the next transaction. The next and the current transaction can’t have equal time.

…Can’t ideally. Right now I understand we’ll get a problem if a transaction completes in less than a millisecond. It would be interpreted as the same time value. That should be a rare case for UNO and its friends, but possible for more powerful boards. The fix should be introduced at runtime engine level.