Pin Parameter is not supporting multiple instrument type

[bharathirm11]

Bug Report

The measurement configuration parameter of pin type does not allow for defining multiple instrument types in type specializations. This limits us to grouping two or more pins. More about the use case is described below.

Repro or Code Sample

1. Define a new parameter in the measurement configuration.ctl
2. Define the parameter as pin type and select two instrument types in Get Type Specialization.vi.
3. Create pinmap with pins of two different type
4. On running the service, the UI pin dropdown populates only the last instrument type pins defined in Type specialization list.

Expected Behavior

The pin parameter should populate the pins of both the instrument types from the pinmap.

Current Behavior

The pin parameter dropdown shows only the last instrument type defined in the parameter type specialization list.

Possible Solution

Glad to contribute if required.

Context

We have two use cases I can provide here,

1. We have a Regulator Load measurement where the measurement plugin is capable of using SMU or DMM to measure the load voltage based on the instrument available in the bench.
2. We have an RF measurement plugin that uses an attenuator from a 3rd party (Agilent or HP). Again, the measurement should allow the user to configure the pinmap based on the instrument available in the bench and reuse the measurement plugin.

In both case the measurement plugin developed can be used with the instrument available/required based on need.

Your Environment

• OS & Device: [Windows]
• Measurement Plug-In SDK Service version [e.g. 3.3.1.1]
• InstrumentStudio version [25 Q2]
• LabVIEW version [2024 Q3]

AB#3232037

[jasonmreding]

I would probably call this more of a feature request than a bug, and supporting this isn't as trivial as it might seem. The type specialization API presented to the author is an array of annotations which is somewhat unfortunate as that could give the impression this is supported when it isn't. We also don't perform any validation on this which might alert the user to the error sooner than later. This array then gets mapped into a dictionary in the measurement service API. The way this works in protobuf is that only the last entry written is maintained by the dictionary. To support this, we would have to encode all values in the array for the same key into a single string. That usually means creating a comma delimited string. That would then have to be decoded by all clients into multiple values, and all client APIs would have to be updated so they could retrieve multiple values for that single key (or a list) rather than just a single instrument type.

[bharathirm11]

Thanks for the details. For our UI pin dropdown, we currently expect a single consolidated list of pins based on the selected instrument types (one or more). The user can configure the pin within the measurement configuration. At runtime, the FAL API handles the instrument type by using the sessions info from the Reserved Pin Session.

[jasonmreding]

Ah, so you are wanting this in support of development of your own HAL/FAL? I sort of envisioned a HAL/FAL API would end up declaring its own instrument_type for use with reserving sessions so it could add its own API for creating or attaching to sessions. This API would return the type specific HAL/FAL session type used to interact with the device from that point forward.

With that said, I don't know of anyone who has tried to do this yet so I'm not sure how well that strategy works out. I'm sure there are other ways you could go about it. I guess the new instrument type strategy means you kind of have to reimplement I/O discovery to some extent for pin controls and what not which might not be ideal.

[jasonmreding]

This is likely to get closed/rejected as a bug. We may still keep it around as a feature request. In the meantime, the possible work arounds would be to either:

1. Don't constrain the parameter to a particular ioresource.instrument_type. This means the end user would see channels/resources from all instrument types and would need to know which ones are valid.
2. Create a parameter per instrument type and modify the UI as needed to choose or swap between the valid instrument types.
3. Define a new instrument_type for the FAL/HAL and create I/O discovery/session manager plugins for the instrument type as desired.

From a feature perspective, the work involved would be to:

• Update Python measurement SDK to support multiple instrument types. We would need to encode all instrument types into a single string value in the annotations dictionary.
• Update LV measurement SDK to support multiple instrument types. We would need to encode all instrument types into a single string value in the annotations dictionary.
• Update C# client code to properly decode multiple instrument types from the annotations dictionary.
• Update C# ioresource/pin control used for .measui user interfaces so that it understands filtering for multiple instrument types rather than just one.
• Update LV gplugin code used to populate values for list box control for .vi based user interfaces. It's possible we might get this for free with the other changes.
• Make design decision on whether we are comfortable with allowing this type of specification. For things like DAQmx, there were thoughts of creating additional annotations for things like iotype (e.g. physical channel, terminal, task, etc.) and channel types (analog input, analog output, digital input, etc.). If we are going to allow multiple instrument types for the ioresource.instrument_type annotation, then creating subsequent annotations that would only apply to one of the supported instrument types gets kind of weird.

If another development team wants to take this on, I am happy to consult and review PRs as needed. However, I don't know this will be an immediate priority for my team.

[bharathirm11]

Thank you for the insights, @jasonmreding.

Workaround #3 – Defining a new instrument_type_id under a custom instrument would be close to our use case of performing the same function in two different instrument types. For example, measuring frequency using the Counter (DAQmx) or the Scope. But the drawback is that instrument channels need to be added manually, even for NI instruments. Also, we may need a secondary configuration to map resources with the instrument type/driver to handle HAL.

As an additional workaround:
4. Define the parameter not as pintype and use a custom pinmap parser API to fetch pins of the necessary instrument types to populate in the list box control. Then we can employ the FAL/HAL approach based on the "session info" after pin/session reservation.

Currently, the pinmap library is dependent on session reservation, which forces us to create a custom pinmap parser to access pinmap information for UI features, such as a custom InstrumentStudio plugin for debug needs or instrument softpanels not provided by NI, like Switch Executive or relay/switch control.

Based on our RF device validation, customers are expecting to reuse the measurement across different benches with available instruments. Therefore, enabling pin control to support multiple instrument types will be beneficial for building a validation framework with FAL capability and will increase user adoption of the InstrumentStudio solution.

[jasonmreding]

But the drawback is that instrument channels need to be added manually

Right, that is why you would also to implement an I/O discovery service plugin so that you can serve up I/O resource choices to controls bound to measurement parameters marked as pins or ioresources. However, given the nature of your FAL/HAL, I suspect a single annotation for instrument type would be sufficient for you to achieve the desired filtering of resource choices across all of your use cases. Adding additional annotations for this sort of filtering is something that was discussed when adding I/O discovery, but it wasn't needed/requested at the time so it wasn't implemented. You could revisit that if this is a strong need for your features, and this design sounds promising.

Currently, the pinmap library is dependent on session reservation...

I think that is a misunderstanding on your part. It's actually the other way around. The session management library is dependent on the pinmap library, and the session management APIs are the only things exposed through the SDKs provided here. The session management service then talks to the pinmap service as needed. The only pinmap related APIs exposed from the SDK currently is related to registering a pinmap with the pinmap service since that was needed at one point in order to write a TestStand code module in LV in order to register a pinmap for use with the sequence. However, we have since implemented a built in TestStand step type that does this without the user having to write a code module so this is mostly unused now with new code. None the less, all of the grpc-labview generated client stubs are still there and deployed to so you can use them if they are useful to you. Similarly, we could add additional public APIs to NI Pin Map V1 Client.lvlib if that were helpful/useful to measurement authors. I think the biggest hurdle here would be how to retrieve the registered pinmap id being used by the InstrumentStudio project. That is possible, but it would also require feature work if you want to access it from a UI VI.

I'm still not entirely sure how all of the above would help you though. I guess you could create your own custom pin controls in the LV UI which you manage and populate with control values. Maybe that is what you were suggesting? For that to work though, I think you would have to "shadow" the controls bound to the actual measurement parameters such that only your "shadow" controls are shown in the UI and then you programmatically forward values to the "real" controls bound to measurement parameters. Otherwise, you are going to be fighting the UI framework which will automatically try to set the list of available pins for you.

[bharathirm11]

At this point, we plan to implement custom pin control and handle multiple instrument type filtering and update in the UI Initialize state. Similar to relay control below, which is currently not supported.

As you mentioned, the current NI Pin Map V1 Client.lvlib does not expose certain public APIs needed for use in UI VIs. To address this, we developed a pin map parser library that provides the required APIs to retrieve information on Pins, Relays, Relay configurations, and Resources.

For now, the registered pin map ID is configured through the INI file (at this point, there is a single pinmap used). We would like to submit this as a feature request for future updates.

Currently, this API is included as part of the IS plugin SDK, and we have used it to build our own pin-based Relay soft panel for IS.