Write To Measurement Duplicate Timestamps

[afdasfdasfadsfdafadfdsf3]

Hello,

I'm currently reading voltage data serially via USB (COM port) and I'm trying to use the "Write to Measurement File" block to log some of the data that gets passed through. 

For both cases, when using the Write To Measurement block:

- I experience lag in the rate at which data gets plotted to the Waveform chart and,

- The written file ends up with data that has duplicate timestamps with different values.

I've searched for similar issues in the forums but I couldn't seem to find anything relating to this issue. Is this a known issue? How would one go about ensuring that a set time delta restriction is in place?

Any insight would be appreciated.

The VI configuration and .lvm buffer are attached below.

I am sampling at a rate of 1 kHz (PIC18F2550) and sending the samples out via UART (19,200 baud rate) protocol to be plotted on a waveform chart.

[Dennis_Knutson]

You aren't passing any time information at all to the write function. Your loop spins without any function to determine time between iterations either. The wiring of the tab control to the case statement is also odd.

Try getting the current time and building a waveform data type and pass that to the write.

The sample rate of your pic could be totally irrelevant to how often the loop iterates. It really depends on how you wrote the subVI.

[afdasfdasfadsfdafadfdsf3]

In terms of odd wiring, are you referring to the blocks inside the case structures that encompass the boolean switch followed by the "Serial Config + Verify" block? I wasn't sure if this was the best approach but I essentially want the COM port config to be accessed globally throughout the various tab control modes.

I should clarify, by timestamp, I was actually referring to the first column in the attached bufferdata.txt file which I believe is in milliseconds. I was wondering why there is multiple data points for the same time value?

[Dennis_Knutson]

No, odd wiring is wiring the tab control to anything at all.

As I said, you aren't passing any time information to the write function. I'm surprised that there is any thing at all there. The express function is designed to work with dynamic data (waveform data types in a pinch). You are passing a scalar and that contains no time data.

[afdasfdasfadsfdafadfdsf3]

Alright, after looking more into Tab Control's properties, I found the "Value" property which signals whenever a tab has changed wheras the Tab Control's enum does not and would require constant polling (which according to some other posts is greatly inefficient).

I deleted the original "Write To Measurement File" block and added another one and now I'm getting data in a totally different form. So as far as I understand, the only way to get time data (elapsed would be preferred vs time stamp seconds) would be to transform the input data into a waveform type?

Attached is the current output of the new "Write To Measurement File" block

[Dennis_Knutson]

Passing data as waveform data type is one way. The write to measurement file function requires data that includes time information. It doesn't keep track of time, you have to do that in your program. You don't have to use the write to measurement file. You can use any number of file write functions.

[Dennis_Knutson]

And using the property node is just as silly as using the control itself. If you insist on using the tab control that way, move it inside the loop.

[rossya16]

How else can you access the active tab control page without hooking up to the tab control?

[JÞB]

---

@rossya16 wrote:

How else can you access the active tab control page without hooking up to the tab control?

---

Well, how often do you want to read the value of the control?  In your example it will be read once.  (That's all the number of times you read the value from the terminal, ONCE when the vi starts)  The value input into the while loop's tunnel cannot change even when the value of the control changes since the terminal cannot be read more than once.

[pj1390]

I too have this question, regarding the data logging.

If my data is being sent serially 1 sample every millisecond to the serial read, is it crazy to expect that after starting the program a logging function would produce the roughly the same as the following:

Time (s)          Value

0.000                250

0.001                275

0.002                300

0.000                250

0.003                275

0.004                300

0.005                250

0.006                275

0.007                300

I understand that there will be slight offsets in time as the modules take time to run but each sample coming in should have its own time value that is roughly 1ms apart from the previous and next values right?

My data is logging in a similar fashion as the OP's result, with some samples coming in with the same time value, which doesn't make sense if they are transmitted 1ms apart. Instead of the desired table I receive something like the following:

Time (s)          Value

0.000                250

0.000                275

0.000                300

0.001                250

0.001                275

0.002                300

0.002                250

0.002                275

0.003                300