This is a VI Package to install the Message Maker, a scripting tool that creates message classes for actor class methods.
You need VI Package Manager to install this package.
You also need to install this support package FIRST.
[EDIT] Version 3 posted to fix a bug on non-Windows platforms.
[EDIT] Version 4 posted to improve behavior so that the actor classes are not locked at the end of the message creation.
[EDIT] Updated to be compatible with Actor Framework 3.0.6
You may experience a bug in the latest version of VIPM (vipm-2011.0.1) that causes VIPM to hang during the "Resolving Package Dependencies" step. The work-around is to install VIPM 2011.0.0.
See the discussion thread here on the JKI forums.
LVB wrote: You may experience a bug in the latest version of VIPM (vipm-2011.0.1) that causes VIPM to hang during the "Resolving Package Dependencies" step. The work-around is to install VIPM 2011.0.0.See the discussion thread here on the JKI forums.
No need to do that. I had the same problem but if you install the support package first, there are no issues.
Any instructions or videos on how to use the message maker?
1. Place your code in a project
2. From the Project Explorer Window go to Tools -> Message Maker -> Actor Framework Message Maker...
3. CTRL+Select the methods you want to create messages
4. Select "Build Selected"
Note: A VI inside of a virtual folder will not apper in the message maker tool. Work-around: put them in the "root" of your class temporarily to make the message .
Ok, that was a pretty significant usability bug. I was only seeing my classes. No methods were populating. I assumed it would just make messages for each public method of a selected actor which it didn't because it returned an error. The reason that no methods showed up is because I organize all my methods in virtual folders under my classes and the tool does not populate methods under virtual folders as you pointed out.
Thank you for the quick response and work-around.
> Note: A VI inside of a virtual folder will not apper in the message maker tool.
No one reported that one before! I just now tested it in the version of Message Maker that went out in the second beta of LV 2012 and it works fine there, so I'm assuming we fixed that bug at some point, perhaps without realizing it was ever broken.
Unfortunately I have not had much time to put 2012 through its paces. I have noticed a few issues with the public message maker tool:
1. Location where messages appear on disk and in the project is not obvious
2. Virtual Folder issue mentioned above
3. Message creation failures with auto-populating folders
AristosQueue wrote: > Note: A VI inside of a virtual folder will not apper in the message maker tool.No one reported that one before!
No one reported that one before!
Well, I only ran into it a few days ago when testing the AF, but I simply modified the MM to go recursively through all the child items of the class. I can post the VI if that will save some time, but since you already have it fixed in the next version, I assume it's not worth it.
I added the modifications I made to the original post (since you can't have attachments in comments) but that deleted the original attachment, so I reverted the document to the previous version.
I give up on fighting with the system. Just look here - https://decibel.ni.com/content/docs/DOC-17167/version/6
tst, I hate to make you more frustrated,but your link points back to this document.
Ignore the hyperlink, just use the actual URL. As part of its fight with me, the system seems to automatically take that link and fix it to point to the updated version of the document.
First of all, thank you for this useful tool, it helps me much in developing Actor messages!
So, when I create receive message (the normal messages designed with actor framework) it all good. But If I want to make send messages with zero coupling, as mentioned in this post https://decibel.ni.com/content/message/34600#34600 (look at the 5th reply) I still have a lot of work to do. I thought about making it automated with modifying your tool.
So, to make it clear, this would be the process for creating zero coupled send messages:
Create Message for override:
0. The User creates a Data Member Access VI, or similar to supply the next step a staring point. It should access the data the is to be sent with the message.
1. Create message class for the Actor just like Message Maker currently does, but change the message class constant to control and connect it to the connector pane as dynamic dispatch input. This will be the parent message, and both Do and Send will be overriden by the childs created later on.
2. Insert this message class control in the Actor's Private Data. (could be in separate cluster, to differentiate a bit form the other Private Datas)
3. Create Data Member Access VIs for Read and Write for this message class control.
4. Create a Message to Write this message class as the Message Maker currently does.
Create Message as a chid of the upper mentioned parent. (actually this will be called with dynamic dispatch when the original Actor wants to Send messages)
1. Let the user select the Parent Message and the Actor class that wants to receive this message (let's call it Receiver Actor later on).
2. Copy the Parent Message's Private Data (contained in a cluster, or so) in the Receiver Actor's Private Data.
3. Create Data Member Access VI in the Receiver Actor to Write the Data just copied to the Receiver Actor's Private Data.
4. Create a Message that calls the just created Data Member Access VI, has the same format as the Parent Message and inherits from it.
5. Open up the Data Member Access VI for Write to the User for editing. The User will have to modify this VI to make an action upon receiving the Message.
So, did you also think about it? If yes, are you already developing it? I just ask because if I have time, I may start to implement it, but if you already started it, it not worth to do it twice. (and I don't know if I will ever get time to do it...)
I hope everithing is clear and at least I gave some basic ideas.
We are not already developing it, but we have given it a lot of thought. Just haven't had time! 🙂
Before you start on it, wait a couple weeks... by mid-June, we should know whether or not we'll have the bandwidth to tackle this project in the short term or not. If you don't hear from us in two weeks, please post another message here to remind me.
Having said that... if you want to go ahead and put together a front panel that you think would be an effective revised UI for the message maker, please do so. Having an option of which type of message to create means we need more than the simple "build it" button that we have today.
Ok, I see. Hope you will return with a positive answer, and of course I will remind you if you forget.
As you just mentioned the front panel I started to have ideas, so if I can find a real good one, I will post it for sure.
So, I am here to remind you. The two weeks have already passed Do you know now what is the plan at NI about the Message Maker? That would be nice to have it from the official source
Regarding the FP, I thought of it a lot, and only could come up with an approximately good design. It is rather a basis to start a discussion about it.
I think the easiest would be if we could graphically edit the Messages between Actors. It's not the simplest UI regarding implementation, but rather more simple regarding usage:
So, one example:
- The Gray boxes represent Actors.
- The list in the actors is the list of Messages.
- Receive: The Message which has thin arrows pointing towards the Actor is "normal" usual message. This receives message from other Actors. This is already possible with the current MessageMaker.
- Send-Parent: The Message which has thick arrows pointing away from the Actor is a message for sending data. This sends message to other Actors. This is actualy an abstract method that will be the parent of all the Receive Messages (Send-Childs) associated with this SendMessage.
- Send-Child - and now read carefuly and correct me if I am wrong - this can be any Receive Message that has the same data type (connector pane) as the Send-Parent Message. The only thing necessary is to make Send-Child inherit from Send-Parent. This way this Receive Message still can be used as an Input Message, but also serves as the destination of the Messages sent by Send-Parent.
This concept makes it necessary to modify the current Message's connector pane to match the Send Message's con.pane. In my previous post I described how the new con.pane and contol could be created:
"1. Create message class for the Actor just like Message Maker currently does, but change the message class constant to control and connect it to the connector pane as dynamic dispatch input. This will be the parent message, and both Do and Send will be overriden by the childs created later on."
- Actor manipulation: Actors could be drag&dropped from the Project window(I mean d&d the class). Also could be added by right click menu on an empty part of the UI. Removed also by an option in right click menu, or so.
- Create Receive Message: Drag&Drop a Data member access VI on it's Actor (check if the Method is member of the Actor). The UI should ask if the User wants to make a Receive Message or Send-Parent Message. Do if User selects Receive Message.
- Create Send Message:
option1: Drag&Drop a Data member access VI on another Actor (call it ActorB). This should mean that we want ActorB to send Message to this Data member access VI, to the owner Actor of the Data member access VI (call it ActorA). So we create a Send-Parent in ActorB and create a Send-Child in ActorA. (The datatype of the meassage could be created in the ActorB's Private Data, or just use a simple control of the correct type- to be discussed)
- create Send-Parent: Drag&Drop a Data member access VI on it's Actor (check if the Method is member of the Actor). The UI should ask if the User wants to make a Receive Message or Send-Parent Message. Do if User selects Send-Parent Message.
- create Send-Child: Click on a Send-Parent, cursor starts to pull an arrow, click again on the destination (which should be a Receive Message), and the arrow should be drawn. The destination should be inherited from the Send-Parent. Check if the Send-Child and Send-Parent has the same data type. (If not, a new Send-Child could be created and opened up to let the user make the data conversion. But of cource this should be optional.)
So, I have further suggestions, like the creation of transmit messages, that transmit a Send Message (ActorA) through an ActorB to a Receive Message (ActorC), but leave it for later. I guess it's enough to discuss.
Some more GUI images:
An idea to let the GUI include arrows and items only to indicate where do we use the receive messages of other Actors. These are only decorations. All decorations are in RED:
And the representation of the idea to make "transmit" messages:
So, it's what I have in mind.
Please feel free to discuss, suggest, accept or deny
The plan has fallen apart. Long and short of it: Some people at NI still dream of doing the modifications to the Message Maker for zero coupling prior to NI Week 2012, but, honestly, it's an outside of work project at this point and I wouldn't bet on anyone actually working on it. If you've got the motivation to get started on it, go for it.
As for the UI you propose: A message is really only defined by its receiver, not its sender. The abstract message of the zero coupling solution doesn't have a receiver, but it really doesn't care about its sender either. My instinct is not get the sender involved in any way shape or form. Indeed, the only time the sender could even vaguely be considered to be involved in my mind is when you set the access scope of the message class to private in an owning library so only that actor can send that message. I would therefore not consider a UI that consists of mapping senders to receivers. The senders are irrelevant (and, in the case of the zero coupling solution, deliberately unknown).
Having said that, if you think that the UI is valuable as it stands, go ahead and build it. I might like it a lot once I have it to play with. 🙂
Sorry to not answer so long, but didn't do anything in this case. So, I just thought a bit about your comment and I have concerns...
AristosQueue wrote: The senders are irrelevant (and, in the case of the zero coupling solution, deliberately unknown).
The senders are irrelevant (and, in the case of the zero coupling solution, deliberately unknown).
You say that the senders are deliberately unknown in case of zero coupling? Maybe I am wrong, but I thought that the zero coupling is a good way to make a reusable actor-unit, so to pack all the messages it may send together with the actor. And of course there are no output messages in the actor framework, so these "output messages" are only preparations to define the datatype of the message, and to serve as a parent of another actor's real input messages.
Maybe we talk about two different concepts under the same expression "zero coupling"? please help me to see clear in this topic
I would be very pleased if would share your opinion about zero coupling and the topic I talk about in my comment. I ask because I am actually developing something and don't want to in the wrong direction too far.
The zero coupling solution does the following:
-- It introduces an abstract message class (XYZ Msg.lvclass) that the nested actor can send, but the class has no Do.vi method. This is packaged with the nested actor.
-- Each caller actor creates a concrete message class (Concrete1 XYZ Msg.lvclass) that inherits from XYZ Msg and implements the Do.vi for that specific caller actor.
-- When the caller actor is going to launch the nested actor, it gives the nested actor a copy of the particular concrete message class. The nested actor then sends that particular message object when it is ready to send the message home.
Does that match your understanding?
Yes, perfectly matches. Sorry to answer so late, but somehow I don't get notifications about new comments added to this Document.
By the way if I would get to know that I can use the source of the original message maker (in lv 2012) in my work (just as any other VI from the palette) than I would finally post the Message Maker that produces these kind of Zero Coupled messages.
The legal conversation has proceeded slowly. Let's dodge the whole question ... when you post your VIs, do not install over the existing Message Maker. Instead, install yours as an additional item and just call into the existing message maker for any subVIs you want to share. To do that, just declare that the 2011 Message Maker package file is a dependency of your package file... VIPM should detect "these VIs are in the other package" and leave them out of your package.
Yes, this will result in there being two entries in the Tools >> Options menu instead of just one, but it dodges the whole legal discussion.
Thanks for the creativity and willingness to help Unfortunately my case is not so straightforward as you think: I also modilified the GUI of the Message Maker which - as you probably know it - contains the whole state machine and variables. So I should either create a script that copies this VI and modifies it with scripting as I did by hand(as part of the installation) or - to stay on Earth - create a whole new GUI (and some other VIs are also slightly modified). I may do a whole new GUI later as I go on with development, but currently the version I have is useful, and I should use it to do my current project. So, I guess I will have to wait for the answer - or for my new GUI in the future, whichever happens first.
Argh. Fine. I'll go poke Legal again.
Is 220.127.116.11 the version of Message Maker that ships with LV2013?
No. The MM is unchanged from LV 2012.