Target VI stops before being commanded using shared variable

[Ben]

"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. "

Ditto that!

Ben 

Message Edited by Ben on 06-04-2007 09:00 AM

[RKT_Scientist]

Ben,

With all those credentials, your affirmation about SV's failings helps me grasp the level of difficulty I am dealing with. I don't like to spend a lot of time on a trival problem not knowing it's trival to begin with, but I also don't want to spend too much time stressing about something I thought should be easy. I am beginning to appreciate that this problem isn't just with me and will in fact take time and patience to resolve. Thanks again.

JD

[RKT_Scientist]

Ravens Fan,

Some bad news, I added the flat sequence to my code and got the exact same response I described earlier.

Keeping the SV library deployed on the RT target, every other run attempt of RT.vi fails, the boolean Stop automatically goes to a True state. Even though booleans default as False, and I've "initialized" the SV to False.

I'll patiently wait any feedback. Thanks

JD

[RKT_Scientist]

Ravens Fan,

Couldn't find my post edit link...hmm..Anywho.

While going over your post again, I forgot to incorporate your written comment (I just added what the picture showed) to create a third sequence at the end.

Welp, good news this time. It worked. Every run works correctly with your implementation. Now, again, I wonder if this is a required coding style for "successfully" running these network-published SVs?

Anywho, it works, which is good, but it doesn't give me satisfaction with being able to figure out the operation of the network-published SV. In particular, what is happening in the original code that would make those SVs automatically change states..Hmmmm..The quest continues.

Thanks again to everyone who has provided support on this thread

JD

[RavensFan]

I'm glad to hear that my comments were able to help you get it working.  I don't think it should have been necessary to add that third frame, but my thought process was that it would be a good idea to reset the shared variable in the library before the program ended.  As I understand it, the library will remain deployed and hold the last written value until it is either undeployed, or you shut down the system.  I would have thought that resetting it to false at the beginning of the next run would have been fine.  But, ......

I see a lot of promise in the shared variable concept.  I had just started learning about the tag engine with the DSC module in 7.1, when the shared variable concept completely rewrote everything.  I've seen the problems with the slow startup of SV's on a cFP as I pointed out in the links in the earlier post.  I've seen delays of several minutes on the first run to get the shared variables updated when I am only dealing with perhaps 1 or 2 dozen SV's on the cFP.  I haven't fully investigated the whole problem yet.  Once, they start operating, they work fine.  Even if I stop and restart.  The slow initial reading only occurs after a cold boot, and that is a lot of effort to try to troubleshoot.  I have some ideas to try to check that all variables are initialized and up and running before my code gets into the real operating stages.  But I haven't had time to try them out.

Besides those links, I haven't seen much conversation about the slow initialization of the variables.  I hope NI takes this seriously and can improve their performance in upcoming LV versions.  It can be quite dangerous when running a real machine if things start operating when some variables begin communicating, but other critical variables have not started communicating.

My system is a PXI machine as a user interface and not critical DAQ computer communicating control parameters to a cFP which is operating a test stand.  I am using shared variables so that commands such as start and stop can be transferred from one to the other.  This is basically one way communication, and I want to be sure that the command gets through and is read and isn't over written.  So if I have a variable called STOP.  It is single value only and is not queued.  I don't want to deal with buffer overruns or underruns and I only care that the most recent value gets through.  When the stop button on the front panel of my PXI machine with the user interface gets pressed will only write a TRUE value to the shared variable, it never writes the false.  (I don't want it to get rewritten back to false before the cFP has a chance to read it.)  Once the cFP reads the SV and sees it is True, it will execute its stop functions, and it is the only one to write to the SV to reset it back to FALSE.  It is my way of establishing a latching action between two different machines through the SV.