Using cRIO with NI-DAQmx from Windows/C++ to get real-time determinism

[DanielS123]

Hello all,

I have inherited a very complex control system which at present uses Windows/C++ for user-interface,  and a parallel real-time (RTX) system to provide the real-time/deterministic control for interface to equipment.  For I/O, we presently use PCI boards for ~50 DI channels, ~100 DO channels, 16 AD channels (some acquiring at 1KHz),  and 8 D/A channels (which are updated also at 1KHz), and quad counters.  PCI boards are all running under our RTX OS.

I would very much like to change our IO hardware from PCI boards (which we have encountered many problems with - particularly when running under real-time OS) to (perhaps?) a cRIO system.  I am not contemplating changing all code to Labview (at least at this time...) - that would be too much.  I am trying to figure out though how I could get cRIO,  which I would be calling from C++ code running under Windows (which of course is not deterministic...) to provide the realtime control (both for output and input) which I need.  I know for instance that for A/D channels I can start them with DAQmx commands to acquire automatically at set rate (e.g. 1000Hz) and put values directly in buffer,  from where I can read them (as shared memory) on my real-time side of things.  I assume that I could do equivalent with reading  from DI's.  But for D/A channels (which I have to update at 1KHz),  or DO's (which I sometimes have to toggle at  ms timing) - is there an equivalent method whereby I can update a memory buffer (from real-time side),  and (automatically) this buffer will be transferred to D/A and DO's at constant rate?

Or perhaps someone can suggest some other alternative which I have not envisioned?  (It's been about 15 years since I have really used Labview...)

Thanks

[ZYOng]

I would recommend referring to Cross-Compiling ANSI C NI-DAQmx Examples for Linux RT Using Microsoft Visual Studio Code

The C code will be deployed to the cRIO hence it is deterministic. 

To control cRIO from Windows, you would need non-deterministic network communication protocols. See Understanding Communication Options Between the Windows HMI, RT Processor, and FPGA

[AustinMan@NI]

This information on cross compiling is more up to date:

Part 1: Cross Compiling C/C++ Code for NI Linux Real-Time — nilrt-docs 1.0 documentation

[DanielS123]

Thanks very much for this info.  The paper about non-deterministic communications protocols was particularly applicable and interesting.

I guess I was hoping that there were some DAQmx commands (within API,  which I could call from C++ code running on HMI machine) which would initiate continuous transfer of memory buffers (buffers which would contain registers for DI/DO (as acquired/sent on cRIO),  A/D input (from cRIO inputs), D/A (to cRIO outputs) over ethernet connection from HMI to cRIO.  (Very similar to DMA which many PCI/PCIe cards have for this task).  It does not appear that anything like this is available.   My whole goal with this idea was to find a way to both simplify our present  (relatively cumbersome) data acquisition (in realtime),  and to use the reliable cRIO hardware.

If anyone has any other ideas as to which direction I might look - I would be appreciative...

Thanks,

If anyone has any other ideas as to 

[AustinMan@NI]

I suggest you contact NI, or a distributor, and discuss your requirements with them. ComapactDAQ may meet your needs. The person you talk to will probably want to understand the function of the real time component in your current application. 

[ZYOng]

---

@DanielS123 wrote:

I guess I was hoping that there were some DAQmx commands (within API,  which I could call from C++ code running on HMI machine) which would initiate continuous transfer of memory buffers (buffers which would contain registers for DI/DO (as acquired/sent on cRIO),  A/D input (from cRIO inputs), D/A (to cRIO outputs) over ethernet connection from HMI to cRIO.  (Very similar to DMA which many PCI/PCIe cards have for this task).  It does not appear that anything like this is available.   My whole goal with this idea was to find a way to both simplify our present  (relatively cumbersome) data acquisition (in realtime),  and to use the reliable cRIO hardware.

---

You can try gRPC server providing remote access to NI device driver APIs.

However, note that network communication between HMI and cRIO is not deterministic.