LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

reference node

Hi again all!

 

Well, I'm still plugging away at various applications (still using 7.1 on my laptop too - for the most part!)  and have a query for you good folks out there.

 

One of my applications has a few events going on at once, and depending on the current state of each event I require a valve to open.  

 

In a nutshell, 1 or more events ON the valve is shut, if all events are in an OFF state then the valve will open.

 

Now I have had this working before, using reference nodes but they just aren't working not - I think thier settings on the original I use for referal may have been borked up in the passage of tme.

 

Each 'event' is monitored in a case structure within a while loop.  On the same vi I had reference nodes (I think I do/have/had at least!) of which were encased solely in a while loop.

 

This had to be done due to the need for the case structures for each 'event'.

 

So, in this other 'solely a while loop' while loop I have 5 references, hopefully monitoring an LED (in one of 5 case structure/while loops)  that indicates when a fieldpointexpress vi. is ON, or giving an output so to speak.  All 5 references in the (solely a while loop - like the terminology here?) lead to a 5 input array, then a NOT gate connecting to another Fieldpoint express vi of which turns the valve on.

 

So, how the heck can I get these 'nodes' (for want of a better word) to correctly read the state the 5 'event' fp express' are in?

 

Hope you can help (as you always do!)

 

regards,

 

Steve

0 Kudos
Message 1 of 10
(2,772 Views)
Is there any chance you could post your code or at least a screenshot?  I'm getting a bit lost in your terminology and it definitely sounds like you're using too many references.  When you say "event" are you actually using an event structure, or something else?  Are your events triggered by the user or by reading from an input?  A look at your code would make it much easier to understand what you're asking.
0 Kudos
Message 2 of 10
(2,754 Views)

Hi Nathand, thanks for replying.

 

As it's just gone midnight here in Singapore (Brit working abroad) I'll make a simplified vi in the morning for you, as I link the cFP2020 up with a Qlarity g75 touchscreen. 

 

Those 'events' are button presses from the touchscreen for various purposes.  The amended one I will send will have all the qlarity stuff removed for ease, and be a little simplified - but will retain the gist of what I am trying to regain.

 

All shall become clearer in a few hours for you.   

 

Thanks again for looking at my query, much appreciated.

 

Steve

0 Kudos
Message 3 of 10
(2,747 Views)

Here we go.

 

I have simplified the vi greatly, leaving only the relevant parts.  Note that the while loop / case structure parts were there originally for a timing sequence.  This is simplified by a 'safety switch' I have added, but leaving the while loop / case structure intact (as that could effect the nodes if removed).

 

 So, if none of the switches/heaters are on then the valve is open.  If any or all of the switches/heaters are on then the valve is closed.

 

cheers!

0 Kudos
Message 4 of 10
(2,725 Views)

Sorry, I don't have fieldpoint, but why are you having all these loops spinning like crazy as fast as the computer allows?

 

How long does it take to switch a valve? Can't you jut place everything in one loop, with one single stop button and with 5 case structures. Place a delay in the loop so it spins at a defined rate. e.g. every 10 ms.

 

Do you really need to write the same state to the valves millions of times/second? Isn't it sufficient to write to the hardware once and then whenever the state chages? 

 

If any of your loops accidentally stops (e.g. if you hit one of the stop buttons) that part will no longer react to user interaction, but you would never know.

0 Kudos
Message 5 of 10
(2,721 Views)

Hi Altenback,

 

I thought the write to hardware setup was set to 'state change' - I'll have a look at it - thanks for pointing it out, that bit must have slipped my attention!  🙂

 

 The thing about not being able to put them all in one loop is due to the fact that once an operation has occurred (I have taken out those parts to focus on the node/reference part itself) then a timer stars for that particular heater.  Each heater cycle can be reset (I have taken that out in this example) individually, without effecting any of the other 4 heater circuts.

 

The case structures however require thier own individual loops in order for the timer and resets to work.  If they were as you said (I have tried it and wished that it did work!) 

 

That's the problem you see.  I had it working over a year ago, but it seems to be misbehaving now (all my fieldpoint units have been checked for errors too).

If I directly wire them then the signal gets lost when it leaves the loops.

0 Kudos
Message 6 of 10
(2,716 Views)

fios wrote:

The case structures however require thier own individual loops in order for the timer and resets to work.  If they were as you said (I have tried it and wished that it did work!) 


There should be no problem keeping track of 5 timers in a single loop, You can do it as an array of five timer values, kept in a shift register.

Message 7 of 10
(2,710 Views)
Writing it up the way you mentioned there...finger's crossed! Hopefully each reset button (on the large more complicated vi) won't become a general reset 🙂
0 Kudos
Message 8 of 10
(2,700 Views)

Just tried it - no too much better, but I will directly attempt to wire to the 5 input array rather than use a node this time.

 

I forgot to mention earlier too, and I really should have, that in the original configuration (of which includes the example above) the valve output flashes at about 3 or 4 times a second.   With this (using nodes but reduced  loops) the valve output flashes once a second.

 

 

0 Kudos
Message 9 of 10
(2,697 Views)

That seems to have done the trick! Cheers mate 🙂

 

Much appreciated.

0 Kudos
Message 10 of 10
(2,694 Views)