05-17-2007 01:11 PM
05-21-2007 12:12 PM
05-24-2007 08:01 AM
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
05-24-2007 02:02 PM
05-29-2007 02:59 PM
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
05-30-2007 01:38 PM
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
05-31-2007 04:52 PM
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
06-01-2007 02:08 PM
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
06-01-2007 11:07 PM - edited 06-01-2007 11:07 PM
Message Edited by Ravens Fan on 06-02-2007 12:10 AM
06-04-2007 08:54 AM
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