Local Variables in parallel loops

[Malakeh]

Hello, I am trying to see if there is a way to run in parallel two tasks on the same equipment. More specifically with the DAQ functions. My problem is that i need both to have a continuous indication of temperatures but also trigger when to start recording data. At the moment the way i have programmed it is to run the temperature acquisition in a parallel loop and trigger when to collect data and acquire the data by using local variables. However because i am new to LabView i had no idea that using locals is actually bad programming in LabView so i wanted to know if someone could tell me if its ok the way it is right now or is there some other way to do it? I am currently running on LabView 9.0 Cheers

[Malakeh]

I couldn't upload my file to the message for some reason here it is sorry for the inconvinience https://rapidshare.com/files/2962955303/Program.rar

[Dennis_Knutson]

Try attaching again - perhaps as a zip file. That site of yours requires registration.

The use of locals can be a problem. Also, you cannot run more than one task on the same hardware - i.e. an analog read.

[Malakeh]

Hi Dennis, I tried doing the zip file that you proposed but still it doesn't work . You can download from the server even if you are not a member or registered just follow the Grey "Free Download button" Again sorry for the inconvenience. Cheers

[altenbach]

Here's the above program attached as zip file. Seems to work OK.

(Sorry, I cannot efficiently work on this code, because my monitor is only 2048x1152 pixels and thus way too small)

[Malakeh]

So the use of the Local variables in this case is ok i guess?

[Yamaeda]

Although ridiculously large, it's structured, well wired and you do use a few sub-vi's. You dont use many locals and the functions connected are wired so you shouldn't create any race conditions as far as i can see.

However, a few more sub-vi's would go a long way, specifically the case-structures in the middle where you clearly make the same thing at 5 places.

/Y

[JÞB]

---

@Malakeh wrote:
So the use of the Local variables in this case is ok i guess?

---

The Locals can be problematic but, you have bigger problems.  Those unwired tunnels with defaults feeding USRs scare me silly.

The Ke

Keilthly init where you bundle by name and pass the input to the output ignoring the new data scares me.

Initializing the keithley INSIDE the main loop every time Scares me (Keithley's especially like to hang up if re-initialized often)

Needing the Navagation window scares me.

I guess the locals are actually a "lesser included offense"

[Malakeh]

Thank you for your replies, Hi Jeff thank you for remarks. The purpose of that loop is to monitor continuously a temperature and the case structure inside is to initialize the recording of data from the for loop below the reason why those outputs are not wired is because i want the previous for loop data acquisition that was triggered to be cleared and initialize the array wires at their default(no data in them) again so the next triggering will deal with empty arrays. I must say that i dont know if i done this correctly but my intention was that. Please be free to suggest me another way of doing this if you think that is more appropriate. When i saw the 2nd part i was like wth have i done 😄 thnx for pointing that out :). The funny thing is that i run it like that and it worked fine but yes its a major mistake :D. The initialization of the keithley inside the loop i don't know if it will be such a big deal since the program runs only after the input of the user and it would require sometime before it would run again, also it is not my intention to run the loop continuously. Do you have a suggestion for that? Again Thnx to all Cheers

[JÞB]

Well,

First- if it works it works.   With code that approaches abstract art "fiddleing" with it garuntees headaches.  This "Spaghetti code" occurs in more places than you think and is usually a project that grew in scope and complexity beyond the base archietecture's utility.  So, with that said you asked for advice.

Look in the LabVIEW examples on design patterns and study them to avoid this type of code in the future.

Break the code into functional blocks on paper what are the inputs and outputs haw are they generated?

For your application , essentially, "Get ready- get data- display data- exit" I would probably chose a Producer- consumer template to start.   I would have a Queued state machine driving the hardware. Think three states "Initialize resources", "Use resources (get data)" and "Close resources".  You may need a "Read Filters" too.  Since the user infrequently presses the "Get'r'Done" button I would have an event loop looking for operator activity (Exit and Get'r'Done) and looking at updates to the display to show system state (Initiallizing, Ready, At work, Closing...)

The shipping examples and the Large application development user group page are good places to start.