Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

RT 8.2 Project Wizard Problems

Hello All,
 
I am having some issues running the example in "Getting Started w/ the LabVIEW RT Module " Oct05. Every time I run the host.vi, after successfully deploying the target-multi rate-variables-fileIO.vi, I receive an error code:
 
1950679023 occurred at host-network-RT(separate).vi>NI_Variable_RT.lvlib: lvvar_RTSinglePointRead DBL.vi: 1.
 
(this occurs every time after the signal, on the host.vi Graph Chart, runs at a value of zero and the x-scale gets to 300) 
 
I then precede to press the "Continue" button on the error message about 20 times or so (because the error will pop up again and again) at which point the error message goes away and the sine wave signal begins to appear.
 
Another problem is, it seems that this " project template" that the RT wizard creates saves the three vi's included as different LV versions or something. Because I am constantly getting save messages pop up after deploying/running etc without having opened the block diagram or changed anything and even after just closing the Front Panels that the wizard displays automatically when finished completing the project. This discontinuity seems very odd to me based on experience with other tools and software I've used in the past. The host.vi and target-multi rate-variables-fileIO.vi pop up after the wizard is finished and they do not contain an "*" at the end of the file name on the Front Panel, however, the support-acquire data.vi does open up with an "*" at the end of the file name?? I know VI's are like "living" code that by just running them causes parameters to change that require a save but I am having a hard time wrapping my head around this one.
 
Final problem is, after getting through running the example successfully (well, besides the errors described above) while loaded only in the controllers memory I can never get the sine wave to work after building a stand alone application to run on the controller at startup. While running as a stand alone app I don't get the error message described above, but the host.vi chart only shows a flat line signal.
 
It's easy for me to get bogged down trying to sovle a small issue if I don't know it's just a small issue and should move on. Please help me move on to bigger better things. Thanks
 
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 1 of 10
(8,914 Views)
Hey JD,
    As for the first problem you are seeing, the host VI is losing communication with the shared variable engine running on the real-time system.  This could be caused by a number of things, such as firewall settings, network traffic, or the real-time application starving the processor. 
    The second issue is a little more confusing.  When you are asked to save the VI, there is a link to click that says "explain changes."  Could you please click that and tell me what changes it is reporting?  Thanks!!

Brian B
Account Manager
National Instruments
0 Kudos
Message 2 of 10
(8,895 Views)
Brian,
 
Thanks for the reply. Before submitting this post I did some previous trouble shooting on NI support regarding that error code and got the feeling it was network related. Like I mentioned the VI would eventually kick in after pressing "continue" a few times but I didn't know if this was acceptable behavior that I would have to learn to live with or if I could have learned something more in depth concerning that error. I am using the company PC networked directly to the PXI with Local Admin privileges and every conceivable NI utility and port checked under Windows Firewall exceptions. The RT app starving the processor is something I didn't think about but would find it hard to believe that NI would allow their wizard to create something like that? Anywho. If you have any tips/tricks regarding that first problem I would like to give them a try.
 
Here is the result of the second issue you asked me to delve into more:
1.) I follow the steps in the RT Module Getting Started guide (dated 2005 so could be out of date with the latest LV versions I'm using??) at which point the wizard automatically creates the project and also opens the target-multi rate-variables-fileIO.vi and host.vi Front Panels once finished.
2.) When I try to close the  target-multi rate-variables-fileIO.vi Front Panel I get the "save" dialog.
3.) I click a blue link in the dialog titled "list unsaved changes" and then the Explain Changes dialog pops up.
       - In the " VI List " column there is the subVI support-acquire data.vi 
       - Under the "Changes" box there are two items:
         A.)The VI was converted from a different version - Last saved w/ LV 8.2, has been converted 
              to 8.2.1
         B.) VI recompiled - Changes to the front panel data structure or block diagram data flow 
         causes LV to recompile the VI, generating new execution code.
4.) I then ignore the save changes and close the  target-multi rate-variables-fileIO.vi
5.) I close host.vi Front Panel, after it was created and opened automatically by the wizard, and I do not get prompted with the "save" dialog.
 
As I mentioned in the original post, both the target-multi rate-variables-fileIO.vi and host.vi do not contain an "*" at the end of the file name in the Front Panel but support-acquire data.vi does.
 
And my final problem, which wasn't handled in your reply, is that the host.vi only shows a flat zero signal on the Graph Chart when I create a stand alone app running on the RT controller at startup.
 
Thanks again Brian for your time on this.
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 3 of 10
(8,890 Views)

Well joy. Here we are a week later and no reply. I know it's probably not recommended for a novice to use LV RT but I am at least capable of following instructions and for the examples given in NI documentation to not work is getting pretty frustrating.

Anyway. I found a decent KB (Document ID: 3HUD6PUW, Report Date: 01/31/2005, Last Updated: 04/27/2007) that tries to help those having error 1950679023 problems like myself. I followed those steps exactly to add some more exceptions to my already very long list of Windows firewall exceptions to only be provided with the exact same error message. Now remember, I am just running the LV RT Module Getting Started example, which creates a simple project using the RT Wizard. This isn't a rocket science project we're talking about here.

So trouble shooting time. I ran some LV Example VIs that are not necessarily RT, like PXI-5404 clock and sin wave generators and NI-Scope VIs, provided real signals to the various hardware in my PXI and didn't have a problem (well duh, that's because those examples don't use shared variables. ahhh, ok). Those little experimentations got me excited enough to not want to throw the companies new $40k worth of hardware out my cube.

Welp, anymore enlightenment regarding the above is still of interest to me.

My other problem, regarding all the different save dialogs poping up every time I closed things, has now been accepted as just a nuisance. I am taking the stance that they have nothing to do with my overall problem of A.) Getting 1950679023 errors and B.) not getting the stand alone app example to work correctly. I now just press save every time asked to, since saving always seemed like good practice to me.

Thanks again for the 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 4 of 10
(8,762 Views)
Hey JD,
       So, the initial shared variable error that you were getting, 1950679023, could also come from the fact that the shared variable engine is not working correctly.  Make sure that the shared variable engine and shared variable client are installed on the real-time target.  Also, you can open the Variable Manager (Start>>Programs>>National Instruments>>Variable Manager) and see the deployed shared variables, both on your PC and the real time target.

       As for the startup application, we can check and see if it's actually running and the host VI isn't communicating correctly, or if the .rtexe just isn't running by using the Real-Time System Manager (RTSM).  In a LabVIEW Window, navigate to Tools>>Real-Time Module>>System Manager.  This will allow us to look at the VIs loaded into memory on the controller at any given time.  Note:  VI Server TCP must be enabled on the real time target in order to use RTSM.

     The issue with VIs recompiling is a strange one, and I'll need to look further into why it needs to be saved.  Once you save it, does it ask to be saved again the next time as well?


Brian B
Account Manager
National Instruments
0 Kudos
Message 5 of 10
(8,143 Views)
Brian,
 
Thanks for getting back with me. In the time since your last post I was able to learn a lot more about the Shared Variable (SV) system through trial and error and some help from the NI support tools. I posted a similar question (link below) that might help you see the direction I've been heading recently.
 
 
Getting to your recent comments, I was finally able to get the RT Project Wizard example to routinely work with the VI only loaded in the RT's memory. Out of about 10 runs I only saw the 1950679023 error once. So, what does that mean, I don't know. Again, could be from the experience I've been picking up since your last post. In any event, I am more comfortable with the SVs while running directly on the RTs memory.
 
Something I noticed is that the sine wave would take about a minute to show up on the Host.vi. This was probably a big part of the confusion from when I first started, since I was under the impression this SV system wouldn't have such a long delay, and would usually stop the VI after only seeing the flat line for about 30secs.
 
Now, regarding the stand alone application, I can not get the example to work at all. I keep getting a Deployment Error, " This VI is part of an RT Startup Application...." And there is a lot of interesting things related to that. For one, the instructions in the "Getting Started w/ LV RT Module " (Oct05), are contradictorily to some NI KBs I've found, most notably, Document ID: 3UCBHM8T, Report Date: 02/13/2006, Last Updated: 05/07/2007 and Document ID: 3V0H36XL, Report Date: 03/01/2006, Last Updated: 05/15/2006. The example in the "Getting Started" manual uses network-published SVs and yet does not at all instruct the user to do any of the things listed in the KBs referenced. Also, my Project Explorer window (including all the VIs created by the wizard) looks totally different, than the ones given in the manual, such as Figure 6 on page 14 and elsewhere. I've included links to all the files the wizard created for me after completing the steps given in the manual exactly.
 
 
Well I hope I've added useful information to this discussion. I look forward to hearing more from all who can help. 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
0 Kudos
Message 6 of 10
(8,050 Views)
Hey JD,
       I believe that I see where some of the confusion is coming from:  shared variable deployment.  Once you have deployed a shared variable, it will remain deployed unless you explicitly undeploy it.  The first KB that you reference talks about programmatically deploying shared variables from an executable.  This is not needed if you have already deployed them.  As for the second KB, it is talking about deploying a shared variable library to a real-time target which is already running a program.  Any deployment to the real-time target requires  you to stop any executables that are running on it currently.  This is the reason for the "this VI is part of a startup application" message you are seeing, apparently there is an executable already running on the real-time target.
      What kind of error handling have you implemented in the VIs?  If the error cluster is being passed all the way through the loop, the shared variable error should not pop up a dialog box.  Also, is this an error or a warning that appears every so often?  How is the host PC connected to the target, over a router or a cross-over cable?  The 1950679023 error could be caused by dropped packets in the network. 
       If your program runs as a VI, then it should run as an executable.  Take not, once you set the .rtexe as a startup, deploy it, and reboot the system, it will take some time for the application to actually start running.  The target has some boot-up time that must be taken into account.  By using the Variable Manager, you should be able to watch the shared variables and see when they are being written to.  I see no reason that the .rtexe would be unable to successfully use the shared variables. 
      Just a few minutes ago, I setup a simple test.  A VI on the RT target that contains a while loop executing every 100ms and writing its iteration count to a shared variable.  Then I created a host VI to read this shared variable every 100ms.  All has worked fine, even building both applications into executable versions.  Have faith JD, it will work!!  I want to help you out, so let me know where you're at now and we'll work on this more.


Brian B
Account Manager
National Instruments
0 Kudos
Message 7 of 10
(7,922 Views)
Brian,
 
Thanks for the feedback.
 
I think I had a Eureka moment from some of your thoughts. Now when I build an rtexe it does not necessarily embedd the SVs into it right? SVs and rtexe are two separate entities and as long as the SVs have been deployed to the RT controller, whether manually or programmatically, a rtexe that references them can access them at runtime? That might explain why the "Getting Started" guide didn't need to provide the information contained in the KBs I referenced, since from a previous step, the SVs had already been deployed to the RT and then stay so unless explicitly undeployed. I had originally assumed the act of building an application assembled all the required files including SVs.
 
My problem however is not that the rtexe isn't running or that the SVs have not been deployed. I have verified them using VM and RTSM. My problem is the Deployment Error I get when trying to run Host.vi. Since Host.vi is located under My Computer in the Project Explorer and doesn't have the option to deploy, your comment,  " Any deployment to the real-time target requires  you to stop any executables that are running on it currently. This is the reason for the "this VI is part of a startup application" message you are seeing ", doesn't make much sense for my particular problem. I get the Deployment Error when trying to run Host.vi, not deploy it. Now your comment "apparently there is an executable already running on the real-time target" is true. In fact it is the executable I want to run. It is the one created by following the instructions in the guide. I get to the step of rebooting the target and then clicking Run on the Host.vi. That is where I end. I appreciate your efforts in creating a test project and all, but I would encourage you to go through the example given in the " Getting Started " guide dated Oct05. This thread is about problems I am having automatically creating a project using NIs RT wizard, my concern is if there is something wrong with the wizard. Again, I pointed out that my Project Explorer screen shot looks nothing like the one given in the guide. The guide shows only 2 SVs created and both located under My Computer. Where as, when I create the same project using the wizard, I get 4 SVs and all are located under the Target. That is quite different and cause for investigation.
 
Also, since I submitted links to my code in the previous post you should have been able to see the error handling implemented. Further thought, this thread is discussing VIs automatically created by NIs wizard, so I assume you would be informed of what type of error handling that would be either way. I am confused by that comment. Is this latest response of yours based solely on that other thread I posted and linked earlier?? Now that I think about it, it seems like you responded soley to that other topic. Sorry if I added confusion by referencing that other topic of mine, but for this thread, I am interested in the problem of getting the stand alone application, created with the RT Project Wizard, to run.
 
Finally, my PC is connected directly to the RT controller using a standard 5E cable, not a cross over cable because the manual said this particular controller can perform that function in hardware.
 
Here are links to some screen shots of the errors related to the topics discussed in this thread.
 
 
Thanks again for the support. I know it can be a challenge to handle multiple problems in one discussion with out it getting confusing. I'll wait for further instructions if available.
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 10
(7,897 Views)
Hey JD,
        I apologize for the confusion, it does seem that the getting started guide has some incorrect documentation.  I realized this earlier in our conversation, but forgot to mention it.  We will work to correct these documentation problems in the future.
        As for your application, the problem you are having is due to the fact that the shared variables are on the target instead of My computer.  The library containing the variables is set to Autodeploy.  This means that whenever you run a VI containing one of those shared variables, it tries to redeploy the library.  Since the library is on the target, and your host VI contains the variables, running your host VI causes the library to be redeployed.  This deployment causes the target to attempt to stop the executable that is running on it, and pops up the message that you see.
        In order to fix this issue, there are two very easy solutions.  First, you can right-click the library and deselect "Autodeploy."  Second, you can drag the library from the target to My Computer, thereby removing the need to deploy the library to the RT target and stop the executable from running. 

Brian B
Account Manager
National Instruments
Message 9 of 10
(7,199 Views)
Boo-Yah! Brian,
 
I got it!! Very easy solution indeed. That is what I was worried about, spending way too much time for easy.
 
Removing autodeploy was the clincher. Ben recommended that as well for another problem I was having.
 
I left the SVs hosted on the target though, which my personal knowledge base says is fine and may be more beneficial in some cases. It is just hard and frustrating to trace down issues when the documentation one follows doesn't match the outcome of that documentation. I was getting confused by the very support I was using for help.
 
So, to CLOSE this thread, I was successful in getting the " Getting Started" guide example to work, both, in memory as a VI and also as a stand alone application that runs at startup. I was also able to get my own simple creation to work both in memory and as a stand alone application.
 
There are still minor nuances I have to get used to or better understand, but I believe I am now ready to forge ahead with my designs using SVs (more specifically network-published SVs).
 
Thanks again Brian for the help with this thread.
 
JD

Message Edited by RKT_Scientist on 06-05-2007 10:00 AM

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 10 of 10
(7,098 Views)