how to create Hardware abstraction layer

[reteP]

Hi all

i have one question about hardware abstract layer. I have parent class cylinder this cylinder has two children Monostable and Bistable. This children have children 1Sensor, 2 Semsor and more sensor if i need. I want create HAL for cylinder (simulated hardware & real hardware).

I want create manipulator actor this actor is composite with 4 cylinders (3 monostable with 2 sensors & 1 bistable with 2 sensors) And i want simulate HW by global variable. Therefore i need create hardware abstract layer.

How to create HAL for cylinder ?? I can create HAL for each child or is any better way ??

[mike-o-tronic]

Hi reteP,

I'm wondering what's your Actor supposed to do? From the graphic you attached I'd assume the Actor will just observe the cylinders position!? What's the difference in the Monostable and Bistable class?

[reteP]

Hi Mike,

What i mean with graphic ?? Sketch shows the inheritance from parent class Cylinder because exist more types of cylinder. Monostable and bistable this is a basic dividing. Monostable has 1 valve and no sensors and Bistable has 2 valve and too no sensors but standard cylinder in application has 2 ending sensors. This sensors notify in which position cylinder is.

Check my project there is testVIs folder and inside is Test handler.vi Program working good but problem is  there are only monostable cylinder with 2 sensors. I want do universal program where initially it would be possible to choose cylinder for example: in one app I will be have 2 monostable with 2 sensors, 1 monostable with 0 sensor, 1 monostable with 1 sensor and 1 bistable with 2 sensors but every cylinder has same function check position -> Move -> check position -> idle . Cylinders have others hardwares but same behaviors.

Message was edited by: reteP

I know that every class must have same dynamic dispatch (Configure HW, Close HW, Read sensors and Write Valve state) But i do not know how to do when every child has specific configure.vi. For example: Monostable cylinder with 2 sensor needs both (idle and busy) adresses of sensors also needs adress valve. Bistable with 1 sensor needs only 1 adress of sensor and 1 adress of valve.

Message was edited by: reteP

[mike-o-tronic]

Ok... I think I get what you're going to do...

To me it looks like you loose all the flexibility you actually want to gain with OOP/AF by by putting your sensor, your actor and your controller into a single object. I'd tend to a seperated solution.

cylinder -> (monostable/bistable ->) HW/SW

controller -> without sensor -> manual UI

               -> with sensor -> manual UI/feed-back-loop

(sensor ->) 1/2 sensors -> HW/SW

I put some classes in brackets, because they might not be necessary. For exemple if your bistable cylinder only has two control states, which are controlled by one DO (H->V1 open,L->V2 open)

[reteP]

I'm sorry but i don't know what you thought it. My actor cylinder and controller (manipulator) are not into a single object. Similar example is Evaporative cooler, he has real Evaporative HW and Simulated Evaporative HW, Dual fan actor has same real dual fan and simulated dual fan. I want create something similar but my actor cylinder has children ( monostable or bistable cylinder ) and they have also children monostable cylinder with 0..nSensors. Only this is difference.

I want create universal API for cylinder parent class and children will use it. For child I create special method override parent method. For example parent class has "configure method" it is type dynamic dispath and child override it with specific behavior for this child. In application dynamicaly loading specific method for specific child.

Other way is:

Composition not inheritance. Composite cylinder from Sensor and Valve class.

[mike-o-tronic]

You got it!

The other way is the one I was talking about! In the way you described with two seperate classes, you would implement the controller in the sensor as in the evaportative cooler example.

sensor = cooler

valve = pump/fan

If you want to go this way your hierachie could look the same as I described before just without the controller. But the extra controller would give you the ability to control a cylinder manually no matter if it has sensors or not.

[reteP]

I want develop this way. Could you tell me more about how you meant it? Could you sketch some picture ?

[reteP]

Well I go to this way. And now I have one question: IF I create cylinder by composition (sensor & cylinder classes) and after I want create manipulator by composition ( 3 monostable cylinders & 1 bistable cylinder) could you tell me how to do it (manipul object)?

I thought about it but I don't know if I had to do actors to sensor and valve. And then create actor cylinder composite from actors sensor & valve ??

I am little confused how many actors I must do. 😞

Message was edited by: reteP

[mike-o-tronic]

How many Actors do you want to do?

I'd say this is depending on your personal preference and requirements. If you need high reaction time you might want to avoid polling but use change detection... But easiest to start with is probably polling. You can create one actor to scan all sensors and send their states to the manipulator. Or you create a single sensor Actor, give it an id like int 0 and 1 OR better enum "pos limit" and "neg limit". Then send state and id to manipulator.

Regarding the manipulator class I'd start with a manual one. Just make so that it shows your sensor states and that you can control your valves. You can also include a selector to choose how many sensors you want to read and which kind of cylinder you want to control.

For the cylinder/vales it's the same as for the sensor... It's your choice! Either an Actor per valve or one for the Cylinder. When you integrate safety controls like open only one valve at the time, this change wether your safety need to be in the manipulator or in the cylinder.

For the beginning I'd recommend to start with an sensor array. One Actor for all sensors always sends an array to manipulator with either one or two elements. Same for your outputs. One Actor for your cylinder receives an array from manipulator either with one valve state or two valve states.

[reteP]

Hi Mike.

I understood what you mean, but I would like create manipulator actor composite from instance of cylinders. Every cylinder is independent and check own state. Cylinder announces his state to manipulator.

For example: manipulator send message to Lift go upward, cylinder Lift do this message and then send message to manipulator I am done -> manipulator send message to Shift go leftward, cylinder shift announces to manipulator I am done without error or I am done with error. Actor cylinder manage own sensors and valves.

You know what I mean ?

Message was edited by: reteP