Unexpected behavior logging with DSC

[A.S.]

Forgot to attach the screenshot. Here it is:

[pjlaskey]

Your results are interesting in that they don't exactly match mine. This might be a useful data point.

Each of the runs in the historical log files has a non-empty string associated with it. The application should not return an empty string, but it obviously does. I have seen this to be the result of a problem with my Binary Search (timestamp).vi. Please debug this VI on a run that fails to return a string and see if you can determine why.

I find it interesting that I was able to return a string for 101 and not for 100, whereas it is the opposite for you. I had thought the problem was related to data logging, but maybe it has to do with retrieval. If you can achieve different results on the same dataset then we have a different problem.

Thank you,
Peter Laskey

[A.S.]

Hi Peter,
I have trying to debug your Binary Search VI for quite a while. It seems like your algorithm is based heavily on the presumption that timestamp (in) will be before the target timestamp (in). But, as you noted, this is not always the case. I was repeatedly able to get results from run# 100 and none for run# 101. But I think the problem is the same for both of us...the bit shift causes a roll over in the index into a non-sensical boundary number. This again is because the target timestamp is smaller than the actual timestamp for run#101. (See attached image)

Why is a timestamp before the Time Interval actually returned by the Read Traces VI? This is because when calling the Read Traces VI, the interpolate option is set to False. If a datapoint does not exist at the start time of the time interval, the Read Traces VI goes back to the last actual datapoint and grabs that value and its timestamp. So to make sure that the Read Traces VI doesn't go back before the start time to grab the last valid point, you need to set interpolate, extrapolate and remove data break options to TRUE. This will ensure that the data will be grabbed exactly at the start time. And you will see that you won't see any problems with the Binary Search VI. However, be aware that then the interpolated data is being returned as opposed to the actual data.

If the above solution is not a behavior your system can afford, then the other work around is to modify your Binary Search algorithm to prevent the rollover from happening in the bit shift routine. This is something you will have to play with yourself as I couldn't fully understand your routine.

But based on your needs, you can go with the first suggestion and simply interpolate the data. Simpy change the first 3 constants to TRUE in the Options input cluster constant of the Read Traces VI on the main block diagram. Otherwise, you may want to re-do your binary search algorithm.

I realize I wasn't able to provide a way to fix your binary search algorithm. But I think the other solution I provided will be quicker and easier if it is something your application can work with. Hope this information is helpful and thank you very much for your patience while I tried to replicate your issue.

Happy Holidays!!!