Map DAQmx Physical channel list to Typedef cluster elements

[Blokk]

Hello,

Since I often tend to over-complicate certain things in LabVIEW, I would like to ask for "best practice" for the following task 🙂

I have two cDAQ modules, together 24 Thermocouple channels. I have a Typedef cluster with 24 double controls, representing the 24 physical sensors. Time by time, I might want to change the order, how the physical DAQmx channels (cables) are connected to the sensors. I could just simply convert the DAQmx 1D array of data to the cluster, and I could use the element order in the cluster (reordering the cluster elements) to map down the channel-name pairs. But what about if I do not want to change this typdef cluster? Right now I am only planning to change the cabling order during dev time, but what about if later I need to do such changes during runtime?

I have several solutions in my mind, both are using a kind of "home made" look-up table, or dictionary. See the snippet below. What do you think? How do you do such things?

[SpaceFlight · Accepted solution]

A more flexible option would be to use an .ini file or other text based file that defines the DAQmx physical channels.  

At run time you'd read the configuration file to load the channel configuration.  Note that the DAQmx function except strings as inputs, you don't have to use the I/O physical channel datatype.

[Blokk]

 I really like your idea! Instead of using an extra channel list, and fighting with the array to cluster transformation, I only specify the order of the physical DAQmx channel list at the beginning. So the received 1D array will be already in the proper order. Nothing else needed to be changed. A type cast, then i have the cluster output...

[Kevin_Price]

Typecasting from array to cluster is a neat-but-possibly-not-so-safe trick, especially due to the fact that cluster sizes must be fixed at development time, array sizes can vary dynamically at run time.  It can work, but it's important to be using fixed-size typedef'ed clusters.

I remember posting about this once upon a time...  yup, here it is.

-Kevin P

[Blokk]

---

@Kevin_Price wrote:

Typecasting from array to cluster is a neat-but-possibly-not-so-safe trick, especially due to the fact that cluster sizes must be fixed at development time, array sizes can vary dynamically at run time.  It can work, but it's important to be using fixed-size typedef'ed clusters.

I remember posting about this once upon a time...  yup, here it is.

-Kevin P

---

Thanks Kevin for the insight!

"It can work, but it's important to be using fixed-size typedef'ed clusters."

I guess you wanted to write "fixed size arrays"? Since the clusters are fixed sized during runtime? Or you meant not to change the size of the cluster during dev time? 🙂

Actually another danger is if you change the element order in the cluster. In such cases the solution using the labels to set values of individual elements in the cluster is better (using that MGI VI). But I guess the array-to-cluster typecast is much faster than the label-lookup solution. Ok, probably for 24 elements the speed penalty is not huge...?

[Blokk]

I have another idea, see snippet below. So I would not change the ascending order of the physical channel list, but the names of the channels (input option for DAQmx Create Channel VI). Also, instead of using external toolkit (MGI) or the non-safe typecast option, I create a FOR loop + CASE structure combo to fill the elements into the Typedef cluster in a fail-safe way. Note that, I would use a Default case in the Case structure to capture programmatic mistakes, and it would also make sense to check the incoming string array and compare it to the Typedef cluster element labels (but the incoming string array could be made safe anyway, like using a fixed 2D Listbox programmed to not accept duplicates, etc...

 

[Kevin_Price]

---

@Blokk wrote:

---

"It can work, but it's important to be using fixed-size typedef'ed clusters."

I guess you wanted to write "fixed size arrays"? Since the clusters are fixed sized during runtime? Or you meant not to change the size of the cluster during dev time? 🙂

I basically meant that the typecast trick isn't a good idea until/unless the cluster typedef has become stable during dev time.   You're right that you'd also need the arrays to be the same fixed-size -- in my past usage, the arrays were typecast from the clusters in the first place, so they *had* to be the right size, even if I added or removed elements from the cluster typedef.

Actually another danger is if you change the element order in the cluster.

Definitely!  That could turn the typecast trick into a total disaster. 

As to the latest snippet, my gut reaction is that it seems like a move in the wrong direction.  Having to hard-code all those individual cases in the case structure seems to run counter to your original goal of flexibility at both dev and run time.   A combo of the .INI file idea previously suggested and some kind of mapping or lookup table you were already working on strikes me as a better approach.

-Kevin P

[Blokk]

I wonder if there is any problem if we specify the DAQmx physical channels not in a consecutive order? Also, it might happen that different modules are intermixed in the list. For example, what if the DAQmx create channel gets a list like: dev1/ch1, dev2/ch3, dev1/ch5, ...

 I guess there is no penalty...?

[Kevin_Price]

No problem for physical channels from the same board to be non-sequential.  You can put the same channel in the list multiple times if you want.

When you start trying to make a task that brings in channels from multiple boards, that's where you could have trouble.  Only a  limited subset of DAQ devices support this ability, and even then they would require a common timing backplane connection.  PXI does this natively, desktop boards would need a RTSI cable to each board.  I don't happen to know how this would go on cDAQ.

-Kevin P