How can I publish a high channel count of real-time item from an embedded controller to a datasocket server on a host PC. My desired update rate is 10 Hz.

[KirkEvans]

When I try to publish multiple channels to the datasocket server simultaneously the realtime vi and server bog down

[Kristi_P]

Can you clarify how you have architected your real-time application? Typically, you will have one VI running at time-critical priority handling your high-priority task, and you'll have another VI running simultaneously at normal priority doing operations like DataSocket communications back to the host computer. Communications between the time-critical and normal-priority loops usually happen with RT FIFO's.

Can you clarify what you mean by the real-time VI and server bogging down?

Regards,

Kristi H
National Instruments

[KirkEvans]

In my particular situation the publishing is just as time critical at the aquisition. That being said, by bogging down I mean that the RT VI takes about 300-400 seconds to iterate and the data socket server becomes unresponsive on the host pc. Currently I have all tasks in one VI, but I am reconfiguring to use the 3 vi system. However, I am finding that I can't even sample the hardware as fast as I would like. This is utilizing traditional DAQ and as I understand it DAQ-mx is unable to run 2 concurrent analog input tasks and I don't know how to make a task that will sample all analog input types instead of just voltage, or just current, or temperature. My total channel count is 356 (128 AI, 32 AO, 196 DI-O).
In a nutshell I would just like to turn my P
XI system into an OPC type server.

[Kristi_P]

If you simply need to do deterministic data acquisition, then you could do buffered data acquisition rather than single point acquisition. Perhaps that is what you are doing.

With buffered data acquistion, you can acquire data at the rate of your DAQ device and then you can stream the data back to your host computer. However, you'll still need to allow your program to have enough time to send data back to the host. One thing to note is that if you're doing buffered data acquisition, you should not need to run your DAQ code at time critical priority because buffered DAQ is already deterministic. Depending on which digital board you are using, you may or may not be able to do a buffered digital input.

Are you doing buffered DAQ or singl
e point I/O? How much data are streaming back at a time and how fast do you need to acquire data? Which devices are you using?

Regards,

Kristi H
National Instruments

[KirkEvans]

I am doing single point aquisition utilizing the rt communication wizard so that a have a time critical aquisition vi and a normal priority posting vi. I am trying to stream the data back as 356 channnels at 8 Hz, but the data transfer won't keep up with the aquisition and my rt system crashes because it eventually runs out of memory.

My hardware is as follows:

PXI 8176 controller @ 866MHz
4 PXI-6527 DIO card
2 PXI-6704 AO cards doing 0-20 mA signals
1 PXI-6025E Multiplexing a SCXI 1000 chassis
4 SCXI-1102 doing various AI signal

My time critical or aquisition vi as able to single point sample all 356 channels at about 10 Hz, with the AI multiplexed sampling being the limiting factor.

The absolute minimum samplin
g rate that I can use is 4 Hz.

I really need this data available to multiple PC's and I am almost to the point of abandoning realtime and just running the system in windows - it seems to be much more efficient at posting data the the datasocket server in windows using the data socket connection on the right-click submenu. I can handle the excessive jitter of the windows os as long as the average sample rate is correct. Although, I would like to retain the robust nature of the realtime os.

Thanks,

Kirk

[Kristi_P]

Hi Kirk,

Either you're running out of memory or your time-critical loop is not sleeping enough for you normal priority code to run. We have some tools available for troubleshooting situations like this, including the Real-Time System Manager and the Execution Trace Toolkit.

The Real-Time System Manager (RTSM), which installs with LabVIEW Real-Time 7.1, allows you to monitor the CPU usage and memory usage on your controller. Be aware that the RTSM will utilize TCP/IP communication to send the results back to the host, thus taking up some room on the network. If you are unable to run the RTSM, try simplifying what you are sending back to the host so that
you can really view if the problem is that of memory or CPU usage.

The Execution Trace Toolkit provides even more detail as to exactly which threads are running at what times. It also allows you to view when you are calling the memory manager and when a thread is sleeping.

How much memory do you have in your 817x controller? You should be able to expand up to 512 MB of RAM. You might also try streamlining your time critical code as much as possible, ensuring that data flow is controlling the code throughout the program. For example, you can use the error handler to control data flow, rather than allowing the VI to execute code arbitrarily.

If you would like to attach your code, I can see if there are any ways we could increase the efficiency. However, it's possible that your system will simply not have the bandwidth to handle all of this.

Please let me know how I can help.

Regards,

Kristi H
National Instruments

[KirkEvans]

Hi Kristi,

I think I am running out of memory. I am having trouble getting the realtime system manager to work. It keeps giving me the message that the server is not running nor can it start it. I haven't found much trouble shooting on this (probably because it is such a new feature).

As far as the bandwidth I am able to run the time critical loop at 5Hz in windows on the pxi system and publish to the datasocket server on the machine that served at the host when running realtime on the pxi system. I appear to have plenty of bandwidth left according to the window taskmanager on both machines.

I have attached the code that I am using and it includes the base time critical vi that I used with th
e realtime communication wizard. And I have also included the windows version of the vi.

Thanks,

Kirk

Any help you can offer would be greatly appreciated.

[Kristi_P]

I noticed that you are using property nodes to read the value read by the analog and digital lines. This will not work in Real-Time because the value property is going to read the value on the front panel indicator that you have. On a deployed Real-Time system, there is no front panel so there is no value to read from the indicator.

The RT Communication wizard can sent data back as arrays and as waveforms, so there's no need for you to do all of the indexing and reading from the property nodes. Instead, just allow the Wizard to create FIFO's for your existing arrays and the waveform. I've modified your VI to show you all you should need.

If you're still having troubles at this point, use the e
rror line to control the data flow. In other words, all of the tasks that you think are running in parallel are not actually running that way and won't run that way. So, you should use the error handler to first call the DAQmx Read Analog Wfm, then read the Digital 1, then the Digital 2, etc. Then you know your code will run the same way every time.

If you're still unable to use the Real-Time System Manager, be you have enabled VI Server access on your RT Target as described in the KnowledgeBase 39Q7AMFL.

Regards,

Kristi H
National Instruments