How could I implement something like "interfaces" with the Actor Framework?

[AristosQueue (NI)]

TobinJones wrote:

I think that quite possibly my problem is that I'm still thinking in a sort of MVC or tiered-architecture way rather than in a fully Actor way? Do you think so?

I don't think that's your problem. I generally encourage people using the AF to think MORE in terms of MVC, not less. Each of the M and the V can (and often should) be separate actors with the messages playing the role of the C between them. Sometimes the C is formalized as an actor itself depending upon how much state the controlller needs.

[mike-o-tronic]

Hi,

I've been also struggling a lot with HAL and how to build up the class hierachy for a flexible system. I'm not quite sure if you ment this by:

TobinJones wrote:

Perhaps, though - this should be solved by simply implementing two interfaces to the Whizbang 3K, one as a concrete implementation of a "power supply" class and one as a concrete implementation of "power supply and meter combo" class. Then I could have a second "power supply and meter combo" implementation which just delegates to two separate devices. That covers all the bases, I believe.

But since your main application for your hardware seems to be the power controller, which needs current meter and power supply, I'd would go with AQ's solution:

AristosQueue wrote:

LabVIEW does not have interfaces at this time (wish it did, and someday it will, but not today). There are several kludges to get around this limitation.

• Creating a parent class that has all the methods and returns runtime errors for methods that are not overridden is one option (with obvious downsides).

Which would lead to the hierachy as Daklu was drawing it with the (advanced) power supply on top. The power controller could then either start a current meter and power supply, so that you have two seperate enqueuers. Or it starts just a power supply and uses its enqueuer for both "hardware devices". In this way you have the flexibility you want just by overwriting a "launch hardware" method.

But if you feel uncomfortable putting current meter and power supply together in one "family", you could use abstract messages.The evaporative cooler example has something like this implemented. I think this would maybe come an interface solution a little closer.

Best regards,

Mike

[BuckleyPhysics]

DFGray wrote:

For any particular measurement, you would use three actors - a measurement manager, a driver, and a function. When you need a particular function, you query the measurment manager for availability. If the function is available, it will spin up the driver for the function, if it is not already spun up, then tell the driver to spin up the function and return a reference, which will then be returned to you. At that point, you use the function. The function uses the functionality of the driver. The driver has all the functionality of the specific instrument and does the state caching so that you don't try to do something like taking a voltage and current simultaneously with an instrument that cannot do that. Function locking and reservation can be done in either the driver or the measurement manager (I used the measurement manager).

I used "abstract" classes which returned errors if called directly to write top level code.  These were subclassed for particular implementations of functions and drivers. Functions only called driver code, never the native driver.

This is once over very lightly. Let me know if you need more information or particulars.

AristosQueue wrote:

• Damien's "query for functionality" system mimics the "To More Specific" cast that you would do if LabVIEW actually had interfaces... as such, it is probably the most like interfaces, but obviously isn't as simple to write

Can I ask for some more information about this particular proposal?

It sounds like I would have a "Measurement Manager" which is responsible for managing hardware actors. When a controlling actor would like to use a service (lets say, it wants to "set the FizzBuzz current"), it would request this from the measurement manager, which would ensure the hardware actor required (concrete power supply) was started and in a good state. The measurement actor then tells the hardware actor to send a reference to its service (an enqueuer and concrete implementation of a message perhaps?) back to the original controlling actor. The controlling actor then goes about its work.

If I'm understanding, then "Measurement Manager"  is resonsible for managing hardware actors and relaying "Service" requests, and each hardware actor needs to be able to reply to a service request with a "Service" implementation which is a bundle of an enqueuer and a concrete message.

Am I following at all, or missing the point?

[3esmit]

Hello Tobin Jones,

I'm designing a system quite similar to yours. I really liked this discussion as It opened my mind to other solutions then the one I found. I will explain what I am trying to do.

I've found out G# Framework, that have a hack to use interfaces in Labview. It adds functionality to the Project Explorer. For interfaces it uses a set of VIs for more abstract, and a interface class that stores the name of the implementing interface in the "Interface object" and call it dynamically using VI Server. (Works nice and is easy to use)
You can have a measurement manager that will interpret a configuration file with the available hardware, which interface it implements and the "measurements" where the interfaces are required. First the measurement manager builds the hardware objects and then it builds the "tests" passing the interfaces mapped to them.

Example of XML ASL mapping configuration:

<ASL version="1.0" product="STE" name="Principal">

<Instruments>

          <Instrument class="ChromaHiPot"><!-- Chroma GPIB HiPot -->

                    <Parameter id="bus">GPIB</Parameter>

                    <Parameter id="address"/> <!-- No address defined - auto find address -->

                    <Realize interface="HVACOutput">hipot/hvac</Realize>

                    <Realize interface="HVDCOutput">hipot/hvdc</Realize>

                    <Realize interface="ResistanceInput">hipot/resistance</Realize>

                    <Realize interface="CurrentInput">hipot/current</Realize>

          </Instrument>

</Instruments>

<Measurements>

          <Measurement name="LeakageMeasurement">

                    <Parameter id="hvac" type="HVACOutput"><Bind interface="HVACOutput">hipot/hvac</Bind></Parameter>

                    <Parameter id="hvdc" type="HVDCOutput"><Bind interface="HVDCOutput">hipot/hvdc</Bind></Parameter>

                    <Parameter id="reading" type="CurrentInput"><Bind interface="CurrentInput">hipot/current</Bind>          </Parameter>

                    <Parameter id="active" type="DigitalOutput"><Bind interface="DigitalOutput">hipot/select</Bind></Parameter>

          </Measurement>

</Measurements>

</ASL>

This project is not coded yet, still in design. If anyone have ideas in improving my design will be appreciated.

Best Regards,

Ricardo Guilherme Schmidt