parallel execution

[smm]

Parallel execution when multiple subvis are in a while loop is not really parallel. It executes in an inorderly fashion

I have a vi here which contains another vi file path to open which consists of a subvi. If I try to run this, I realize to the eye it might seems parallel but inherently is not. The subvi is also made re-entrant. Can anyone help me to make it truly parallel. I tried using separate while loops but it did not do it either.

7862-Buttons_ver2 is my main VI

78652-manual_EDIT is the 2nd vi in the heirarchy and then 7862SUBVI_manualmode is the 3rd in the heirarch. Its a subvi.

Can anyone help me here.

[MikeS81]

---

@smm wrote:
...

 Can anyone help me to make it truly parallel. ...

---

Hi smm,
this is only possible if you use more than processor.
If you have two or more you can use timed loops and assign each loop to one processor.

Hope this helps
Mike

[smercurio_fc]

How many DAQ boards do you have? 1 or 6? If you only have 1...

[smm]

I have one DAQ unit- the PCI 6515. I am basically trying to automate a thermostat tester. I have 6 units connected to it.

[smercurio_fc]

Well, there you go then. You can only have 1 "read" task for one device active at a time. Your "78652-manual_EDIT" is set up in parallel, but each task can only execute once the currently active "read" is done. Since the "7862SUBVI_manualmode" VI is dependent on data from the "78652-manual_EDIT" VI, it can only execute once the data has been read. You can mitigate this somewhat so that instead of 6 separate reads you perform 1 read to get a 2D array of booleans and then index out each one to your 6 instances of "7862SUBVI_manualmode". The "7862SUBVI_manualmode" VI, however, contains additional DAQ tasks so you may get some blocking in there as well.

[smm]

I had tried that, but they are grouped in different bunches, so it throws errors. Like I have say for example P3.0-3.4, P1.0-1.4 just for example... So I have lines which are onot necessaily bunched together and I don;t know how to index them.l

[smm]

Y also like you mentioned there are DAQ tasks taking place on those lines in the loops, structures

[smercurio_fc]

I'm sorry, but I do not understand what you are saying. I do not know what you mean by "bunched together". Also, "P3.0-3.4, P1.0-1.4" is completely meaningless to me.
Also, what do you mean by this:

Y also like you mentioned there are DAQ tasks taking place on those lines in the loops, structures

[smm]

---

smercurio_fc wrote:
Well, there you go then. You can only have 1 "read" task for one device active at a time. Your "78652-manual_EDIT" is set up in parallel, but each task can only execute once the currently active "read" is done. Since the "7862SUBVI_manualmode" VI is dependent on data from the "78652-manual_EDIT" VI, it can only execute once the data has been read. You can mitigate this somewhat so that instead of 6 separate reads you perform 1 read to get a 2D array of booleans and then index out each one to your 6 instances of "7862SUBVI_manualmode". The "7862SUBVI_manualmode" VI, however, contains additional DAQ tasks so you may get some blocking in there as well.

---

What I am trying to say is, you said I should create an array and perform the reads. I had done that initally. But the subvi contains DAQ tasks and using the value after indexing arrays is leading to errors.

Also the P3/0-3.5 ets are port nos and lines. So i don't have lines of a function in a straight order together. The indexing also makes DAQ writes difficult to implement.

[smercurio_fc]

I didn't say to create an array to perform the reads. What I said is to perform a single read that reads multiple channels/samples to generate a 2D array. You index out the individual rows and give them to the individual instances of your "7862SUBVI_manualmode" VI.

The only reason I suggested this was to help in your parallelling attempt. I'm not telling you to completely recode your DAQ operations. You initially claimed that LabVIEW wasn't performing the parallel operation, and I explained why: you only have 1 DAQ card! On the generation side you have a similar restriction, though you can manage to get two output tasks running if one is controlled by software and another is controlled by hardware, as explained here. How you handle the situation at this point is really up to you. The bottom line is that your bottleneck is because you only have 1 DAQ card. It's not because LabVIEW "can't parallel".