Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Actor Framework and cRIO

Solved!
Go to solution

Good morning,

I have a project that I am working on where I have several cRIO targets. We noticed that we were unable to create an AF class on the cRIO target. If we try to import the AF into the cRIO side of the project of course AF wigs out and corrupts the Stop Actor Core VI..this would probably be a cross linking issue.

How do you use AF in cRIO? The LNA?

Any help or advice would be appreciated. 

0 Kudos
Message 1 of 23
(7,764 Views)

I am using completely separated LabVIEW projecst for the RT/FPGA and Windows stuff.

I created a class library inheriting from the AF containing RT/FPGA specifics that are not supported on windows since that would break the class hierarchy due to undesired dependencies on windows.

Refer to https://github.com/HB-GSI/CSPP_RT for details. This is part of the CSPP project.

For the standard actor messaging I am using the Linked Network Actor. For messages that would include undesired RT/FPGA dependencies, I am using the CS++LNAMessages,https://decibel.ni.com/content/docs/DOC-41126. That works really nice for me.

I hope that helps. Holger

0 Kudos
Message 2 of 23
(4,665 Views)

Steven,

Have you looked at this discussion started by Casey Lamers regarding his use of AF on the cRIO?  The reality is that there should be no significant difference between using AF on any RT system and use on Windows.  It is unclear to me what Holger is talking about as the AF has no inherent dependencies on Windows libraries.  And, if you have an actor that utilizes some of the RT or FPGA specific methods, then you should not even consider this actor for reuse on another platform.  Holger seems to be addressing some kind of architectural issue that has risen from his particular use of the AF.

Can you provide more information about how the system "wigs out"? i.e. what is the error that you get with the stop core method?  And what do you mean by importing?  Do you mean when you add the AF library to your target?  Or when you try to run it?  This might actually be an issue with your VIObjCache in your Labview Data folder rather than a cross linking issue (cross linking is very unlikely as the AF is contained in it's own library).  If the error you get is...nothing (i.e. just a broken run arrow with no error)... then clear your compiled object cache (or just delete the folder) and restart Labview.  This is likely the problem.

Regarding your comment about how you use the AF on a cRIO target - I don't do anything different than I would when deploying on another platform.  The LNA is simply an implementation of the AF that allows the user to link actors on different targets using network streams.  I would personally just start by developing your project on the cRIO target first and then establish how exactly you want the server to talk to the client.  Personally, I have no use for actors on the client side:

  • I save most of my data directly to a drive attached to the cRIO
  • I just need data at regular intervals (and it won't matter if some of that data is occasionally dropped)
  • and, I don't need ALL of the data on the client side (just enough to make sure that I can empirically determine that everything is ok).

To that end, I have used shared variables in the past (they are quick but kind of a black box) when communicating with a LV developed program on the client side but currently I am using web services to communicate with web tech based clients.

So, in the end, it comes down to this - there is little difference between using the AF on Windows or on cRIO.  The error you are getting is likely due to something internal given that it seems to be so low level.  And finally, the LNA is just a method for linking actors across multiple targets and is a whole separate issue from the core AF (which seems to be what you are having issues with).

Hope all of this helps.

Cheers, Matt

Message 3 of 23
(4,665 Views)

There was some discussion on this thread about what can cause Stop Core.vi to break:  https://decibel.ni.com/content/thread/26650

In that thread, Casey Lamers had some ideas on what could be a contributing to its breaking.  It sounds like you may have stumbled upon one of the circumstances where things can go awry. 

Message 4 of 23
(4,665 Views)

niACS also posted another way of handling the communication besides LNA...  He calls it Network Endpoint Actors.  You can find some information about that here:  https://decibel.ni.com/content/docs/DOC-43797

There's a good section at that link which describes some important differences betrween LNAs and the Network Endpoint Actors.

Message 5 of 23
(4,665 Views)

Indeed, there is nothing special with AF on RT, but:  If you want to send a message from windows to an actor on RT, the message.do.vi calls a public method of the addressed actor. Therefore the addressed RT actor becomes loaded and is part of the dependency on windows, and of course vice versa.   If the RT actor contains resources that are not supported on Windows, e.g. watchdog VIs, you break the class hierarchy. This sometimes resulted in broken VIs of the AF classes. Easy to repair, but not necessary.  This was the reason for me to extent the LNA for zero coupling, and to provide a separate actor class hierarchy dealing with the RT specific stuff. It does some RT health monitoring and defines some dynamic dispatch VI to be overwritten by application specific actor classes.

0 Kudos
Message 6 of 23
(4,665 Views)

Fire, have you checked out this example?

https://decibel.ni.com/content/docs/DOC-24187http://

I demonstrate a technique for managing the cross-linking.  Short version:  you create a proxy actor that manages your communications channel and defines, but does not implement, the messages that will pass over the application boundary.  You make a different child of the proxy class for each side of the boundary; these children implement the target-specific responses to message traffic (forward across the boundary, or take local action).  The platform-specific children never get loaded on the wrong platform, so you never link in inappropriate code, and the only actors that get locked are the proxy and networking actors.

0 Kudos
Message 7 of 23
(4,665 Views)

It seems this might be answered here:

https://decibel.ni.com/content/thread/26650

AQ describes the scenario where an override of a method that is on two targets breaks the parent method.

I suspect you might have it on two targets since you are moving to a cRIO.

As niACS mentioned, a solution is to define a parent class with abstract dynamic dispatch methods. Then make messages for those methods. Then create children for the different targets. I use the LNA. A note on executables is that you need to have the class contant for the message classes in the build. I put them in Pre Launch Init for the parent class. This way when a LNA sends a message to a target that doesn't use the message on its own it can still act on it. Otherwise the messages don't get included in the build.

I use several different models of cRIO with different FPGA personalitlies and I want to reuse my actors so I also wrap the FPGA methods and created a parent FPGA class to define the signature. My actors are portable by "encapsulating what changes".

Casey Lamers


Phoenix, LLC


casey.lamers@phoenixwi.com


CLA, LabVIEW Champion


Check Out the Software Engineering Processes, Architecture, and Design track at NIWeek. 2018 I guarantee you will learn things you can use daily! I will be presenting!

Message 8 of 23
(4,665 Views)

niACS schrieb:

Fire, have you checked out this example?

https://decibel.ni.com/content/docs/DOC-24187http://

I demonstrate a technique for managing the cross-linking.  Short version:  you create a proxy actor that manages your communications channel and defines, but does not implement, the messages that will pass over the application boundary.  You make a different child of the proxy class for each side of the boundary; these children implement the target-specific responses to message traffic (forward across the boundary, or take local action).  The platform-specific children never get loaded on the wrong platform, so you never link in inappropriate code, and the only actors that get locked are the proxy and networking actors.

Yes, I followed the discussion. The abstraction approach of course works fine. But it triples the actor.

Since we have only few actors using RT specifics we prefer to the zero coupling CS++LNAMessages. Many other actors can be used platform independent and accept standard LNA communication.

Furthermore libraries can get locked when used in host and RT target in the same project and you can not even edit a VI. Maybe I did something wrong, but this was my experience and therefore I decided to use separate projects for windows and RT stuff. Another advantage of separation is, that you can continue development of the windows stuff on PCs with no RT/FPGA module installed.

Holger

0 Kudos
Message 9 of 23
(4,665 Views)

Casey,

Maybe I didnt state my question correctly. We have a project where we have 1 host machine and 2 targets that run simultaneously. I would like to utilize AF on both the Host side and the RT side. When we import the AF.lvlib to the computer under the RIO chassis in the project, and I create a new class on the host side, I cant find the AF class to inherit from.

What is the best or only way to get the AF.lvlib into a project that uses cRIO to where I can create classes on both the host and RIO and inherit from AF without it breaking any of the components?

0 Kudos
Message 10 of 23
(4,665 Views)