ni / niveristand-aim-arinc429-custom-device

Custom device for AIM ARINC 429 hardware

AIM ARINC 429 Custom Device

The AIM ARINC 429 Custom Device allows use of AIM ARINC 429 PXIe Modules in VeriStand. The custom device targets exactly one AIM ARINC 429 PXIe module. To target multiple modules, use multiple instances of this custom device.

The custom device supports the following functionality:

• Import configuration file via scripting and System Explorer
• LabVIEW scripting of the custom device configuration
• Viewing read-only configuration in System Explorer
• Transmit and Receive configured labels
  • Scheduled and Acyclic labels
  • Multiple parameters per label
  • Multiple labels per channel
  • Multiple Rx and Tx channels per module
• Log all configured channels and labels per core

Requirements

• PXI Linux RT Controller
• Supported AIM ARINC 429 PXIe Module

Getting Started Documentation

• Download the latest release package from the Releases page.
• See the User Guide for a walkthrough of using the Custom Device.
• See the Parameters XML File Schema documentation for configuring the custom device.

LabVIEW Source Code Version

LabVIEW 2020

Dependencies

Running the custom device

• VeriStand 2020 or later

Real-Time target software components

• AIM ARINC 429 Board Software Package (BSP)
  • Must enable the ni-third-party feed in MAX to install the ARINC429 Board Software Package component

Developing or building from source

• LabVIEW 2020 or later
• LabVIEW Real-Time Module
• AIM ARINC 429 BSP and LabVIEW API
• VeriStand Custom Device Development Tools
  • Install the latest package from the release page
• VeriStand Custom Device Message Library
  • Install the latest package from the release page
• VeriStand Custom Device Testing Tools
  • Install the latest package from the release page

Git History & Rebasing Policy

Branch rebasing and other history modifications will be listed here, with several notable exceptions:

• Branches prefixed with dev/ may be rebased, overwritten, or deleted at any time.
• Pull requests may be squashed on merge.

License

This AIM ARINC 429 custom device is licensed under an MIT-style license (see LICENSE). Other incorporated projects may be licensed under different licenses. All licenses allow for non-commercial and commercial use.

niveristand-aim-arinc429-custom-device's Issues

Convert time to UTC before setting board time

Describe the bug
I am seeing a separation from the expected UTC time for received messages and the returned time for received messages when using system time to set board time. If however, I convert system time to UTC when setting board time, I observe exactly the expected 6 hour difference between system time here in CST and UTC.

To Reproduce
Steps to reproduce the behavior:

1. Go to Initialize Hardware and set Boolean input to convert time primitive (True to convert to UTC)
2. Notice time difference between cases where time is set according to system time versus system time converted to UTC.

Expected behavior
I expect a consistent offset between received times and system time.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows
• Version 10 Pro

Additional context
Add any other context about the problem here.

Parity channels do not correctly report parity bit value

Describe the bug
Using the <createParityChannel> tag on a label successfully creates a Parity channel in the tree, but the value always seems to be zero. As a test, I deployed the following configuration, then logged the raw data words, and compared the expected results.

Expected Behavior
Of those 4 labels, the first and last (SDI 00 and 11) should have the parity bit set. The middle two should not.

To Reproduce
Steps to reproduce the behavior:

1. Create an instance of the CD with the configuration file attached below.
2. The 4x Label 2 instances (each with a different SDI) should have different parity bit values using the default value of 200 on the single parameter.

Additional context
AIM Tx and RX PARAM All Extra Channels and SDI.zip

Pause scheduled transmissions when label is disabled

Is your feature request related to a problem? Please describe.
The disable channel for scheduled Tx labels determines whether to update values written to the transmit buffer or not. When disabled, no new updates are written, but the transmission is still sent at the specified rate. This means that even though we are not updating new values, new messages are still seen on the Rx side, which updates the timestamp and can make debugging less useful.

Describe the solution you'd like
The Tx Execution Unit should be able to utilize Api429Tx Xfer Skip.vi to disable/enable when the label is actually placed on the bus so disabling the label actually halts that label's transmission, not just updated data.

Describe alternatives you've considered
None.

Additional context
N/A

Remove hard-coded constants from Create Execution Unit

Describe the bug
The custom device must support more than channels 3 and 4. The scripting VIs are already in place to populate the RT hardware configuration from the system definition.

To Reproduce
Steps to reproduce the behavior:

1. Inspect AIM ARINC 429 Engine.lvlib--Implementation.lvlib--Execution Unit Factory.lvclass--Create Execution Unit.vi

Expected behavior
The execution unit should work for all AIM channel configurations.

Screenshots

Desktop (please complete the following information):

• OS: Windows
• Version: 10 Pro

Additional context
Add any other context about the problem here.

Simplify mapping from Channel + Label + SDI to VeriStand Channel

Is your feature request related to a problem? Please describe.
Current implementation derives from a time and custom device where we used the remote monitor capabilities of the hardware to read Rx labels. However, this custom device currently Reads by key (module + channel + label + SDI), so the use of multiple maps is not necessary and makes the custom device more difficult to read/decipher.

Describe the solution you'd like
Single map with key = { channel, label, SDI } and value = { necessary indexes }

Describe alternatives you've considered
We could also put the entire configuration into a map.

Additional context
Add any other context or screenshots about the feature request here.

Initialize hardware does not always return error for invalid hardware ID

Describe the bug
Source\Custom Device Support\Hardware API\Finalize Hardware.vi returns an error on first run, but then it returns no error (which ironically fails the new test VI: test Initialize and Finalize Hardware_Invalid Module

To Reproduce
Steps to reproduce the behavior:

1. Run the old test multiple times, or run the new test (before modifications)
2. Note that first iteration produces the expected error 404043
3. Note that the next iteration finds the hardware resource (which should not have been there), and so skips the board open call which produces error 404043 for invalid hardware ID.

Expected behavior
The same error should happen on reset, no reset, force close, no force close regardless of the previous state.

Screenshots
Heart of the problem is in this case of an AIM VI we wrap:

where it can be seen that a remove instance call can add a resource that wasn't found. This is a bug that will also be reported to AIM even though their high-level API doesn't produce the error on/error off behavior reported here.

Desktop (please complete the following information):

• OS: Windows
• Version: 10 Pro (running in test mode)

Additional context
Add any other context about the problem here.

Get rid of this magic number for number of channels

Describe the bug
Number of channels is hardcoded at 16 which was sufficient for Ballard Hardware because maximum number of Rx channels on boards we resell is 16. NI plans to resell AIM boards with 32 Rx/Tx channels.

To Reproduce
Steps to reproduce the behavior:

1. Inspect code as shown below.

Expected behavior
The code should not have artificial limitations. Get the number of channels from the input configuration.

Screenshots

Desktop (please complete the following information):

• OS: Windows
• Version: 10 Pro

Additional context
Add any other context about the problem here.

Multiple Hardware API VIs use maps with complex datatypes for keys

Describe the bug
Multiple VIs called in Read from Hardware and Write to Hardware use maps with complex datatypes for keys. Here are a couple examples:

• Custom Device Support\Hardware API\Get Transfer Identifier.vi
• Custom Device Support\Hardware API\Check for Rx Label Updates.vi

This is easily demonstrable to have large performance impacts on systems with large label counts.

Expected behavior
Use the established workaround of casting to numerics for keys to ensure fast operation on RT.

Multiple labels on the same channel fail loopback validation

Describe the bug
During manual validation of loopback (reference #37 ) it was observed that only the last configured label on the channel updated.

To Reproduce
Steps to reproduce the behavior:

1. Go to "C:\Git\niveristand-aim-arinc429-custom-device\Source\Custom Device Support\Tests\System\Single Core (P2--P3) Simple Loopback\Assets\Loopback (Tx=Ch1) (Rx=Ch2).txt"
2. Add additional (matching) labels on channels 1 and 2.
3. Import the configuration file into an AIM ARINC 429 custom device and deploy.
4. See error wherein the last configured label updates but the first N-1 labels do not update as expected.

Expected behavior
Multiple labels expected per channel.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows
• Version: 10 Enterprise

Additional context
Add any other context about the problem here.

Logging interferes with normal VeriStand Rx

Describe the bug
When logging is enabled, Rx channels are not updated.

To Reproduce
Steps to reproduce the behavior:

1. Go to VeriStand, open a new default project, Add a new custom device for AIM ARINC 429.
2. Import a configuration that supports labels on Rx channels.
3. Enable logging.
4. Send configured labels on configured channels.
5. Note, these labels appear in the log file but the mapped VeriStand channels do not get updated.

Expected behavior
Logging should record all labels received on active channels and VeriStand channels should update for all configured labels on active channels.

Screenshots

from ARINC429Log_2021_12_16_11_00_14.txt:

time stamp,channel,buffer report word,data word
3692467936.411758,4,4278268175,3766979591
3692467936.511478,4,4278268175,3766979591
3692467937.412560,4,4278268175,3766979591
3692467937.511560,4,4278268175,3766979591
3692467938.211762,4,4278268175,3766979591
3692467938.311483,4,4278268175,3766979591
3692467939.211484,4,4278268175,3766979591
3692467939.311204,4,4278268175,3766979591
3692467940.212287,4,4278268175,3766979591
3692467940.311287,4,4278268175,3766979591
3692467940.811328,4,4278268175,3766979591
3692467940.911408,4,4278268175,3766979591
3692467941.812130,4,4278268175,3766979591
3692467941.911130,4,4278268175,3766979591
3692467942.611692,4,4278268175,3766979591
3692467942.711052,4,4278268175,3766979591
...

Desktop (please complete the following information):

• OS: Windows
• Version: 10 Pro

Additional context
Add any other context about the problem here.

single source active channels information

Is your feature request related to a problem? Please describe.
In Construct for each of the execution units, the custom device currently takes in a RT Hardware Configuration as well as a Channels input. Channels can be computed from RT Hardware Configuration, so the Construct VIs should not require both inputs.

Describe the solution you'd like

• Remove the channels input from Construct.
• Make the get channels accessor call the Read RT Hardware Configuration accessor and extract the channels array from that data.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Checking if data changed prior to Tx writes is not valid when multiple instances exist

Describe the bug
This is the same issue as ni/niveristand-ballard-arinc429-custom-device#264.

When multiple instances of the custom device are run on a single target, the data check for whether any values have changed prior to writing to the driver is invalid and may cause not all data to be written.

To Reproduce
Steps to reproduce the behavior:
Create multiple instances of the custom device and note that values sometimes don't update if they are being changed to match values on the other core.

Expected behavior
Each execution unit should have its own copy of the previous data to compare against the latest data.

Desktop (please complete the following information):
Linux RT

Additional context
The Ballard ARINC 429 issue was resolved by ni/niveristand-ballard-arinc429-custom-device#265 and was implemented using call by reference due to urgency of getting a fix out and ease of re-implementing in case an older release of the custom device needed to be patched. Calling VIs dynamically likely is not as performant as performing the check inline in Write to Hardware.vi.

If performance issues are noticed it is also possible to implement this fix by keeping the previous values in the Execution Unit's class data and simply doing an equal comparison. This looks like what the [AIM MIL-STD-1553 custom device does](Source/Custom Device Support/Engine/Implementation/Tx Execution Unit/Write to Hardware.vi).

Restarting VeriStand engine required after deployment of custom device

Describe the bug
After a successful deployment/undeployment of the custom device to Linux RT, I can not re-deploy without restarting the VeriStand engine.

To Reproduce
Steps to reproduce the behavior:

1. Create a system definition with the AIM 429 custom device configured on a Linux RT target.
2. Deploy the system definition.
3. Undeploy.
4. Try to deploy again and get error 404021.

Expected behavior
Undeploying should close any resources in use that would prevent further deployments. The engine should remain running after undeployment without requiring a restart.

Desktop (please complete the following information):

• OS: Linux RT
• Version 2020

need scripting VIs to Set/Get transfer period for rate-based messages

Describe the bug
Currently, Tx execution unit uses a hardcoded value of 50 ms for the transfer period for scheduled (rate-based) messages. This should be configurable through the configuration file.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

Desktop (please complete the following information):

• OS: Windows
• Version: 10 Pro

Additional context
Add any other context about the problem here.

LabVIEW hang when running test Manage Library

Describe the bug
LabVIEW hangs when running the test.

To Reproduce
Steps to reproduce the behavior:

1. Restart LabVIEW
2. Open project: AIM ARINC 429 Support.lvproj
3. Run JKI VI Tester
4. Run All Tests or Run Single Test with 'test Manage Library' selected.

Expected behavior
Tests are expected to run and pass.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows
• Version: 10 Pro

Additional context
Hang also observed with the following VI:

and the test appears to hang at the first call to close hardware (where the force input is set TRUE.

Save channel speed to system definition and use when constructing execution units

Is your feature request related to a problem? Please describe.
Right now, 'high-speed' is hard coded in the configuration of the execution units.

Describe the solution you'd like
Channel speed needs to be user-configurable (through the scripting API) and dynamically set when configuring the AIM hardware.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Error Test Channel Number.vi issues

Describe the bug
I used this custom device driver on AIM 429 cards 32 channels. Channels should start from CH1-CH32 based on manual. But in this Error Test Channel Number.vi check XML phasing with Channels in range 0-31.

To Reproduce
Steps to reproduce the behavior:

1. Create a XML configuration file for AIM 429 with CH32 RX/TX
2. Import to AIM429 Custom Device section under system explorer.
3. See error.

ps: I also tried using CH0, but when I deploy system definition. I got invalid channel error.

Expected behavior
If I declared CH32, It should create CH32 under custom device section without any errors.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10 Enterprise
• Version VeriStand 2023 Q2

User Guide does not have logging configuration

Describe the bug
The Ballard 429 User Guide has a section on configuring logging. This was added after this repo was forked, so it is not present in this repo and needs to be added.

update control and indicator names in scripting API

Is your feature request related to a problem? Please describe.
Don't cause confusion and delay by referring to Ballard in this AIM custom device.

Describe the solution you'd like
'Ballard' --> 'AIM'

Describe alternatives you've considered
We could go with vendor-agnostic control and indicator names to reduce the burden when copying these scripting VIs.

Additional context
Add any other context or screenshots about the feature request here.

Time stamps incorrect in log file because the board time is not set

Describe the bug
Timestamps returned in log files are not accurate.

For example, the monitoring example returned this time stamp:
2:19:37.629 AM
1/2/2021

when I was expecting:
5:45:37.000 PM
12/7/2021

To Reproduce
Steps to reproduce the behavior:

1. Run attached example.
   Receive - Monitor - VS.zip

Expected behavior
Time stamps in log file should correlate with an accurate absolute time

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. Linux RT]
• Version [e.g. 2020]

Additional context
This issue was initially posted on basecamp. An expert from AIM posted this reply:

relating to the timestamps, in order to get timestamps reflecting the PC time, you have to synchronize the PC time with the board time.To do so, just call the VI "Api429Board Time Set" and set the time according to the PC time.

Port to Linux RT

Describe the bug
Temporarily developing on Windows to make progress while Linux installer errors being worked through, but eventually, the custom device will be supported on PXIe Linux RT targets.

To Reproduce

1. Temporary implementation choice. Specifically, reverse commit a97dc91 which changed Build Linux Log File Path.vi.
2. Once this issue is fixed, the following test VI should pass again:
   

Expected behavior
Custom device should deploy, execute, and log on Linux RT targets.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Linux RT
• Version PXIe base version 21.0

Additional context
Add any other context about the problem here.