Updating Mapped Bitfile Incorrectly Updates Module Programming Mode

[benboniface]

Describe the bug When updating the FPGA code linked to the custom device, the custom device sets the programming mode of all modules in NI MAX regardless of how they are configured in the FGPA Code.

For example if a user is trying to use a 9375 card as a Scan Engine resource and a 9381 as an FPGA resource with User Defined Variables, when the custom device is linked to a bit file both the 9375 and 9381 will be set to FPGA mode in MAX. This results in a deployment error due to a mismatch between the configuration in the System Definition and the configuration in NI MAX.

Note: this only appears to be an issue with 904x series cRIO controller as they have the ability to dynamically change modes. At the very least this was not an issue using a 903x series controller.

To Reproduce Steps to reproduce the behavior:

1. Create an FPGA bit file with one C series module as a scan engine resource and one as an FPGA resource.
2. In NI MAX set the programming mode to match the LabVIEW code configured in step one.
3. Load the compiled FPGA bitfile into the uservariables section of the custom device.
4. Observe that all C Series modules have been set to FPGA mode in NI MAX.
5. Attempt to deploy system definition to observe mismatch error.

Expected behavior When using a 9039 cRIO module it was not necessary to set the programming mode of individual modules in NI MAX at all. This would be an ideal scenario for all cards.

If this is not possible, either have the custom device configure the programming modes in NI MAX directly, or prevent the custom device from automatically formatting the programming mode of the modules and have users select "Use Current" under the controller page of the system definition file

Desktop (please complete the following information):

• Windows based VeriStand 2020 configuration

• NI-9045 cRIO Controller running Linux_64 and configured with VeriStand 2020

  • Version installed with VeriStand 2020

[Karl-G1]

@benboniface Thanks for filing the issue. I'm trying to understand if it is a duplicate of #68. That issue was filed in response to #65, and the workaround should still be valid (changing to "Use Current" on the controller page as you mentioned).

Can you confirm if this is the same root cause as #68?

[benboniface]

@Karl-G1

After further review, it is a duplicate of #68, but will produce the same results as #65. The modules being in different programming modes than the bit file expects will throw the same 537702 Error