burd

Hello James,

Since I started using the framework I started having trouble with the so called Infinite Reset of Death during shutting down of the application (executable). The cause of the problem is not the messenger library, and now there is a way to deal with this problem as explained here:

http://www.labviewcraftsmen.com/blog/not-so-infinite-reset-of-death

I used the methodology and it works very well! Now there is no more possibility for the resetting VI message that never goes away during shutting down of the application.

I hope users of the messenger framework find this useful.

On 2/22/2018 at 1:46 PM, Porter said:

I use a constant relative path for performance reasons. When I tried to do anything fancy with the path in mupLibPath, there was too much of a performance hit.

Porter,

Wouldn't the performance hit only be limited to the time period during the creation of the muParser if you use the solution which recursively look for the libmuparser-x32-lv.dll ?

I believe that it should not exist  performance hit after the creation of the muParser in the above case.

I would imagine that after the creation of the reference it won't be necessary to look again for the libmuparser-x32-lv.dll if one keeps the reference to the muParser opened.

Do you agree?

23 minutes ago, Porter said:

Make sure that the libmuparser-xxx-lv.dll is put in the same directory as the executable.

I figured out where the error was coming from,

The mupLibPath.vi is unable to find the correct location of the  libmuparser-xxx-lv.dll if it is not in the same directory as the executable. I fixed it by adding something more generic that will try to find recursively the .dll file within the folders of the project, so I do not have to worry about placing the .dll together with the executable (see picture). If someone likes the idea and want to use it, I put the VIP file that will allow to look recursively for files. I hope that this might be useful for someone,

thank you for the help!

helcio_lib_folder_utilities-1.0.0.6.vip

9 hours ago, ensegre said:

Did you add libmuparser-xxx-lv.dll to the project, and specified it in the Source Files/Always Included section of the build spec? Since the dll is called dynamically (see previous discussions), it is not automatically detected as dependency.

I added the libmuparser-x32-lv.dll to the project and then specified it in the source files/always included section in the build spec (see figure below). However I continue getting Error when I run the executable file. I am getting Error 7, file not found coming from muParser Vis (see below);

Any idea of what I could do to fix this?

Thanks

7 hours ago, ensegre said:

Did you add libmuparser-xxx-lv.dll to the project, and specified it in the Source Files/Always Included section of the build spec? Since the dll is called dynamically (see previous discussions), it is not automatically detected as dependency.

No, I did not do that. I will try!

Thank you so much for the information!

muParser is a great library, I was very sad that I would have to give it up, but now I am happy again!

I am having trouble when I building an executable that contains muparser Vis. The reference to it is getting deleted (Error 1556; LabVIEW:  The reference is invalid. This error might occur because the reference has been deleted.) even though the  application works fine in development mode.

Do I have to copy any DLL to the Data folder of the executable?

I am using labview 2017;

thanks

On 4/8/2017 at 3:15 PM, drjdpowell said:

Ah, so the issue is that an actor both replies with an error message, and publishes one.  One possible solution is to say that only one actor should “own" the error.  If actor_a asked actor_b to do something, and an error occurs, then actor_a is the one responsible for handling/reporting it.  You can do this by changing the error handling case to only publish the error message if their was no return address attached to the original request message.  Thus you Reply OR Notify, rather than Reply AND Notify, and there is only one error message.

Dr Powell,

How do I find out if  there is no return address attached to the original request message?

thanks

10 hours ago, drjdpowell said:

Did you send "Shutdown Actor"?   I don't use "Shutdown" as a command anymore, because it is sometimes used as a notification that something has shutdown.   "Macro: exit", BTW, come from the JKI Statemachine that I used to use as an actor message handler.

I got very confused because the VI Help for the Metronome Actor says that this actor accepts the Shutdown message (if I remember right)  and not Shutdown Actor message as you said. It is necessary to update this help menu if that is the case. For  creating help for vis, I usually use the VIHELPKS that I recommend for that, as it automates the boring process of creating help files.

Thanks for the information

Also that you for helping with the Issue#9, It is fine just to have the topmost actor as Re-entrant, if it is the only way to make everything work, though it is annoying indeed!

On 9/13/2017 at 10:12 AM, drjdpowell said:

I just confirmed I can build in 2017, no problem.   I suggest you try uninstalling then reinstalling Messenger Library using VIPM.  And try build options like "Use Fast File Format".

Hello Dr Powell,

I would like to thank you again for this great library. I use it in all my projects and I am very happy with the flexibility it brings to my work.

There are 2 weird small problems, though not really critical, that I found in the most recent version the Messenger Library:

Problem 1:

If you create a metronome Actor, the only way to shut it down is by sending a message Macro:Exit

If I send a message Shutdown to this Metronome, it won't shut down. This has been happening since version 1.8.3.82 (I started using this version).

Problem 2:

I am currently working in a project that uses the messenger library  1.8.3.82 then I did an upgrade for the messenger library to the version 1.9.2.90. After the upgrade (In Labview 2017), the project opens without any problem (no broken arrows). However, when I execute the main VI, none of the LAUNCH ACTOR work properly; There is a message saying to open the actor and see if the vi is able to execute but all the actors are fine, even the main actor (no broken arrows) . The only way to make it work again after the upgrade is by saving the main Actor (which does not need to be Re-entrant) as re-entrant and changing the the vi properties to shared clone in the VI Properties menu. After that everything works the same as 1.8.3.82

I hope these information help to improve the Messenger Library

Thank you!

mass compile errors.docx

I tried to login too, but no connection!

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.

GoopUtil.png

Hi Michael,

The ones you marked in red were the problem. Good to know that most of the utilities work for Goop4 classes!

Thank You!

Helcio

I'm working on it, you can try this solution, it looks likes it works in 2012 at least.

But I'm not sure if it should work, we better ask NI.

Make sure you convert the number string to U32, not I32 that is the default

RefCheckGoop4.png

Cheers,

Mike

Hello Mikael,

I wonder if the VIs in the GOOP Utility pallet work for GOOP4 classes in the version 1.0.37[37] which is the version I am currently using. I seems that it does not because I get errors when using them. Did you fix them so that they can work with GOOP 4 classes?

thanks

Helcio

Ok, I will check that!

thanks

It's nice that you like it.

Here is another example form the same book.

Design.png

Re: Design Patterns

Missing class

LogMessage.png

Try to install the VIPC file again (https://decibel.ni.com/content/message/75586#75586), something went wrong with the previous upload.  I updated it, now should be fine..

Hi Mikael,

I have completed the abstract factory pattern. I am sending attached for anyone to look and comment.

I realized that I actually do not need to know the reference to a class is empty. If the class wasn't instantiated, the abstract method  parent class executes (in the method toString in Pizza.class, the parent method of classes Sauce, Cheese, Dough, etc will be called in case these classes were not instantiated) resulting an empty string.

Would be nice to have the tool to know of the class was instantiated, but I prefer to wait until you to complete the Utilities for goop 4 classes, looks complicated.

The files are at https://decibel.ni.com/content/message/75586#75586 because they are too big to upload here.

regards

Helcio

Hi Mikael,

I have just read the post, thanks for the tip!

The GOOPUtil_IsValidReference.vi is exactly what I need but unfortunately I use Goop4 classes

Is there anything for goop4?

regards

Hi Mikael,

I am trying to build the abstract factory pattern with GOOP and I do not know how to check if an object reference is not empty in Labview.

In JAVA this was done like this:

How can I do this in labview?

To start, have a look at my solution for the same example :-)

StarbuzzCoffee.png

It looks like you just forgot to set the Cost VI to reentrant.

Reentrant.png

Hi Mikael,

Your solution is very elegant!

I liked that the create vis can be used also to put constructors in it:

and also I leked the way the class item icon in the  project explorer mirrors the class hierarchy:

blue for Beverage classes, red for condiment classes, frame for abstract classes and full for concrete classes:

Thanks a lot for the solution!

Helcio

Hi Mikael,

I am trying to build the Starbuzz example in the Head First: Design patterns using Goop. I have had partial success and this vi works:

However, something goes wrong when I want, for example, double soy or double mocha, etc.

Could you help me to figure out what is going on?

This is the project containing all classes and main vis: Decorator Patterm with GOOP.zip

Thank You!

Hi Mikael,

I built an observer pattern with Goop:

I basically followed the Weather Station example in the Head First: design Patterns:

I used the goop's interface template and the interface implement design pattern for the observers, but I think it would also work just fine using  abstract class for rather than the interface. Here follow the the files (Observer Pattern GOOP.zip) and If you or anybody else have any comments, please, let me know.

thanks

Hi Michael,

That makes  sense and everything works just fine now.

Thanks!

I did a quick example where the Duck class implements the FlyBehaviour like this (see attached file)

Interface1.png

 

But for the design you are looking for, I would implement it like this:

Interface2.png

This soution does everthing you want. Why Interface is used in the design you are looking at (page 22 in Head First esign Patterns), because Interface exists in Java :-)

Hi Mikael,

I have been scratching my head......

I have been looking further into the 1556 error in the Duck Main.vi (attached) which claims that the reference is not valid. But if I clear this error, everything works just fine, as the reference refers to an object which exists in memory and the reference seems, therefore, to be perfectly valid:

The error is generated just after it verifies if the reference is valid using the Not  a Number/Patch/Reference function. I looked in the Help for this function and it says cannot be used to check for the validity of refnums created by Goop Wizard:

 Is this a bug in Goop?

Thanks!

Helcio

Here is the

Duck3.zip

I did a quick example where the Duck class implements the FlyBehaviour like this (see attached file)

Interface1.png

 

But for the design you are looking for, I would implement it like this:

Interface2.png

This soution does everthing you want. Why Interface is used in the design you are looking at (page 22 in Head First esign Patterns), because Interface exists in Java :-)

Hi Mikael,

I am trying to do the second solution indicated in the picture Interface2.png:

The reference for the Duck class is invalid when the method PerformFly is executed, then I get the error 1556. How do I do this the right way?

Thanks

Helcio

Duck2.zip

I’m sure we’ll get interface sooner or later to LabVIEW, in the mean time we have to implement it ourselves in different ways.

Here a thread and one example I use: http://lavag.org/topic/10621-interface/

 

I’ve not documented the Interface class template and how to use it, that comes with GDS.

But here is a quick instruction, this design only makes sense to Referenced Objects.

 

I1.png

 

Add Interface Methods

I5.png

 

Create a Normal class that should implement the interface

I2.png

 

Add a design pattern: Interface

I3.png

 

This is what gets created

I4.png

I6.png

 

Interface.zip

 

Cheers,

Mike

Hello Mikael,

I tried to use the interface the way you described, but I am getting an error (invalid reference) and I cannot figure out how to fix this. Could you give me a help with that?

thanks

Helcio

GOOP DUCK.zip