Jump to content

Timeout on Certain Event


Recommended Posts

Hello,

I have an idea/is this possible question.

When using an event structures is it posible to timeout if a certain event didn't happen. I know right now I can time out if no events for the enire structure didn't occured in x amount of time. I was wondering if I can time out only if a specific event didn't occur i.e. user event.

Thanks

Dan

Link to comment

QUOTE (ASTDan @ Apr 19 2008, 09:17 AM)

When using an event structures is it posible to timeout if a certain event didn't happen. I know right now I can time out if no events for the enire structure didn't occured in x amount of time. I was wondering if I can time out only if a specific event didn't occur i.e. user event.

I'm trying to understand the use case here - you want to timeout only if a certain user event doesn't happen, but don't timeout if other user events don't happen, is that right? How's that different from globally timing out? If your event doesn't happen then it'll go to the timeout case. Are you looking for a "IF event occurs THEN do case one ELSE do case two" pattern? The global timeout will fire if your event didn't occur, and the other cases will fire if their events did occur. Maybe I'm missing your point. :wacko: Can you give us an example?

Link to comment

QUOTE (crelf @ Apr 19 2008, 05:23 PM)

I'm trying to understand the use case here - you want to timeout only if a certain user event doesn't happen, but don't timeout if other user events don't happen, is that right?

I think Dan wants a timeout not influenced by other events.

This can be done by placing just two cases inside an event structure, one for the timeout and one for the event. Upon a 'event-specific timeout' you can trigger a user event in the main event structure. If the event doesn't timeout (eg. just happens) you could handle the code in the 'single event-event structure' or trigger another user event.

Ton

Link to comment

My use case is I have a Custom User event I created. The user event is my device tells me I have data. When my device tells me I have data I fire my Custom User event. What I want is a timeout on this custom user event. Basicaly if I don't see data from my device in say 1 minute, ping the device to see if it is still there running. I don't want my timout reset by somebody clicking away on my user interface.

Does that make sense?

QUOTE (tcplomp @ Apr 19 2008, 11:39 AM)

This can be done by placing just two cases inside an event structure, one for the timeout and one for the event. Upon a 'event-specific timeout' you can trigger a user event in the main event structure. If the event doesn't timeout (eg. just happens) you could handle the code in the 'single event-event structure' or trigger another user event.

Could you post a quick example of this?

Thanks

Dan

Link to comment

QUOTE (ASTDan @ Apr 19 2008, 11:05 PM)

Here's the easy route:

post-2399-1208640069.png?width=400

And the hard route:

post-2399-1208640270.png?width=400

QUOTE (ASTDan @ Apr 19 2008, 11:05 PM)

My use case is I have a Custom User event I created. The user event is my device tells me I have data. When my device tells me I have data I fire my Custom User event. What I want is a timeout on this custom user event. Basicaly if I don't see data from my device in say 1 minute, ping the device to see if it is still there running. I don't want my timout reset by somebody clicking away on my user interface.

I think you should handle this in the place you get your data, not in the consumer of that place.

I would setup a design where my communicator waits for data and than sends data to the user event. If the timeout passes I ping my device. (a little bit like my second design from above).

And yes two event structures in one VI/application is absolutly valid!

Ton

Link to comment

QUOTE (ASTDan @ Apr 20 2008, 05:45 PM)

I feel so naughty using 2 event loops in one app.

There's absolutely nothing wrong with that. In fact, the two event structures can even handle the same events without race conditions (although in that case you should be aware of the consequences, especially if you use filter events). You might have been thinking of two event structures in the same loop.

The only real thing you should avoid when doing this is wiring the same event registration refnum into two different event structures because that will cause you to lose events. As you can see, Ton used two event registration nodes to avoid this.

Link to comment

QUOTE (ASTDan @ Apr 20 2008, 04:45 PM)

Looking in retrospect I think the first solution is the easiest (no extra user events).

QUOTE (Yen @ Apr 20 2008, 08:27 PM)

The only real thing you should avoid when doing this is wiring the same event registration refnum into two different event structures because that will cause you to lose events. As you can see, Ton used two event registration nodes to avoid this.

To understand a little bit what Yen is talking about.

Ton

Link to comment

QUOTE (tcplomp @ Apr 21 2008, 02:00 AM)

I read that very good thread and I have an idea. Is it posible to dynamicly register the timeout event? That way I can turn it on and off as needed.

Thanks

Dan

Link to comment

QUOTE (ASTDan @ Apr 21 2008, 02:47 PM)

Is it posible to dynamicly register the timeout event?

Looks like you can't. If you wire an application reference to the register node, the timeout event is disabled.

What you can do instead is dynamically change the timeout value (e.g. using a shift register). When you don't want it to occur, use a value of -1.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.