GUI - Actor Framework - Decisions

"Hi there,
I think I am pretty clear about how to use the Actor framwork's and I would like to
have some guidance about to use the framework in my project.
This VI is a very simplified version of the actual layout.
Basically, there is only one hardware performing different types of measurements, send TX and RX messages through CAN and LIN.
My development strategy is
I intend to create an actor for everything related to the hardware measurements that I consider as the measurement bench.
This hardware will have to perform some asynchronous operations and will eventually send some messages / commands to others actors.
Those commands will contain for instance, the stuff (value type of course, I'm not willing to message everything with references) related to the information do display to the end-user in different VI.
The other actors representing different VI in some containers will send commands to this actors
In short, I was thinking about creating about 10 actors and more:
1) The most important one: the Bench (containing the settings and parameters in the class cluster) and performing the actions related to the hardware, inputs and outputs and inform other actors about what it just (if doing performing actions synchronously) or what is available (if some things are asynchronously in a loop). [Not sure if splitting the concerns of the Bench purposes into additional actions is really wise or not (especially since it will embed a VISA reference), it will probably require to additional lock accros the different Bench related actors with something like below:
- Bench Master Actor (to send and receive message to the enduser actors and dispatch the work with the two other Bench related actors)
- Bench Synchronous Actions Actor
- Bench Asyncrhonous Actions Actor
It's also in charge of receiving orders to start, stop, notify, performing actions asynchronously and / or synchronously.
2) Actor (especially the core as): VI ML
3) Same strategy for VI BRC
4) Same strategy for VI TRC
5) Same strategy for VI 1
6) Same strategy for VI 2
7) Same strategy for VI 3
8) Same strategy for VI 4
9) Optional: VI TM ... not really necessary I guess except to go with full actor everywhere..
Thank you."
Attachments:
GUI Actor Framwork.jpg ‏137 KB
GUI Actor Framwork(2012).vi ‏21 KB
Actor Architecture.jpg ‏83 KB

I would post this question to Actor Framework community rather than here, as active Actor Framework users are likely to be subscribed for discussions happening there.
https://decibel.ni.com/content/groups/actor-framework-2011
I am also interested in what people say about it.
TailOfGon
Certified LabVIEW Architect 2013

Similar Messages

References are becoming invalid when passed to an actor using the Actor Framework

I have having an issue with passing a couple of references to an actor using the actor framework 3.0.7 (LabVIEW 2011 & TestStand 2010 SP1).
Some background:
My application has three main components:
Main VI -- is not part of any class and Launches UI Actor.
UI Actor -- Launches the teststand actor
TestStand Actor -- Initializes and starts teststand.
The two references showing similar behavior (invalid reference) are the TestStand App Manager control and the "Current VI's Menubar" reference. The App Mgr control is on the front panel of the UI Actor's Actor Core.vi. The menubar reference is retrieved in the block diagram of the UI Actor's Actor Core.vi
Now,
When I run the Main VI I get an error in the TestStand Actor's Actor Core.vi (Remember Main VI launches UI Actor launches TestStand Actor) because the App Mgr and menubar references are invalid (. I have checked and verified that in this scenario the references are valid in the UI Actor before it launches the teststand actor.
If I run the UI Actor's Actor Core.vi stand alone (i.e. run it top level) the App Mgr and menubar references are passed to the teststand actor, no error occurs, and the code functions as expected.
Why would these references be invalid by simply starting a different top level VI? Could it have something to do with when the references are passed vs. when the front panel is loaded into memory?
I tried putting the App Mgr control on the front panel of the Main VI and passing it to the UI Actor and then to the TestStand Actor. This works....
Anyone have any experience or knowledge to why this is occurring?

Generally, references in LV are "owned" by the hierarchy they are first created in, and the hierarchy is determined by the top level VI. Once the hierarchy goes idle or out of memory, the references created by that hierarchy are automatically closed. That's usually what causes something like this - the reference is created in one hierarchy (let's say the main VI hierarchy) and then that hierarchy stops running.
I don't know the AF well enough to say if that's really the case (I actually thought that it always launches a separate top level dynamic process, which I assumed is where the UI actor's core VI would always be called), but that might help explain it. If not, you might wish to post to the AF group in the communities section.
Try to take over the world!

Best way to transfer large datasets between actors (Actor framework)

Hi everyone
I am in the planning / design phase of a larger application for which I wish to use the Actor Framework. It seems like a good "design pattern", easy for multiple developers to work on, easy to expand and easy to maintain.
In this application I need to transfer data betweeen actors/modules at a considerable rate. The data is the continous measurements from a DAQ device (or multiple devices) sampling at 200kHz. That's 200 kHz * 8 byte = 1.5 Mb/s per device.
There is no way this is done using the messages of the actor framework - those messages are designed to signal start, stop, select tasks etc. within the application. So how to transfer that amount of data between actors?
I've thought about using TCP/IP on localhost - this could also easily be expanded to allow different parts of the program to run on different machines on a network. I've even tested it and it works quite well. But I would like to hear some opinions or alternatives before I decide to go with this solution. Any thoughts or alternatives?
Thanks
Jonas

JonasCJ wrote:
Could this be done without TCP/IP and just a LABVIEW queue? Passing the queue in a message from one actor to another?
If it's in the same process then yes, and it would be more efficient, because with TCP you have to create a copy when converting the data to a string, another copy when receiving and a third one when converting back. Unless you really are planning on distribtuing it, I would suggest avoiding that. Sidebar - AQ has been talking about networked actors and I believe there should even be an experimental branch in the AF group in the community area. You might want to check that out.
Incidentally, if you are planning on splitting it and don't actually need the real time processing, you might consider saving the data to a network drive and then simply having the other side loading the data from the file. It should be simpler.
Try to take over the world!

Correct use of the actor framework?

Hi all,
I was hoping for some advice before I start developing an application. I want to try using the actor framework so I thought I would give it a go for this project.
It is a relatively simple application:
Update rates are at 1Khz max so the cRIO is in scan mode. The cRIO will communicate with the host using 2 network streams. One for sending and one for receiving data.
I want to use actor because there will be 3 screens used. One to display the digital inputs, one to display the analogue inputs and one to set the digital outputs. I thought this would be a good chance to have a go at using the framework because I could have 3 IO actors with one on each screen.. My initial ideas are as follows.
Host Application
Handle all the communication to the cRIO
Send any data it receives from the cRIO to the:
Digital out actor as a message
analogue out actor as a message
Input Data Logger actor as a message
Send any data it receives from the digital out actor to the:
cRIO
Ouput Data Logger actor as a message
I have attached the project file I am working with. I have knocked something up using tabs which gives an idea of how the UI will look for each screen.
I’m really not sure if this is even remotely close to the way to do it. Help please.
Lewis Gear CLD
Check out my LabVIEW UAV
Attachments:
Working Code.zip ‏93 KB

I'm not sure you need to split all of the outputs into separate actors. You could potentially wrap those up into one actor and create a method or small set of methods for each output type. Or, you could create a "Physical I/O" actor, and have that talk to the AO, DO, AI, and DI...then your top level application only needs to send messages like "DO : True" to the Physical I/O actor. Essentially, it abstracts it one more level, and might make things easier in the future if you decided to add other physical I/O (other cards, USB devices, etc.). This way, the Phsical I/O actor could handle the changes, and your top level application remains intact.
Wes P
Certified LabVIEW Developer

Actor Framework executable creation problem

I am created an application using actor framework and trying to build an executable using Application Builder. I just take Launcher as a startup vi for creating executable.
But after run the executable file the launcher imidiately closed. Nothing will happen after that.
Can anyone please help me on that matter.

I am attatched the entire project
Attachments:
Actor FW - EXE.zip ‏361 KB

Actor Framework: Should I merge Errors and error Codes?

Hi guys--
Actor Framework, LV2012: In general, should I be merging normal Error lines with the "error code" lines that occur in some of the override VI's? Or are these meant to be two distinct channels of information?
Attached is a contrived example (I wouldn't normally pass this particular error) that illustrates the kind of situation I find myself puzzling over.
I encounter such situations sometimes when overriding "Stop Core". Assuming one did not want to suppress the error at "Destroy Event", is this the proper way to handle this situation?
Thanks a bunch, and have a great day.
--Brad

I would post this question to Actor Framework community rather than here, as active Actor Framework users are likely to be subscribed for discussions happening there.
https://decibel.ni.com/content/groups/actor-framework-2011
I am also interested in what people say about it.
TailOfGon
Certified LabVIEW Architect 2013

Actor Framework 4.1 with GOOP 4.8 problems

Hi, Im running Labview 2014 f2 + GDS 4.8 + Actor Framework 4.1. When I create a simple project with with two actors (EndevoGOOP400 class provider) and a launcher vi It gets on a loop of the parent actor calling the nested actor and nested actor calling the parent. I used GOOP + Actor Framework 4.0 on Labview 2013 with no problem.
Some help?
Solved!
Go to Solution.

Solved, I was calling the wrong way.

Using actor framework 2014

I've used earlier versions of the actor framework just fine. Then I installed LabVIEW 2014, and I do not know how the new framework is supposed to function. Is there some example of how nested actors are supposed to work? I've been looking around but actor examples are strangely absent.
Lars Melander
Uppsala Database Laboratory, Uppsala University

> You don't need to call two extra VIs to launch an actor.
Sorry, I don't see how the number of VIs changes.
> Launching becomes easier to understand, because the concept now is that each actor creates its own queue and nested actors have implicit access to their caller's queue. The naming of the enqueuer terminals on the subVI also confused some people (including me) about which enqueuer belongs to which actor and this solves that.
Unfortunately, it seriously mucks up my design. I have a network of actors, and that does not translate to the new VIs. It's not obvious in any case.
> In general, if you want AF discussions, the AF group is the best place, as that also includes the NI people working on it. Here's one example thread also requesting an example - https://decibel.ni.com/content/message/94190#94190
I will look there, thank you.
Lars Melander
Uppsala Database Laboratory, Uppsala University

Actor Framework Message Maker Icons

I’d like to suggest a small change to the way the actor framework message maker works.
At present - regardless of the icon of the method for which the message class is being produced - the following VI icons are created:
Do.vi
Send <Method>.vi
<Method> Msg.ctl
How about if instead the message class takes its VI icons from the method (with the existing glyphs layered on top). So if the method icon is:
The following icons will be produced:
Do.vi
Send <Method>.vi
<Method> Msg.ctl
OK, its not gorgous and may need a bit of tweeking but I think this might make the Actor Framework quicker and more intuitive to use.
Dan
Dan
CLA

Might be useful to bring it to the attention of the Actor Framework enthusiasts: ni.com/actorframework
- Cheers, Ed

Actor Framework Help!

Hi all,
I am trying to figure out how to use the actor framework. Being new to LabVIEW, I am not very confident on how to use OOP properly either, but I do have a basic understanding. I have found many resources on actor framework, and I am trying to create a new project from scratch, as I found the template seems confusing to me before I can make all of that by myself. My goal is to make a VI that generates random number data, and 2 actors, one to gather the data and one to display the data. I don't have anything right now, but if anyone can get me started/help explain or give me some more resources to learn besides https://decibel.ni.com/content/docs/DOC-17193, it would be greatly appreciated.
Thanks!

Your link was malformed and didn't work
https://decibel.ni.com/content/docs/DOC-17193
I personally avoid NI's implementation of Actor, so sorry I don't have more help for you.
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

Actor framework

Hi
Where can i se the version of Actor Framework that I have on my PC?
regards Bjarne
Solved!
Go to Solution.

Hi Manu
First I will really encourage you to post you questions in a new thread. By doing that you will post your question to the hole forum and not only to the few people that actually attended here. Very few people will monitor the post when it is marked as resolved.
As for you question I looked over you code. Seems like you get your issue here:
In Gamma Actor -> Messages for Gamma -> Do.vi
You convert you Gamma Actor to a Type of Beta. Where you should have converted it to type Gamma.
If you look at the do message for alpha and beta that should show you how it is done correctly.
It could also be that you think Gamma Actor is a child of Beta actor and you therefor would like to convert it to the Type of Beta Actor (which is allowed), if this is what you want then the inheritance hirachi should state that Gamma Actor inherits from Beta Actor and not from Actor.
Both things could be valid depending on what you actually want. Right now you are trying to convert a car to a banana and that is what LabVIEW tells you is wrong.
Best Regards
Anders Rohde | CLD | Platinum Applications Engineer | National Instruments Denmark

Actor framework strictly typed message queues?

I'm just getting to grasps with the Actor framework. I have implemented "similar" stuff in the past but I've approached it differently.
One thing I noticed was how easy it is to send a message to an incompatible actor core which results in a nasty run-time "to more specific class" error.
In the example project included with LV 2012, if I make the change shown below (OK, I am purposely senidng a wrong message on the given queue) I get no feedback from the IDE that an incompatible message is being sent ont he queue. I think this has to do with the Message queues being for the base actor class.
Is there no way to have the actual queues more strictly typed so that we can say that Launching Actor Beta will result in a Queue reference which is only compatible with Beta (or children) objects or does this ruin the entire concept? If possible, it would prevent the ability oto send incompatible messages completely which IMHO would be an enormous benefit.
The presentations on the Actor framework have shown huge benefits in strict typing of state machines (I'm referring to a couple of videos I've seen ont he NI website) but this element of things seems to be just a pokey as a string flatten and unflatten. Send the wrong message to the wrong receiver and >bang< run-time error.
Just thinking out loud.
Shane.
Say hello to my little friend.
RFC 2323 FHE-Compliant

So two days and no reply...
I'm referring in essense to this part of the actor framework white paper as included with the template in LV 2012.
Messages from Callee to Caller
When a caller wants to send a message to the callee, the caller knows the type of the actor that it launched, so caller can easily choose the right type of message to send. But when an actor wants to send a message to its caller, the actor does not necessarily know what type of caller it has, so it does not know what type of message to send. Ideally, actors should be usable by many different callers. That maximizes code reuse. But making the actor truly independent of the caller requires more effort than is warranted for the situation. There are three techniques for defining messages that an actor sends to its caller
The High Coupling Solution—In this solution, the callee actor is written specifically for one type of caller, and can never be used with any other type of caller. In this case, the callee knows details about the caller's interface, so it may simply call the Send Message VI of the appropriate message. The message type is thus hardcoded into the actor.
The Low Coupling Solution—This solution works best when you have a known inheritance hierarchy of callers. In this solution, you create a matching hierarchy of callee actors. So suppose you have callers Hard Drive, Air Conditioner, and Fire Suppression, each of which needs to launch a Fan actor. You would create the Fan class, and then inherit from it Fan For Hard Drive, Fan For Air Conditioner, and Fan For Fire Suppression. Each caller launches its specific callee actor. All of the main Fan class' code is shared, but when it comes time to send messages, the Fan class has a dynamic dispatch method for doing the sending, and each of the children overrides that method to send the message appropriate for its caller. Each callee is still coupled to a specific caller, but the system as a whole is flexible to accommodate new caller types.
The Zero Coupling Solution—In order to make the callee actor independent from the caller, the caller must tell the callee what types of messages to send so the callee avoids picking a type itself. The best implementation of this solution has the caller record a message into the callee at the time the callee is launched. The callee provides a Set <Type> Message.vi method, where <Type> is the particular event that will trigger the message to be sent. The caller sets the exact message it wants to receive when this event occurs. When the event happens, the callee sends the chosen message, without any knowledge of what kind of caller is receiving that message.
Often the callee will define an abstract Message class that it uses as the input type for Set <Type> Message.vi. Callers create their own specific child of this abstract class. This setup gives the callee a way to set data into the message through the API defined by the abstract class, and gives the message a way to deliver that data in a form the caller can consume through the various overload and extension VIs.
Would it be possible to get some examples of the three different approaches to typing of the messages? I'm aiming for the high coupling solution (with the option of slipping to option 2 through common ancestors) in order to provide the ability to detect wrong messages on wrong queues at edit time.
Shane
Say hello to my little friend.
RFC 2323 FHE-Compliant

Recherche exemple simple sur Actor Frameworks

Bonjour,
Je recherche un exemple très simple utilisant la programmation Objet avec le module Actor Frameworks, tous les exemples que j'ai pu trouver utilisant ce module me paraissent un peu complexes.
Mon application consiste à utiliser une structure Producteur/consommateur en POO.
Comment utiliser cette structure Producteur/Consommateur avec Actor Frameworks.
Merci pour votre aide.

Olivier JOURDAN a écrit :
[...] AF est un très bon framework [...]
[...] Pour bien comprendre son utilisation il faut déjà une bonne maitrise des concepts liés à l'OOP[...]
[...] Les exemples les plus simples se trouverons sur le groupe Actor Framework du NI Community.[...]
[...] s'il est puissant, l'AF nécessite une bonne connaissance de LV[...]
Perso je suis d'accord avec Olivier (comme toujours), l'AF est très puissant mais pas simple d'utilisation.
La NI community me semble être le meilleur endroit pour trouver des informations. Il y a notement le document
« READ THIS FIRST to get started with Actor Framework" by ElijahK in Actor Framework 2011 [...] We've uploaded a lot of different documents to this web community to discuss the Actor Framework. This gives you a summary of the documents so you know where to start. [...]
Un producteur consommateur avec structure événementielle et file d'attente (type cluster : état + donnée) est plus simple à utiliser. Question évolutivité il n’y a pas de problème.
Luc Desruelle | Voir mon profil | LabVIEW Code & blog
Co-auteur livre LabVIEW : Programmation et applications
CLA : Certified LabVIEW Architect / Certifié Architecte LabVIEW
CLD : Certified LabVIEW Developer / Certifié Développeur LabVIEW

Actor Framework auto generate actor

Hello,
I'm starting to use the actor framework for a large application. I am wondering if there is a way to auto generate a new Actor?
I understand I can auto generate messages for an actor using Tools -> Actor Framework Message Maker...
I make an Actor by making a new Labview class say:
Test Actor.lvclass
Then set the inheritance of this class to Actor.lvclass
Make the Actor Core.vi Method
Make a Write waveform method
Set the scope of Actor core to protected, and other methods to public (just like the Simple Actor example) and make actor core reentrant
I am making the structure EXACTLY like the Simple Actor example, but I get the following errors in my new Actor Core.vi:
"This VI doesn't match other VIs in the method, Connector Pane Terminal(s) are different. All VIs that implement a method of a LabVIEW class must match Connector Panes. To correct this, compare Connector Pane of both this VI and the VI of an ancestor class that implements this method."
and
"The owning VI is not a dynamic member VI of a LabVIEW class. The Call Parent Method node should only be used in a dynamic member VI of a LabVIEW class."
I tried to read into this message, but it appears my connector pane is the name. I'm not sure whats going on.
(1) Can someone show me what I am doing wrong here?
(2) Is there a way to auto generate the Actor?
Every time I try to construct an actor from scratch I get the above errors. I have attached my project (LV2012).
Any help is greatly appreciated!
Solved!
Go to Solution.
Attachments:
Simple Actor Example Mod.zip ‏179 KB

I know this is old, but just to update this thread with info to others that are starting with Actor Framework and LabVIEW 2013.
The GOOP Development Suite is free now, free to download from NI's website.
With this you can make an actor. It is described here how to use GOOP to do it.

XML as datasource in GUI components framework

Hi all,
I'm looking for a framework to use XML data as datasouce to GUI components like Swing ones. I've investigated SwingLabs but in it XML databinding namely is under process now. Can anyone suggest something on the subject?
WBR, Max

if there are few data use odbc directly to the xml...
but the best way is to put them in a relational Db
i hope i helped....
http://greekoraclebi.blogspot.com/
///////////////////////////////////////

GUI - Actor Framework - Decisions

Similar Messages

Maybe you are looking for