LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Extend HAL with specific methods/parameters

Dear NI community,

let me, please, ask you one more question regarding hardware abstraction layer (HAL) implementation.

 

I am implementing now HAL classes with methods, which have common inputs/outputs. Then, there is API VIs for calling of these methods; and API VIs, as the top-level VIs are called from TestStand/LabVIEW.

 

But the problem comes, when some device needs specific setting/parameter. So, it means, that I have two ways of implementation:
- create new method for generic HAL class, and then implement it in specific device class;
- extend specific device class with the private method.

 

Both of solutions have issues. The first one:
- now, specific device implementations classes would have methods in override what they don't need (not a bit issue at the end, I can leave with that, but it seems for me that it's not so nice solution);
- if existing method needs additional parameter, it's not good to create new method which will do the same, but will have additional input. So, I can implement method of setting up that parameter, and then use it internally in specific device implementation. But, it is difficult to see for the end user, and without proper documentation purpose of that method could be unclear in the future.

 

The second one:
- if there will be private methods, it means, that I need to create APIs specially for them. Thus, LV code/TestStand sequence will contain steps for particular, and not abstract hardware. So in case of instrument change, it will be not enough to init HAL class with proper instance. I will need to remove that specific API call step. If I'll not do it (hopefully, I'm not mistaken) then while running other specific implementations of the class on that device-specific method could cause error (or not?), b/c that method is not common for siblings classes.

 

Is there some third way? And which way is more preferrable, please? Or there is no some strict experience with it, and one should consider it based on the situation?

 

Thank you very much in advance!

 

Sincerely, kosist90

 

logos_middle.jpg

 

JKI VI Tester – useful tool for LabVIEW developer

0 Kudos
Message 1 of 5
(2,841 Views)

On a comment of extending unnecessarily - if you don't want a class to be able to call a dynamic dispatch method, you can choose not to override it, and set the parent method to unconditionally output an error. Make it so that overrides never have to (or try to) call the parent method.

 

Then, if a class that shouldn't use a method tries to call it, the parent method is used and an error is returned. Not sure if that helps you but might be useful?


GCentral
0 Kudos
Message 2 of 5
(2,806 Views)

Thank you, cbutcher, for your reply!

 

Yes, this approach could be possible to use, but indeed when child HAL implementation will run method which they don't have defined (and they should not have it defined), I'd prefer that no error would occur. If child class must override parent's method, then let it generate an error.

 

In my case it's not a problem from execution point of view - that class can call parent's method which he should not call. For me it's logical error - to leave possibility implement method for the device, which does not need it.

 

If I will need to add new methods/parameters for existing methods of the parent HAL, then later on my generic HAL class will contain dozens of methods, but child classes will use just few of them.

So, either such design smells, or while adding new, device-specific method I need to extend child classes with private methods, but then later on to change my API VIs calls, to include those specific methods, or exclude them...

And this is what I am not sure of about...

 

Sincerely, kosist90

 

logos_middle.jpg

 

JKI VI Tester – useful tool for LabVIEW developer

0 Kudos
Message 3 of 5
(2,795 Views)

I guess you already tried this, but can the device specific additional private methods be added at Initialization of that specific device? Is the information for the additional settings known, or does it depend on test-specific information?

 

Can that information be given to all devices, with the other devices just ignoring it? I guess that sounds quite similar to the first method though - giving everything information which maybe it doesn't need...


GCentral
0 Kudos
Message 4 of 5
(2,772 Views)

I've decided to change point of view on this topic.

One needs to have the same methods (dynamic dispatch methods) for all HALs implementation in case of plugin-style: when one wants to load any device type dynamically.

But if I'm going to implement some API VIs-wrappers, which will deal just with some particular HAL implementation, I can extend my modules with static/private methods, put on the connector pane HAL Generic class, and inside just check "Preserve Run-Time Class" to be sure, that this method must be present in API while I'm using specific HAL implementation.

So, when I'm statically link my HAL implementation class, which is based on some HAL Generic class, I'm using benefits of HAL - b/c I have general methods templates, it saves my time - but also can add device specific methods, without "spoiling" other HALs implementations by not applicable classes.

Thus, open/closed principle is kept, and core methods will be reusable, and not modified.

 

Sincerely, kosist90

 

logos_middle.jpg

 

Caraya test framework for LabVIEW – convert your VIs to test code!

0 Kudos
Message 5 of 5
(2,736 Views)