05-18-2022 05:52 PM
Thanks for the great advice.
I am less concerned about data in sync in my output file as long as they are not off significantly. I am more interested in making real-time decision about data in order to trigger the quench protection system before the magnet burns up. These are super expensive magnets and burns up very quicky like with in a few tens of milliseconds, so the faster I can detect a quench, the more likely it will survive. Therefore, the on-demand mode for AO seems like a better choice assuming there is not a significant delay at the AI end.
Don
05-18-2022 06:03 PM
Usually the voltage signals are in the microvolts range, and when a magnet quenches, which usually happens when a part the magnet is no longer superconducting, the voltage starts rising very fast. So the sooner this rise is detected, the more time for the quench protection system. If this fails, there is a great chance the magnet will be destroyed, which does happen once in a while, and the power supply to the magnet can be damaged as well. This could be a very expensive damage, so I want to minimize that.
Don
05-18-2022 07:10 PM
Since you use the term "super expensive" your current pursuit of a software-based solution is "not reliable" and you need a deterministic hardware system such as a cRIO as Kevin suggested.
05-18-2022 08:36 PM
Here's another idea that might be able to work for you. Or maybe not. It only works if you can identify ahead of time which input signal to focus on for the sudden voltage rise. If you can't know in advance, you may as well skip the rest of this post.
The idea is to add a DAQmx-supported PXI card that supports analog triggering (one example: PXIe-6361). You'd parallel connect the key voltage signal to both the 4303 and the 6361. You'd configure an AI task on the 6361 to use an analog trigger and then make use of a special internal *digital* signal known as the "analog comparison event". The A.C.E asserts whenever the triggering conditions are met. So you'd also configure your AO task to use the 6361's A.C.E. as a digital start trigger.
There are a few more details to work out if/when the time comes, but once you verify that the tasks are started without errors, a method like this could be a reliable hardware-based method as well. Not as solid as an OS-free solution on a cRIO, but maybe good enough when the risk is about cost rather than lives in danger.
-Kevin P
05-20-2022 06:01 PM
This will not work as it's not possible to determine ahead of time where it's going to quench.
Thank you for your invaluable help and advice. I appreciate it.
Don
05-20-2022 08:58 PM - edited 05-20-2022 09:02 PM
FWIW, I recently noticed an option for Analog Multi-Edge triggering in the drop down selector for DAQmx Trigger.vi while responding in another thread. I don't recall seeing that option before, but then again I haven't happened to do much with analog triggering in several years. Maybe I just missed it.
The advanced help suggests that you can use it to trigger off any one of several possible channels, each with their own level and slope specs. Not sure if it's widely supported on lots of DAQ hardware or not. Note: I'm using DAQmx 20.1
-Kevin P
05-22-2022 07:41 AM
Thanks for this great suggestion. I don't think PXIe 4322 supports analog trigger, so this will require buying a new DAQ module. I am just wondering if this can as reliable as a hardware based solution such as cRIO.
Don
05-22-2022 09:58 PM
Assuming properly implemented and fully debugged code in both cases, the hardware aspect should be equally reliable. Now the subtleties:
- the analog multi-trigger idea is limited to the reliability of the OS you run. A cRIO FPGA solution *is* hardware with no OS, so therefore more reliable than Windows or (probably) LabVIEW Real-Time
- are you familiar and experienced with FPGA programming? You need to consider your *ability* to create perfect code and test/validate it. Whereas it's pretty safe to trust that DAQ device triggering circuitry will work as intended
- you can theoretically implement a more complex reaction algorithm in FPGA than what the analog triggering circuitry can do. If you need it, that would point toward cRIO again.
-Kevin P
05-23-2022 07:34 PM
Could you please underline how the analog trigger is limited to the reliability of the OS? I am trying to understand how an analog trigger signal is processed and fed to other tasks. Does it require the computer processor, or does it get processed on the DAQ card and directly fed to other tasks?
Unfortunately, I have no experience with FPGA programming, but I can try to learn.
Don
05-23-2022 09:28 PM - edited 05-23-2022 09:35 PM
Once you prepare and start the DAQmx tasks, the analog triggering approach should generally have no further dependence on the OS at all. The reason I only say "should" is that the system is limited by OS-level catastrophic conditions like:
- blue-screen crash of Windows
- Windows update temporarily interfering with a driver (we've seen this many times with NI Serial though not so far with DAQmx.)
- an auto-reboot due to Windows update or something pushed by the I.T. dept
It's conceivable the task behavior would withstand even something as bad as a blue-screen crash, though I doubt you could expect it to do so reliably. A reboot would definitely reset the DAQ device. The worry about pending Windows updates may not be credible -- I'm not aware of it being a real issue for DAQ tasks, just drawing an analogy to issues we've seen with NI Serial devices.
In summary: it's really only the risk of something like a crash or reboot that makes me downgrade the reliability of the analog triggering approach on a Windows box. Under normal circumstances it should have about the same hardware level reliability as an FPGA solution.
However, I don't know which devices do and don't support Analog Multi-Edge Triggering. You can start trying things out yourself by setting up simulated devices in MAX, but before you buy it'll be best to contact NI sales for guidance and verification.
-Kevin P