Using Actors on RT and Desktop in the same project

[patrickpollock]

I'm working on a project that has both RT and desktop code. I've been using the Actor Framework on the desktop side for a while and it works great. I am adding some functionality to the RT code and am trying to use actors there as well. After I created an actor on the RT, I've had probems with the Actor Framework Message Maker. If I try to create a new message on the desktop side, the new message automatically is placed in the RT part of the project. This locks the actor on the desktop side because that actor exists on both the desktop and RT (I believe this is the reason for the lock: http://digital.ni.com/public.nsf/allkb/219A8BB7FD8EF0D9862571840053A5E9). Normally in when I use classes in a project, I just make sure that they only exist in one platform. In this case, the Actor Framework Message Maker automatically places the new message in the RT section, regardless of whether the actor is on the desktop or RT.

I attached an example project that demonstrates this problem. Just use the actor framework message maker to build a message from "Message1.vi". The new message will be created in the RT and "HostActor" will be locked. The message then needs to be moved to the desktop part of the project. Once the project is saved and restarted, "HostActor" will be unlocked.

Is there any way to avoid this?

Thanks,

Patrick

[Todd_Lesher]

There was an NI Week 2013 Presentation by Allen Smith: The Actor Framework in Distributed Systems.

I can't find the presentation, but the video is in Balla's ftp site in the LAVA forums. I think the system they described is related to this one:

https://decibel.ni.com/content/docs/DOC-30762

[CaseyLamers1]

I worked with Allen and that was my presentation that Todd inked to above.

I can't answer your question as to why it is creating the message on the RT target instead of on the Computer target.  I can tell you why it remains locked when you move it.  The class is in the Dependancies in the "Items in Memory" folder.  Closing the project clears that out.

My work flow avoids the issue you have.  I have separate projects for the Computer and the RT target.  Anything that needs to happen in both locations can be in both projects, but you can only have one project open at a time or the class/library will be locked.  Generally speaking I use an abstract parent class with dynamic dispatch methods that are also abstract.  Then I create concrete children for each target and override the DD methods for local implementation.

If you start using the Linked Network Actor (LNA) to send messages between targets then there is even more I can share, but we can do that in another thread if you need it.

Casey

[patrickpollock]

Todd,

Thanks, I found the presentation and just had a chance to watch it. Really fascinating! I'll need some time to digest it.

Casey,

Thanks for sharing your work. I've definitely realized that I need to separate the Computer and RT into two projects. I've been wanting to dive into LNAs so even without this issue with the message maker, it will still be necessary to have separate projects. Once I have time to explore LNAs, I'm sure I'll have many more questions.

Thanks for the help,

Patrick