Is your feature request related to a problem? Please describe.
Right now, if a major frame, minor frame, or acyclic frame is empty, it is still generated in the configuration data and compiled into the engine. Ideally, these would be skipped of the XML does not have any contained references for the frames, since they function as containers.

Describe the solution you'd like
I think ideally the Import code could be modified to check for the contained references, and if zero are found, skip parsing that item as if it were not there.

Describe alternatives you've considered

• We could also continue to pass around the empty containers and notify the user that empty containers are in the XML in some way

Additional context
This was identified during PR #54

Describe the bug
When working on a project where I need to script custom devices from either Ballard and AIM. If I mix both APIs in the same project, I get several naming conflicts as there are VIs with the same name, for example:

Shared folders (<vi.lib>\addons\VeriStand Custom Device Scripting APIs\Ballard MIL-STD-1553\Shared and the one for AIM) have VIs / ctls. with same name
Import folders have lvlib with the same name

To Reproduce
Use scripting APIs for both Ballard and AIM on the same project to

Additional context
One option I quickly tested is the creation of new libraries for those folders that don't have any and renaming the existing libraries with the same name. Something like:

Is your feature request related to a problem? Please describe.
In order to improve Serialization of XML files from applications written in LV or Python, I am proposing some changes to the XSD file to enalbe MS xsd utility to generate C# classes.

These changes should not impact the VS CD logic for parsing xml files.

Changes proposed (I have a PR ready for it):

line 55:
<xs:element type="xs:string" name="minorFrameRef" maxOccurs="unbounded"/>

line 180

remove
<xs:choice maxOccurs="unbounded" minOccurs="0">
add
<xs:sequence>

Describe the bug
The "period" of the minor frame can be set in the parameters XML to a certain value, but currently the custom device ignore this and uses the default bus transfer setting of 0.001 milliseconds

To Reproduce
This was idenfitied will implementing Logging, which is not currently in the custom device. With Logging enabled, the extra frames can be seen in the logs.

Expected behavior
The minor frame parameter configuration should apply to the bus controller instead of the default value.

Screenshots

The custom device should be able to log messages available to the AIM driver without explicitly reading messages by buffer ID.

Currently, the logging section is being scripted into the custom device upon initialization and some engine initialization is present. However, this will not be complete for the first release, so we will note in System Explorer that Logging is not yet enabled.

Describe the bug
When using the Parameters file in the User Guide assets, the <startingBufferIndex>1</startingBufferIndex> makes it such that using this file for 2x BIUs on the same module will trample over the buffer ID allocation.

Expected behavior
When using the example Parameters file, the startingBufferIndex tag is not present, meaning the custom device should use the result of BIU ID * 2000 + 1 as the starting buffer ID.

Describe the bug
The coupling mode / bus selection logic in the Hardware API's Set Device Coupling.vi appears to be incorrect.
It looks like the Both option only configures the primary bus, Primary only configures the secondary bus, and Secondary configures both.

Looking at changes to that file, PR #22 appears to have changed the case structure logic when the Both option was added.

Right now, selecting Both results in the Primary bus having its coupling mode set as desired, so this issue has probably been masked during real-world testing.

Screenshots

I would like to set the time each message is sent in a minor frame, relative to the start of the minor frame. As far as I can tell from the documentation the only timing that may be set is the period of each minor frame. Am I correct in this? How is the timing of each message determined? Does it launch each message in a minor frame as quickly as it can, waits until the minor frame ends, then executes the following minor frame? Is there any workaround to setting the execution time of each message?

Describe the bug
When running the Import Parameters Configuration scripting example, the BC and RTs, along with their command channels are correctly imported, but the subaddresses and messages are not imported.

To Reproduce
Steps to reproduce the behavior:

1. Run the Import Parameters Configuration example.
2. Open the resulting sysdef in System Explorer and see that BC and RTs exist, but not subaddresses or messages are present.

Expected behavior
Everything should be correctly imported.

Desktop (please complete the following information):

• OS: Windows 10

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

Additional context

To enable users to control and monitor the state of the simulated 1553 Terminals (including BC and RTs) in their system, we should implement the state control and status channels for each terminal.

Currently these are scripted for each terminal but not used in the engine. We will remove scripting them until they are implemented fully, so this issue is a placeholder for future enhancement.

Is your feature request related to a problem? Please describe.
This could be a problem if tests are run on systems with hardware in different locations in the future, or if developers want to quickly run the test suite without changing hardcoded values or setting up an identical system to the ATS.

Describe the solution you'd like
They could be put in an ini file like targets.ini or another configuration file.

Describe alternatives you've considered
The way it is now can work, it just pushes people toward having identical hardware setups for all hardware and development, which could lead to bugs slipping through.

Additional context

Issue #50 was worked around in PR #53 to allow multi-BIU deployments. However, this used a simple ID offset based on the BIU number, limiting all custom device instances to ~2000 Buffer and Header IDs.

As an enhancement, we could allow advanced users to expand the number of IDs allotted to one custom device instance using one of these methods:

• 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.

The milliseconds of the IRIG time stamp input is ignored by "Source/Custom Device Support/Shared/Convert AIM Time Stamp to NI Time Stamp.vi". This can be reproduced by running the VI in isolation and observing that the milliseconds field of the Time Stamp output does not match the milliseconds field of the input.

Bugfix in screenshot below.