Best practices for file I/O within producer/consumer loops

[jamoore84]

Here's the remaining enum for the AE tester

[jamoore84]

---

As it is right now, though, I have hit a snag with Recording

---

I think I solved the problem.   I had originally branched the Error line going to the  "Recording section" of the Consumer Loop off of the "playback section". I changed that section of the error line to be a Local Variable and now the  main graph updates and I can record files. (picture attached)

I'm not very clear on why this would be, though - could someone explain branching error lines vs. local varialbes? is it just because of the order in which these things are executed because they are on the same error line?

Now that  the previous error is cleared up, some other problems have asserted themselves:

1.  When I read in a file for playback, I want to view it at the same speed as if it were live, acquired data.  Will I need to specify a value at the count terminal of the "Read From Binary" File function to accomplish this incremental updating?

2. When the Read From Binary File function reaches the end of the recorded file, it issues an "end of file" record.  Is there any way I can suppress this?  It causes havoc due to how I have my Boolean control variables defined  off of the error line status.  Otherwise, is there  a better way to define these variables?

Thanks again,

Jimmy

[Ben]

HI Jimmy,

You are way ahead of me! (I have a real job and only answer Q durring breaks. Involved Q's require much longer breaks).

But while you are working away fixing things up I have two suggestions

1) Watch your code in execution highlighting mode.

2) At quick glance it almost seems you are not keeping the state info inside the AE but are still relying on locals. Don't reply on the button that triggers the command to record to tell you are recording, check the AE to see if you are recording. If the AE does not know when it is recording, then change it so it can remeber what state it is in so it can report its state properly.

Stepping back:

Try to use a mental model where the data is "in the SR" and the control and indciators only give you copies of what is inside the AE. As long as the "master copy" is only one place and that place is protected (like in an AE) you will not have race conditions. AS soon as you have to look more than one place you are stting yourself up fro trouble.

I'll still try to get back to this thread latter,

Ben

[Ray.R]

Don't mean to step into Ben's efforts..

... but I notice that you are using a Local of the Consumer Error to wire into the 2nd Case Structure at top right.

Since you are wiring the Waveform Chart data to the 2nd Case Structure which creates a data dependency at the output of the 1st Case Structure, then why not wire the Error Cluster directly?  There's no parallel execution..  And the added bonus is that you won't have to merge the error at the end.  Not to mention the fact that any error caught in the 1st Case Structure would be ignored by using the Local Variable (which is often a bad thing).

R

[Ray.R]

As shown below..

 

As a matter of fact, your next step would be to get rid of all Local Variables.   Of course, I have the reputation of hating and forbidding the use of Locals.  First day training within my organization is that Locals are forbidden.  Any such use results in immediate dismissal..  Not that I am extreme or anything 😉

Message Edited by Ray.R on 03-17-2009 01:19 PM

[jamoore84]

---

Ray.R wrote:

Don't mean to step into Ben's efforts..

---

Not that I can speak for Ben, but feel free to chime in if anyone notices smaller nagging issues.  save the hard stuff for ben 

---

why not wire the Error Cluster directly? 

---

Error routing is not my strong suit.  The original version of my test program had the top right case structurebranched off from the original error line, which was then merged, and that caused some problems.  I switched to locals and that seemed to fix it, though it introduced the vulnerabilities you mentioned.  I made the updates you suggested and it works and makes more sense.  Thanks!

jimmy

PS: i've attached the revised version of my tester 

[Ben]

Ray,

feel free to jump in anytime!

Jimmy,

You have skipped my design stepped as a result I really don't know what the req for this app are!

It almost likes like you want to record one file while playing back another at the same time. Is that correct? That Q makes a big differnce on how I proceed.

Could you define "Use Cases" for your tester please?

Ben

[jamoore84]

Apologies for being unclear,

My goal is to enable file recording and playback functionality in a program that already collects data.  In my test vi, the collected data is simulated by the random number generator and its queue.

I would like my user interaction to be such that they could record the collected data or choose to playback a previously  recorded file. Not both at the same time (at least not now). 

Also, there is no use in recording a file when it's playing back.  :

1. Program starts up with the option to select between recording data or playing back data (the Recording and Playback Start buttons are Enabled).  The collected data will stream regardless.  The record and playback "Stop" buttons should be disabled, since you cannot stop something before you have started it.

2. Clicking the Record Start button prompts the user to create a file and specify location to save.  If the file dialog box was not canceled, toggle the states of the Record Start, Stop buttons (disable Start, enable Stop), and set a flag to indicate the user intends on recording. (thats what the Record Boolean variable is currently used for).

3.  Clicking the Record Stop Button  toggles the button states again (Stop disabled, Start enabled), ceases file writing and closes the file.

        Note:  Could this be a point of contention - The order in whcih the writing stops and the file is actually closed?

4.  Clicking the Playback Start button prompts the user to locate a file to read from.  If the file dialog box was not canceled, toggle the states of the Playback Start, Stop buttons (disable Start, enable Stop), and set a flag to indicate the user intends on playing back a file. (thats what the Playback status Boolean variable is currently used for).

5.  Clicking the Playback Stop Button  toggles the button states again (Stop disabled, Start enabled), ceases reading data from the file reference, and closes the file.

I think that fleshes out the core functionality I'm hoping to acheive.  There are certain things I do not want to have happen, like recording a file which is playing back, or playing back a file while recording, but that should easily be taken care of  by disabling/enabling the appropriate buttons at the appropriate times.  So long as the core recording and playback functionality work (recording seems too, playback seems to occur too fast), I should be good to go.

I hope this answers your question.

jimmy

[jamoore84]

---

 2) At quick glance it almost seems you are not keeping the state info inside the AE but are still relying on locals.

---

 As I've understood it in your example, I created an Action Engine with a state machine inside that I can place it at numerous locations within my main VI and call upon any one of its internal states to perform the action needed.  Any information I would need to accomplish  a state-specific action is wired to a terminal  on the subvI, the most important ones being the file refnums for recording and playback.

THe boolean locals I rely on to toggle the  playback/recording states within the consumer loop are leftovers from my orignal design method.  Would a better method be to provide output terminals for the recording and playback file refnums and then use the "Not A Number/Path/Refnum constant to determine whether these paths exist?  

---

If the AE does not know when it is recording, then change it so it can remeber what state it is in so it can report its state properly.

---

  If what I have programmed is valid, the shift registers of the AE should know when the reference exists after the "Record Start" and "Playback Start" AE cases.

---

Try to use a mental model where the data is "in the SR" and the control and indciators only give you copies of what is inside the AE. As long as the "master copy" is only one place and that place is protected (like in an AE) you will not have race conditions. AS soon as you have to look more than one place you are stting yourself up fro trouble.

---

What does the term "SR" stand for?  All the File IO functionaliy resides within the AE if that is what you mean.  The only non "master copy" of information that is not stored inside the AE would be the data piped in to be written to a file.  Let me know if I am on the right track or if I'm totally off in left field.  

I appreciate your patience,

Jimmy

[Ben]

SR = Shift register

See attached zip for a revised version. I added a "State" as a SR inside the AE that keeps track of what state the AE is in, Idle , Recording, Playing.

Notes:

I used a "trick" to get teh Ae to call itself in the Check case so it can invoke the playback state if it is playing mode.

Please note that the state is just showing what state the AE says it is in.

If it is playing back, and reaches the end of the file it will drop out of play back and go to idle. There is a bug in the sense that once the file replay is done the GUI shows that it is NOT palying (boolean extinguished) but the Stop Playback is still enabled.

THe code posted is not pretty! I just quick dropped my way to something that would help this discusion. Please clean-up the code.

Please watch the code in execution highlighting mode if you want to learn how it is working.

Post updated code if you make changes.

have fun!

Ben