Using multiple BIUs on the same PXIe module doesn't work

[Karl-G1]

Describe the bug AIM 1553 PXIe modules can have 1, 2, or 4x BIUs. These are targeted with a CD instance per BIU, and they should be able to be controlled completely independently. For example, the same Parameters file should be able to be used for 2x CDs targeting 2x BIUs on the same module.

Currently, the buffer and buffer header IDs used to address the low-level driver API in the custom device prevents this from working.

To Reproduce Steps to reproduce the behavior:

1. Use the parameters file below to create 2x CD instances targeting 2x BIUs on the same module
2. Deploy and modify the Tx values on one of the Tx words
3. See the Rx values for both CDs update

Parameters - One Message.zip

Expected behavior The Rx and Tx channels of the same configuration file deployed to 2x BIUs on the same module should be backed by separate buffers. A few different approaches are possible:

• Use a fixed buffer ID range based on the BIU number It appears that 8191 buffer/header IDs are addressable (from testing on 1x and 2x BIU modules). A simple solution would be to limit the custom device to ~2000 IDs per instance, then offset by the BIU number. This would limit the maximum number of messages/endpoints that can be simulated, but it is the easiest to implement
• Share buffer offsets between custom devices There are many possible ways to do this: calculate the buffers needed and store it in the sysdef, use some form of global during initialization to store the last used buffer per module, etc. However, all of these require the custom device to access data outside of its own configuration, making the approach non-ideal.
• Make a parameter available to superusers to define the starting buffer ID to use This is relatively easy to implement and would give advanced users a way to bypass a hardcoded limitation such as the 2000-buffers-per-CD option. Provide an optional scripting entrypoint for setting the initial buffer offset for each CD instance. When not in use, default to a hardcoded offset.

Screenshots

Today, the behavior results in the same buffer IDs being used. This makes the data read by message on both BIUs the same:

 

If different buffer IDs are used, the values are independent:

 

Additional context

Buffer and Buffer Header ID from the API help:


[Karl-G1]

53 enacted the first workaround:

• Use a fixed buffer ID range based on the BIU number It appears that 8191 buffer/header IDs are addressable (from testing on 1x and 2x BIU modules). A simple solution would be to limit the custom device to ~2000 IDs per instance, then offset by the BIU number. This would limit the maximum number of messages/endpoints that can be simulated, but it is the easiest to implement