Measurement buffer proof of concept

[RTSLVU]

I an trying to upgrade our testing software to implement a "data buffer" that can be saved when a test is aborted due to measurements outside of the "Safe Operating Limits" (SOL).

Our current software only takes measurements at the data collection intervals. About a year ago after a catastrophic test failure, I was asked to implement a SOL feature that would abort a running test and disconnect power to the UUT if current exceeded the SOL.  

I managed to kludge that into the existing test software, but after the SOL worked a couple times. Everyone was happy but R&D said it would be nice if I could implement some sort of buffer that would hold the previous 10 seconds of operational data and write that to disk if SOL is tripped. As that could be helpful to see what was going on before the failure.

I have back burnered this for a long time and now we have new test systems to build. The new systems have a couple of new instruments that I have to add in support for, so while I am doing that I plan to implement this feature.

My first though was Queues but with Streams being the fancy new thing I have decided to try them out.

This is my proof of concept I threw together this afternoon. I am not sure I fully understand Streams as using two streams is the only way I could figure out how to do it.

I am open to suggestions for a better way if this is not the way to do it....

[mcduff]

I have never used streams before, but in this case it seems a limited element queue would be better.

Looking at your code, it likes like your buffer empties point-by-point. If you were using a queue then you could use a "Flush" queue function to get all the data at once. Not sure if something like that is available for streams.

The other potential issue is what happens during a "test abort". Do both the DUT and program shut down, or does the program continue running? If the latter, you have a shift register that could have old not needed data. For example, assume DUT A aborts a test run, then your program goes to DUT B, and it also aborts a test run. Your shift register data for DUT B will have both DUT A and DUT B data on it. This can be avoided is there is a "Flush" operation like there is for queues.

mcduff

[RTSLVU]

---

@mcduff wrote:

I have never used streams before, but in this case it seems a limited element queue would be better.

Looking at your code, it likes like your buffer empties point-by-point. If you were using a queue then you could use a "Flush" queue function to get all the data at once. Not sure if something like that is available for streams.

The other potential issue is what happens during a "test abort". Do both the DUT and program shut down, or does the program continue running? If the latter, you have a shift register that could have old not needed data. For example, assume DUT A aborts a test run, then your program goes to DUT B, and it also aborts a test run. Your shift register data for DUT B will have both DUT A and DUT B data on it. This can be avoided is there is a "Flush" operation like there is for queues.

mcduff

---

Actually the part I got hung up on with Queues was how to dequeue the last (most recent) element at the data logging interval without using two Queues.

But I ended up using two Streams anyway so... Meh... 

But if a test was aborted for exceeding SOL the program is stopped and the UUT shutdown.

The entire test would have to be restarted. 

[dsb@NI]

I am a fan of the channel wire but am less enthusiastic about multiple channel readers in the same loop. With your example, I don't see a possibility of locking while waiting, but it's a pattern that has tricked me before. Anyways, I tried different approaches that all seemed to capture the data behavior you described.

I gravitated towards the implementations where the recent history could be viewed on the Front Panel while it ran (see Stream to Queue case), but that wasn't your requirement.

I don't know which implementation cries out, "I'm readable. Maintain me!" In the end I was thinking the best solution might be to use a file buffer. Alternately write to two files (A, then B, then overwrite A, ...) all the time. If ever the test was aborted, you would have the data requested between the two files. But maybe that is not feasible because the actual test data is large (and too slow to write continuously).?

[Bob_Schor]

Drat.  I had a simple solution, then when I said "Post Reply", it kicked me out!  Fortunately, I saved the Snippet.

So it's easier than you think (and the Lossy Stream Channel is exactly the right choice).  I'm going to assume you have a State Machine architecture (my Dummy Example has one).  You get a Data Point, add it to the Lossy Stream Channel Wire (which you bring out to the right side of the State Machine While Loop) and also test to see if you need to execute the "Process SOL" State next (instead of whatever normally follows).  You add a "Process SOL" State to your State machine -- I'll tell you in a second what goes into it (though you can probably guess).

Go to your Stream Channel Wire, sitting on the output Wall of your State Machine's While loop.  Drag the Pipe up, make a Left Turn across the top of the State Machine, another left down the Input side, and a final Left into the "Process SOL" State.  Richt-click and create a Channel Reader, use its output to write to the "SOL Error" File, close the file, and go to your State Machine's SOL Shutdown State.

Bob Schor

[RTSLVU]

Thanks, I get it now, no need for two Streams I can make the buffer in its own loop.  I think I am going to go with a CMH architecture as the template seems to have a lot of the stuff I need already done.