Keysight 34461A DMM Measurement Plugin (Refactor of 34401 DMM example)

[MIpetrov-NI]

• This contribution adheres to CONTRIBUTING.md. (Required)
• Automatically post PR comments with images for G code changes? (Recommended for small changes)

What does this Pull Request accomplish?

High-level description of the changes in this pull request:

• Added a new measurement plugin example for a 3rd party DMM; it's a refactored version of the existing Keysight 34401A DMM Measurement plugin example. I've documented the process (in the readme) for refactoring existing examples to be compatible with different drivers for similar 3rd party instruments. In this instance, I tested implementing the 3446X driver on an Agilent 34461A DMM in InstrumentStudio.

Why should this Pull Request be merged?

Justification for why this contribution should be part of the project:

• This example is meant to contribute to a workflow we can communicate to customers that would make it easier for them to create measurement plugins or use/alter our existing examples to connect their 3rd party devices to our PXI platform.
• Through this workflow, I found that one of our more popular drivers, the 3446X LabVIEW driver, has a bug that has been documented in a KB (and should be fixed rather than communicating a fix to a user), I've linked that KB in this folder's readme.

What testing has been done?

What testing has been done to ensure this submission meets requirements:

• Tested building the LabVIEW project, running the measurement plugin service, and taking measurements in Instrument Studio with no error.
• Tested the implementation on a Keysight 34461A DMM communicating with a windows PC via USB. (laptop & PXI embedded controller)
• Ran the run_tests.vi: the vi crashed after some tests have passed: debugged by verifying VI properties and device connection. Was not able to figure out the reason for this crash, there is no documentation on what to do in this event.
• Have not tested the TestStand implementation.

[jasonmreding]

The session factory implementation needs to be revisited. I'm not sure what the motivation is for using local driver sessions rather than grpc-device sessions, but the factory implementation should reflect that choice. At the very least, the factory should throw errors for things that are not intended to work. There are also some bad linkage issues and copy/paste artifacts that need to be corrected to avoid confusion when looking at the code.

[jasonmreding]

Is it intentional that you are using "Keysight34401A_DMM" as the instrument type here? Or if this copy/paste error from the 34401 project? I'm guessing this is an oversight as it doesn't match the id declared in the .pinmap file added as part of this PR. Make sure you update the VI icon as well.

[jasonmreding]

It looks like the project is loading with several dependencies still linked to the 34401 library. It looks like this is coming from the TestStand code modules. If I manually load and resolve dependencies for those VIs, then the broken dependencies disappear.

[jasonmreding]

The builds specs still have 34401A in the name as do the generated binaries for the builds.

[jasonmreding]

Why does this have a hard code constant for the session rather than using the session in input terminal? If this works for the existing 34401 example I don't understand why it won't work here.

[jasonmreding]

The diagram could be cleaned up a little so wires aren't running right to left.

[jasonmreding]

The Measurement Todo comment needs some cleaning up. A lot of the comments do not make sense to me and there are some grammatical issues as well.

[jasonmreding]

Many of the VIs in the class are confusing to read because the icon template for the class is still using "34401" as the text. This makes the class constants appear like they are referencing the existing 34401 class and not the new 34461 class.

[jasonmreding]

It might be nice to move this as a member of the Session Factory.lvclass so that it can be called from Get Instrument Type ID.vi rather than duplicating the logic and the MeasurementTodo labels.

[jasonmreding]

If you do not want to use grpc-device server, then you should return empty string for both the provided interface and service class outputs. That will indicate to the framework that it should not try to resolve through the discovery service to find the remote address for the server. Instead, it will be up to your factory implementation to return native VISA sessions instead of grpc enabled driver sessions. This will allow you to use the refnum passed into Close MeasurementLink Session.vi rather than using a hard code value in a local constant.

[jasonmreding]

If you want to use local/native VISA sessions with this instrument, the factory should be updated to produce local/native sessions rather than grpc-device sessions. Your measurement logic would then use the factory APIs to create sessions like all of the other examples rather than adding custom logic to the measurement to create local driver sessions outside of the factory APIs.

[jasonmreding]

We could also look into adding a Boolean input to the API for the user to indicate whether they want to create local driver sessions vs. grpc-device sessions.