how to choose architecture

[reteP]

 

Could you help me please choosing the best architecture for my app.

 

My app contain 5 pneumatic cylinders, 5 hydraulik valve, semaphore of the lights (green, red, yellow, blue) and 2 HW buttons. I want use Message handler for Control, Manipul and Cylinder Loop (check layot). Cylinder has state move and check position. 

 

For example: If i want move with Gate (close door) Control loop send message to Cylinder loop and cylinder will do sequence (check position -> move -> check position -> done "send message command done") and then controler go to next state and send message to manipulator take a part and then manipul do seqvence for this command and send result ( command done ok or comand dane with error) etc. 

 

I dont know how to create this think. 

 

 

layout.pdf

[PaulL]

What you have described is good so far.  The one thing I would add is that in practice your controller should execute in very small steps.  What I mean is that a cylinder move could take a long time.  You don't want the application to "stop" while the cylinder is moving.  The cylinder move should be part of a loop.  (The system may be in the same state during the entire cylinder move.)

 

Anyway, you are going in the right general direction.  OK, one more thing: if you use a Model-View-Controller architecture, the Cylinder is a model element commanded by the Controller.

Model-View-Controller is the architecture I use.  It does require a knowledge of object-oriented programming and design patterns to implement well from scratch, though.  It is well worth the effort, I suggest, if you can invest that effort.

[reteP]

Hi PaulL,

 

 I would like to do it using OOP. I am beginner in OOP and i have question for class cylinder. Cylinder is parent class for my 5 cylinders ?

 

For example: parent class is formula for others cylinder or not ? When i have 5 cylinders with others parameters (evry cylinder has other time to execute and other count sensors default 2 ) but every has sequnce: check position (call to sensors) -> move (write to HW direction) -> chceck position (call to sensors). First check is checking default position cylinder and second check is checking whether command is completed.

 

 

[PaulL]

If I follow your description, each cylinder has the same properties (but with different values) and the same behavior.  If that is the case, then the application should have 5 instances of the same Cylinder class, not multiple Cylinder classes.  The application will write unique values of the properties to each object instance.

If, on the other hand, the cylinders have unique properties or methods, consider subclassing as an option.  (Subclassing is one option and makes sense if we are talking about different types of cylinders.  The Strategy Pattern is an alternative to subclassing when an algorithm is the thing that varies.)

[reteP]

Yes, that's true.

 

And could you tell me how working with this object Instance, for example: when i would like to move with 2 cylinder together. My idea is: every instance put into array and than working with array. It is correct or is better way?

 

 

I don't understand, how objekt cylinder doing sequnce. I must send each command to cylinder ?? Or is way to do automatic, send 1 command (message) to cylinder loop MOVE and he execute sequence.

 

Thank you 

pokus_101.zip

[reteP]

Here is upgrade example.

 

 

pokus_101-1.zip

[PaulL]

Yes, an array is a good idea.

 

Are the all the cylinders in the same state at the same time?  If so, then the array will only need one state machine.  If not, each cylinder will have to store its own state.

 

There are several good possibilities for executing a sequence of moves.  My preferred approach is to define states so that each sequence step defines a state.

 

I will see if I can download your zip file.

[PaulL]

OK, I looked at your files.

 

The most obvious thing to address is that Move and Position should be in a separate hierarchy from Cylinder.  You are moving in the broad direction of the Command Pattern, which is a great thing to use for this purpose.  I recommend that you check out the Command Pattern in http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented-ebook/dp/B000SEIBB8/ref=sr_1_1?s=books&ie=UTF8&qid=1390927051&sr=1-1&keywords=design+patterns or http://www.amazon.com/Head-First-Design-Patterns-Freeman-ebook/dp/B00AA36RZY/ref=sr_1_2?s=books&ie=UTF8&qid=1390927051&sr=1-2&keywords=design+patterns, or read one of my papers.  (Maybe you won't have time to comprehend the pattern fully, but I think understanding the basic concept will help, if you want to architect this well.)  (Note: a command object can store a context value that defines the target.)

 

There is a long way to go yet before having a full application (there is a lot to making such a thing), but you are generally moving in the right direction, it seems to me.  How complicated is the final application going to be, and how much time do you have to complete it?

[reteP]

I don't know what you mean with sentence: Are the all the cylinders in the same state at the same time?.

I think all the cylinders isn't in the same state at the same time check pdf. Each cylinder has behavior: Initialization, Move, Check position, Retry, Error. I don't need in this app move with more cylinders together but maybe next app need it. This app need sequence move: move with Gate and than move Lift etc. 

 

My problem is with check position because when i moved for example Gate and than must check position real time (every 50ms) upper object must generate message (chceck position) for cylinder every 50ms? Cylinder has time for execute. If time is elapsed cylinder go to the error state and send message to upper object. He equip an error and send to indikators loop error (flash red led on semaphore and beep with buzzer every 250ms till error until the fault is removed) also send message to cylinder Retry.

 

I know that i need a lot of time. I have 5 weeks for this app maybe more

HY72100.00_RVS pracovisko kpl..PDF

Edited January 29, 2014 by reteP

[PaulL]

OK, well, then you will need an independent (orthogonal) state machine for each cylinder.  I've done that with a fairly simple variation on an implementation of the State Pattern.  I think it is not incredibly difficult, but you will need to choose the design accordingly.

 

I would start by making a state machine diagram (OK, I would really start by assembling a use case and a set of requirements, but let's presume you have those and are ready to do some design) to describe how the system must behave.  Creating a model of the behavior won't guarantee that you can implement it, but describing the desired behavior correctly is, in my mind, a necessary prerequisite to writing the code, whichever architecture you choose, and the model will likely drive certain architectural decisions.  It will also be helpful to communicate with others if you want to bounce some ideas off them.  (Hint: I recommend, for a number of reasons, the use of UML for this purpose, but the necessary aspect is to be able to model or describe accurately and effectively the states of the system.)

[reteP]

Ok so, what do you think about Actor Framework ???

[PaulL]

First, I looked at your other thread later yesterday and saw you posted a draft of a state machine there.  I had a question on that: what are the triggers for the transitions between states?

 

On the Actor Framework (AF):

My experience with the Actor Framework is limited; I have worked through Actor Framework examples, but I don't use it, largely because we previously developed our own template that has many, many more features, does what we want it to do (e.g., works with multiple components distributed over a network), and, in my opinion, has a more sound and user-friendly design.

 

What I like about the Actor Framework (as I have seen it):

The broad concepts of actors and Model-View-Controller are the way to go.  (Our own approach uses M-V-C and components, which are identical with actors, although we use them more sparingly--see below.)

Providing a solid architectural baseline for users is a worthy goal, and the Actor Framework is a big step in the right direction.

 

What I consider caveats are:

The Actor Framework makes more or less everything, even within a component, an actor.  This is one of the factors that leads to what I consider an overuse of by-reference native LabVIEW objects, which, in my opinion, have an ugly API and the overuse of which tends to obfuscate the workings of the code.  [An application programmer should not be dealing with Data Value References (DVRs) and In Place Element structures (IPEs).  Our template has none of these, so that the developer only focuses on the details of the particular application.  Moreover, a subVI call is easier to follow and preferable in many cases.] 

The Actor Framework does not use appropriate interfaces, so that code dependencies are hopelessly tangled.

 

These make the AF more difficult to use than it should be.  Nonetheless, the broadest strokes of the design are sound and worth understanding, whether or not one uses the AF itself.  In the end the AF does offer a ready-made path to a working application with a reasonably good architecture.

[PaulL]

So... how is your project going?