Is there a way to force the Tag Engine to dump its input buffer to the database?

[Jake Stern]

I have an application where I start a process and log the data, and then call a subVI that uses the Read Historical Trend VIs to get all of the data from when the process started until now. The problem is that the Historical Trend VIs only read from the database on disk, and the Tag Engine's buffer doesn't write to disk until it's full (or possibly times out; I'm not sure about that, though). Is there a way to force the Tag Engine to write to disk, so that the Historical Trend VIs will return the most recent data?

Shrinking the buffer will help a little, but that will only result in missing less of the most recent data. One possible hack is to have a dummy tag that I simply write enou
gh data to that will cause the buffer to be written to the database. I was hoping for something more elegant, though.

[Roli]

That's a good question.

The control about the datalogging and the DSC Engine is all done (more or less) automatically - you feel the NI ease-of-use idea 🙂

That means the Citadel service (one of the NI Services installed by LabVIEW DSC) is responsible of taking care about the datahandling (writing to and reading from the database files including caching some data e.g. index files, frequently used data...).

The DSC Engine makes a request to the Citadel service that this data has to be logged. Everything else is handled by the Citadel service. Internally, there are two kinds of logging periods handled through the Citadel service. One for traces being viewed (a small period: 200ms) and one for traces not being viewed (slow (big) log period: 20000ms). That
means, if Citadel gets a request to store a value it will buffer it and store it as soon as possible depending on other circumstances. One depends on the fact if this trace data is being viewed (e.g. with Read Histroical Trend.vi) If you request/read to view a trace you should pretty much see the current values because citadel should use the fast log period.

The Citadel service takes care as well about setting priorities e.g. the writes before the reads (We don't want to loose data - right?). That means if you really stuff the system by writing a lot of data the CPU might get overloaded and the reads will happen less often.

If you really want to see "real-time" data I would recommend to use the "Trend Tags.vi". With this approach you avoid the chain DSCEngine-Output Buffer-CitadelService-InputBuffer-File-HD... and back.

I hope this info helps.

Roland
PS: I've attached a simple VI that has a tip (workaround) in it which might do what you are looking for... However, Nationa
l Instruments cannot support this offically because the VI being used are internally DSC VIs that certainly change in the next version of LV DSC... and therefore you would need to "re-factor" your application.

[Jake Stern]

Thanks for the insight, Roland. I'll check out your example, but in the meantime I found a work-around that seems consistent with what you said. I simply do a Read Historical Trend for each of the tags I'm interested in, ignore the returned data, and then read them again. On the second read, all of the data are there.

-Jake

[unclebump]

How about a trend tags graph implementation in a future release?? I have an application where I am monitoring the power used by cutting tools for several hundred cycles a day. The trend tags vi leaves gaps in the data when a machine stops running and makes it hard to see how a process trend is running. I would like to see new data added to the graph after each cycle. Right now I am trying to implement this by writing the values to a memory tag and using the read historical trend vi. I unbundle the output of this and only look at the value data and wire to a graph. I guess what I would like to see is a trend tag vi that would only add data based on a boolean transition and not a default time value.

[Roli]

Probably I did not exactly understand... But you might use the Set Tag Attribute.vi to turn off/on data logging based on a boolean value.

I think, the Data Set Logger (VI-based) server in LabVIEW DSC 6.1 would provide you similar functionality. Logging of batches base on start/stop conditions. Here is the link to an introduction with an example: Data Set Logger Tutorial for LabVIEW DSC Module

Hope this helps
Roland