Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

First program and first problems with AF

Solved!
Go to solution

Hi all, another new poster. I've been trying to implement a basic program using AF and have run into my first problem. I should probably start by saying that my approach has been to start from a top-down view of a (very basic) system of actors and associated messages and implement the program from that, rather than just trying to convert some QMH programs to an AF implementation. My program is a crude Flight Sim model, with the start point as shown below (my aim is to build this up with other actors as I learn more about AF).

 

So in this basic system, the root actor FlightSim launches the Plane actor, which launches the Cockpit actor, which launches both the Throttle and Airspeed Indicator actors. (The example is loosely based on something I read in an Akka book on concurrency.) There are only two messages in the system. Msg 1: The Airspeed Indicator actor sends a message to itself every 200ms to recalculate the airspeed and update a gauge and set-point indicator. Msg 2: When the throttle changes, it sends a "ThrottleChanged" message to Airspeed Indicator. This just has the effect of updating the (exposed) private data "Throttle %" in the Airspeed Indicator actor. And so far so good; this works with no issue.

FlightSim Basic1.png

But then I decide to extend the system by adding in Stick and Altimeter actors, also launched by Cockpit, with three new messages in the system shown in red. As the altitude (Altimeter actor) is based on airspeed as well as stick angle, I need Altimeter to receive messages from both the Airspeed Indicator actor and the Stick actor. Also, I want Altimeter to update itself every 100ms with a self message.

FlightSim Basic2.png

When I launch this system, the Airspeed Indicator actor still works as before, and the Altimeter sends messages to itself as expected, but Altimeter does not receive the messages from the other actors. I'm using event structures in the Altimeter and Airspeed Indicator cores, and it's likely I'm using them incorrectly. I've attached the code in a ZIP file, and I'd really appreciate it if one you more learned folks could point out the undoubtedly obvious errors I'm making.

(Just to also add: I'm using LV2014)

0 Kudos
Message 1 of 10
(7,922 Views)
Solution
Accepted by topic author DMurrayIRL

It looks like the messages are being sent and recieved just fine when I just ran the code. Are you maybe probing somewhere and not seeing the changes you are expecting? Do the Altimeter values not change when the Stick and Throttle Change? (i.e. does "Rate of Climb" just stay at 0 the whole time for instance?). If they aren't changing for you than maybe you fixed it by posting the code to the forum and you just need to run it from the code you uploaded! It is like when you call the IT guy over to check on the error you are having and your computer magically fixes itself! (:

Great job on your first AF project BTW. It is looking good.

If you want to see the values of Airspeed and Stick% you could add controls to your front panel of the Altimeter and update them (and read their values) through references (see attached example).

-Carl Wecker

0 Kudos
Message 2 of 10
(4,426 Views)

Thank you Sleepy_Engineer - your version worked for me which was quite strange. Also I just saw that the version I uploaded was a debug version (I had a "Test" control on the Airspeed Indicator actor, rather than having the airspeed message being periodically sent to the altimeter actor). The attached version is how things are supposed to work.

Still it's strange and a bit worrying that my original version doesn't work.

0 Kudos
Message 3 of 10
(4,426 Views)

Okay, so to fix my original code I deleted the messages and associated accessors that weren't working, then re-coded it exactly as before, and it worked. One thing I remember during my original coding was that after I created one of the messages (using the Message Maker tool), I went back and manually changed the representation of one of the variables from a DBL to an I32 in both the class private data and the message logic itself. Is this likely to have broken the messaging process somehow? And also, if I create a method + message and I'm not happy with it, what are my options to modify it? Do I have to delete both and create them again? 

0 Kudos
Message 4 of 10
(4,426 Views)

DMurrayIRL wrote:

And also, if I create a method + message and I'm not happy with it, what are my options to modify it? Do I have to delete both and create them again? 

Modify the method as you require.  You can then either hand-modify the message (it's not hard, but it's a bit tedious if you have to do a lot of them), or delete the message from your project and from disk, and then recreate it.  You may have to relink your send message VI as well.

We're looking at offering rescripting at some point in the future, because this is somethign of a pain point for users.

Message 5 of 10
(4,426 Views)

Throttle shouldn't message Airspeed Indicator directly, because that's not how those actors would work in real life.  Both of those actors would be adapters for hardware, or a physics engine that simulates hardware.  Take a look at how the simulation is built in the Actor Framework sample project, if you want to see what that should look like.

0 Kudos
Message 6 of 10
(4,426 Views)

Don't forget that the GOOP Dev Suite now allows you to update all AF messages associated with an actor to match its methods.

It seems to be a little fragile, but it's so useful that I use it regardless.

Message 7 of 10
(4,426 Views)

Thanks for the replies, guys.

niACS wrote:

Take a look at how the simulation is built in the Actor Framework sample project, if you want to see what that should look like.

I'm not quite sure which project you mean, can you please point me to it? Also, the code I posted was just a first pass I put together to try to understand messaging between (sibling) actors. When it didn't work I thought I was doing something badly wrong, hence the post. My original aim was to have a "CalcAirspeed" actor between the Throttle and Airspeed Indicator actors, so that the job of the Airspeed Indicator actor was simply to update its gauge, rather than doing the calculation as well. Is this along the lines of what you are suggesting?

0 Kudos
Message 8 of 10
(4,426 Views)

DMurrayIRL wrote:

I'm not quite sure which project you mean, can you please point me to it?

Start LabVIEW.  Select Create Project.  You'll get the Create Project dialog.  Highlight Sample Projects, in the left hand pane.  In the right-hand pane, double click on Feedback Evaporative Cooler.  Name the project and click "Finish".  This will create a sample project in a location of your choosing.

DMurrayIRL wrote:

My original aim was to have a "CalcAirspeed" actor between the Throttle and Airspeed Indicator actors, so that the job of the Airspeed Indicator actor was simply to update its gauge, rather than doing the calculation as well. Is this along the lines of what you are suggesting?

Something like that.  Although, if you look at the sample project, you'll see that we actually create parent actors with business logic (whatever logic would be part of Throttle and Airspeed Indicator that isn't tied to hardware) and then create child actors that add the hardware or simulation implementation.

0 Kudos
Message 9 of 10
(4,426 Views)

I also use the GOOP Development Suite to update AF message classes to reflect changes to AF actor class methods, though it is really very fragile.  It's workable now that I've figured out all (some?) of the gotchas that go along with it.  Here's my list to get you started:

  • If the actor method has no inputs (beyond the required actor in/out and error in/out), attempting to update the message class after adding one or more inputs results in the tool crashing.
  • If the actor method is renamed, attempting to update the message class results in the tool crashing.
  • If the actor method has a mixture of required and recommended inputs, they will not be reflected properly in the send VI of the message class.
  • If the tool is used to update a message class, the send VI of the message class will have the message enqueuer indicator deleted.
  • If a message class does not already exist, the tool cannot be used to create a message class.  Attempting to do so results in the tool crashing.

Since the GOOP development suite can't be used to create message classes using a right-click, I have installed niACS' Actor Framework Project Provider to do so.  The catch with this tool is that it does not appear when methods are located within virtual folders inside of the class, so you might need to move your methods around to access it.

It would be great if these tools were further debugged and developed - they go a long way towards streamlining use of the AF.  It's also a bit rough for new developers to get onboard when tools like the GDS are full of readily apparent bugs even though they are "officially supported" by NI.

0 Kudos
Message 10 of 10
(4,426 Views)