Add acyclic frame functionality

[papowerNI]

• This contribution adheres to CONTRIBUTING.md.

What does this Pull Request accomplish?

Adds Acyclic frame transmission to the engine in the Tx Acyclic Execution Unit (in a future PR, should rename Tx Acyclic EU to Trigger EU)

Why should this Pull Request be merged?

• Adds acyclic frames for all transfer types to the engine
• Updates system tests and unit tests
• Wraps hardware API calls in a structure to avoid VS crashes when XML contains empty frames
• Wraps Write to Hardware calls in In Place Structures to have better performance

What testing has been done?

Automated tests have been run, and manually tested the acyclic frames. Tried running with an empty frame of each type, and no crash occurred.

[Karl-G1]

I've updated the system test and asset for acyclic frames, but it's currently failing. RT to BC and BC to RT work, but I am not seeing RT to RT messages contained inside of acyclic frames be sent.

VI Tester Results

[buckd]

• Tx Acyclic Write to Hardware - Is this property node access for the triggerable frames going to hit the massive performance problem we found in the Ballard custom device? Should we just use an in place unbundle since we're in the same class?
  
• Potential same question as above for Transmitted Messages in the scheduled Write to Hardware.

[niveristand-diff-bot]

Bleep bloop!

LabVIEW Diff Robot here with some diffs served up hot for your pull request.

Notice something funny? Help fix me on my GitHub repo.

AIM MIL-STD-1553 Engine.lvlib--Implementation.lvlib--Execution Unit Factory.lvclass--Create Execution Unit.vi.png

AIM MIL-STD-1553 Engine.lvlib--Implementation.lvlib--Execution Unit.lvclass--Get VS Channel Handles and Messages.vi.png

AIM MIL-STD-1553 Engine.lvlib--Implementation.lvlib--Execution Unit.lvclass--Read Module Reference.vi.png

AIM MIL-STD-1553 Engine.lvlib--Implementation.lvlib--Shared Resources Factory.lvclass--Get 1553 Configuration.vi.png

AIM MIL-STD-1553 Engine.lvlib--Implementation.lvlib--Shared Resources.lvclass--Read Bus Controller Message Configurations.vi.png

AIM MIL-STD-1553 Engine.lvlib--Implementation.lvlib--Tx Acyclic Execution Unit.lvclass--Initialize.vi.png

AIM MIL-STD-1553 Engine.lvlib--Implementation.lvlib--Tx Acyclic Execution Unit.lvclass--Populate Triggerable Frames with Messages.vi.png

AIM MIL-STD-1553 Engine.lvlib--Implementation.lvlib--Tx Acyclic Execution Unit.lvclass--Read Triggerable Frames.vi.png

AIM MIL-STD-1553 Engine.lvlib--Implementation.lvlib--Tx Acyclic Execution Unit.lvclass--Tx Acyclic Construct.vi.png

AIM MIL-STD-1553 Engine.lvlib--Implementation.lvlib--Tx Acyclic Execution Unit.lvclass--Write to Hardware.vi.png

AIM MIL-STD-1553 Engine.lvlib--Implementation.lvlib--Tx Execution Unit.lvclass--Write to Hardware.vi.png

AIM MIL-STD-1553 Hardware API.lvlib--Configure Major Frame.vi.png

AIM MIL-STD-1553 Hardware API.lvlib--Configure Minor Frame.vi.png

AIM MIL-STD-1553 Hardware API.lvlib--Configure Simple Frame.vi.png

AIM MIL-STD-1553 Hardware API.lvlib--Send Acyclic Frames.vi.png

AIM MIL-STD-1553 Scripting.lvlib--Find All Acyclic Frames.vi.png

AIM MIL-STD-1553 Scripting.lvlib--Read Terminals and Acyclic Frame Names.vi.png

Create Execution Unit.lvclass--test Get VS Channel Handles and Messages.vi.png

Loopback.lvclass--Execute Acyclic Frame Loopback.vi.png

Loopback.lvclass--test Triggered Acyclic Frame.vi.png

[buckd]

Is the skipping of driver calls when transfer IDs aren't found just something we need to do or is there something we need to report back to the user to tell them that something is incorrectly configured?

[Karl-G1]

Is the skipping of driver calls when transfer IDs aren't found just something we need to do or is there something we need to report back to the user to tell them that something is incorrectly configured?

We should probably put an error in the log file and improve our frame parsing to not persist empty frames/messages into the compiled data.

[papowerNI]

Is the skipping of driver calls when transfer IDs aren't found just something we need to do or is there something we need to report back to the user to tell them that something is incorrectly configured?

We should probably put an error in the log file and improve our frame parsing to not persist empty frames/messages into the compiled data.

We can do what @Karl-G1 recommended as well, but we also need the case structures because if there is ever an empty array in any of those cases, Veristand crashes.

EDIT: I added an issue (see link below) for this to be addressed in the future.