Actor Framework on real time in LV 2012

[SamoraJ]

Hi,

How's it going?

I still haven't managed to modify the template into something that runs on a sbRIO.

I get unsupported method/property errors from "down below".

Any chance you have something (anything!) working at the moment?

Cheers

http://db.tt/5FLGaJHv

[justACS]

Soon, Marcus.  I'm finalizing the documentation and VI package, but this is a side project, and I have some tasks for my day job that I need to clear.

[Fred_V]

As an FYI:

The LabVIEW 2012 Real-Time module f1 patch is now available (details here) and resolves CAR 360974:

VIs or controls that use library items in community scope both fail to download to and do not work in built applications on VxWorks targets.

I hope this helps!

[Bob_Schor]

I've started a Real-Time Project (a big port from, heaven help me, LabVIEW 7.0) using the Real Time (DAQ) Templates that ship with LabVIEW 2012.  These, of course, use the QSM as their "cornerstone" method.

I'm very interested in trying to do this with the Actor Framework, envisioning a Host Actor Framework, a Remote Actor Framework, and (for now) Network Streams sending data ("messages") between the two.  I'm working with a PXI system, so my RTOS is PharLap, not VxWorks, so it will be "interesting" to see how AF behaves.

I notice that there is reference to sending messages by "networks" (which I presume means TCP/IP).  Does this mean that one could have Actors "distributed" across both the Host and Remote?  This strikes me as problematic -- I'm not sure that LabVIEW Project would support this.  In any case, I'm going to start with two semi-independent systems, and if someone figures out how to unify them, I'll attempt it ...

BS

[Daklu]

Bob_Schor wrote:

I notice that there is reference to sending messages by "networks" (which I presume means TCP/IP).  Does this mean that one could have Actors "distributed" across both the Host and Remote?  This strikes me as problematic -- I'm not sure that LabVIEW Project would support this. 

AF messages are just objects, there's nothing that prevents you from sending them over the network.  You'll need to implement the network streams as helper loops, meaning communication between the host and remote systems will occur "outside" of normal AF channels.  You'll probably also want to take steps preventing systems on each side from being statically dependent on each other.  I'll leave it to others more experienced with the AF to explain the best way to do that.

[CaseyLamers1]

I have a RT AF project using a host and a remote.  I use niACS's Linked Network Actor (LNA).  I had to break the project into 2 projects so that the locking wouldn't be a problem.  Any piece that needs to be on both sides you make a parent class for.  Then add abstract methods in the parent.  Now on the host computer project and RT you make 2 children that inherit from the parent and implement the method.  You make the AF messages based on the parent class.  As an example, lets say you need to change a double setpoint.  The parent class would have a method an abstract method with a double input.  Make a message for that method.  The host would implement that method by taking the double and putting it in a message and forwarding it to the RT if it is connected.  The RT would implement the method by taking the double and deciding what to do with it (check to see if you can change the setpoint at that time and then act).

Note, you can only edit the parent class when one project is open.  It will be locked if both projects are open.  The children classes remain unlocked.  I had a problem with creating a "New VI for Override" when 2 projects are open, but once the method is created editting it with both projects open is no problem.

Also, when you go to build this into an EXE you need to include the class constants of the message classes if the method isn't used on the particular target directly.  In other words, if you don't change the setpoint from the RT but only from the host then you need to have the constant.  The reason for this is that the LNA recieves messages but doesn't know what the messages will be.  They are flattened to string.