ni / niveristand-engine-simulation-toolkit-custom-device Goto Github PK

The FPGA IP must be capable of sending synchronization signals between bitfiles running on N FPGAs in N chassis so simulation signals are synchronized when read in VeriStand. This should be accomplished through external trigger, something like NI-9401 to sync PXI to MXI-RIO.

In several system explorer files we concatenate the RIO name to a existing property name. We should single source this formatting in case we change our mind about ".". Create a SubVI that takes property name and RIO name.

The Main.Feature Toggles.Multi FPGA property was added to the system definition late in order to prevent us from having to set the feature toggle each time we wanted to load a test. However, it's not in the scripting API, which means when you script a new custom device, deployment fails. You have to manually open the sysdef to get mutation code to run and then save. Now everything will deploy.

The multi-FPGA synchronization test is only supported in VeriStand 2018 and later. We need a way to skip this test based on the version we're running all tests in.

When clicking the Add Bitfile button, the Add Bitfile dialog does not open centered, it opens wherever it was last saved.

Also, the dialog title shows "Engine Simulation Toolkit System Explorer.lvlib:Add Bitfile Dialog.vi". This should probably just show something like "Add Bitfile".

This issue was migrated from NIVeriStandAdd-Ons/Engine-Simulation-Toolkit-Custom-Device#3.

If an event capture indicator is detected with no name it will sow up in the list of available captures to add under a measurement. This causes all sorts of issues. Overall this IP is named incorrectly and should not be listed in system explorer.

Example good name: capture.FI 1.Event1
Example bad name: capture.FI 1

This issue was migrated from NIVeriStandAdd-Ons/Engine-Simulation-Toolkit-Custom-Device#1

Both the RT Engine and the vi.lib "Error Ring" use a VI named "initialize.vi". This causes a conflict when building an LLB. The error ring in vi.lib uses its initialize.vi inside its GUI that is only used at edit time, so this conflict is normally not a problem because the autobuild server doesn't include edit time dependencies into its LLB builds due to the NI_AppBuilder_SDist_ExcludeEditTime=True ini key, but for others building the source on their machines it will cause a build failure.

The APUs shown in the list of APUs on the main page, as well as the APUs in the system explorer tree are not updated when a bitfile is removed.

• We should remove the APU section if no more RIOs are under it
• We should update the list of APUs whenever a bitfile is removed

The virtual folders contained in the LabVIEW project are not mirrored on disk, which makes finding VIs difficult.

This issue was migrated from NIVeriStandAdd-Ons/Engine-Simulation-Toolkit-Custom-Device#2

the plot legend always says 'base' 'remove' 'add'. this confuses people who only have a base, or just base+add. It should rather say something like 'base' 'step1' 'final' or 'base' 'final'

test Multi FPGA Feature Toggle fails with a File Not Found error. The sysdef points to a bitfile at C:\Users\nitest\Documents\EngineSimulation_FPGATarget_Everything_2_APUs_z44qtGJ2Thg.lvbitx, which doesn't exist (I can't find that bitfile anywhere in the repo).

Add Bitfile Dialog.vi uses Modern controls for the Bitfile Path and RIO Device Address. These should be System controls.

Error -63195 occurs when combining a multi-FPGA APU with a single bitfile APU IF there are multiple bitfiles deployed. If there is only one bitfile deployed that contains these two types of APUs, there is no error.

To reproduce:

1. Compile a bitfile containing one single FPGA APU instance on one multi FPGA APU instance.
2. Compile a bitfile containing a multi FPGA APU instance with the same name as the first bitfile.
3. Add both bitfiles to a custom device instance and deploy. Monitor the Status/Status code value and notice error -63195 (The handle for device communication is invalid or has been closed. Restart the application).
4. Remove the bitfile containing only the multi FPGA APU so there is only a single bitfile.
5. Deploy the system definition and now check Status/Status code and see that there is no error.

Allow scripting support for the following measurement/generation types using a custom device API:

• Digital Pattern Generation
• Directional Speed Sensor Simulation
• ECU Event Timing Capture
• Knock Sensor Simulation

Note: Scripting Analog Replay is already supported today.

In default operation, adding an analog replay does not enable voltage override and therefore does not create channels for voltage override. The channels are added when the user goes into the system definition and manually enables voltage override. The user can then manually disable voltage override, which in turn, deletes the voltage override channels. Therefore, the code managing this operation can assume that when enabled, there were no channels (so add them) and when disabled, there were channels (so delete them). However, when scripting the disabled state, there are no channels added because there was no manual interaction. So, the code tries to delete the channels that aren’t there and returns an error.

The icons in the system explorer have inconsistent backgrounds; some are white, while others are transparent. The icons with white backgrounds appear different than the native VeriStand ones when highlighted.

Both the APU State and Event Timing Status sections use the same GUID (F1CEE36E-E483-4565-3A3E-AB06893FB67A, see GUID.APU State). This makes it difficult to operate on each type of section independently, since you cannot query for them based on the GUID without getting references to both.

Event Timing Status should get its own GUID, instead of hijacking APU State's.

This issue was migrated from NIVeriStandAdd-Ons/Engine-Simulation-Toolkit-Custom-Device#4

When you configure multiple APU's on a single FPGA, the analog replay's on APU's other than the first one may not work. However if you configure all of the Analog Replay's onto the main APU page, then everything works correctly. This works because the APU's are linked to their specific modules on the FPGA, so even if analog replay "4" is configured on the page for APU "1", it is still wired to the register bus for APU "4" so it will look up it's current position using the proper APU.