how do I update a timer's timeout threshold in realtime?

[MatthewDC]

Hi all. 

I'm trying to implement something that would look like a 'Timer event' but I couldn't find anything in Labview that could be used to trigger a case in an event structure.

I also can't seem to update the internal timeout threshold of running timers (such as one of the frames in a Time Sequence).  If the user accidently entered a number with 2 extra digits in it, they have to wait all that time for the frame to end.  This breaks one of my personal design rules: Allow the user to update anything in real-time unless it violates the the intended functionality.

With neither of these approaches available, does this mean I'm still stuck doing a low-level approach polling timestamps?

[tbd]

Hi Matthew,

---

I'm trying to implement something that would look like a 'Timer event' but I couldn't find anything in Labview that could be used to trigger a case in an event structure.

---

An event-structure can be "triggered" from anywhere in your application by writing to the value(signaling) property of a control, if the event-structure is configured to wait for the control's value-change events. 

---

also can't seem to update the internal timeout threshold of running timers (such as one of the frames in a Time Sequence).  If the user accidently entered a number with 2 extra digits in it, they have to wait all that time for the frame to end.  This breaks one of my personal design rules: Allow the user to update anything in real-time unless it violates the the intended functionality.

---

I'm with you on this!  I like to have applications repond instantly (if possible) to user interaction - any delay is frustrating.  I don't understand what you mean by "internal timeout", though.  If you're talking about an event structure, surely it can be registered for a quit event and react instantly(?)

For general waits, I've been using a "Wait with Abort" VI that waits an arbitrary period for a user abort (Notifier), if abort occurs, the VI builds an "Operator Abort" error and normal error-handling shunts execution up the call-chain.  If no Notification occurs, execution continues normally.

Cheers!

[Gabi1]

to resolve this problem, i generally use two loops:

one with the event structure, that react instantly to user events. this structure includes very little calculations, especially no hardware communication.

then i have a second loop, unrelated, which does most analysis and all communication with hardware.

the two loops comunicate either with a notifier (quit, start, pause...events), or with a queue (data transfer).

to pause the second loop, inside is a case structure (true -false) to perform operations. if more involved it is a full state machine, with next state called from the event structure loop with a queue.

i find it works nicely.

[MatthewDC]

thanks for the responses!  I think we are circling the problem without quite landing on it yet... 

Let me describe the simple version of what I'm doing.

Customer needs a PWM digital signal with period times that could be very long, an hour or more.  Duty cyle and period are two separate user-settable controls.  There is also an enable/disable switch.

In the old days, I would implement this like an onion.

First,  polling-wait loops for each half of the PWM cycle..  If the user aborts or changes the PWM timing, the loops just finishes or extends out, depending.  Each half of the PWM cycle is buried in a two-step sequence.

That two-step sequence sits in a case-statement gated by the Enable switch.  That assembly sits inside an endless While loop.  Everytime one PWM cycle ends, the enable switch is retested and the PWM started again, otherwise nothing happens. (appropriate wait statements to keep polling to a minimum neccessary are scattered around)

I'm trying to move away from this effective but messy approach.  Instead of polling wait-loops, the timed sequence should be ideal.  However, once a time value is passed to a frame, it can't be changed.  So, for example, once a frame of a time sequence receives a value of one hour, then me the programmer can't provide the user with any way to change the one hour setting once it has engaged. (except for the 'Stop Sequence' VI, but that kills the whole sequence, not just the frame.  Grit teeth, arghhh!)  Ideally this would be a 'timed-sequence Method' driven somewhere else that would update the timer value insidethe frame.  If the method call passed a value of, say, 30 minutes, and 45 minutes had already passed, then the frame would calculate that the time limit for that threshold had been exceeded and the frame would simply timeout.  That would be the ideal.

OK, can't make a timed sequence work.  How about some other kind of background timer?  Can't do.  Can't find anything like it in Labveiw.  If there was one, I'd make it an Event-driver.  Start a clock somewhere, then tie an Event-structure frame to it, where the action would happen.

I can still do it the old way, I'm just tring to find a more elegant way using more event-driven techniques.  Besides, lots of nesting requires lots of tedious outward-propagation of abort signals. (and high-resolution polling uses more CPU time)

thanks,

Matt

[tbd]

Hi Matt,

      So, you have a PWM process that you don't want to interrupt for new Period/Duty-cycle settings, but you'd like to have pulse state reflect new settings if appropriate?

Attached is a VI that implements time-on and time-off as you described, it could be writing to a DIO instead of flipping a boolean LED.  I'd have a second loop/thread watching the GUI for PWM duty cycles changes and writing to time-on/time-off using value signaling.  I'd also add some event that allowed quitting the DIO-loop - or maybe quit if time-on is less than zero.

Cheers!