parallel execution
in [LabView]
|
Prev: Stepper Motor & FP-DO-403
Next: Save For Previos... menu is greyed out for project styleinstrument driver in Labview 8.0.
From: smm on 7 May 2008 14:40 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
From: smm on 7 May 2008 14:40 Y also like you mentioned there are DAQ tasks taking place on those lines in the loops, structures
From: smercurio_fc on 7 May 2008 14:40 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
From: smm on 7 May 2008 14:40 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.
From: smercurio_fc on 7 May 2008 15:10
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 <a href="http://zone.ni.com/devzone/cda/epd/p/id/354" target="_blank">here</a>. 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". |