LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Target VI stops before being commanded using shared variable

All,
 
I decided to post this in general since it deals mostly with shared variables however I am working with a RT target so feel free to move it to another forum.
 
I originally posted a problem I was having with the RT Module Getting Started example, regarding the 1950679023 error, and trouble shooting led me to create the simplest test project I could think of. (I know you all want a link to the VIs but my company does not allow me to access internet file sharing sites to upload data so bare with me.)
 
NOTE: This is NOT an RT project. Just deployed on an RT target.
 
In Project Explorer I have Host.vi under " My Computer " and Target.VI and 3 networked-published shared variables (call them A,B,C here for simplicity) with RT-FIFO checked, under my RT target.
 
Host.vi is a single while loop with a 0.5sec time delay express VI. The loop contains (along w/ the time delay) 1 numeric control wired to SV A, 1 numeric indicator wired to SV B, and finally a Stop button wired to SV C plus the conditional term (stop if True). SV A is configured as write, SV B as read, and SV C as write.
 
Target.vi is a single while loop with a 0.5sec time delay express VI. The loop contains (along w/ the time delay) a numeric add function wired to a constant double and SV A configured as read. Also, SV C is wired to the conditional term configured as read (stop if True). The VI adds the two numbers, one of which is controlled by the Host.vi using SV A, and sends the results to Host.vi using SV B until the Stop button is pressed on Host.vi and sent back to Target.vi using SV C.
 
I successfully ran this project (which included my always present 1950679023 error). Then changing no code but merely redeploying/running it again right after or through out the course of many other project deployments I get incorrect data on Host.vi. Basically sometimes it would work, sometimes it wouldn't; having changed NO code. First discovery was that Target.vi would automatically stop after running ~ 1sec since deploying/running on the target and before I could disconnect and open/run Host.vi. I then deployed/ran Target.vi with a probe on the wire between SV C and the conditional term and highlight execution running. After an average of 3 runs through the loop the SV C would automatically send out a True signal even though I never open/run Host.vi. How can shared variable C, which is write controlled by Host.vi, automatically change it's state like that when I never even open/run Host.vi?
 
Another interesting observation is, If I first open/run Host.vi and then deploy/run Target.vi, the program ALWAYS works. But those steps go against my limit understanding of running VIs with shared variables on a target, which I got from NI's RT Module Getting Started Guide? I am going to have a hard time developing anything useful with these shared variables if I can not get the LV RT Guide example and this simple VI working. Any help would be great.
 
Thanks
JD
 
P.S. I've noticed this error message a few times during deploying/running either the Host.vi or Target.vi. The error is not consistent; sometimes I see sometimes I don;t.:
error-2147220727 (Hex 0x80040309)
The client process cannot communicate with the configuration server process. If this problem persists please note the steps you performed that led to this error and contact technical support.
PXI-1045,PXI-8196 RT,PXI-4220 (slot 2),(2) PXI-6259 (slot 3 and 4),PXI-5152 (slot 5),PXI-2585 (slot 6),PXI-5404 (slot 7)
LV 8.2.1, RT 8.2, DAQmx 8.5, MAX 4.2, VISA 4.1,
Pharlap OS ver.12.0, PH_EXEC ver. 8.2
0 Kudos
Message 1 of 15
(11,710 Views)
Hello JD,
 
Are you initializing your shared variables outside of the loop or before trying to read them?  If not, this could definitely explain that you are seeing different results after your first run of the code.  I would definitely try initializing your variables and then testing your code again, as I believe all of these issues may be related to uninitialized shared variables.
 
Happy programming!
 
Janell R | applications engineer
0 Kudos
Message 2 of 15
(11,671 Views)

Two ideas come to mind (lacking code to review).

1) Is the library containing the shared variables on the host or on the target?

2) Have you unchecked "auto-deploy" and tried deploying manually before testing?

Trying to help,

Ben 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 15
(11,553 Views)
Thanks for the responses, (sorry this is going to be long)
 
- First question is how do you initialize a shared variable (SV)? I don't have the DSC module, which I know has an initial value parameter. The SV is configured as a read and doesn't have any inputs, so am I missing something on the way to initialize it? I know the boolean defaults to False, which is good for my application. Also, right clicking on the SV doesn't bring up any obvious solution? Help if I am lost. Also, all my code is inside the loop (both the RT.vi and Host.vi), nothing is outside the loop.
 
- I think I learned something through some trial and error. I made this test VI project even simpler by just having an incremental counter using shift registers inside the RT.vi while loop. The results of that counter are sent out, by way of a network-published SV, to the Host.vi. This network-published SV is located under the target within the Project Explorer. I temporarily got rid of the boolean SV, which was used to stop both the RT.vi and Host.vi. It was that boolean SV that gave me all the problems.
 
This new test VI works consistently (also as a stand alone application, which was a first for me). My thoughts are that the issues had something to do with not "completely" removing all previous run instances of the VI and associated SVs/library from the RTs memory. I think I was getting old buffer data or SV corruption when, on my first test VI, would re-run the RT.vi and have the boolean SV inexplicitly switch states from False to True, even though the write controlled instance on Host.vi wasn't even running. I now undeploy everything (and check the Variable Manager) to make sure I have a clean sheet when re-running the VI. Now that brings up a question, is undeploying the only, or proper, way to clear the RT's memory?
 
Anywho, I reintroduced the boolean SV into this new edition of the test project (read instance on RT.vi and write instance on Host.vi, while "hosted?" under the target in the Project Explorer) and everything works (although I still get that 1950679023 error once in a while when running for the first time). Meaning, I deploy the RT.vi then disconnect, then run the Host.vi and get valid data, then I press stop and both VI's stop. I then clear out the RT memory (I think all of it?) using undeploy and then repeat. Doing this I get consistent, valid results. If this seems like a learning experience for me please let me know, I don't want something to "work" just by accident. 
 
- To answer the second reply: 1) all the SVs where created under the target in the Project Explorer. Also, I have not unchecked auto-deploy or tried deploying manually, but will give it a try. That brings up a great point, most of NI's data on SVs is "technical specification" like and not very in depth for something so complex. I have not been able to find any "tips/tricks" or "best practices", like trying to deploy manually. Is it because SVs are still new?? Also, a frustrating thing is that NI's step by step tutorials treat SVs like they are simple and fool proof, but following their instructions to the T I get errors. They leave out all the little nuances of correctly working with SVs and so it creates a steeper learning curve.  Enough of my rant.
 
Thanks again for the responses and any more help to come.
 
JD
 
 
 
PXI-1045,PXI-8196 RT,PXI-4220 (slot 2),(2) PXI-6259 (slot 3 and 4),PXI-5152 (slot 5),PXI-2585 (slot 6),PXI-5404 (slot 7)
LV 8.2.1, RT 8.2, DAQmx 8.5, MAX 4.2, VISA 4.1,
Pharlap OS ver.12.0, PH_EXEC ver. 8.2
0 Kudos
Message 4 of 15
(11,538 Views)

Hope everyone had a wonderful Memorial weekend. And God Bless to all our Brave Men and Women who have, are, and will be providing the freedoms and liberties we, in every democracy around the globe, are very grateful to have.

Continued work on this project is verifying my belief that the problem dealt with the RT's last memory state. Specifically, for all you newbies, like myself, be forewarned that NI does not clean up your memory; just like Microsoft, C++, etc. You will have to make a consorted effort to clean up after yourselves. If I did not first remove the libraries stored on the RT, which include the shared variables of course, I would get bad/incorrect data from the SVs. Specifically, the boolean Stop button would automatically go to a True state without even opening the Host.vi that controlled it's value. Also, the counter function would start at the last good value in the RTFIFO buffer. Now I know that sounds obvious but for code development it is very tedious and time consuming at best to have to always "remove" the libraries before re-running code.

My RT stand alone application success was short lived by the way. I will pose that problem on a clean thread after completing some more research in NI support.

Thanks again for the help

JD

PXI-1045,PXI-8196 RT,PXI-4220 (slot 2),(2) PXI-6259 (slot 3 and 4),PXI-5152 (slot 5),PXI-2585 (slot 6),PXI-5404 (slot 7)
LV 8.2.1, RT 8.2, DAQmx 8.5, MAX 4.2, VISA 4.1,
Pharlap OS ver.12.0, PH_EXEC ver. 8.2
0 Kudos
Message 5 of 15
(10,312 Views)

Hi JD,

By initializing your shared variables, I meant to write a known value (like a false to the boolean) at the very beginning of your code - outside of the loop.  When shared variables are deployed, they are deployed forever - meaning that the next time you run the code, you will read the last value from the last time you ran the code.  That is why you always want to initialize (or write a known, beginning value) before reading a shared variable.

I think this would help you significantly - best of luck to you!

Janell R | applications engineer

Message 6 of 15
(10,106 Views)

Janell,

I know from NI's LV Basic 1&2 courses I've taken, that initializing things are very beneficial and lead to more efficient solutions. For this situation it just didn't come to me as obvious.

By the way, I was able to convince the IT department that using an online file storage site would not cause infections, well and of course I can't post proprietary data, but in any event I have real live code for everyone to chew on.

http://www.mediamax.com/rkt_scientist/Shared_Var

So the solution Janell provided worked great, except for one interesting caveat. After deploying/running and later stopping the RT.vi and Host.vi successfully, for the very first time (meaning first deployment of the SV Library into the RT's memory), the very next deploy/run of the RT.vi (SVs are still in memory) fails due to the Stop SV, which should default as False, outputting True. And then every run of RT.vi and Host.vi there after (never removing the SV Library from the RT's memory) works exactly as expected.

To add more twist to the saga, if, after that very first deploy/run ends, I open the RT.vi diagram for the second run attempt and have Highlight Execution on, the VI never fails, it works as expected with the default Stop SV values always being False. But remember, as mentioned earlier, RT.vi does fail during that second run, if I don't have Highlight Execution on. Oh, how I know this must read 🙂  Sorry everyone.

One more treat, if I just place a probe (no Highlight Execution this time) on the Stop SV and Function SV (the Function SV exhibits similar behavior to the Stop SV if I stop the Host.vi while the Data On boolean is True) in the RT.vi diagram, I will see those values automatically go True even though I have the SVs intialized outside the loop. And the RT.vi then fails because of that. Again, this only happens for that second run after the very first time I deploy all the VIs and SVs. Then, having never removed the SV Library from the RT memory and only rerunning the RT.vi and Host.vi, the project works perfectly every time there after (meaning runs three, four, etc...). Oh yeah, W E I R D..........

Well enough of that confusion, I am sure running the code will reveal its strangeness. Most likely situation is something isn't exactly right. Which brings up something of concern, how in the world am I going to be able to trust these SVs in a real world RT application if they exhibit such finicky behavior?

Thanks again for everyone's time.

JD

PXI-1045,PXI-8196 RT,PXI-4220 (slot 2),(2) PXI-6259 (slot 3 and 4),PXI-5152 (slot 5),PXI-2585 (slot 6),PXI-5404 (slot 7)
LV 8.2.1, RT 8.2, DAQmx 8.5, MAX 4.2, VISA 4.1,
Pharlap OS ver.12.0, PH_EXEC ver. 8.2
0 Kudos
Message 7 of 15
(10,028 Views)

REVISION TO POST ABOVE:

I was incorrect in stating that after failing to run on the second attempt the VIs would always run correctly thereafter. A fresher mind and more runs today shows the following:

1.) First attempt to deploy/run RT.vi and Host.vi works correctly

2.) Keeping both Front Panels open and keeping SVs in memory, the following attempt to run the RT.vi fails, meaning the RT.vi automatically stops. It seems to be getting the last state of those boolean SVs.

3.) Keeping both Front Panels open and keeping SVs in memory, this next attempt to run the RT.vi works correctly and so does the Host.vi.

4.) Repeat steps 2 through 4

JD

 

PXI-1045,PXI-8196 RT,PXI-4220 (slot 2),(2) PXI-6259 (slot 3 and 4),PXI-5152 (slot 5),PXI-2585 (slot 6),PXI-5404 (slot 7)
LV 8.2.1, RT 8.2, DAQmx 8.5, MAX 4.2, VISA 4.1,
Pharlap OS ver.12.0, PH_EXEC ver. 8.2
0 Kudos
Message 8 of 15
(9,823 Views)
Hello Rocket Scientist,
 
There may be a couple of explanations for what is going on.
 
1.  There have been some posts on slow updating of shared variables on real time compact Fieldpoint systems.  I have seen it happen myself.  I don't know whether the same situation would occur on real-time PXI systems.  Some links are Slow update of Shared Variables on FP-2015 and first acquisition very slow.
 
2.  In your RT VI, you are setting the variables to false to the left of your loop which you might think means they get executed first, but there is no guarantee of that.  It is possible that the execution gets into the loop and the stop variable is read as true before the code outside sets it to false.  Set up a flat sequence structure with the setting of the variables in the first frame, and the loop in the second frame.  This guarantees that all the variables get set before the loop starts.
 
3.  You may even want to set up a third frame after the loop that again sets the variables back to false.  Essentially, the program would clean up after itself before coming to an end.  This would allow the falses to remain in the shared variable library while they remain deployed even though no programs are running.
 
4.  This may not be the cause of the problem, but there seems to be some redundant programming.  (Although I realize this is a simplified example of your actual situation.)  You can eliminate the loop and everything inside the false case.  In the true case you can eliminate that loop and just leave the SV write.  Move the shift registers to the outer loop and wire it through both cases.  It just seems like keeping the code straight to stop an inner than outer loop could be a complication.

Message Edited by Ravens Fan on 06-02-2007 12:10 AM

Message 9 of 15
(9,720 Views)

Ravens Fan,

Thanks for those links and the example code. I'll wire that up later today and see how it goes. Now are you suggesting the example you gave is the only way to initialize SVs? I ask because my intent on creating this thread was to see why I was having problems with the SVs and to get a little more knowledge of the SVs operation. The code I created was the simplest I could think of for allowing me to carefully follow the SV concept. The code obviously doesn't do anything useful. It was odd to me how the boolean values set as a Read SV in the RT.vi would automatically turn True, when booleans default to False, and the Write SV for the boolean is wired in the Host.vi and wasn't even running. So far I've been frustrated with NI's promotion and support of the SV system as being some straight forward concept that should "just" work right out of the box. I now know it is a delicate and powerful tool, but lacking true user support details.

Thanks again,

JD

PXI-1045,PXI-8196 RT,PXI-4220 (slot 2),(2) PXI-6259 (slot 3 and 4),PXI-5152 (slot 5),PXI-2585 (slot 6),PXI-5404 (slot 7)
LV 8.2.1, RT 8.2, DAQmx 8.5, MAX 4.2, VISA 4.1,
Pharlap OS ver.12.0, PH_EXEC ver. 8.2
Message 10 of 15
(9,055 Views)