Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Substantial Delay Between when PXIe 4322 AO Card is Asked to Put Out a Signal and Observed by a PXIe 4303 AI Card

Solved!
Go to solution

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

0 Kudos
Message 11 of 21
(699 Views)

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

0 Kudos
Message 12 of 21
(706 Views)

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.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 13 of 21
(696 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 14 of 21
(690 Views)

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

0 Kudos
Message 15 of 21
(668 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 16 of 21
(662 Views)

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

0 Kudos
Message 17 of 21
(648 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 18 of 21
(638 Views)

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

0 Kudos
Message 19 of 21
(616 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 20 of 21
(607 Views)