Need Help Buffering Shared Variables

[kehander]

I've been attempting to write a project that will send some parameters to a VI running on my PXI, acquire data through DAQmx, and send the data back to a VI on the Host PC.  I've attached the project to this message (saved in LV 8.2); I run it by first starting Fulcrum Read Data Trisample on the PXI and then starting Fulcrum Shell on the Host PC.

Everything works fine for one sweep, but shortly afterwards, somewhere in Fulcrum Read Data Communicator I get error -1950678981, "The shared variable client-side read buffer overflowed" (though I'm not sure where exactly) and the DAQmx tasks in the VI on the PXI start complaining that they're getting empty channel lists.

Increasing the time delays in Fulcrum Shell seems to make it work better, but I'd prefer that this program run efficiently and would rather not insert longer delays if I can avoid it.  It would seem I need to increase the size of the buffers, but which ones, and how large should I make it?  Should I make more of the variables RT FIFOs?

A couple of other questions:

I write the default values to all the variables at the start of Fulcrum Read Data Trisample, but how do I keep the Host PC VI from reading the zero value in Mean Array?  Is there some easy way to dispose of it?  Do I even need to write this default value at all?

And is there some easy way I can make the VIs on the Host PC automatically start the VI on the PXI?

(I hope I'm being sufficiently clear here; I've never tried to post my own code before.)

[NathanT]

kehander,
       First, please take a look here.  It is a link that talks about Shared Variables and the different ways that you can use them.  I looked over your code, but would like for you to isolate it down to the bare minimum that demonstrates the issue that you are trying to fix.  Also, it is a very good idea to limit the block diagram to one screen, this makes it easier for someone else to follow what your VI is doing.  I don't think that you need to write the default values to the shared variables.  I would recommend troubleshooting your application further to see where you are getting the -1950678981 error.  Have you tried using highlight execution?

As far as your last question, look here.  It talks about using VI server.  Let us know when you have reduced your code to the most simple example.

Thanks,

Nathan

[kehander]

Thank you for replying! I was unaware that my code was still overly verbose; while I can trim it down a little, the basic structure will still be the same in the end. I'll see what I can do, though.

It seems I neglected to mention that I used the Shared Variable Client - Server example as a basis.

As I mentioned, inserting delays into various parts of the program seems to solve the problem, so I would not expect it to behave the same way when using highlight execution (since that also slows down everything).

And VI Server appears to be what I was thinking of; I shall read up on it.

(If I may ask a second, related question: LabVIEW RT 7.1.1 added a fix that improved network performance, as described in http://zone.ni.com/devzone/cda/epd/p/id/2769 . This is automatically implemeneted in 8.2, right?)

[kehander]

Here we are; I don't think I can make it much smaller than this.  I shall keep this in mind when posting code in the future.

[kehander]

I hope I'm not trying to tackle too many issues for a single thread here, but it seems to me that VI Server cannot be used in this case.  Specifically, I've tried to implement this with Read Data Trisample, only to be informed that the VI is broken when I try to call it.

If I copy the VI to the PXI's hard drive, then the copy is no longer part of the project and can no longer access the same shared variables, even if I copy Fulcrum Variables.lvlib as well, right?

[NathanT]

kehander,
      It should be possible to reference the VI on your RT PXI.  I will try to find a good example for you and post it tomorrow when I answer your other questions.

Thanks,

Nathan

[kehander]

I've done some further analysis and have come to realize that my "Ready?" boolean should not be a buffer, since it is meant to store a single value indefinitely and is the cause of at least some cases of the read buffer overflow errors.  I'm still trying to figure out some of the other problems, though.

I notice in the Shared Variable Manager that Mean Array, Measurement Array, and Params are listed as having types of DBL Array, DBL Array, and Custom, respectively, but in the project their types are stated to be DBL Array, Custom, and I8 Array.  Is this behavior expected?

[NathanT]

Kehander,
       To avoid an overflow or underflow on your buffered shared variables, the average speed of the reads and average speed of the writes must be close to equal.  Look into how you can adjust the read or write speed to even things out.  The reason that putting delays in part of your code works is that it is slowing that part of the VI down.  Delays are not a bad thing, they allow the loop to go to "sleep" and allow other threads to use the processor.  This is especially important in RT systems.
      Did you have a chance to read all of Using the LabVIEW Shared Variable?  It is very informative.  Another good link is Deploying and Launching a Real-Time Application.  The part that is especially useful to you is the second method of launching the executable.  It uses VI server.  Read over it and let me know if you have any specific questions.
       Once deploying the VI to the PXI, it will still recognize the shared variables.  If you can run the VI from the project on the RT PXI, then you should not have any problems turning it into an executable, deploying it, and then launching it programmtically.  I see the difference in Variable data type labels that you wrote about and I would not worry about it as long as they are not having data type conflicts.

Take care,

NathanT

[kehander]

I am familiar with the first page of which you speak; I'm just not entirely certain how to apply it to my code.

After some experimenting, it seems to me that I really don't need buffering for anything, except maybe the Command variable. I think the major problem I've been having arises when the "Init" string gets overwritten with the "Data" string before the Read Data Trisample VI has a chance to read it (causing the DAQmx task to choke when it receives an empty task).

But buffering the Command variable doesn't seem to help either - that just makes the Init command come out of the buffer at inopportune times. I guess making sure there's a delay between sending the "Init" string and sending the "Data" string is the best way to get around this after all?

I'm still wondering about that zero value I mentioned in my first post. Is it necessary or even advisable to write that value when I start Read Data Trisample? And why doesn't it get overwritten with new data even when I turn buffering off?

As for your other suggestion, are you saying that in this case the only way I can automatically launch a VI like Read Data Trisample that contains shared variables is to compile it into an executable first?

If you have any suggestions at all, please do not hesitate to bring them up; it's been really frustrating trying to get to the bottom of all this, and I'm going nuts.

Message Edited by kehander on 10-04-2006 10:03 PM

[kehander]

I have experimented a little more and found that quite frequently, the Host PC reads the Mean Array shared variable before the PXI has a chance to write to it, which explains that spurious zero value (and also severely messes up the data I'm trying to collect).

Why does this happen?!  I set up the Ready boolean for the express purpose of keeping this from happening!  Is there a better way of keeping the Host PC from taking the reading before the PXI is ready?