LabVIEW Development Best Practices Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx multiple tasks

Solved!
Go to solution

Good day LV BP team.

 

I'm developing a DAQmx system that serves 6 identical test stations.

 

I've decided to build a preallocated clone reentrant executed Functional Global Variable to manage DAQmx tasks however this is not working as I expected.  It works fine for the first station but it does not work when I use two or more stations.

 

My original plan was to manage 6 different instances of the reentrant FGV.   Configure each and run DAQmx commands separately.

 

Dinnova_0-1647473885682.png

Dinnova_1-1647473926299.png

 

My basic question for the team is what is the best practice when it comes to DAQmx serving multiple stations?

 

I'm ready to re-write my code.

 

Your experience and advice will be much appreciated.

 

Sincerely,

Julio Aguayo,

Dinnova Ingeniería

 

0 Kudos
Message 1 of 9
(3,933 Views)

Is it true that each of the 6 test stations is a different computer running a LabVIEW program? How do they physically connect to the DAQ instruments?

 

I think only 1 LabVIEW application can connect to a DAQ. So one option is to: Connect -> Do an action -> Disconnect every time, from every station. It's not very elegant. You will need each machine to catch errors like "Can't connect - device busy".

 

Another option is to make 1 master station (or a 7th computer) own the DAQ instruments. Then you need some additional message scheme between the 6 test stations and the DAQ server. The stations would never know the DAQ address, they would only send high-level command like "Set Mux( 3 )". You will need to choose some station-to-server communication that is comfortable. The easiest place to start is Network Streams (lossless for incoming commands) and Network Published Shared Variables (lossy latest value, all stations can view the hardware state).

 

I'm no expert with this type of architecture, hopefully others can give input too.

0 Kudos
Message 2 of 9
(3,919 Views)

a. Functional globals work when the vi is non-rentrant.

b. Storing refs in functional globals can be tricky due to the lifetime of the ref. 

 

Without diving too deep into your code, my suggestion would be to pick a different pattern. Sorry I can't be of more help, but I don't have time to dive any deeper right now.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 3 of 9
(3,910 Views)
Solution
Accepted by Dinnova

Also - just quick glance  but it looks like you are mixing regular global variables and FGVs. I wouldn't recommend that. 

 

One question to ask yourself every time you reach for either an FGV or a regular global is: Does this data really need to be global? Is there a way to pass it via a wire and normal dataflow? If so, that is usually the better answer.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 4 of 9
(3,908 Views)

Thanks for your comments.

There will be only one industrial computer having the DAQ instruments and attending the six work stations.  All running from one centralized CPU.

0 Kudos
Message 5 of 9
(3,876 Views)

My intent with FGV was to be able to perform DAQ tasks from anywhere in the remaining code without running wires for that.

0 Kudos
Message 6 of 9
(3,872 Views)
Solution
Accepted by Dinnova
@Dinnova wrote:

My intent with FGV was to be able to perform DAQ tasks from anywhere in the remaining code without running wires for that.


From this statement, it appears that you are expecting two separate calls to an FGV to access the same values stored within the FGV's uninitialized shift registers (USRs). The moment you have two separate calls to your FGV even with the same 'Oven' input, say 'Oven 1', you are working with two separate, unrelated memory spaces. As Sam Taggart has already indicated in point 'a' of his first post of this thread, such FGV behavior will work only with a non-reentrant VI. You can easily verify this, by writing up a very simple FGV that uses only one USR, holding an integer, with maybe two cases within - a set and a get; and try both, reentrant and non-reentrant calls with two separating calling VIs.

 

It appears you already know about message queues from your other topic post. The basic idea is for you to launch up to 6 message handling loops (each 'message' would correspond to your FGV command; as an example). Your coordinating routine, along with the GUI routine, should know which 'Oven' (i.e. test station) should receive the aforesaid message. You will need to consider alternate scenarios. For example: Should any problem detected with one oven affect the running or stoppage of the other ovens.

Message 7 of 9
(3,859 Views)

Thanks for your insight.

I have enough information now as to re-write my code.

My FGV will not be reentrant

0 Kudos
Message 8 of 9
(3,843 Views)

LabVIEW FGVs are an old topic. If you have not already done so, I would encourage you to do an online search. You will find quite a few well-written blogs. Some of those blogs also contain comments that you would not want to miss.

0 Kudos
Message 9 of 9
(3,833 Views)