Prev: non-LabVIEW look
Next: 6533 delay trigger
From: Tim C. on 5 Dec 2007 16:10
I have a CRIO application that uses the web server interface.  Everything was working good until I made a small bool indicator change.
 
From that point the web server would not update.  I know the FPGA and RT loops are running because I have them toggling
the User1 and FPGA LEDs.
 
I then added the run arrow and stop button to the VI and republished the web server page.
 
Now when I go to the web server the front panel is not updating (at first).
 
I then hit the run button and the front panel starts updating.  It will start and stop using the run and stop control.
 
Does anyone have any ideas on how I can get the webserver to update automatically?
 
Thanks in Advance
Tim C.
From: Kevin_H on 6 Dec 2007 18:40
Hey Tim,
 
Thank you for contacting National Instruments.  I am slightly confused with what you have going on here, so I want to clarify a few things.
 
You stated that you added a run button to the front panel, and your front panel does not update until you press this button.  Now I'm assuming you are expecting things to be updated before you press the run button?
 
How do you have this run button set up? Should you be seeing the front panel update before it is pressed?  I guess I am just a little confused on your setup, and what you are expecting to see when the Front Panel initially launches.
 
 
Regards,
 
Kevin H
From: Tim C. on 7 Dec 2007 10:10
To Clarify:
 
The Run Button is the Native LV Toolbar run button, it was simply turned on for runtime under the VI properties.
 
Problem Summary -  I made a major mistake and upgraded my dev package from 8.2.1 to 8.5 that cuased the following
1.  Application would run with no problems when it was deployed to the CRIO through the development package.
2.  When the user would access the CRIO via the web page the web page had two menus "Edit" and "Operate" that appeared, all menus and Toolbars had been disabled in the VI properties.
3.  Application was running on the hardware as indicated by the User1 and FPGA LEDS that were toggling via the running code.   I setup a write file function outside the right side of the RT loop.  This functions purpose is to write any error code and error source to a text file on the CRIO.  I had to do this to capture any errors because I could not get to the front panel to see the error cluster.  The only way the code is allowed to stop is if there is an error.  The error status signal was tied to the RT loop stop control.
4.  During my attempts to troubleshoot the web server I made MANY publications, each of which looked different, i.e. scroll bars would show up even though they were disabled,  Sometimes the webpage would appear to be floating above the web browser (hard to describe but basically the front panel was not posistioned were it was suppose to be).  Even though the pages would look different and none of which ever came out looking correct NONE of them would update unless the LV run button was visible in the toolbar and pressed.  Pressing the abort button would stop the web page from updating and pressing the run button would allow it to update again.
5.  During the early stages of troubleshooting errors were captured that pointed to a Property node in a native low level vi.  To correct this problem I had to delete the open FPGA ref and install a new one on the block diagram and point it to the ORIGINAL bit stream file,  Another word of caution is to ensure you VISA reference is pointing to the right resource AND saved as default value.  I also want to note that during this projects developement that there was a bug in LV that would not always be visible.  The bug is that the FPGA ref would would not flow into a Sub VI.  The work around was to create a Type def control and place it inside the Sub Vi then wire the upper level VI FPGA ref to the Type Def control of the Sub VI.  Again this would not always show up but would cause problems with the code if it was not wired like this.
Solution
The problem turne dout to be the RT VI that gets published.  It was corrupt.  It would run but would not allow the web server to access it properly.  I found this out by creating a small vi that used the same sub VIs and FPGA taget VI on a smaller scale.  It worked like a champ so I rebuilt the Host VI and it worked the firts time.
Note I was unable to get my error log to show up at c:\, I had to use C:\ni-rt  (on the CRIO platform)
lesson Learned
The simple answer here is NEVER upgrade your dev package in the middle of a time sensative project and if you feel compelled to do so make sure you have a complete backup.
 
Hope this info helps other FPGA / CRIO project developers
 
From: Tim C. on 7 Dec 2007 11:40
I need one more clarrification for my notes
 
When you are deploying a CRIO program what are the proper steps.  My situations is that I have multiple identical CRIO platforms.   I developed the code on a single platform, created the startup.rtexe files and index.html (htm) file.
 
My RT code CALLS the FPGA to startup (ie the FPGA code does not autostart with a power cycle)  The RT code also closes the FPGA code if there is an error and the application is shutdown.  I use this as part of my debug / error detection rutine.
 
I have downloaded the Target VI to the Flash memory and have placed the rt startup files and index.htm files into thier appropriate directories.  BUT when I power cycle the CRIO my application does not start.
 
My work around is to open the dev package and run the host VI 1 time which sends everything to the CRIO platform.  Once I have ran it one time the application works from a power cycle state.
 
Does anyone know why I have to perform the one time run from LV to get this to work?
 
Thanks in Advance
Tim C.
 | 
Pages: 1
Prev: non-LabVIEW look
Next: 6533 delay trigger