You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Use the parameters file below to create 2x CD instances targeting 2x BIUs on the same module
Deploy and modify the Tx values on one of the Tx words
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:
The text was updated successfully, but these errors were encountered:
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
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:
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:
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
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.
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:
The text was updated successfully, but these errors were encountered: