rebind variables

[WNM]

In the 2013 known issues, #128059 (  http://www.ni.com/white-paper/14490/en/#128059_by_Category  )  says "Workaround: Manually rebind the variables..." What does this mean? How does one manually bind or rebind shared or user-defined variables?   

For what it's worth, I'm trying to migrate an RT/FPGA project that was working fine under LabVIEW 2011 to LabVIEW 2013 and the shared and user-defined variables (UDVs) are giving me fits. It uses a cRIO-9024 and NI-9114 FPGA plus two NI-9144 EtherCATS and their FPGAs. The RT code would run fine within a development environment but refused to start when built into a startup executable. Just adding a diagram-disable structure to a block diagram around some of these variables and then enabling it would be enough to fix them so I eventually figured out that I could get the RT startup app working by forcing any VI with shared variables to recompile.  Now I'm finding that the FPGA code on the two EtherCATs acts like it is not running or else is refusing to work with the UDVs that are used to move data into or out of the FPGAs. For example, both FPGAs are supposed to report their respective EtherCAT's temperature back to the RT system as a fixed-point UDV number but all the RT system sees out of these UDVs is the value zero. This code worked fine under LV2011.  I'm at the point of grasping at straws and right now that means figuring out how to "rebind variables". But if anyone has other suggestions about how to fix or even troubleshoot this, I'd be happy to hear them.

[PedroMunoz]

Hi,

This workaround to me seems to refer to shared variables that are bound to I/O Servers and when it talks about manually rebinding them, it’s talking about either two things:

1. Manually rebind them to the I/O Server to which they are supposed to be bounded. Like it explained here:

http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/sv_binding_to_existing_sources/

“Complete the following steps to bind a shared variable to an existing data source….”

2. Or deleting the instances of the shared variables on the block diagrams and adding them back from the project explorer.

[WNM]

Thank you Pedro.  As none of my shared variables were network-published shared variables, it would seem that this does not apply to the problem I was having.

I have since gotten it all working again but it was not easy. In the interest of leaving myself and any others who might have a similar problem a reminder of what was done, here it is.

I took a project that was fully-functional under LV2011, made a copy and recompiled it under the latest & greatest 2013 versions of LV/RT/FPGA and tried to deploy the RT (as a VxWorks startup app to a cRIO-9024) and three bitfiles (one to a NI-9114 backplane and two to two NI-9144 EtherCATS). The RT code would run fine if deployed and run in development mode but would refuse to start as a startup app. 

I tried mass compiling -- it returned many "bad VI" errors but those "bad" VIs never did appear bad within the development environment. How can you fix something that's not visibly broken? 

I tried cache clearing. Because we use source-code control, we try to keep the compiled code separate from the sources; it did not help.

Finally I discovered that I could search for all VIs that contained shared (or user-defined) variable objects and wiggle something in each of those VIs so LV would see the VI as having been changed, after the all the "changed" VIs were recompiled and the RT Startup app rebuilt and redeployed, it was no longer broken and it would run as a startup app.

I thought that everything was fine until I noticed that the FPGA code that was supposed to be running on the two EtherCATS was not running (the code on the 9114/FPGA backplane never did have a problem; I guess it didn't get the memo to make this 2011-to-2013 upgrade as difficult as possible). For the EtherCAT code at one point I had all of the old code disabled and the minimum amount of new code added to blink the "FPGA" LED on each EtherCAT and still the code appeared dead when deployed.

At this point I made a copy of the 2013 project and, from this new copy, deleted the two EtherCAT devices. With them also went all their IO, user-defined variables and VIs. I then let LV automatically discover and add the two EtherCATS and their IO back into the project. At this point I quickly threw together another blink-the-LED code for the first EtherCAT and it worked!

After that it was just a matter of having both the old/bad and new/good 2013 projects open side-by-side so I could manually transfer (lots of cut and paste) all the custom module names, IO channel names and module settings from the old project to the new (a day’s worth of work).  I took a risk and moved the two EtherCAT-specific user-defined variable folders from the old project to the new by "drag and drop" and that seemed to have worked too. Then it was just a matter of adding back in the upper-level VIs for each EtherCAT FPGA and that got the EtherCATs running.

By this time the startup RT app was broken again. At least this time I knew how to fix it. Find the VIs with shared-variables, wiggle something to cause a recompile and then rebuild the app.

Now it is all up and running and acting "happy". A few more edits to various pieces of the system have been made without problems

This is the second time in about as many years where I have had to throw out and rebuild a project or portion of a project to overcome some internal corruption that has occurred. It seems to be THE way to fix problems like this (I have support-request responses saying as much). Given that “toss and rebuild” is the suggested fix, I find myself wishing that NI would provide a couple of tools to make the process go quicker.

First of all, I would like a tool that will automatically transfer the module names, IO-point names and module settings from an old project to a similarly-configured new project. It should also look at the user-defined variables in the old project and create similarly named, data-typed and configured UDVs in the new project.

Second, I would like a tool to compare two supposedly identical projects (old/corrupt  to  new/functional) to see what differences, if any exist between the two. Primarily I want to compare the names, data types and settings for all the modules and variables to be sure that the new/rebuilt project has been configured properly, but it would be exceptional if the comparison tool could look deeper and see where the differences were that caused one project to be corrupt while the other was not. Then NI might stand a chance at getting to the root of these messes and make them go away.

[Jesse_D]

I'm sorry to hear about the friction you encountered. 

I tried mass compiling -- it returned many "bad VI" errors but those "bad" VIs never did appear bad within the development environment. How can you fix something that's not visibly broken? 

Mass compile would be opening VIs in the RT application instance. If you were opening RT specific VIs I would expect there to be errors. I assume if you opened them in your project again you were opening them on the RT target, which fixed the issue the mass compiler saw.

Finally I discovered that I could search for all VIs that contained shared (or user-defined) variable objects and wiggle something in each of those VIs so LV would see the VI as having been changed, after the all the "changed" VIs were recompiled and the RT Startup app rebuilt and redeployed, it was no longer broken and it would run as a startup app.

This seems like something force recompile would fix for you. 

After that it was just a matter of having both the old/bad and new/good 2013 projects open side-by-side ...

I don't like the fact that you have to configure IOV etc just in the project, I have yet to find a more robust way however the .lvproj files are human readeable. You can just open both in a text editor and copy the appropriate sections to speed this up. 

First of all, I would like a tool that will automatically transfer the module names,

This would be a utility that could be created with VI server. I know some people have ventured into it on the forums. 

Second, I would like a tool to compare two supposedly identical projects (old/corrupt  to  new/functional) to see what differences

It would be interesting to do a diff of the two project files you have. If they are identical then the problem cannot lie with the project. 

[WNM]

I had thought that perhaps mass compile was not smart enough to open the VIs in their proper project context and that was what was causing the errors but in a response to a support request I had opened I was told "The Mass Compile Locates the Project File and then processes it and all files in the project first before continuing to other folders or files in the designated folder. The RT and FPGA VI's should not have a problem with the mass compile."  But it was interesting to note that in the earlier stages of this effort, after I had manually fixed the problems with the standalone RT app, just for grins (and after backing everything up) I cleared both object caches and then ran mass compile on the project folder again. I got the following, which was considerably better than before when there many "bad" VIs also listed.

#### Starting Mass Compile: Fri, Nov 15, 2013 1:00:10 PM

  Directory: "C:\AccuRev\LABS\th_arc\LABS_TH_ARC_Control_System_dev2_LT\nif\th_arc_control_system"

Insane object at FPHP+12732080, UID 10588, in "ARC T&H TypDefs.vi": {tdname } (0x4000): Type Definition (DDO )

insanities in FPHP of C:\AccuRev\LABS\th_arc\LABS_TH_ARC_Control_System_dev2_LT\nif\th_arc_control_system\src\Auxiliary VIs\ARC T&H TypDefs.vi

Insane object at FPHP+2EB519E8, UID 10588, in "Scissor Lift Diagnostic Host.vi": {tdname } (0x4000): Type Definition (DDO )

insanities in FPHP of C:\AccuRev\LABS\th_arc\LABS_TH_ARC_Control_System_dev2_LT\nif\th_arc_control_system\src\Auxiliary VIs\Scissor Lift Diagnostic Host.vi

#### Finished Mass Compile: Fri, Nov 15, 2013 1:01:32 PM

I then immediately repeat the mass compile, changing nothing but the log file name, then I get these results:

#### Starting Mass Compile: Fri, Nov 15, 2013 1:03:14 PM

  Directory: "C:\AccuRev\LABS\th_arc\LABS_TH_ARC_Control_System_dev2_LT\nif\th_arc_control_system"

#### Finished Mass Compile: Fri, Nov 15, 2013 1:03:31 PM

I find it a bit interesting that 1) manual compiles seem to work better than the mass compiles and 2) that the results from the mass compile got better if it is run more than once.

Yes I know about "force recompile" but I can never remember the keyboard shortcut and it is extremely easy, using the arrow keys, to wiggle a shared variable left & right one "pixel" after it is "found" before moving onto the next found VI with a shared variable.

That's good to know about the .lvproj files and the possibility of editing and moving data between them. I'll look into that.

As for comparing the .lvproj files, even for two that are fairly close in time, one that works and the other that does not, they show a great many differences (below). At some point I'll try to through make sure that the broken project file is configured exactly like a working project file and see what differences remain but I'm guessing there will still be quite a few given the great number of the seemingly randomly generated hex ID values present.