1st Post - Implementaion Review Request

[winston.hensley]

Greetings,

Any guidance from those with greater skill regarding Object Oriented Design and the Actor Framework would be greatly appreciated on my current endeavor. My skill with LabVIEW is approximately CLAD level or a touch higher but I'm having difficulty making the leap from simpler design patterns to GOOP and the Actor Framework. There seems to be quite a leap from basic OOP concepts, like methods and state data, to the queue and control refrences that are passed around between actors.

To implement a range sensor verification system I've chosen to use LabVIEW's Actor Framework and compose discrete actors for a target's motion control, 1Hz sensor data logging from multiple serial output range and meteorological sensors along with the presentation of sensor's output on the Front Panel.

Can anyone offer an opinion as to whether the AF is well suited to this task or if I should revert to a simpler architecture? Also, I've been taking a first attempt at a UML diagram for the class heirarchy as I understand it with respect to the AF. Because I am the only LV developer in this office, I'm (finally) reaching out the the LabVIEW community for answers with high hopes for a thoughtful review. Thanks in advance.

Best Regards,

Winston

[dsavir]

Hi, welcome to AF

The general concept looks fine to me. Some questions:

1. I assume a controller provides a UI for the sensors?

2. Why does the FP have both a controller and a reference enqueuer?

3. the controller has a an enqueuer to the reference and a referenece has an enqueuer to the control?

4. What's the difference between a sensor reference and a sensor? In fact, what is a sensor reference?

Good luck,

Danielle

[winston.hensley]

Hi Danielle, thank you for the quick response! My labeling scheme may be confusing because I'm using the term 'reference' and 'reference control' interchangeably. The reason for this is that a reference will undoubtably have a software controlled element. I'm writing code to verify that a sensor under test agrees with a sensor reference. Think of a laser range finder pointed at the wall and using a tape measure the distance between laser and the wall; the tape measure would be the sensor reference.

Regarding your questions:

1) Yes, I'm modeling the design after the Feedback Evaporative Cooler example and the 'controller' will provide the UI which gets dynamically loaded into the Application Actor.

2) The user needs to be able to enqueue a Stop, Forward or Back message to the (sensor) reference actor from the Front Panel if manual control is selected...but I suppose the reference enqueuer does would belong better in the controller of course.

3) Since the reference will be instructed to move by the controller, the controller needs the (sensor) reference's enqueuer. Because there will be hardware systems which generate software fault cases, I think tha the (sensor) reference needs to the controller enqueuer, yes? Perhaps I'm misunderstanding something...

4) Sensor reference is a flat metal target on rails whose linear motion is controlled via LabVIEW, microcontroller and DC motors.

Thank you for taking a look at the design diagram, it instills a bit of confidence that the AF is the correct approach for this problem.

Cheers,

Winston

[FabiolaDelaCueva]

Just a small suggestion. I would change the name of the reference to "Sensor Reference ". It might clear up things when discussing the code with others and it would not be confused with an actual LabVIEW Control Reference.

My 2 cents.