Actor Framework and cRIO

[justACS]

Look at the example I referenced above (it was a reply to one of Fire's posts).

[CaseyLamers1 · Accepted solution]

Like niACS just mentioned, I think this is answered.

There is no way to only have AF.lvlib. You need an abstract child of Actor (call it Interface Actor) that defines the methods that you want on both sides (Host and Target(s)). The methods are abstract, but define the input.

As an example, I have a "Change Setpoint" method that the PC side forwards the message to the RT and the RT side sends component setpoints to hardware. So, the Interface Actor has a Change Setpoint method that is abstract and has a Setpoint input. Then the PC project contains Interface Actor and then a child of Interface Actor (UI Actor). UI Actor implements the Change Setpoint method by placing the setpoint data in a "Change Setpoint Msg" class and forwarding it to an LNA. Magic happens and the LNA on the RT receives the output from the network stream and builds it into a Change Setpoint Msg and forwards it to the RT side. The RT side has a child of Interface Actor (RT Actor). RT Actor implements Change Setpoint by sending setpoints to components.

You need 2 projects, on for the PC and one for the RT. Interface Actor is in both projects. I usually only have one project open at a time because Interface Actor will be locked.

Hope that helps. I can do a phone call if needed.

Casey

[StevenHowell_XOM]

The link doesnt work. I understand what you are both saying, but seeing an example in practice would be great.

[justACS]

That's because there's an extra "http" at the end; clealy a cut-and-paste error.  Anyway, here is the corrected link:

Actor Framework on CompactRIO (and Other RT Targets)

If the link doesn't work, just search for that title.

[CaseyLamers1]

I am working on a concise example for the community.

Casey

[CaseyLamers1]

Here is an example of an interface class with UI and RT children using the LNA. Saved for 2014 and 2015.

Casey

[StevenHowell_XOM]

Thank you Casey,

I am still a little bit confused. I see your tips on only adding the Actor Framework.lvlib to the RIO target, but is it possible to have both the RIO and Host in one project and do this? For simplicity's sake, we need to do this for our project, it is unrealistic to have 2 separate projects, as we would like to test before we deploy.

If you put the AF.lvlib in the RIO folder on the target, how do you create actors on the host? You would have to add the AF.lvlib to the host side to be able to create classes to inherit from AF and this locks the libraries.

I understand what you are saying about "proxy" actors on both sides....my question is, how to get the AF.lvlib into the project so that it doesnt lock....does it have to be in 2 separate projects? If so, this will be un-doable for us.

Could you import the AF.lvlib into the host side, then open the AF.lvlib, create a copy of it and rename it something like RIO AF.lvlib and drop that copy into the RIO side? Would that work? The locks are because of the library namespace correct? If you had 2 copies of the AF library in the project but different name spaces, would that work?

[CaseyLamers1]

Any class that is open in two locations will be locked. Unfortunately, having a class on two targets in the same project counts as being open in two locations.

If you want a single project then you can only do it after the interface used by the LNA has been finished. You can still edit the children actors on the PC target and RT target. BUT... there is an issue when overriding a dynamic dispatch method when a parent is open in two locations that breaks the parent.

So, I would suggest that you either come to terms with using 2 projects or you don't use AF. As an aside, I use 3 projects for my PC and 2 cRIO configuration.

Casey

[justACS]

I'm not sure I see the problem here.

Yes, AF.lib and its contents will be locked when you are working with both the host and the RIO target at the same time, but this shouldn't be a problem, because you won't be editing anything in the AF library.

Children of actor.lvclass won't be locked, unless you try to load them on both targets.  The LNA gets locked, for that reason, so it has to be maintained separately.  But your other actors should not be.  The number of actors cross-loaded on both platforms should be small.

If you follow the guidance in the cRIO example and make proxies, you should be able to work on most of the components of your project, even when both host and target code is loaded.

[StevenHowell_XOM]

Thank you everyone for the input and feedback. At this time, we are abandoning deploying AF to the cRIO side of the project as we need to move forward. We never could get the LNA to work for some reason. It would never connect to the RIO side, and I made sure we put the IP address of the RIO into the "Launch UI Actor" of Casey's example. The RIO code would run on the target but as soon as I brought the UI side up and sent a command to the target it killed the target side code. I did some probing around in the LNA and it was never connecting the streams together for some reason. As I stated I put the URL of the target into the Launch UI Actor startup and I assumed that was the only place it was needed. We had already developed a Network Stream that works for our project and incorporated that into our design following the LNA example and creating a proxy class that the main Actors on each side inherited from. The stream actors inherited from Actor.lvlib that resides in the LabVIEW folder. We could get this to work in the development environment and send messages between the host and target and back. However, as soon as we compiled the RT side into an RT exe and ran it....nothing. We had the RT and Host side in separate projects. Not sure what we are doing wrong, have to take some time to figure it out after we finish this project. Any feedback or issues anyone see's with our implementation would be appreciated.