Time elapsed for data logging causing issues

[Mitch_Peplow]

Hi all,

Got a bit of an issue with the attached vi which I'm hoping you can can resolve.

I normally use hardware timing for my acquisitions which allows me to accurately determine the total test elapsed time as well as the correct point in time to send the trigger to log data. The problem I have is that I'm using a serial comms based device which means I'm having to use software timing to derive the test elapsed time and the log trigger point.

Now the total test elapsed time vi is exactly the same as this and that works fine as as it never gets reset, but with the log triggr I am experiencing lag which means that over time, the number of logs is lower than it should be relative to the elapsed time. So say I run for 30 minutes at a logging interval of 10 seconds, I should expect to have 180 logs. What I actually end up with is 176 logs. 

Now when I run the main code and inspect the vi, I can see that the issue is to do with the fact that the vi gets reset when the target time has elapsed. I can see that the elapsed time and the remaining time exceed the target time (so say the elapsed time is 10.1 seconds and remaining is -0.1 seconds). Because of this offset occurring every ten seconds, it accumulates to the point where I am drifting out of sync by seconds, in this case 4 seconds as im 4 logs short.

How can I resolve this? Do I modify the attached vi, use a different method, somehow synchronize the elapsed time to the log trigger etc, all the above?  

Any help or ideas are more than welcome.

Cheers

Mitch 

[GerdW]

Hi Mitch,

Because of this offset occurring every ten seconds, it accumulates to the point where I am drifting out of sync by seconds, in this case 4 seconds as im 4 logs short.

How can I resolve this?

You cannot resolve this! Atleast not within your ElapsedTime VI…

Your serial comm is slow and has delays. To overcome/minimize them you should change the timing scheme from "wait fixed amount of time" to "wait for next multiple"…

Another approach: keep the current readings of the serial comm in a notifier (or local variable). Use a parallel loop with your ElapsedTime to read the current values at the exact moment you need them. (It's a simple producer-consumer to separate DAQ/COMM loop from data handling/saving loop.)

[Mitch_Peplow]

Hi GerdW,

Cheers for the quick reply, much appreciated.

The thing is I don't actually time the serial comms acquisition loop, I let it run as fast as it can so the serial device itself is timing the loop. 

The device is a balance/scale and it takes roughly 200ms for each iteration as dictated by the balance, however this fluctuates wildly. What I have found is that if I set a wait time longer than say 200ms, the balance appears to stop responding. It hasn't but the data updates very slowly, almost like it's filling a buffer because if I put a weight on the balance, eventually the reading updates. If I remove the wait of set it to a lower value, the readings update instantly. Is this where you suggested putting the "wait for next multiple" or have I misunderstood? 

Just to let you know, the balance drivers were supplied by the manufacturer, I have not created them.

I already implement a full producer-consumer in the main code with the Acquisition, FileIO and Display all as separate loops.As you can see from the above pic I send the balance data straight to an FGV for the display and then ping it into a queue for the FileIO. It's done this way as this is how I do it for Hardware timing as each sample in the queue represents a specific sample time. 

Any more ideas?

[RTSLVU]

Well first off if your instruments take more time to take a measurement than your logging interval then you need to increase your logging interval or decrease the time your measurments take. 

But it sounds more like you are not accounting for the time it takes for your instruments to actually take a measurement.

Here is an example of what I do: 

When the timer runs out the current time is sent to my logging state for a timestamp.

That timestamp then becomes the new start time on the next wait so it accounts for the few seconds the instruments take to make their measurements.

Now my logging interval is always exactly the interval I set.

Also in the odd case that a measurement takes longer than the logging interval, the wait will automatically be zero (or less than 0) seconds on the next interval. 

[Mitch_Peplow]

Afternoon RTSLVU,

It's not so much that the instrument takes longer to measure than the logging interval as the measurement takes ~200ms and the logging interval in this case is 10 seconds, however I do agree that if close to 10 seconds logging has passed, say 9.95 seconds, then the next log will be out as the FileIO loop that contains the elapsed time vi has to wait ~200ms to get its next chunk of data and update meaning it will flag as time elapsed, however in reality ~10.15 seconds has elapsed. This in conjunction with the vi resetting compounds the offset issue.

I really would like to know why the read doesn't like it if I set a wait higher than 200ms though as the behaviour is very annoying. I've attached the driver set that the manufacturer sent me just in case you want to have a look.   

Right, your example vi. I'm struggling to understand if I could implement your method by modifying my vi or wether I need to implement this in another part of the code. Given my statement above about the offset due to waiting for the balance to output and thus trigger the FileIO dequeue, would your method still work with my architecture? 

[RTSLVU]

Well RS-232 communications can be slow, I have a few power analyzers here that only have a  serial port and they take just under 2 seconds to transmit their readings at 9600 baud.

I am kind if confused as to why you have a timeout on your elapsed time to begin with.  If you are just trying to get elapsed time then just get the elapsed time. 

I need to see your full program as if sounds like you are saying you have issues if you wait longer than 200mS between measurements. That makes no sense at all...

[RTSLVU]

---

@Mitch_Peplow wrote:

The device is a balance/scale and it takes roughly 200ms for each iteration as dictated by the balance, however this fluctuates wildly. What I have found is that if I set a wait time longer than say 200ms, the balance appears to stop responding. It hasn't but the data updates very slowly, almost like it's filling a buffer because if I put a weight on the balance, eventually the reading updates. If I remove the wait of set it to a lower value, the readings update instantly. Is this where you suggested putting the "wait for next multiple" or have I misunderstood? 

---

Instead of always waiting 200mS why not wait until there is a valid measurement available regardless of the time it takes? 

[Mitch_Peplow]

Morning,

I was off work Friday, hence the lack of response.

If by timeout on the elapsed time vi you mean the target time, that’s the logging interval time so when say 10 seconds has elapsed, the time elapsed flag goes high and forces the FileIO to write to file. The data from the balance is always placed in the FileIO queue, then the FileIO module decides if a log is required or not based on the elapsed time flag.  

As much as I’d love to send the code to you, unfortunately my company will not allow this. I can send individual bits and bobs and like I say the balance drivers were designed by the balance manufacturer so there’s no issue sending them in their entirety.

Yeah, it’s very weird indeed regarding wait longer than ~200ms. It’s almost like once the balance is kicked off, it needs to be able to offload data unimpeded or else it buffers up, however the lag between me placing something on the balance and the screen updating is seconds, even if I demand say 250-300ms wait so I don’t believe this is what’s truly happening. The screenshot of the acquisition loop is the only instance of the read balance vi.

Regarding the wait of 200ms, I’m not actually setting any wait time, that’s the inherent latency of the balance updating. As you mentioned, your power analysers take just under 2 seconds to transmit their readings. With mine, it’s taking ~200ms at 1200 baud.

I wonder if what I need to do is create another loop purely for the timing so instead of relying on the data from the balance to iterate the FileIO module (which we know will fluctuate and cause compounded time offsets) use the flag from the elapsed time vi in this new high-speed loop to dictate when the log occurs.

What do you think?

[Mitch_Peplow]

Quick update. Just tried a quick experiment and the balance is definitely doing some kind of data buffering. If I check the loop iteration time with no wait, it's around 200ms as we know. If I add a wait, say 1 second, leave it for three seconds then take the wait off, the iteration time runs at the speed of light until the buffer is empty whereby it then reverts back to the ~200ms iteration time.This means the data was already there ready to be spat out. 

My assumption was that when the read request was sent, that's when the data is transmitted from the balance to the PC, however it appears that the data is continually being sent regardless and the read is a read from the buffer, not a direct read from the balance if you get me.

Doesn't help my situation a great deal but thought it worth mentioning.

[Kevin_Price]

I'm just reading the thread quickly and don't have time to examine code now.

One very general comment I'd like to add is that vendor-supplied drivers can be pretty hit-and-miss.  I've pretty often found some unfortunate things -- like hardcoded unnecessary delays, code based on checkable assumptions that aren't actually checked, commands that should support many options but the code only supports one, etc.

It's often worthwhile to dive into the driver code, see what it's doing, and be prepared to make your own modified versions of code where necessary.

-Kevin P