Migrating from GOOP2 to modern

[Morgan McLeod]

I started a topic on the NI GOOP forums today about running out of memory when running the GOOP2 to GOOP3 conversion tool.   I pared back my ambitions and got it to finish.   However my code is all quite broken so I must not be taking the right approach.

 

Background:

We have been developing electronic test systems for radio astronomy receivers and their sub-assemblies since 2005.   We started on LabVIEW 7.1 and settled on 8.6.1 with Endevo GOOP 3.0.5 as the production development environment.   We did not want to change platforms until the project was through its construction phase.   Now it is in operations/maintenance phase and we must, for obvious reasons, move to Windows 7 and therefore a more modern LabVIEW environment.   We chose LV2013 as a recent standard to build on.

 

I have 20-30 classes which are shared infrastructure for the different test systems, plus dozens more which implement specific devices or measurement sequences.    So I am loathe to rewrite all of this from first principles.

 

Does anyone here have experience with upgrading this scale of project to the latest / best tools to run under LV2013?

 

What is the path of least resistance to get this done as painlessly as possible?

 

What are the gotchas I should look out for along the way?   

 

Are there good resources I may have overlooked to help me understand the underlying architectural changes?

 

I've been reading everythign I can find on this forum and the NI GOOP forum for the last few days but I'm still not clear what the implications for my code are with regard to, for example, GOOP2 object references becoming their GOOP3 equivalent.

 

I can add specific examples of what I've found broken if that will help.

 

Thanks so much for reading.

Edited January 30, 2015 by Morgan McLeod

[Morgan McLeod]

A quick follow-up for now:

 

The GOOP2 to GOOP3 conversion tool left a few things in an incorrect state.    All things I could correct most likely.    It failed to notice one parent-child relationship in the class hierarchy.  Also some of the NEW methods were not executable but I didn’t dig in to figure out exactly why.

 

However, the software framework I am porting relied upon some other tricky LabVIEW techniques, some of which also won’t port cleanly.   So I’m porting it using a “clean room†approach making new classes in GOOP4 and repackaging the existing code.   Also making some new design decisions to try to encapsulate the tricky bits better.

 

Specifically, the framework used Call By Reference pretty extensively.   The VIs which were called in this way were GOOP2 class members.   This doesn’t seem possible in LV OOP because you must use a strict type definition when loading and calling the VI.   I tried doing the same thing where the type def. was to the base class method but actually trying to load and run a derived-class member.   Unsurprisingly this did not work.   Instead I’m channeling all those calls through a dispatcher method declared in the base class and implemented in the derived.

 

It also makes heavy use of DataSockets for inter-module communication.   I’m going to try to retain that capability but encapsulate it behind a Publisher/Subscriber interface so that I can try other techniques without affecting the rest of the library.

 

Once I get the framework ported, it’s going to be a ton of work porting the actual applications, but it should be pretty cookbook and maybe I can partially automate it.   Deadline's still a month away!

 

I will show my work once I get further along.   This will look very familiar to at least one member here.   (Hi Mike!)

[Michael Aivaliotis]

Native LVOOP is Goop4? I haven't heard that term. Just checking.

[MikaelH]

Morgan, I converted the UML Modeller(>20 classes) from GOOP2 to GOOP3 using the conversion tool, but you are right it can’t convert everything automatically, I still had to do 20% manually.

You can always debug/fix the conversion  tool since all VIs are unlocked.

(LabVIEW 20XX\resource\Framework\Providers\Open_GDS\ClassProviders\Common\ConvertGoop2ToGoop3.vi)

 

If you have some sample classes in GOOP2, I can help you look into it.

I’m about to release a new version of OpenGDS.

In that version there is a new conversion tool that you got to try :-)

 

I most often use GOOP4 (DVR) now a days, but the biggest change I have to do in the design when going to GOOP4/DVRs, is that I can’t just read Attributes while someone has locked the access to the Attributes/DVR

That could be done in GOOP2/GOOP3. So when you have a class member SubVI that tries to read an attribute, and you place that inside a IPE structure that has locked the same object your code gets stuck, as you probably experienced.

 

//Mike

[Morgan McLeod]

That could be done in GOOP2/GOOP3. So when you have a class member SubVI that tries to read an attribute, and you place that inside a IPE structure that has locked the same object your code gets stuck, as you probably experienced.

 

 

I haven't run across that yet but I will keep watch for it.   So far I'm making my DVR locking sections as small as possible.   I'm thinking in some timing critical members I will have to hand-optimize by caching everything I need so I don't need to read the attributes at all.   Thankfully there are not very many of those.

Native LVOOP is Goop4? I haven't heard that term. Just checking.

 

I may not have my terminology all up to standard.   But GOOP4 is indeed implemented in terms of native LVOOP + Data Value References.

In that version there is a new conversion tool that you got to try :-)

Conversion.png

 

 

Oh Wow.   Like C++ or Python to LabVIEW?

[MikaelH]

Oh Wow.   Like C++ or Python to LabVIEW?

 

It supports java and c#, it's now available for testing: http://opengds.github.io/

Just click "Show untested versions".

Everything is Open Source, so have a look in the code if you want.

I've not had time to document it too much though :-(

(I even have a build for LV2015 Beta)

 

I've also added Interface classes (By VI Server calls), and I will create a video soon that shows how it works.

Remember that all features that the NI and Symbio version has, still exists in the OpenGDS version.

Have fun.

[ThomasGutzler]

I’m about to release a new version of OpenGDS.

In that version there is a new conversion tool that you got to try :-)

Conversion.png

 

Maybe you should mention that it doesn't actually convert the code - just the class structure. Unless you've added that feature in last weekend

[MikaelH]

You are right, it only creates the classes, attributes, methods (including the arguments and return values), data types such as enums and structs, so you have to do a little work yourself, but it does helps you out by adding this to the VI's block diagram:

 

[PaulV]

Mikael:

 

OpenGDS 1.0.27((Master):   SubVI  'LcString_XmlEnumToStringValue.vi' is missing when calling "Convert text based code to LabVIEW..."!

[MikaelH]

Thanks, I'll add it in tonight's build.

I've attached a 2014 version of it here:

LcString_XmlEnumToStringValue.vi

[MikaelH]

New OpenGDS build ready for testing:

http://opengds.github.io/

Just click "Show untested versions".

 

Or use these links:

www.holmstroms.eu/OpenGDS/OpenGDS_1.0.28(Master)_LV2012-32.zip

www.holmstroms.eu/OpenGDS/OpenGDS_1.0.28(Master)_LV2012-64.zip

www.holmstroms.eu/OpenGDS/OpenGDS_1.0.28(Master)_LV2013-32.zip

www.holmstroms.eu/OpenGDS/OpenGDS_1.0.28(Master)_LV2013-64.zip

www.holmstroms.eu/OpenGDS/OpenGDS_1.0.28(Master)_LV2014-32.zip

www.holmstroms.eu/OpenGDS/OpenGDS_1.0.28(Master)_LV2014-64.zip

www.holmstroms.eu/OpenGDS/OpenGDS_1.0.28(Master)_LV2015-32.zip