How do I get live data from a subvi while it is running ?

[altenbach]

---

@Ravens Fan wrote:

Note also that in a lot of places you send in a wire to an indicator and branch it off to a local variable of the same indicator.  That is redundant.  Sending the wire to the local variable does the same thing as sending the wire to the indicator.  Try to use wires instead of local variables as much as possible. ...

---

Exactly! Actually, the current code is much worse than you think, because you send all these strings to hidden indicators that have no other purpose or prioviding local variables. Get rid of them! All you need is a plain wire as drawn for one example in the image. Repeat for all others.

You currently get serious race conditions due to lack of dataflow. Your code cannot guarantee that the read local will be read only after the terminal has received valid data since there is no data dependency. Most likely the local variable of the string will get read well before the indicator receives valid data! A wire as shown will fully determine execution order and ensure that correct data is available in the next structure.

LabVIEW does NOT execute left to right or in any predictable manner UNLESS execution order is determined by dataflow. If you have disconnected code "islands", each can execute in any order and the order cannot be predicted.

Overall, you have way too much code. For example all code in "MPS setup loader" could be done in a few simple programming strokes instead of all these duplicate operations. You do way to many explicit operation, for example b1...b18 could be made into an array, eliminating that nightmare of connections to the subVI.. I am not sure what determines the loop rate of the big loop.

In Prg-all-sub, you have 5 sequential copies of the same code, differing only in a string. Place one instance in a FOR loop and feed it an autoindexing string array and delete the others. Now you can just update the progress indicator in the loop.

This code was clearly written by somebody pretty fluent in text based programming and it shows. You need to adapt to a labVIEW programmers way of thinking. 🙂

Message Edited by altenbach on 08-13-2007 08:19 AM

[Synchrotron Guy]

Thanks for all your inputs, it really helps !

I initially could get the \r and other unprintables to work, but I found out how to change the string constants to code view so it works. 🙂

I'll have another look at the subvi, I get what you mean and I didnt really see that before you mentioned it.

Arrays are not something I'm ready for yet, I'll go on the Basics I and II in september, so maybe I'll take up that later on.

About the use of variables, well, I know hehe, First timer bads I guess, I'm still learning, and sometimes thinking a little like it was a written code..

/Brian

[vish.solanki]

Hello,
I am using NI-DAQ 6534 card(2 byte input) taking data in handshake mode (interupt 6.2khz for two ports i.e. i receive 12.4Kbytes data per second in my card memory.)this is realtime application hence display of graph is critical..

My system: PC -3, 800Mhz, 1GB ram, WinXP, LABview 8.

Problem:
I acqurie data frame of 12500 bytes/per second read through "DIO read" and and then i send data(and compute waveforms) for analysis to different subvi's  (analysis include 4 graphs, counters etc.)
For this 1 sec data(12500 bytes) labview takes around 2.8 secs for anaylsis. and new data arrives the overhead increases and data analysis lags more than input....
. i suppose PC CPU speed.. as labview software itself startup take few minutes to open

 what could be the problem?..
can you advice ,solution
 
thanks
vishal

[Synchrotron Guy]

Hehe, I must admit that it is a little funny that you say it looks like I'm fluid in written languages.. The last time I did programming was for about a week, and that was VB, in 1997.

Anyway, as I said in one of my first posts, this is the very first thing I have EVER done in labview, so I'm quite pleased that I actually made it work.

I'm really happy to get all the input from you guys, because until I get some proper training, its the only way I can get better.

With your last comment, you were very true about the race conditions my slobby code generates. Real life experience have shown me this... What I get on the table when testing this actually works fine, but deployed on a laptop pc and dropped to about 300 power supplies (which is what this is for) actually generated about just as many combinations of settings 😞

Oh well, there is a saying, that what you dont have in brains and knowledge, you will have in your feet.. so I will spend a few days to get these things fixed so it will work as intended.

anyway, as I gain more experience in labview, I will fall in to the labview way of thinking 🙂

/Brian

[wha@atmel]

Hello Brian,

there are already a lot of comments about  your vi.   Find attached  two  hints about cleaning up .......

I was surprised as I started your vi, that my connected µController (AVR) at serial Port sent some SPI - stuff @ PortB ....    🙂

Regards
Werner

[RavensFan]

Hello Vishal,

Your message is completely unrelated to the thread that you posted it into.  If you want a reply, repost your message in a new thread.

[MKES]

Hello,

I have the opposite situation to get live data, but instead to start a new one, I like to continue in this because it's related and could be of help to others,

This is my question,

How to stop a sub-vi running continuosly (communicating to one equipment using serial port) doing data adquisition ? I have a main vi wich reads a config file... then starts sub-vi

Sub-vi has 2 while loop independent

Firts while-loop communicates using serial port with an equipment to get process variables data

Second while-loop responds to an HMI using modbus-tcp with data first sub-vi feeds to it.

They both running continuosly in the sub-vi, so main vi doesn't have a way to stop communications once control is passed to sub-vi.

I've tryed based on methods mentioned here to get live data from a subvi runing without success

Any help will be appreciated

Thanks

[RavensFan]

You could use a similar architecture.

Create a stop control in your main VI.  (It could be hidden or even an indicator).  Pass a reference to that control into the subVI.  Read the value node of the passed in reference and wire that to the stop condition of your while loops.

Your main program would set the control/indicator to stop.  Your sub-VI reads the value by way of the reference continuously in each loop.  When the stop control goes true, each loop would stop.

[KavehSohrab]

thanks so much, it was very helpful, 

Best Regards,

Kaveh,