Jump to content

Repeat events inside case structure


Recommended Posts

Hi,

I am having a bit of a problem getting my program to work properly. As I have it set up right now, I have a while loop as the outer-most structure. Inside the while loop, I have an event structure (on Value Change). Inside the event structure I have a case structure. The different cases in the case structure correspond to the possible value changes that the event structure detects.

Is there any way to constantly repeat events in a certain case structure until the event structure detects a different value (a value change)? I tried putting a while loop inside one of the case structures, but the program just waits in the while loop and ignores any input that is supposed to cause the event structure to detect a value change (and thus execute events inside a different case). I also tried having an external boolean wired to the stop button of the while loop inside a certain case but that did not seem to work either.

Any ideas are greatly appreciated. Thanks!

Link to comment

Hi,

I am having a bit of a problem getting my program to work properly. As I have it set up right now, I have a while loop as the outer-most structure. Inside the while loop, I have an event structure (on Value Change). Inside the event structure I have a case structure. The different cases in the case structure correspond to the possible value changes that the event structure detects.

Is there any way to constantly repeat events in a certain case structure until the event structure detects a different value (a value change)? I tried putting a while loop inside one of the case structures, but the program just waits in the while loop and ignores any input that is supposed to cause the event structure to detect a value change (and thus execute events inside a different case). I also tried having an external boolean wired to the stop button of the while loop inside a certain case but that did not seem to work either.

Any ideas are greatly appreciated. Thanks!

Well a Value Change(signl) property node will programmatically fire an event but you can end up with race conditions. You ought to be wiring a timeout to the event case (say 100ms the, default is -1....wait indefinately) and checking the controls in the timeout case.

If you are seeing the event execute only once, then it is likely that you do not have the control inside that event case. This is required for the control to be "reset".

Edited by ShaunR
Link to comment

It sounds like your application could benefit from using a producer consumer architecture. Use a single event structure in one while loop that will detect the value change and have the event notify the consumer of the new value. A state machine in the consumer could process the data as required and if necessary repeat over the action until a new value is detected.

Link to comment

It sounds like your application could benefit from using a producer consumer architecture. Use a single event structure in one while loop that will detect the value change and have the event notify the consumer of the new value. A state machine in the consumer could process the data as required and if necessary repeat over the action until a new value is detected.

A bit excessive dont ya think?

Link to comment

A bit excessive dont ya think?

Why would you say that? I think Mark's proposal is valid, as is yours. When I first read the question, the first thoughts that came to my mind were both of your solutions. Ultimately, it is a design decision for the developer to make and he doesn't offer up enough additional information to make a choice.

-Scott

Link to comment

Why would you say that? I think Mark's proposal is valid, as is yours. When I first read the question, the first thoughts that came to my mind were both of your solutions. Ultimately, it is a design decision for the developer to make and he doesn't offer up enough additional information to make a choice.

-Scott

My reply wasn't a design proposal. It was to get his events working properly. Like you said. theres not a lot of detail, but its likely its a control with a couple of cases checking a value. Do you really need a Consumer-Producer design pattern with state machines to see if a value is higher or lower than zero for example?

Link to comment

Do you really need a Consumer-Producer design pattern with state machines to see if a value is higher or lower than zero for example?

No, probably not, in which case yours is the simpler solution. I would agree based on the question that is the more likely scenario. But it could also possibly be that he is monitoring multiple controls for value change in the same event case, which starts to favor a producer-consumer or some similar design.

And it's a personal preference of mine that I try to avoid using timeouts in the event structure unless really necessary. There are times when it makes sense, and it's still superior to polling. But it still *feels* like I'm resorting to polling before we got the event structure. Man, doesn't that seem like ages ago.

Link to comment

No, probably not, in which case yours is the simpler solution. I would agree based on the question that is the more likely scenario. But it could also possibly be that he is monitoring multiple controls for value change in the same event case, which starts to favor a producer-consumer or some similar design.

Well. If that is the case then there should be an event case for each control or set of dependent controls. Still don't see the need to complicate it further.

And it's a personal preference of mine that I try to avoid using timeouts in the event structure unless really necessary. There are times when it makes sense, and it's still superior to polling. But it still *feels* like I'm resorting to polling before we got the event structure. Man, doesn't that seem like ages ago.

Me too. and re-reading what I posted I did say they should be checked there. What I was really getting at was to add a timeout so that his vi doesn't "hang". I think once he posts more, we will probably see that his issue is understanding how and why an event structure works the way it does rather than a design implementation. After all there are a few unintuitive things like having the control inside the event case.

Link to comment

A bit excessive dont ya think?

It depends on his application as both you and Scott discussed. The thought that came to mind though when I read the original post was that he was trying to do polling using an event structure. Like Scott, I try to avoid using the timeout event in an event structure. I also prefer to use events rather than polling. As for a producer consumer architecture being excessive I don't really think it is. At least not for anything that will be an application and interact with a user. It isn't that challenging of an architecture to understand and it provides lots of flexibility and extensibility for an application. It is the architecture of first choice for any application I write. No I'm saying that it is the greatest thing since sliced bread but it is a proven architecture for applications where user interaction will be involved.

Link to comment

Poor OP.

He posts an innocent question and all he really gets is a load of old women arguing about thier crochet patterns tongue.gif

hey Hey HEY! I said drop 2 curl 3, not drop 3 curl 2! biggrin.gif

HEY! I resemble that! I'll argue most anything for fun. But I'm glad you said it and not me.

I wonder... Did he ever get his program working the way he wants or did we just send him into an infinit loop? wacko.gif

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.