Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Need some guidance on AF project

I'm glad I asked, because I like your idea better.  Particularly because I want to be able to code and debug on my laptop which won't have access to the hardware, so I was going to do a Hardware Abstraction Layer, so I could have simulated hardware.  I would probably keep the hardware interface actor alive and then I can call into it for the manual actions and I can also have it broadcast some sort of status update to be displayed on the GUI.

I think that will work very well.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 21 of 40
(3,056 Views)

Look up "low coupling".  You could write a simulated hardware interface that takes the same messages as the real one, and use them interchangeably.

The basic idea is to make a parent actor with all the method VIs you need.  Make them dynamic dispatch, and leave them empty (no new code on the block diagram).  Make messages for all of these methods.  Then make children of this parent actor, and provide those children with overrides of all of the dynamic dispatch methods.  You now have a family of actors that all take the same message, but respond to them differently.  (Yes, there are similarities to state pattern actors.)

Message 22 of 40
(3,056 Views)

Sounds perfect.  Another question:  How are people handling configuration?  Static configuration that doesn't change while the program is running isn't too bad, but what about configuration that the user can change while the program is running.  I've got a few ideas, but kind of curious to hear what everyone else is doing?

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 23 of 40
(3,056 Views)

niACS wrote:

. . . make a stateful actor with "manual" and "running" states. . . .

A "manual" state: That is a much more useful idea than the "not running" state which had somehow taken over my way of thinking about it.

I have my sequencer and an instrument manager as children of my application actor. The sequencer asks the app to do things with the instruments, the app passes those requests to the instrument manager, the app then passes results from the manager back to the sequencer as needed. It's indirect, but it reflects that our list of connected instruments doesn't change based on what we're doing with them.

Message 24 of 40
(3,056 Views)

I'm curious... Why did you decide to make them children?  Is that just so that they all use the same messages?  Do you perhaps mean they are nexted subactors of your application actor?  That coincides more with the way I am thinking about the problem.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 25 of 40
(3,055 Views)

Sorry. I meant sub-actors.

Message 26 of 40
(3,057 Views)

That makes a lot more sense now.  I thought that was what you meant.

It is very easy to get confused with some of the terminology.  I'm finding particularly in the beginning its easy to confuse the "actor tree" for who launches who and who communicates with who, etc with the object inheritance heirarchy tree.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 27 of 40
(3,057 Views)

Taggart wrote:

I'm curious... Why did you decide to make them children?  Is that just so that they all use the same messages?

Yes.

Do you perhaps mean they are nexted subactors of your application actor?  That coincides more with the way I am thinking about the problem.

No.  Parent/child always refers to inheritance; caller/nested refers to actors launched by other actors (which is a composition relationship).

0 Kudos
Message 28 of 40
(3,057 Views)

NiACS my comments about inheritance were directed at what Auspex wrote. I think you and I are on the same page with regards to the low coupling and using inheritance so they all take the same messages and then overwrite the parent method in the child classes to get different behavior for the same message depending on which child actor I have launched.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 29 of 40
(3,057 Views)

Taggart wrote:

NiACS my comments about inheritance were directed at what Auspex wrote.

Oh.  Sorry about that.

0 Kudos
Message 30 of 40
(3,057 Views)