LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

SUBVI connections issue

Solved!
Go to solution

Hi,

 

I have a Eurotherm 3504 temperature controller connected to my VI including a number of SUBVIs to set the set point value and read the current temperature. The main code which is attached was not very new, so in order to make it communicate with Eurotherm I had to replace most of the SUBVIs with their 2008 version of drivers. Now, all my SUBVIs are working fine, I can read the current temparature from Eurotherm by both the subvis separately and by the main VI and I can set the setpoint through the "set setpoint value" subVI, but I can not do that by the main code. The fact that subvis are working fine but the main code is not, tells me that something is wronge with their connections. Can anyone help me find out what is going wrong in my connections?

If it helps, the "set setpoint value" subvi is in "run test" section of the code.

 

Thanks

 

0 Kudos
Message 1 of 4
(2,896 Views)

I see two major flaws in your VI that might explain the problem you are describing.

 

You event structure and your case structure both have tunnels that are set to "Use Default Values if Unwired".  Uncheck that options on those tunnels from the right click menu.  Your VI will now break because you have unwired tunnels.  Now you can go and find those unwired cases and fix them by wiring values through those cases.

 

The problem is if your code executes a case where something like the VISA wire doesn't travel through, the value coming out of that case and going into the shift register will be the default, which happens to be an invalid resource.  The next time a case runs that needs that resource, it won't work because you don't have a valid one anymore.  It might even throw an error, but you'll never know because the errors are never displayed or handled in any way.  They just go into their own shift register which may also keep other code from running in other iterations, or may just get discard because that tunnel is also set to "Use Default if Unwired" which is a "No Error" cluster value.

 

Second, I see two state machine cases that have event structures in them, and both of those have events that are set to Lock Front Panel Until Event Completes.  So if you trigger an event by pushing a button, it will lock the front panel.  But if the event structure that handles that event doesn't ever execute because the flow of execution never gets to that case, you'll lock up your code cold.  It is highly recommended that you don't have more than one event structure in a VI.  It can be done, but unless you really know what you are doing, I guarantee you'll screw it up.

 

Read Caveats and Recommendations when Using Events in LabVIEW - LabVIEW 2015 Help

 

When you have an event structure, have just one.  Put it in a case that will regular execute.  For instance, your state machine can regularly go to a state called "Check Events" then go back to where it was if there are no events and the timeout event occurs.  That or look at an architecture called "Producer/Consumer with Events".  That can be combined with a state machine.

Message 2 of 4
(2,857 Views)
Solution
Accepted by topic author Golareh

We really need to see "Timer FGV.vi" and "Array Builder.vi".  A typical profile file would be nice too!

 

Likely you never press generate profile on the configuration Tab.  Nothing actually guarantees that it is pressed and, that event is the only one that uses the data from temperature steps and writes to "Temperature profile."  Without writing to temperature Profile" the Timer FGV.vi has no data to write as a new setpoint. 

 

Obviously, the order of execution for required steps needs to be programmatically enforced by the state machine state flow rather than depend on an educated user.  Refactor your states.  


"Should be" isn't "Is" -Jay
Message 3 of 4
(2,805 Views)

Thank you. I guess the problem was with generating the data. I got and it is working fine now.

 

0 Kudos
Message 4 of 4
(2,777 Views)