Time elapsed for data logging causing issues

[Mitch_Peplow]

Morning Kevin,

That's one of the first things I went looking for but couldn't seem to find anything that would cause the observed behaviour. That's not to say it doesn't exists and could easily still be embedded in the code somewhere, it's just I've missed it. It doesn't help that this is the first time I've dealt with serial based hardware so there may be settings in there that are causing problems, I just don't realise it. If you get five minutes to take a look at the drivers (further up in my other post) that would be most appreciated as you may spot something glaringly obvious.

That said, it was mentioned in the other post that update rates for a particular serial based power analyser was around 2 seconds at 9600 baud so even if I can stop the odd wait/buffer issue, the timing resolution for the log will still only be as accurate as the jitter between serial data reads.

To prove this I disabled the read balance data vi and replaced it with a cluster constant and ran the loop with a wait time between 0-10ms. As expected, the total time elapsed and the log elapsed time were both synchronized (to the human eye, there will still be time offsets occuring in the background) so the times matched and so did the total log count (I left it for an hour and it was still ok).

So this proves that the time between serial reads and the reset time of the elapsed time vi is causing the offsets as the log elapsed time is only as accurate as the speed at which the FileIO loop iterates. The faster the loop, the more accurate the elapsed time becomes. I realise this is partly down to my architecture as the log timing is dependent on a variable (balance data) whose timing can vary wildly which is why I wondered if a dedicated timing loop may help. That said, even if the timing loop was perfect, I would still need a method for the loop to flag that a log was required, ensuring it was logging the correct data at the correct point in time with the correct timestamp. And even then, if the timing loop said hey, time elapsed, take a log, if the balance was in the process of reading there would be no data at the exact point in time that it was required. Potentially a feedback node could be used so the last data would be written twice to ensure the timing stayed in sync which I would happily live with.  

[Kevin_Price]

I took a few minutes to look at the driver you attached.  It doesn't rank too well on the awesome-o-meter, though I've definitely seen worse.

I didn't spot anything particularly time-consuming in the driver code for querying a weight.  I looked at their example for querying weight and noted 2 things:

1. There's a function to set the weighing mode which needs a filter setting.  This could also affect the responsiveness to new queries.  (It may "filter" or maybe just average across multiple internal samples so it takes longer to get them.)

   Whether you call this function in your code or not, the instrument probably has a default setting.  Consider calling it during your config so you can observe the effect.

2. Are you using their Initialization function? It has a subtle problem in setting up the termination character for serial comm.   They've tried to define the combo of "carriage return + line feed" as the termination character.   However, VISA serial comm will only recognize a single 8-bit character as a message terminator.

   Presumably the instrument terminates its messages with that combo.  However, during setup, only the carriage return gets registered as a termination character.  That means that each VISA read will terminate at the carriage return, leaving a line feed in the serial buffer that will be the 1st character brought in on the next Read.

   Some of their parsing seems to very much depend on the specific position of certain info within the string.  The extra leading line feed character could throw that off.

   Further, it appears they are trying to use the same combo for all writes and their VISA Writes count on this setup to automatically append a termination character.  Only the carriage return will get appended and I don't know how the instrument will respond to that.

I don't have a specific idea how these things might produce reasonable readings and odd timing, but sometimes fixing a problem that seems unrelated can have some good side effects.

-Kevin P

[Mitch_Peplow]

Morning Kevin,

That's great, many thanks for taking the time to have a look and get back to me. Much appreciated.

I will give your suggestions a go and have a play around to see what effect it has. 

Cheers

Mitch