rebuilding project: how to handle type def /globals and local varibles

[BrainDrain]

Hi LabVIEW experts!

I urgently need some advice regarding a larger cRIO project. After updating LabVIEW 2012 to 2013 it seems that the shared variable lib got broken. However, I want to try to rebuild the project from scratch - but using the old code. Can I simply copy the old vis into the new project folder? How  to handle the global variables and the type definitions?

Luke

 Win7-PC with Labview 2013 SP1  connected to  cRIO 9022, cRIO 9114 Chassis (Virtex 5 LX50 FPGA) ;AO N I9263, AI NI 9215, DIO NI 9401

[christian_w]

To use the 'old' VI's shouldn't be a problem.

I suggest to

- (in the 'old' project) set names for all FPGA IO's to become independend from the current module position and save the FPGA VI's

- define a physical directory structure of your choice for each target (Host/RT/FPGA)

- use separate folders for typedef's

- import this structure to your new LabVIEW project by using the Add-->Folder(Snapshot ) option

- add names to the FPGA IO's in the new project

- define new build specifications ( optional copy the build spec lines form your old project file into the new project file )

Local variables are stored in a VI and Global variables are just VI's with a target scope (Host,RT,FPGA) so I can't see a problem here.

Typedef's can be used over targets and become dependencies. I use a common_typedef folder for referenced *.ctl files if a typedef file is not located under the targets typedef directory to clean the dependency.

I haven't seen a broken *.lvlib file so far but if so, you have to build it from scratch.

I prefer to set the project option --> Separate compiled code from new project items.

Hope it helps

Christian

[BrainDrain]

Hi Christian!

Many thanks for the fast reply. I will try as you have suggested, but I have two questions to your reply (probably quite stupid ones):

> (in the 'old' project) set names for all FPGA IO's to become independend from the current module position and save the FPGA VI's

       I don't understand this ...   1) What do you mean by "set names for all FPGA IO's". In the old project they had allready names assigned. Do I have to give them new names now?

                                                   2) When saving the FPGA vi, do I have to save it from the OldProject into the NewProject folder  - or do  simply copy it to the new position?

What would be to best place to "store" the globals in the project hierarchie; on the level of the host or the RT?

Best wishes,

Luke 

[christian_w]

I think it's a good practice not to use the default FPGA I/O name like Mod1/AI1 because the module position or the module model may change. So I use alias names i.e. TestpointSensorXyz. That improves the documentation too.

I would copy all VI's to a new physical structure. It's not a good idea to use one physical structure for different projects, so copy yes and use the FilesView to check bad links to the old project folder.

The globals have a target scope, so save the Host Globals to the host VI's and the RT Globals to the RT VI's. I have a global VI folder under each target (Host/RT/FPGA).

Again, I prefer a synchronized folder structure between project (virtual) and harddisk (physical). Check this by using the 'Show VI in Files view'

[BrainDrain]

Hi Christian!

Thanks again for the reply. I allready gave modules and channels appropriate names for reasons you named.

I will redesign the folder hierarchy, copy the files into the new project and rename the old proejct folder. This should break all links to  the old stuff...

Regarding the broken shared virable lib just a comment: In this project I started with designing and testing the FPGA, RT parts and the basic Host vis. It worked all fine and passed all test without any problems. The next developingstep was manly on the host part. However, after the update something went wrong and even the most basic vi did not work properly anymore. I nailed the problem down to communication problems between FPGA and RT. , I assumed that...  Going back to the FPGA data logger example worked fine, and therefore I assumed  the main problem arised from the shared lib library, because information is exchanged via this path. I might be wrong, but from a practial point of view it seems to the best solution to start over again ...

Best wishes,

Luke