Finite data storage, retrieval and display within a while loop

[jcannon]

Hi DFGray,

What you suggest makes perfect sense and conceptually I can follow what you are suggesting... Implementation is another story, however!

I did some reading on "ring" (circular?) buffers and found this http://zone.ni.com/devzone/cda/epd/p/id/5883... I downloaded it and added it to my vi along with the "basic trigger detector" you mentioned... The trigger detector works great myself and the circular buffer (in my case structure) is grabbing a segement of data and plotting it as required...

However, I cannot work out how to program the circular buffer... I think I need to use it like the queue, where I have one outside the loop (set to "initialise") and another inside the loop (set to "read")... But I cannot work out the numbers to use for the cluster into "Buffer size" for buffer intialisation or the relationship these numbers have to the "read size" input in the buffer read inside the loop (or to my desired pre/posttrigger durations)?

I played around using different combinations of numbers and the display (LOOP 3) was behaviing as expected; but it appears that the only "pretrigger" data was being displayed...

To get pretrigger data and posttrigger data in the same waveform for display, do I need to get pre and posttrigger data separately and append them; sending the appended waveform to the display? I spent all day trying to follow the ni.com example and replicate the code in my vi to not avail... Would you be able to explain this to me?

Many thanks!

Jack

[DFGray]

You did not include your subVIs in your post, so I can't look at your code.  Please zip them up and post them.

Thanks.

[jcannon]

Do you mean the circular buffer subvi? I had to install this function from the link above into my "user library" and select like a normal function... Attached are all subvis that I have called (ingnire previous TMS5.vi and use the one attached here)..

Hopefully I zipped the right circular buffer bits...

Regards,

Jack

[DFGray]

My apologies for the late reply, things have been busy here...

You are currently doing only the first part of what you need to do - detecting the trigger.  After you detect the trigger, you still need to gather 2800 points before displaying them.  So you really have three stages - wait for trigger, trigger detected, fill buffer.  You are doing the first two, but not the last.

I would recommend you change the simple boolean you have going into the case statement to an enum with these three values.  You will need to cache the value in a shift register, since it may take several iterations to fill the buffer.  You will also need to keep track of how far you are toward filling the buffer (again in a shift register), so you know when to transition from filling the buffer to displaying it and waiting on a trigger again.  Note that this will mean moving the trigger detection into the case statement, since you don't need to check for trigger while you are filling the buffer.  The output of the trigger will determine whether your next iteration is "wait for trigger" or "fill buffer".

Keep at it.  You are very close.

[jcannon]

Thanks... I will keep working in it...

Whilst waiting for your reply, I tried to tidy up the vi by clustering wires and using event structures whereever possible... However, I am havibng trouble using an ecvent structures with my stop button in LOOP1 and save button in LOOP 4.

When the stop button is inside an event structure the vi runs without error, but the charts do not up-date or display data, yet the button will stop the vi...? I assume the event structuire is somehow affect the queues?

Regards,

Jack

[Yamaeda]

Slight misunderstanding of event structures, and quite typical the first times. The event structure will wait until an event happens or it timeouts. This means the top loop will only run once and then wait for a stop button press.

The solution is simple, add a timeout value and place the other code in there, then it'll run every timeout (which can be 0 or 1 if you want it fast) and the stop button will stop the loop.

/Y

[DFGray]

You don't need an event structure around the stop button in loop 1.  Simply remove it, leaving the stop button behind.  While some folks like to do it, I consider more than one event structure per VI poor design.  If you want your stop button in an event structure, put it in loop 5.  This will necessitate getting the stop information back up to loop 1.  You can do this by converting loop one to a queue driven state machine.  This will involve a fair amount of rework and really will not get you a whole lot you do not already have, unless you are looking for an industrial level flexible, extensible solution.  We can guide you through this conversion if you are interested.  Eventually, you should learn about state machines.

[jcannon]

Hi DFGray,

I have not had any luck with the circular buffer; however, I managed to get the trigger and gate working and doing what I need... Over the last couple of week I have been using the instrument and adding the extra controls needed to make the instrument fully operational... One thing I do need is a strain feedback display on a separate monitor... Took some fideling, but now I have the front panel covering two screens...One for the person controlling the instrument and another person being tested...

After all the work I/we have done, there is a somewhat small problem in the strain feedback indicators that I can't work out; how to stop a max value indicator from being responsive to new input data for about 2 seconds when a short lasting condition (~1ms) is met; then become responsivle again without being reinitialized...??

I have tried using timers, waits, case structures, and other means to no avail.. Any chance you could help me out?

Regards,

Jack

[jcannon]

Sorry... Forgot to mention the max indicator problem is in loop 4.... Also, I still need to add a loop just for the UI controls... But how do I send information about when each control changes value? I assume a via queue or notifier? So that would mean a separate queue/notifer for each control? That would be a lot of queues? What would you suggestion.

Thanks for your feedback... Greatly appreciated as always.

Regards,

Jack

[Yamaeda]

You can add a command enum to your queue which would allow you to consume all in 1 queue/consumer. Then you can get the Command -> case -> unbundle/convert to perform the action.

/Y