Boolean event driver failing to toggle

[JeffOverton]

Sorry to bump an old thread, but I think I accidentally figured out my problem.  I had unknowingly generated a race condition in my sensor polling, which lead to an inefficient but oft-called sensor read algorithm during my event timeout.  I had the timeout set at 10ms in order to update all my sensors several times a second, and upon developing a more efficient data gathering system, I have a 100ms timeout.  Now it works without a hitch, so maybe the 10ms timeout made the system spend too much time polling and not enough time operating controls or something.

Interesting, at least.

Message Edited by JeffOverton on 01-09-2008 12:58 PM

[JeffOverton]

And, another new problem.  After automating it, I'm having trouble getting proper displays again.  The valve display toggles back to its default state when it shouldn't, which makes me think the indicator is getting reinitialized.  If it is, I can't figure out where.  Also, my data poll has been moved outside the main while loop because it would freeze while in some of the subvis.

Finally, if anybody wants to look at my code and has comments about style or good practices, I would be more than thankful to hear them.  It's looking like this contract job might turn into something more permanent.

[RavensFan]

Not of of the sub-Vi's were present in the zip fil.  I think some of the architecture may be more complicated then it needs to be.

For example, your passing a VI reference to the Write Valve state VI.  Why not just pass values in and out by the connector panel?  I think this is where the problem occurs.

In your Write Valve State VI, you take the fixture display (hidden control on front panel) where the subVI is used, you never wire anything into that connector.  Then you update a single valve value in that wire based on the valve control information that was passed in.  so you basically have a screenful of defaults with only one value changed.  Then you write that to the main VI control by reference.  If you do it again with another valve, the previous valve gets reset to its default, because that is its value on the front panel of the subVI.

You put the front panel display controls and indicators on the connector panel of the subVI for a reason,  use them.  It may be better to set up this subVI with an architecture that is closer to an "Action Engine" or functional globabl variable where it is able to remember its previous state from the last call.

EDIT:  The first location where I see the connectors unwired is the boolean 2 value change event.  Whether it is happening elsewhere, I'm not sure.

Also, using the stop sign VI to stop your VI is very unusual.  In the top loop you have it to when i <>0, which means the top loop will run twice, once when i=0 and the iteration where i becomes 1.  That iteration will run and the loop will stop after it because the i not equal to 0 will become true.

Message Edited by Ravens Fan on 01-09-2008 04:54 PM

[altenbach]

Sorry, I don't have fieldpoint and I am not sure which booleans don't behave as you expect so I cannot help you there.

---

JeffOverton wrote:
Finally, if anybody wants to look at my code and has comments about style or good practices, I would be more than thankful to hear them.  It's looking like this contract job might turn into something more permanent.

---

OK, this code has a couple of real problems that would be worth to correct. Once you are a bit more familiar with LabVIEW, they will all seem obvious.

You have two parts running in parallel, the upper and lower loop, but the upper part only runs exactly twice after which it aborts everything (unless the other loop aborts the VI first :o).

<<<< this makes no sense!!!!

The use of the STOP primitive is like an abort and should never be used in production code. Once a STOP is encountered everything dies and there is no way to do any shutdown code. What you need to do instead is feed a boolean to the loop termination so all operations can complete. Once the loops are done, the VI stops automatially. 🙂

Since the upper loop currently runs exactly twice, you should replace it with a FOR loop if that's really the desired operation (somehow I doubt that).

You do things way too complicated. For example the "fixture display" can go in a shift register, eliminating most its local variables and the replacement of cluster element values can be done in one step. If you want element zero, you don't need to wire the index.

Sorry, I don't have any of the subVIs, typedefs, etc. so there is no way to troubleshoot further. These are just some general comments.

Message Edited by altenbach on 01-09-2008 02:00 PM

[altenbach]

Actually, the upper loop really only completes once, because at the second iteration things get aborted pretty quickly because the STOP will execute while the other code segments have barely (if at all) started to execute.

[JeffOverton]

First, thanks for all the help.  I really appreciate it.  Second, I apologize for not providing the rest of the code, but what you see is all I'm allowed to post by my company's IS policy.  Anyway, to the issues:

Ravens Fan
Regarding Write Valve, I've passed the actual fixture display indicator into the connector on the subvi, so I'm a little confused about how it is actually getting reset.  It's passed in, a cluster value is updated, and the result is passed to the next stage, so I would think the values should stay.  Also, the VI reference to update is a carryover from desperate attempts to fix the indicators by switching it to a control or using value set or using value signal or etc etc.

Also, I'm not sure what you mean by "Action Engine" and from what I've seen on the forums here, globals are usually recommended against.  Would this be a proper situation for a global?

Boolean 2, which has an unwired event, is there to shut down the automation from another VI.  For instance, if the automation VI hangs up and the 30,000 psi source valve is open, you want to regain control, which is also the reason I'm using a stop (yes, I'm kind of ashamed ) to prevent any further opens or closes from occuring after a fault.

And finally, a for loop is a really good idea.

Altenbach
Again, the for loop is a good idea.  I'm actually a little disappointed in myself for creating an event to end a while loop after a predetermined number of iterations.

I'm not sure if a shift register would work in the data read loop, because I want the local to reinitialize every cycle.  I was worried that if I called the local outside the loop and wired it in, it would constantly be writing the initial valve states at the same time as it updates the pressure displays, causing exactly the problem I'm having.

Also, I'm not sure what you mean when you say the replacement of cluster values could be done in one step.

Again, I've only been using LV for about three weeks, so if something seems completely backwards, it's probably not me misspeaking, it's probably me being wrong.

Message Edited by JeffOverton on 01-10-2008 07:54 AM

[RavensFan]

Action Engine is another term for a functional global variable.  Ben wrote a community nugget about its uses here.  They are also know as Labview 2 style globals.  These aren't really the same thing as "globals", which are usually frowned upon.  I have actually never used a global variable, but have written quite a few functional global variables (i.e. action engines.)

A FGV is a sub-VI that has a while loop with a True wired to the stop terminal so that it only runs once.  It uses uninitialized shift registers on the while loop to store information from one iteration to the next.  It has a case structure that has cases such as Get and Set.  You can use the Set case to assign values input to the subVI to shift registers.  You use the Get case to return the values from the shift register.  You can really expand the functionality by added other operations in other cases, in which case it really takes on more of the meaning of Ben's term "Action Engine".  The sub-VI is set to be non reentrant which means there is only one instance of it.  And since it can only be executed from one location at a time, you helps eliminate problems with race conditions where one location is trying to write to the stored values while another is trying to read from them.

It is a very good architecture to learn and is very popular.

[JeffOverton]

The USR retains data between calls?  That's pretty cool.

[JeffOverton]

Worked like a charm.  Thanks Ravens Fan.

[altenbach]

---

JeffOverton wrote:
I'm not sure if a shift register would work in the data read loop, because I want the local to reinitialize every cycle.  I was worried that if I called the local outside the loop and wired it in, it would constantly be writing the initial valve states at the same time as it updates the pressure displays, causing exactly the problem I'm having.

---

Then just use a plain tunnel and place the "fixture display" indicator terminal at the output of the "bundle by name". 🙂

---

JeffOverton wrote:
Also, I'm not sure what you mean when you say the replacement of cluster values could be done in one step.

---

Just look at the picture I attached above. Here's a side-by-side comparison. See any difference? 🙂

---

JeffOverton wrote:
Again, I've only been using LV for about three weeks, so if something seems completely backwards, it's probably not me misspeaking, it's probably me being wrong.

---

This is a good time to go into things a bit deeper and learn why some ways of doing things are better that others. If you don't, bad ideas become bad habits that are harder to get rid of later. It seems you are learning fast. Good luck! 😄

Message Edited by altenbach on 01-10-2008 09:00 AM