2 replies to this topic

[boone_93]

I was using the OpenG Periodic Trigger in an application and notice that my time base was drifting. After spending some time on it and rewritting to make it a little more readable I made a change to fix what seems to be a time leak to me. The change is made where it gets the new time after a trigger has occurred. If someone would take a look and give me feedback that would be great. Could this be an update to the OpenG Time library?  Periodic Trigger.zip   24.33K   69 downloads

[Ton Plomp]

Hello Dan,

your code looks valid and for the (small) test I'v run it's OK.

I don't fully understand what the bug/fix is, could you describe that in more detail?

Ton

[Ton Plomp]

OK, I figured out what the essential difference between the two implementation is.
The original OpenG Periodic trigger resets the phase upon every trigger. Your implementation is maintaining the phase.
I have a little table showing this:


Where I had a Time (ms) of 500 ms and waited 450, 100, 400, 100 and 10 ms. The column Next Trigger is showing the output state of the upper Shift Register which basically contains when the next rollover of the timer will happen.

I think we should add both implementations, making yours the default for new VIs, the old functionality should be maintained via deprecation. So currently already code isn't changing current behaviour.

Here's my proposal:


And it's documentation:
.

Losing phase has functionality if you alter the 'Time to wait'. However we might need to auto-reset then as well.

EDIT:
Please note that you might get unexpected Triggers with Maintain Phase On:


Ton