NI DAQ Terminal error - Rattlesnake version 3.0

[lukanovak999]

Bug description
I have encountered a bug in the newest version (3.0) of Rattlesnake Vibration Controller Package. The error occurs in all environments and it has to do something with the NI device terminals. For example, when I go to Time Signal Generation Environment everything works fine, until I press the Arm Data Acqusition button. That is when I get the following error:

The same error occurs when trying to do system identification in MIMO Transient Environment or MIMO Random Vibration Environment.

To Reproduce
Steps to reproduce the behavior:

1. Two small linear motor shakers, each with accelerometer attached to it.
2. NI hardware: cDAQ-9174 chassis with NI 9234 (for 2 accelerometer inputs and 2 voltage inputs) and NI 9263 (for 2 voltage outputs):

3. Channel table:
   channel_table.xlsx

Possible Fixes
I then downloaded source code for the previous version of Rattlesnake (2.0) and tried the same thing and it worked. Then I did some source code comparison between the versions, specifically the nidaqmx_hardware_multitask.py file inside the components folder. I noticed that the file in the newer (3.0) version is the same as th file in the older (2.0) version, with exception of 2 new lines added in the newer (3.0) version of Rattlesnake. Those two lines are:

• line 382: task.triggers.start_trigger.dig_edge_edge = ni.constants.Edge.RISING
• line 383: task.triggers.start_trigger.trig_type = ni.constants.TriggerType.DIGITAL_EDGE

After commenting out those two lines in the newer version, the error is gone and the program works as expected.

My question is, what does these two lines of code do and why were they added in the newer version?

Thanks,
Luka

Desktop:

• OS: Windows 11
• Python version: 3.11.5

[dprohe]

Hi Luka,

Thanks for the bug report, and thanks for doing some debugging. I know it's not trivial to try to figure out what's going on in a big, convoluted codebase like Rattlesnake.

These two lines of code were added to fix a bug in the previous version where the trigger to synchronize the output and acquisition tasks were not actually applied. Basically, the trigger was "set up" but never "applied" to the data acquisition output task. In that case, the output would start, then the acquisition would start afterwards, but there was no synchronization between the two, so there could be some undetermined amount of time between the acquisition and output starting up. This is typically not a huge deal, because with standard operations, this delay should be relatively small (probably a few samples), and with Rattlesnake measuring the output directly, there is no concern that the data is out of sync as measured.

More reading into how NI does it's triggering led me to add those two lines. With those two lines added the output task starts up, but does not start outputting until the trigger occurs, which occurs when the acquisition starts up. In my mind, that would allow output and acquisition to be better synchronized (there is still a small delay, though it's usually less than a sample). Anyways, it looks like the bug that you are seeing is a result of the cDAQ chassis not actually having a trigger pathway between the acquisition and output cards that you are using. This was an oversight on my part. We primarily use PXI chassis, which do generally have a dedicated trigger lines (though it can get funky when daisy chaining multiple chassis together), and I haven't had the opportunity to do a lot of testing on other NI devices. I had assumed that any NI-DAQmx device would have the same triggering capabilities, so it is hard-coded into the NI interface, as you saw. Commenting out those lines then removed the application of the trigger.

Ideally, there should be some kind of check to determine what trigger lines are available in a given hardware device. Looking through the NI-DAQmx documentation, I'm not seeing anything that immediately jumps out at me as a way to determine what the available terminals are. Perhaps the export_signals property of the task (https://nidaqmx-python.readthedocs.io/en/latest/export_signals.html)? I'm currently out of office, so I don't have any hardware to play around with to see, but if you wanted to investigate if there is a way to determine the available terminals. You can see the available routes in the NI MAX utility.

If you want to do some more debugging, you could try changing the write_trigger attribute in the output task on Line 342 to self.write_trigger = '/cDAQ3/ai/StartTrigger'. From what I read online, e.g. here, it looks like a cDAQ start trigger comes from the chassis itself rather than a module on it like the PXIs do. This will, however, hardcode Rattlesnake for your specific setup. Obviously it would be better if we could dynamically assign this value from some list based on of what is available. Alternatively, if there is no way to dynamically find the trigger sources available for a task, it would probably be better to simply add an extra dialog where the user could enter the trigger signal they wanted to use.

To summarize:

• The lines of code were added to better synchronize output and acquisition.
• The code was written for PXI devices assuming all NI DAQmx devices worked that way, which is apparently incorrect
• Removing these lines removes that synchronization, but I don't think it's detrimental to the controller as the output and acquisition usually start "close enough"
• The better solution would be to adjust the trigger for your device to point to a valid trigger
• cDAQ devices seem to have a start trigger, but it is on the chassis itself (e.g. /cDAQ3/ai/StartTrigger) instead of on one of the modules (e.g. /cDAQ3Mod1/ai/StartTrigger/). You should verify this in NI MAX.
• Ideally we could use the nidaqmx library to query the device to select a valid /ai/StartTrigger/ on the device, but I don't immediately see the function to do that.

[dprohe]

I just pushed a fix for the software which should now support cDAQ devices without needing to modify the code. In the updated user's manual, the example problem in the appendices uses a cDAQ device. Could you by chance try it out for me to see if it works for you.