producer/consumer and continuous PDF help

[andrew-mat]

hello,

I am writing a code to collect data, store it, and also display a live continuous PDF. The hot wire data (hw data) is being collected at 25 kHz and the temp data at 400 Hz. This section of the code attached is the part handling the collection and displaying of live values. The problem is that after 45-60 seconds, it times out and I get an error response that the hardware cannot keep up with the data acquisition. I'm looking for either 1) a better way to collect and store data (in 1 array) with 2 different collection rates simultaneously or 2) a way to display a continuous PDF without causing errors over time. 

thank you.

[santo_13]

You did not attach any VI

[Bob_Schor]

LabVIEW (per se) does not have the ability to write PDF files.  As far as I know, all programs that "create" PDF files start with text (in some format, not necessary a .txt file, but possibly a file of another "well-defined" type (like ".doc", ".xlsx", ".tex") and convert the entire file to PDF.  I am not aware of any PDF "processor" that works in "streaming" mode, "growwing" the output PDF as new "text" is input.

It is easy to write a Producer/Consumer system that lets the "Producer" keep adding to an ever-growing (say) Text file.  Here is a Kludge that might work:

1. The Consumer routine would get some text, which it would "add to the end" of the "growing text file thus far". 
2. Before finishing its Consumer Loop, it would make a copy of this intermediate file and (as a Producer) call a second Consumer that would treat the "ever-growing" intermediate text file as the input to a "text-to-PDF" routine, over-writing any previous .PDF output.

For several years, I've been using "another" non-Microsoft system to write documentation, one that takes a text document (with embedded formatting commands) and periodically (through a two-key Control sequence) generates a resulting .PDF document (including any embedded figures I may have included).  When I'm on a roll, I might type a few pages of text before looking at the resulting PDF, but if I'm fiddling with looking at a formatted Table or looking for page breaks, I might generate'check the PDF more frequently.  So I am my own "second Producer/Consumer" that I described above.

Bob Schor

[wiebe@CARYA]

---

@Bob_Schor wrote:

LabVIEW (per se) does not have the ability to write PDF files. 

---

In this context, Probability Density Function - Wikipedia makes more sense.

[Bob_Schor]

Oops ...  Thanks for clarifying what a "continuous PDF" means.

BS

[andrew-mat]

yes, sorry for not clarifying, PDF is a probability density function and the inputs are:

hot wire data: 1x2 array of double

temp data: double

also, here is the attached VI (.vi file included below as well)

 

[wiebe@CARYA]

That middle loop is concatenating (building) an array as fast as it can.

And why would you concatenate temp data with your hw data array?

The bottom right loop is completely redundant. You can combine it with the middle loop. Then again, why not combine the middle and bottom right loops with the top right one?

You should make a deterministic way to make the loops communicate (e.g. using queue(s)).

The purpose of "number of samples" is a complete mystery. 😂

It's hard to give advice, because I can't really tell from the code what you're even trying to do.

It's clear you somehow want to combine hw data and the temp, and get a PDF from that, but we'd need to know a lot more about the daq. E.g. could you sample hw data and temp simultaneously? That would make things a lot easier.

[andrew-mat]

sorry for the confusion, this code is a smaller part of a larger VI. hw data and temp data are collected separately because hw data needs to have a data collection rate of 25kHz while temp data cannot collect any faster than 400 Hz. For data storage purposes, they need to be combined into one array. 

The error is somewhere in the right two loops because when taken out, data is collected and stored without a problem. The purpose of these loops is to display real time data separate from the data storage that occurs elsewhere (not shown in this VI). when these loops were added, however, the code would produce an error 45-50 seconds after starting that said the hardware couldn't keep up with the data acquisition. I tried queues and channel wires without much success. The problem seems to be somewhere in creating a continuous PDF that updates as data comes in and managing two separate DAQ sampling rates. 

[wiebe@CARYA]

---

@andrew-mat wrote:

however, the code would produce an error 45-50 seconds after starting that said the hardware couldn't keep up with the data acquisition. I tried queues and channel wires without much success. The problem seems to be somewhere in creating a continuous PDF that updates as data comes in and managing two separate DAQ sampling rates. 

---

You're middle loop fills 1 CPU for 100%.

Put a wait in it.

That might fix that problem, but you're code is much more complex that it needs to be. You're using 5 loops where 3 at mx are needed. You'd be much better off handling the data synchronously (e.g. put hw data on a queue, get temp from a 1 element queue or local when needed and put it in a cluster with the hw data). Free running asynchronous loops will make everything totally indeterministic.