under review Periodic Trigger: Maintain Phase

[Ton Plomp 169]

I have added feature request to the OpenG tracker for this functionality.

Some detail on the code change is in this discussion.

This review has the following options:

• Do not add a 'Maintain Phase' input
  
• Add a 'Maintain Phase' input, defaults to 'False' (means that we don't need to deprecate the old code)
  
• Add a 'Maintain Phase' input, defaults to 'True' (means that we need to deprecate the old code)
  

Please add your vote (it's public voting), if you have input for this discussion please add it!

[drjdpowell 362]

I haven’t used this function, but I’ve done similar timing, and I find that both forms of timing ("since last", and “on schedule”) are both needed. There is no reason to prefer one over the other as default, and thus it would be simpler to stick with the current behavior as default, with the new one as an option.

[Ton Plomp 169]

I added another 'mode' for this VI:

• Maintain phase, dismiss missed
  

To show the effect of the three modes I made this table (with a dT of 50 msec), all times are in msec:

Graphical this is the representation:

Now for the difference between 'Maintain phase' and 'Maintain phase, dismiss missed' some more zooming in:

Where at 3.35, 3.36 and 3.51 a call was made.

All three models will return a True for the first call (the wait time before was > 500 msec).

When 'Maintain phase' is selected 3.36 returns a True as well, (the wait time was > 1000 msec).

The 3.51 call returns True for the 'Maintain phase' and for 'Maintain phase, dismiss missed', since the phase is stuck at 3.50. 'Since last' returns a False since the time since the last trigger is < 500 msec).

Here's my current VI:

Periodic Trigger.vi and the test VI Periodic TriggerTest.vi

so you can run your own scenarios.

Ton