terminal name from physical channel

[Yuri33]

Is there a way to programmatically determine the associated terminal name from the physical channel name?  Since physical channels cannot be used for signal routing (e.g., DAQmx Connect Terminals), I would like to know what terminals to connect based on a user supplied channel name.

For example, in an M-series board (6221), the digital channel p2:0 is also known as terminal PFI8.  At run-time, knowing the user input p2:0, I would like to programmatically connect the terminal PFI8 to the RTSI bus so I can use this channel as a trigger for other tasks across multiple devices.

[Brooks_C]

Good Morning Yuri33,

I’ve taken a look around and I don’t think there is a way to directly convert a channel name to the associated terminal name i.e. /Dev1/P2.0 to /Dev1/PFI8, but I have a couple suggestions that can allow you to accomplish this.

Below is a screen shot of an example program that I made to change the name programmatically.  Basically I used the Type Cast VI to convert the physical channel constant to a string and then I use the Search/Split String VI to search for the ‘/’ character with an offset of 1.  The offset makes the search ignore the first character so the first ‘/’ is skipped and the output given and input of “/Dev1/P2.0” is “/Dev1” and “/P2.0”.  Once I have split the channel name I wire the “match + rest of string” output which is “/P2.0” to the selector terminal of the case structure.  Then for each case I manually rebuild the string path using the “Substring before match output” and a constant corresponding to the correct PFI line.  You can create a case for each physical channel so that it will format the string correctly.  Note:  The cases are case sensitive so if you want the user to be able to enter “p2.0” and “P2.0” you would need two cases.

Another solution that would be easier to implement would be to include a picture of the device pin out on the front panel of your VI.  Then the user could just use the drop down menu to select the appropriate PFI line and have the pin out for reference so they knew to select PFI8 if they wanted P2.0.  My DAQ card has been named “SuperDAQMaster” instead of the default “Dev1.”  If you’d like to rename your card you can change the name in the Measurement and Automation Explorer.

I hope this helps, and if not please reply with more information about what you want so that we can offer more suggestions.

Have a good day!

Message Edited by Brooks_C on 02-12-2008 11:10 AM

[Yuri33]

I thank you for taking the time to provide a solution, but I was hoping there was a better way to implement the feature other than hardcoding the conversion in.  My software may be expected to run on computers with multiple device configurations, so I can't be certain that a 6221 board will always be used (that's why I only used it as an example).  I just figured that since the DAQmx driver has all this information available (privately, at least), it could be exposed to us somewhere via a property node (perhaps on the device class or the physical channel class).

[Brooks_C]

Hello Yuri33,

The reason that there isn't a build in function to do this is because internally on the board Port2/Line0 refers to a different hardware system than PFI8.  Port2/Line0 is a digital input/output line and while it might share the same output stage with PFI8, which is for timing input and output, the lower level hardware is different when referring to one name or the other.

The best solution would be to make the pinouts for your devices readily available so that the user knows which PFI line to select.  Calling this pin by a different name is essentially trying to change its functionality.  For the purpose of routing signals the PFI reference must be used.

I hope this helps explain a little better why you have to use the correct PFI line name rather than the digital I/O name when routing signals.

Have a good weekend!

[Kevin_Price]

Brooks,

I'm just chiming in as another interested user.  I do understand your explanation about the distinction between different ways to refer to certain signals.  Routing is possible for timing signals while data acq is only performed on channels, etc.

However, as a developer, I agree with Yuri33 that the inability to map from one to the other programmatically can be a real shortcoming.  A pinout diagram on the UI will help many users, but may only confuse others.  Having to ask a user to keep 2 independent inputs in correspondence is like begging for an occasional mistake.

-Kevin P.

[Brooks_C]

Hello Kevin and Yuri,

I agree that it would be nice for the names to be interchangeable at the level of the user interface.  I will go ahead and submit a product suggestion at the Product Suggestion Center and encourage you to do the same.  R&D reads each of these suggestions, and they carry more weight coming from customers.

Have a good night!