parallel configuration for DAQ

[smm]

I have written a program in LabVIEW 8.5 to test thermostats. I had initially written the code for testing 1 thermostat, now I have modified it to test 6 thermostats in parallel. I'm going to be using a PCI 6515 DAQ unit by NI and Labview 8.5. The code is done in the State machine form.The thermostat has 4 outputs (W, Y, GH, Gl) which are inputs to the DAQ since I want to read the signals. The inputs to the thermostat are power and temperature control which are outputs from the DAQ. So I basically write to these lines.Now the problem is I'm writing to port 4 lines 0-5 and port 5 lines 0-5. Port 5 lines 0-5 are for power for every thermostat i.e Port 5 line 0 for T'stat 1, line 1 for t'stat 2, line 3 for tstat 3 so on and so forth till t'stat 6. I want to turn the power on after the state named dialog1 and then I want these lines to be turned high till the end.Port 4 is for temperature control. line 0 for t'stat 1, line 1 for t'stat 2 so on till t'stat 6.Port 4 lines 0-4 are manipulated in most states. Sometimes turned on, sometimes off.I want to know how to handle the daqmx write VIs. Like do I need to incorporate multiple create channels for every write VIs sor can I work with one create channel annd somehow be able to spilt lines I write to. This question might be confusing. I have attached the code here. I know for a fact that I am handling the write VIs incorrectly. It's only edited for the 1st case structure.All other case structures are replicas because they represent every thermostat.I fogot to add the VI in my previous post. This is it

[mross]

QUOTE(smm @ Jan 7 2008, 09:43 AM)

I have written a program in LabVIEW 8.5 to test thermostats. I had initially written the code for testing 1 thermostat, now I have modified it to test 6 thermostats in parallel. I'm going to be using a PCI 6515 DAQ unit by NI and Labview 8.5. The code is done in the State machine form.The thermostat has 4 outputs (W, Y, GH, Gl) which are inputs to the DAQ since I want to read the signals. The inputs to the thermostat are power and temperature control which are outputs from the DAQ. So I basically write to these lines.Now the problem is I'm writing to port 4 lines 0-5 and port 5 lines 0-5. Port 5 lines 0-5 are for power for every thermostat i.e Port 5 line 0 for T'stat 1, line 1 for t'stat 2, line 3 for tstat 3 so on and so forth till t'stat 6. I want to turn the power on after the state named dialog1 and then I want these lines to be turned high till the end.Port 4 is for temperature control. line 0 for t'stat 1, line 1 for t'stat 2 so on till t'stat 6.Port 4 lines 0-4 are manipulated in most states. Sometimes turned on, sometimes off.I want to know how to handle the daqmx write VIs. Like do I need to incorporate multiple create channels for every write VIs sor can I work with one create channel annd somehow be able to spilt lines I write to. This question might be confusing. I have attached the code here. I know for a fact that I am handling the write VIs incorrectly. It's only edited for the 1st case structure.All other case structures are replicas because they represent every thermostat.I fogot to add the VI in my previous post. This is it

Just a comment to help you get help. Please hit the enter key every now to create paragraphs and thus make your post more readable. I wanted to give up just looking at it.

I glanced at your vi and think there is one principle you need to know immediately.

The way your state machine is constructed, none of your functions is wholly parallel. The case structures within the outer while loop will execute in parallel, but they will stop each in its own time, and the while loop will wait until all the cases are completed before proceeding to the next iteration of the while loop.

It is more common when running parallel operations to have a while loop for each process.

Here is the principle I mentioned: All of the structures - case structure, for loop, while loop, sequence structure, event structure, etc. - they will not operate untill ALL their input tunnels have received data, and they WILL NOT stop and pass data untill ALL of their output tunnels have received data.

This means that if anything happens to hang any of your case structures the whole vi will grind to a stop and wait for that data to be produced. This is becasue the outer while loop is going to wait for each and every one of its output tunnels has received data before it wil recycle and produce new inputs for all the cases to run again.

This is the principle of data flow. Data flow is what makes LabVIEW work in so many ways that are easier than the usual text based programming language which is sequential. But data flow requires a shift in thinking that can be slow in coming. If you learned a text language in the past and are just now learning LabVIEW without any gurus nearby, it can be a very important point to hear about data flow the first time.

Another style comment needs to be made that is we usually try to fit the entire block diagram (BD) into one screen so that no scrolling is necessary. This is done by the creation of sub vi's. Your "Cool Mode" case would be a good example of where to create a sub vi.

The sub vis add depth to the code rather than height and width. Sub vis are opened up by double clicking on them. You have created a vi that is unmanagable with out the use of the Navigator Window. It is fair to say that the navigator window was created partly to help out with small monitors, but also to compensate for badly built vi's that are too large in screen area.

The use of sub vi's does not hamper execution at all. In a sense sub vis are a fiction for the programmer, each time you change the BD or front panel (FP) the vi is recompiled behind the scenes. There is essentially one big program running behind the scenes and you are absolved from worrying about that, at least for mundane programming. I don't mean that as a slight since for 6 years I have never had to concern myself with the behind the scenes business - all my own work with LabVIEW is mundane by that definition. Sub vi's are your friends. They will make debugging much easier to accomplish than a large BD.

Mike