single-process shared variable with single-element fifo reads arbitrary values

[baslers]

Hello,

my real-time application features a motion control loop and a DAQ loop. Prior to the move, the start position is read once in the motion control loop and saved as a single-process shared variable with single-element fifo enabled (I want to save only the latest value). The start position is then read repeatedly in the DAQ loop and compared to the actual position. The motion is stopped in the DAQ loop when the difference between the start position and the actual position reaches a certain target displacement.

Now to my problem: the start position is read in the DAQ loop from the shared variable correctly in the first iteration after it has been written. Then it keeps reading some arbitrary value that I have no idea where it comes from. How can this happen?

I summarize: I write the start position only once and then read it many times to calculate the actual displacement...

Thanks in advance for any help! Kind regards,

baslers

[Wayne.C]

baslers,

I'm guessing that after you read the FIFO the first time, there is no data left in buffer to read the next time.  Arbitrary value is probably some default.  If you connect the error cluster to the read shared variable you should get some sort of error or warning if the FIFO buffer was empty when you tried to read it.

Why not read the Shared Variable once and store its value in shift register in the DAQ loop?

[Christian Mergl · Accepted solution]

Hey,

This is a strange behaviour, usually the variable should return the latest written value. Do you write the variable in another place of the code too? Did you debug the application?

What is the RT platform you are working on? LabVIEW Version?

I would suggest to use a "Functional Global Variable" and see if you still get this random values.

Christian 

[baslers]

Thanks for your suggestion, Christian!

As you proposed, I implemented the start position as a functional global variable instead of a shared variable. This solved the problem, and now I am getting the one value I want to save.

For your information regarding the original problem: I am using LabVIEW 8.6 and LVRT 8.6. When I was using the shared variable, I only wrote it in one instance.

Thanks again for the help!

baslers

[StevenA]

Hey baslers,

I'm wondering what version of LabVIEW and RT you are using?  Are you using Compact RIO?

I have had this problem before using LV 8.5 and a cRIO 9012 controller.  You have one infrequent writer and a very frequent reader with a single element RT FIFO shared variable.  I worked on this issue with the LV RT PSE and there was a patch that we installed in the cRIO controller to fix it.  I'm not at the computer right now where I have the details, but I was curious what versions you were using to see it was still an open issue.

As Christian said, this is strange behavior the RT FIFO variable (single element) should return the last value even if no new values are written. 

Steve

[baslers]

SteveA,

I am using LabVIEW 8.6 and LVRT 8.6 on a separate desktop system with a PCI-7344 motion controller and a PCI-6221 DAQ card. Does this give you any clues?

So you are saying this is a bug which was fixed with a patch in earlier LV versions? I didn't find any documentation on this...

Best regards,

baslers

[StevenA]

baslers,

Yes, I think this is a bug.  What I can't remember is if there was a specific fix.  This was a problem I was having on a system for a company that I no longer work for so I don't have the details on if there was a fix.  It sounds like LV 8.6 still has this issue.  What I do remember doing in that project was changing all my single element RT FIFO shared variables to regular RT FIFO API vi's.  That fixed my problem.  The single element RT FIFOs work fine, if you are both writing and reading to them regularly.  However, if in your case, you only write to them once and a while, I think there is an issue. 

In my case I had a single element boolean RT FIFO shared variable that may only be written to once a day.  However, every 2 - 4 hours I would get a spurious True value on the variable when I would read it.  It was being read every 20 ms in a Time critial loop.  This was a single reader single writer variable so I know there were no race conditions.  In addition, in the case where I  was writing to the variable, I was writing to more that one variable the exact same value.  However in only one (or the other) variables would I see the spurious value.  I have attached an image of the basic variable architecture where I saw the problem.

In this case very intermittently, one of the loops would stop, when no true value was ever written in the top loop.

Message Edited by StevenA on 01-14-2009 09:05 AM