Common Problems with LabVIEW Real-time Module

You are here

17 February
0
  0

Common Problems with LabVIEW Real-time Module

This is the first part of the series where we address problems users occur with LabVIEW real-time module. 

If the instability of Windows appears to be a concern, we recommend a fault tolerant design that could handle the Windows platform going down occasionally.

Here’s what we’re talking about 
Three machines:
1) DB Server
2) DB Writer
3) RT Data collection

Notes:
1) DB Server of your choice. Preferably SQL based.
2) Responsible for pulling readings from RT and writing to DB. The buffer between two systems. More on this below.
3)RT Data Collection and short term storage. More below.

The DB writer acts as a buffer between the short term storage on the RT platform and the server. The data collected from the RT system will be coming in at a steady rate. The updates going to the DB should be viewed as being asynchronous.

Break RT app into two parts, Time Critical (TC) and other. The TC loop reads data and queues to the other loop. The other loop should read the queued data and write to LV2 style globals. These LV2 globals should maintain an array of the data. If the array exceeds some predetermined level, newest data goes to buffer file. This journaling to file will allow the Windows based DB writer to fall behind, re-boot etc. 

Meanwhile, on the Windows platform...

DB Writer could periodically use a call by reference node to execute a read operation to the LV2 global written by the "other loop" on the RT platform. Read data is then used to write DB using SQL Toolkit or whatever.

The data collection rate will determine the amount of local disk storage you will need on the RT platform to handle buffering backlogs while the Windows app is down. The size of the cached array in LV2 global should be large enough to handle the non-periodic nature of the DB Writer's read operations. When the LV2 global on the RT platform is read it should return the contents of the cached buffer when a read operation is performed (by the RT Writer). If there are samples waiting in the RT's buffer file, a read of the oldest values should be read from the file and placed in the buffer waiting for the next read. The LV2 global should also return a boolean or similar flag that indicates more reading are waiting to be read.

We realize that this article does not tell you how to write to a DB from the RT platform but it does represent an architecture that will allow you to harness the stability of an RT based app while taking full advantage of the functionality that is already in place. Our LabVIEW experts will try to provide answers to your questions. Do you have any?

Latest From Blog

Semiconductor Testing
12 December 2017 | 0 comments

Automated test equipment (ATE) is computer-controlled test and measurement equipment that allows for testing with minimal human interaction. The tested devices are referred to as a device under test (DUT).

[Read more]
SUBSCRIBE TO OUR NEWSLETTER

About

“ReadyDAQ provides a customizable LabVIEW solution which is both time saving and affordable”. 

 

The team – ReadyDAQ has a dedicated team of physicists, electrical engineers, and programmers who work to provide a data acquisition solution for any project in different difficulty levels.

CONTACT INFO

  • Address: Matam - Scientific Industrial park, Building 23      Haifa, Israel
  • Phone: +972 72 250 5555
  • Mail: info@ReadyDAQ.com