parallel execution

[smm]

I have another DAQ unit USB 6501 that I can use. But correct me if I'm wrong. What you are saying is, it's advisable to use separate DAQ units for every t'stat unit to obtain parallelism?

[smercurio_fc]

At the extreme end, yes. However, you don't always have to do this. As I pointed out, one way to improve the situation is: instead of performing 6 reads, you can perform a single read to read all 6 channels and then indexing out the data. You would also need to refactor your "7862SUBVI_manualmode" VI to keep in mind the hardware bottlenecks. I have not investigated your VI in detail, nor do I know what exact steps you're doing, so I can't tell you exactly what to do. That's your job.

You won't be able to get full parallelism, but you can probably get close.

[smm]

Ok so could you advise me, can I keep the writes as they are?

[smm]

Actually if you see the 7862SUBVI_manualmode, you'll see that each read is a collection of 6 signals as well. So in that subvi I am indexing it.

[smercurio_fc]

I'm not referring to that instance. I'm referring to the "7862-manual_EDIT" VI.

Of course, after looking at your "7862SUBVI_manualmode" VI in more detail I can see you've got other problems. For instance, is the "Wait Plus" VI reentrant? If not, that will be another bottleneck. You're trying to launch individual instances of "7862SUBVI_manualmode". Each one starts at the "Initialize" state and then goes to the "Dialog1" state. In that state you are calling the "Wait Plus" VI. If that VI is not reentrant, then the other instances will have to wait (30 seconds) until the wait in one instance is done before they can continue. You then proceed along with other states, where you have sprinkled some DAQ reads and writes. Again, these will be blocking between the separate instances of the "7862SUBVI_manualmode" VI. One big blocking state is the "Heat Mode A" state.

As it is, your architecture simply does not lend itself to parallelism, and reentrancy will only help you so much. What can you do about? Well, you're somewhat limited by hardware. One thing that you may want to consider is to have a completely separate, independent DAQ read loop that's continously reading all channels and all lines. You could timestamp it and save the data into a shared variable or something. Then instead of using a DAQ read you could access the data from this shared variable. Since some of your reads seem to require that you read it after something has happened, you can use the timestamp to wait until this "global" data has been updated to have samples after a certain point in time.

[smm]

Ok. Damn.  I feel, the more i use LV, the more I don't like it

[smercurio_fc]

This has nothing to do with LabVIEW - it's fundamentally a hardware limitation (see here). You would have the same exact problem in any other language.

[RavensFan]

---

smm wrote:

Ok. Damn.  I feel, the more i use LV, the more I don't like it

---

Don't feel that way.  You are working on a pretty sophisticated project.  Like you were told before, it's best to start small.  Work on details of the code, and have an overall architecture planned from a higher level before you start trying to do everything at once.

Smercurio.  That wait plus is (or should be) re-entrant.  There were numerous messages about this project in the past.  Here is a link to one of the threads.

http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=306437#M306437

smm,  I'm a little confused about what your current problem is.  In your first post of this thread, you say.  "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."

What do you consider parallel operation?  How "unparallel" is the operation?  Are you trying to read all channels at the same instant, within microseconds, milliseconds, seconds?  If they are to be instantaneoulsy, or nearly so, why?  I thought you were running test sequences on 6 independent thermostats at the same time.

Message Edited by Ravens Fan on 05-08-2008 12:02 PM

[smercurio_fc]

Ahh, so this has been discussed before. I have to say I didn't think to look in a 10-page post about push buttons to find out if a discussion about parallelism had been talked about.

[smm]

Ravens Fan wrote:

What do you consider parallel operation?  How "unparallel" is the operation?  Are you trying to read all channels at the same instant, within microseconds, milliseconds, seconds?  If they are to be instantaneoulsy, or nearly so, why?  I thought you were running test sequences on 6 independent thermostats at the same time.

---

So last week I thought this program was all done for once but then there were new requirements. Now what they wanted was... if the unit passes display a msg saying unit pass-press space and go to the next state. If the unit fails at some stage (say fan), then a user message should be displayed saying unit Fail- hit enter, and then the program should resume from 2 states before that.

So whilst I was doing this, I purposely tried failing a few units to see the response, there I could see that

a) the order of execution wasn't correct. It did unit 1-2-6-5-4-3 instead of 1-2-3-4-5-6  or most correctly as should have been all 1-6 simultaneously.

So if unit 1 passes, it goes ahead, if 2-6 fail, it goes back to prev states depending on which was getitng executed and then moves ahead for unit 1.

And yes I am trying to run 6 tstats at the same time. Phew