Advanced Message Maker - actual version

[David_Staab]

MikaelH wrote:

But of course GDS costs money, and the free community version only supports 20 classes in your project.

Considering every message is a class, and sometimes two (if it's "zero-coupled"), that might not even let you design a single Actor.

[MikaelH]

I know, I would like to change (or remove) this limitation completley, but it must come from the marketing department.

But you never know, some day it might even be free....

[komorbela]

Hi Jeannius,

I understand your concerns about compatibility. I wanted to develop AMM to be as transparent as possible. All I added to actor class was a child (called Extor) which adds identification capabilities to actors. When you launch an extor, the launcher sends an identification request to the actor and stores the ID in the actor's private data as well as return back the ID from the Launch Extor VI itself. The default way for identification is the actor core's clone number. (by the way that is customizable if you prefer other ways)

Why did I build the AMM on the Extor class?

Because it was unavoidable in some situations to identify the actor that sends a message. As soon as you have 2 instances of a sender actor, you have no way to differentiate between the messages sent by those, only if the message tells you who is the sender. So I made the ID sending built in, lightweight and fast (optimized heavily for speed).

What about compatibility?

As the actor framework gets updated, the Extors will automatically work, unless some compatibility breaking changes will be introduced, but it would break all the programs built with AF, not only the AMM.

If you have some extensions, a custom child of the Actor class, you just have to set that custom class as the parent of the Extor, and it will run as the original version.

[helcio]

Hi,

After I installed the Labview 2012 SP1, the advanced message maker stopped working and it does not say what the error is. Did you try it after installation of the SP1?

Helcio

[komorbela]

I know what the problem is (or at least am 95% sure ).

There is one component in the dependencies that adds a VI to a LabVIEW library in the LabVIEW installation folder. This VI makes the (otherwise protected) "property access VI" creation public. This way I can use it programmatically to create property access VIs for the Message Injection info stored in the Actor's Class's private data control.

I have tested this component for install - uninstall, and that worked fine. But I haven't thought of this scenario. Obviously the LabVIEW update "corrected" my modification the lvlib. Thank you for catching this bug!

Anyways, here is what you can do:

- Reinstall the whole AMM, if you have time for that.

- For a faster solution just reinstall(uninstall-install) this module. It is called NewAccessors Extension, and it modifies the "...\LabVIEW 2012\resource\Framework\Providers\LVClassLibrary\NewAccessors\MemberVICreation.lvlib"

I attach the component's vip to this post (if I can) and will also add it to the AMM's document page.

Update: I just checked and the AF Advanced MessageMaker is dependent on the NewAccessors Extension, so it will uninstall it as auto-dependency. So you will have to

uninstall the NewAccessors Extension

but install the NewAccessors Extension and the AF Advanced MessageMaker

As it adds a VI on install and removes the VI on uninstall to/from a lvlib, it may happen that the the VI is there, only not claimed by the library.

So, you may have problems with uninstalling the component.

In this case please check that the MemberVICreation.lvlib doesn't contain the "CreateBaseAccessor.vi". It should not be there and the library should be in a clean state. If you find the lvlib in this state (or modify it to happen to be in this state) it is safe to install the component.

It should solve the problem. Please let me know how it goes.

Message was edited by: komorbela

[David_Staab]

komorbela wrote:

There is one component in the dependencies that adds a VI to a LabVIEW library in the LabVIEW installation folder. This VI makes the (otherwise protected) "property access VI" creation public. This way I can use it programmatically to create property access VIs for the Message Injection info stored in the Actor's Class's private data control.

Messing with anything distributed by another vendor is generally bad behavior. Why not distribute and link to your own copy of the library or VI with whatever access permissions you need?

[komorbela]

Hi David,

Yes, you are right. I thought it's an easy way to solve the problem. Obviously it is not... I just did't think of this scenario. I will make an update that uses an own copy of this library.

[helcio]

Now it is working again.

thanks