I have a subclass of PhidgetVoltageInputMBS - it’s a current sensor that publishes a measurement every 100ms or so. I want the subclass to publish measurements of 0 Amps if the Phidget is ever disconnected so my app doesn’t indicate non-existent current if, say, the USB gets disconnected.
So I created a property of type Timer in the subclass, instantiate it in the constructor after calling the super’s constructor, and set its period to say 300ms. The timer’s Action event is handled by a method that publishes a 0A measurement, and the timer is reset every time the sensor gets a “real” measurement or a timeout occurs.
Since the timer is being reset at 100ms intervals and its period is 300ms, it should never fire if data is coming in from the sensor, but it does - every 300ms!
I tried all the various methods of reset: the Reset instruction, turning Enable off and On, and changing RunMode.
I tried both Single and Multiple RunModes.
I tried lengthening the timeout to extreme values.
I inserted DebugLog writes all over the place to make sure the code execution is as expected (it is).
Nothing will reset that timer, it just times out at its period regardless of its being hammered with resets.
Finally, in desperation, I moved the timer property out of the subclass and into a module, and… it works!
Strange bug. Maybe I should try TimerMBS, but sadly it doesn’t have a Single mode, which is the “correct” mode for this application, although I guess Multiple would work.
The timer detects when data is not coming from the Phidget. Every time data comes from the Phidget, the timer gets reset, so the timer should never fire if its period is longer than the Phidget data rate. This is a common design pattern in both analog and digital, and how timeouts and “watchdogs” work.
There is nothing wrong with the logic - as soon as I move the property holding the timer reference from the Phidget subclass to a module, it works as expected.
@Julia_Truchsess , a shot in the dark: since the two timers have a ratio of 3:1 regarding their period, is it possible the 300 ms one is fired 1st, and thus it runs for another 300 ms till the end of time ? How about having the second set to 90 ms to prebent both of them reaching 0 at the same time ?
I haven’t checked Sascha’s example yet as I can’t open it under 2021r2.1 and I’m not with the hardware right now, but yes, it’s probably an old and strange bug.
This is such a common, fundamental use case for Timer - unless Julia is really doing super unusual summersaults in her code, this isn’t a big that would have gone unnoticed in any version of Xojo.
I wonder if it’s just slippage between the compiled code and the version of Windows that is now being used.
I do the same thing all the time with subclassed SerialConnections, without issue (fire a one-shot whenever data comes in, and go parse the buffer on the main thread only when there’s a pause). It’s only now with a subclassed Phidget that I’ve seen the problem.
One possible way to track this down may be to subclass the Timer.
Then, in the appropriate events and methods, add some additional parameters and logging as needed to see what is calling the methods and/or triggering the events. Once you figure out what is going on, if there is a resolution, you could then go back to the “standard” Timer.
As mentioned, I tried a wide range of timeout values for the timer, including extremes like 5 seconds - it just always completes its full period and ignores resets. Note there is only one timer in my code, the timeout “watchdog”. The data comes in from the Phidget at a rate determined by its own hardware, which isn’t even in my PC, but the rate is settable from within Xojo. The rate is “nominal” because it’s coming in over USB and is subject to lots of random latencies - using microseconds and DebugLog I see anywhere from 95ms - 180ms when it’s set for 100ms. So the idea that the two are somehow “synced” and firing simultaneously doesn’t seem likely.
