Actor Framework Discussions

Showing results for 
Search instead for 
Did you mean: 

Implement Model-View-Controller with AF on CompactRIO

Go to solution

Hi Guys,


Currently, I am working on a big cRIO project. I have already created separate actors for logging, hardware I/O, and other devices with serial communication, they are working fine. If I would run the whole project on a single device, the AF tree would look like something like this (following Tom McQuillan Subpanel Actor Framework tutorial):


Note that the Devices in my system will increase, so the actor tree will grow over time.

But I would like to detach the UI actors from the cRIO and run them separately on a PC, using Network endpoint actors. I see two ways to do that:

1. Use only one Network endpoint

- Messaging would change significantly

- Actor tree would remain a tree ✔️



2. Use as many Network Endpoint as many device (with UI) I have

- Messaging would nearly remain as it is ✔️

- Basically there would be a circle in the actor tree

- The Root Actor on the PC could be the main UI as well. It would just launch the individual UI actors as needed.




What is the most preferred way to implement this? Is there anyithing that I missed?






0 Kudos
Message 1 of 6

No comment on the "most preferred" way, but here are some considerations.


You're splitting one program into two separate programs, so there's no concern of preserving vs. looping the actor tree. You have two independent actor trees, and you need to create an API between them.


In your first approach, there's a single point-of-failure/bottleneck. If one cRIO actor floods the link, your whole GUI will lag.


In your second approach, all your hardware loops become responsible for maintaining network status and reconnecting. Maybe that's good (eliminates single-point-of-failure above). Maybe that's bad (possibly affects the operation of Business Logic despite no change to the hardware).


I don't love your original single-app structure to be honest. It works for simple stuff, but prevents GUIs that combine information from different instruments, and your Model needs to know about one specific Nested GUI.


I just watched Tom's video and I think he was proposing something a bit different than what you ended up with. His Chat Window Model is not analogous to your device models. I think Chat Window Model and Chat Window Interface is an extra abstraction so that he can easily swap out Chat Window Interface (2) while keeping all the logic identical in Chat Window Model. They're two halves of one GUI. But the diagram you showed has one whole hardware actor feeding into one whole GUI actor. I hope that explanation makes sense...

0 Kudos
Message 2 of 6
Accepted by topic author

Aside from the considerations OneOfTheDans already wrote about, I'd probably lean toward option 2 simply for ease of development. With option 1, every node/actor along the Msg route needs to be able to handle/duplicate the UI Msgs that your Hardware and Serial Device actors send out. In some cases this may be preferable (so that you can potentially modify the message along the way), but in suspect that you weren't doing this since the UI actors were being launched directly by said actors. Even if you're using interfaces, if you add more actors to your tree, you need to at least create more overrides at each node along the way. YMMV depending on how you were planning on treating the Msgs along their route.

0 Kudos
Message 3 of 6
(1,346 Views) wrote:


What is the most preferred way to implement this? Is there anything that I missed?



There is also this possibility, three independant PC UI applications that connect to your Business-logic App.  This maps directly on your original design.  You could compine the three UI pieces in a single App, with a light-weight "Root Actor" that only serves to launch the three parts, but doesn't really do anything else.

Actor Remote.png

0 Kudos
Message 4 of 6

Yep, my second option would be that case. Your figure is nicer and more expressive than mine 🙂 


After considering the pros and cons, I decided to proceed with option 2. In that case, I can stick nearly to the original setup. What is more, I could do an upgrade in my application in the future, and choose between remote or embedded UI with a switch.



0 Kudos
Message 5 of 6

Thanks ChatGPT, we'll get right on it!

0 Kudos
Message 6 of 6