burd

Sure I'm still answering questions. And I will still do bugg fixes and add new feature in my local copy and publish them on the forum.

Hi Michael!

It is great that you can still help the community.

thank you

No sorry, it still don't rename the class controls/indicators.

 

I suggest you change the names to Object In/Out or Reference In/Out on all you classes so you don't have to rename the label when you clone/rename the class.

 

 

Regarding the crash, I've only seen a few crashes myself, but I do get it to hang from time to time (i.e. never finish the clone operation).

But after restarting LV it works again without any problem.

 

But I’ll test your idea of changing application and having many VIs open to see if that could cause the crash.

//Mike

We have released GOOP Development Suite 4.7

 

The main things are: 

[*]LabVIEW 2013 support

[*]The creation of Property Node methods.

[*]UML Modeller fixes for analysing Actor Framework classes

Download it from www.symbio.com/goop

...or here:

GDS 4.7 LV2010

GDS 4.7 LV2010-64

GDS 4.7 LV2011

GDS 4.7 LV2011-64

GDS 4.7 LV2012

GDS 4.7 LV2012-64

GDS 4.7 LV2013

GDS 4.7 LV2013-64

 

And here are some videos:

GDS(4.5) Features Video

Other Videos

 

Contatct goop@symbio.com for questions.

Thanks,

Lars Persson and Mikael Holmström

Symbio Sweden  

Hello Michael,

Are you going to continue supporting GOOP now that NI bought it? Are you still answering questions?

thanks

Helcio

There was some minor modifications to the VIP files, and here follow it attached:

Goop Timer 3.vip

Hi Helcio

You are getting closer and closer ;-)

Everything looks good, but when you like to update the Number Of Timers that you store in the class attribute.

Make sure you do that inside the same IPE structure.

So do it something like this.

IPE.png

 

And also, you don't need (and shouldn't), wire the Class Ref input to the Create method.

This input is only used by the framework when you inherit a base class.

Try to create an extended Timer and inherit it from your Timer class

Hello Mikael,

I have modified the example as you suggested:

and also created 2 extended classes to observe how the Create Class Method behaves for an extended object:

And in example 3 are the extended classes at work:

follow attached the files:

hb_lib_goop_timer-1.0.0.4.vip

Please, let me know if those procedures are fine,

thanks again for your help!

Helcio

Hello Mikael,

I redone the timer based on the advices you gave me: Everything is now by ref, and the class atributes design pattern was apllied.

Now the attribute is updated when the opject is created like this:

Now it works,and  the class attributes design pattern woks like magic. Now I have similar functionality to static variables in java (I think). If you can check and see if everything is really fine would be nice.

Follow attached the package with the vis.

Timer GOOP 2.vip

Thank you for the help!

Helcio

Hello Mikael,
I am sending the timer goop.vip file attached. In this example there is a class called timer created with the GDS,
I do not know why the attribute "Number of Timers in Memory" is not being updated the way I think it should work. I would expect that when the class is created, this attribute is updated and somehow kept in memory, so that another object of the same class type can access and modify it.

In the example sent, why the attribute  Number of timers in memory (in the Example 1.vi and Example 2.vi ) are always resulting in 1? I would expect this value to be the total number of timer objects created, and in this case it is certainly more than 1.

thanks

Helcio

Timer GOOP.vip

You’re right the interface isn't created, and that's because LabVIEW don't support Interface natively.

Maybe a normal inheritance association will work for you.

If not, there are ways of creating interfaces.

 

I have a Design pattern, add-on you can add to a class to let it Implement an Interface class.

But in your case just normal Inheritance might work just fine.

 

Let me know how it goes.

Cheers,

Mike

Hi Mikael

I believe that using the GOOP 4.5 Interface template I was able to build the strategy pattern. Please, give a look and let me know. 

The goop 4.5 provides a easy way to build an interface. I tried other methods before like the Interface Framework but I found it far too cumbersome.

I am more confident to work with OOP in Labview because I know that at least I have the interface support from Endevo GOOP (Why does't NI provide interface support????). I can live without constructors, but without interface I don't think I can.

thanks for the tips!

Helcio

Simuduck.zip

Looks great! I am looking forward to testing this out with some Actor Framework projects.

Hi Michael,

GOOP 4.5 is great, but due to my ignorance it is hard to take advantage of it.

I am trying to use the UML to generate all the classes needed to create a strategy pattern. From the picture attached (LAVA does not allow me to attach the UML  file) you can see what I am trying to do. However, when I generate the code, the interface does not seem to be created. There is no way to apply the Fly method in the FlyWithWings class to the MallardDuck class. Probably I am doing something wrong....could you give me a help with that?

Thanks

Helcio

Hi Justin,

I read your presentation. Unfortunately you may have forgoten to put the power supply presentation's example available for download. It is very hard to follow the example just by reading the power point presentation. Is there any chance you could put this example available for download? There is also another example in the power point presentation using LVx. Could you also make it available for download?

Thanks

Helcio

First, this is a great discussion. Keep it going! I just have a couple minor points of clarification to make.

Regarding the "state machine" terminology, it is absolutely true that the JKI State Machine is not a state machine in the strictest sense of the word. It's really more of a sequencer. For those of you who have seen JKI's LabVIEW User Group presentation on the JKI SM, you may remember that we usually point this out to head off exactly these discussions . I suppose you can call it a message handler, too, but we don't get hung up on the exact terminology. Besides, rightly or wrongly LabVIEW developers (especially beginning ones) think of a state machine as "a While Loop with an enum in a shift register, which drives a Case Structure." The JKI SM is string-based, but it looks a lot like what they're familiar with and so calling the JKI SM a state machine helps them understand it.

The other point I want to make (which might be sort of at odds with the "state machine" terminology issue), is that we don't just treat the JKI SM as a state machine. We use it like a fundamental building block for creating LabVIEW code. It's as much a first-class citizen in the language as a While Loop or a Case Structure, and it's the basis for other, more complicated designs. If you need to build a "real" state machine, you can absolutely do it using the JKI SM as a starting point. Or if you need separate loops for UI handling and asynchronous processing, each of those can be a JKI SM. Part of the reason we love the JKI SM so much is because of its scalability and flexibility.

FYI, I'm going to be doing a presentation at NIWeek 2010 with Nancy Hollenback (The G Team) and Norm Kirchner (NI) called "State Machine vs. State Machine," comparing two different SM designs (JKI's and one of Norm's) and discussing how each one approaches different design decisions. It's currently slated for Tuesday morning right after the first keynote, so if you're coming to NIWeek 2010 put it on your calendar .