MikaelH

Which one is giving you a problem?

The "IsValidReference" has been changed to support GOOP4, but some of the other should work.

The green once should probably work, but not the red ones.

Thanks, you are a champ.

CLA2014 or 2015, General NI Week Folder.. I can't find it :-(

The method appears to accept any valid object reference, so when I typecast the pane ref to a control ref, it appears to work. This, of course, comes with the usual warnings about typecasting references:

 

Example_VI.png

Great, I might dare to try this.

I have another scripting task I like to do.

I like to create a static Property node linked to the Pane, not a control.

The Invoke method to link a Front Panel item to the property node, only accepts a Control, and can't take a Pane-reference.

Is there another way?

Thomas is right, the flatten to string format was changed between LV 2013 and 2014.

To be backwards compatible you need to use flatten the string to the 7.x format in LV 2014 if you like to read that file/format in LV2013 or earlier.

This should only be needed if you want to go back to LV 7,x according to the documentation, but if you test it you'll see that there is a difference between 2014 and 2013

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

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

I've attached a 2014 version of it here:

LcString_XmlEnumToStringValue.vi

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:

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.

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

@Mikael: Basicly what you use is a name queue, am I correct? That's how you get the reference to another object. Thank you very much for your time building the example code

Since I'm using the GDS toolkit, it generates >95% of the code, so it took me less than 5 minutes to create this :-)

The singleton is storing the Object Reference(DVR) in a 1 element named queue.

The Actor/Active Object Process is also using named queues (based on the DVR Reference number) to store the mechanism to send data to and from the process.

The steps to create this with the GDS tool is:

1. Create the class: A as a DVR Singleton class
2. Add Design Pattern Active Object to the class.
3. Add a “Send Message To Process†method(RequestData.vi) to the class.
4. Modify the newly created VI/method
5. Modify the Process VI in the class to handle the message
6. Clone Class A to B
7. Modify the Process VI and RequestData.vi in the new class.
8. Create the Top level Main VI

//Mike

I would use referenced objects, maybe even singleton objects with an active process in each.

That is basically an actor, but a bit easier/more flexible, but maybe more dangerous if you don’t know what you are doing.

Something like this:Objects.zip

So now we know that reference based GOOP4/G# (the DVR type), only supports 2^20 objects.

So if you need reference based architecture, GOOP3 would work, since it's a functional global in the bottom.

It is much much slower but should work.

If there only was a ini-file key that you could change ;-)

Do you have a copy of: ni_tool_esf >= 2.3.0.24  as well?

I remember that we got a issues when using the TimeStamp datatype in combination with Conditional Index Tunnel and running the for loop in parallel.

But for LV2014, I haven't had any problems with the Conditional Index Tunnel.

You have to capture all "Value Change" Events yourself and save them ni the right order they come in.

We have created our own HTML reporting tool, it uses JQuery and JQPlot, so you can have plots that you can zoom into and right click export to xls functions.

The best part is that it's a single html file page, that means that any images gets embedded in it. We refer to some style sheets and js files located on a local server,

but then the file gets pretty big. Here is an report example.

20141219_080953_My Awesome Report_SN012334.html

Have you tried the Icon Editor that comes with GDS?

This VI gets loaded with LabVIEW and will open instantly.

(Tools->GOOP->Create VI Icon…)

If you have installed NI's GDS (http://sine.ni.com/nips/cds/view/p/lang/en/nid/209038)

You can find the IconEditor VI here:

LabVIEW 2013\resource\Framework\Providers\Symbio_GDS\EndevoProvider.llb\GDSIconEditor_CreateVIIcon.vi

Or if you download the OpenGDS (http://opengds.github.io/)

You can find the IconEditor here:

LabVIEW 20XX\resource\Framework\Providers\Open_GDS\ClassProviders\Common\IconEditor\GDSIconEditor_CreateVIIcon.vi

Also consider using Classes by reference for instruments.
Yes, I know that LabVIEW is a by value language, but also LabVIEW is a perfect langue to run this in parallel, and that can’t be done with instruments as by value objects, that’s why VISA, TCP/IP, DaqMx, Vision, are all by reference ;-)

This is something to start with.

RemoveCompiledCode.vi

Maybe that will solve my crash as well. I think I'll try that.

It can't be that much slower can it?!?

Maybe we need something like this always...

Cheers,

Mike

It's just a Project Item. And if you give it (or it has) a path, it's a Auto Populating folder

Ethernet might solve it, but maybe don't use VISA.

I tried it on the file: GOOP_Library.ini and it didn't work.

[Provider]
SupportedType={ABC740D6-F254-4BBC-5675-8858F35B820E}
IsPrimary=0
ItemInterfaceVI=..\Open_GDS\GOOP_Library_Item_Interface.vi
LicenseName=None
InterfaceVersion=1.0
Signature=N2JJ9X329XL9TBJR7XT9J2XRXBW7XCSN

The Value string is:

{ABC740D6-F254-4BBC-5675-8858F35B820E}0..\Open_GDS\GOOP_Library_Item_Interface.viNone1.0

But the Signature became: KXCB229B7CKCK9BRC5BC5SR7CC3J259R

I've added this feature in the latest OpenGDS(1.0.9).

I'm not sure about the user interface, any feedbacks on it would be great.

Cheers,

Mike