DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Does it make sense to write a DQMH instr. driver for this case?



Why is it broken? Can you elaborate?

 



I'll try! As far as I understood from the related videos the DQMH module always need to use the base class. I believe it is because I could instantiate any of the classes and if I have a method only relevant to a certain class and not to the others then the DQMH module gets broken.

 

For example staying with the camera module. I have a base class ("camera base class") and its two children classes ("webcam", "industrial cam"). The base class has couple base methods like open / close session, grab a frame and so on. Each base class methods are implemented to return an error message saying that "this method is not implemented on this class", so if I create child classes and need to override these VIs with the camera specific implementation otherwise they return an error.

 

So far so good, but I'd like to implement a "Set / Get IMAQdx property" and create a DQMH request to it. Because webcams dont have such IMAQdx properties I feel that the first appearance of this method should be on the "industrial camera" class. But if I do so then there is no base class method I can put to the DQMH module and my module gets broken. I  think understand this because it is possible that the DQMH module class-wire has a webcam class but really nothing blocks me to call the "Set / Get IMAQdx property" request and as there is no webcam implementation of the method the modules get broken.

 

If I'm right above, then this suggests that all the childrend/grandchildre etc class specific methods should have a base class implementation (eg: a returning an error like I mentioned).

 

This could be the way, but it looks a bit weird to me so I rather assume that I grossly misunderstood something about classes in dqmh modules.

 

 

 

0 Kudos
Message 21 of 24
(444 Views)

 

So far so good, but I'd like to implement a "Set / Get IMAQdx property" and create a DQMH request to it. Because webcams dont have such IMAQdx properties I feel that the first appearance of this method should be on the "industrial camera" class. But if I do so then there is no base class method I can put to the DQMH module and my module gets broken. I  think understand this because it is possible that the DQMH module class-wire has a webcam class but really nothing blocks me to call the "Set / Get IMAQdx property" request and as there is no webcam implementation of the method the modules get broken.

You could approach this a couple of ways:

 

1) Rather than having a method Set / Get IMAQdx property, instead have something more generic like Configure Camera.  And then both the IMAQdx and webcam camera child classes can have their own version of this method, both overriding the parent class.

 

2) You have the Set / Get IMAQdx property method in the parent class, and being overridden by the IMAQdx class.  But in the DQMH module, you only call this method if you have setup to use the IMAQdx class (and not the webcam).

 

If you want to use the factory pattern, the parent class needs to have the superset of methods.

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

Message 22 of 24
(437 Views)

+1 to what Christopher wrote.

 


@1984 wrote:

For example staying with the camera module. I have a base class ("camera base class") and its two children classes ("webcam", "industrial cam"). The base class has couple base methods like open / close session, grab a frame and so on. Each base class methods are implemented to return an error message saying that "this method is not implemented on this class", so if I create child classes and need to override these VIs with the camera specific implementation otherwise they return an error.


I would discourage this practice.

 

As you have already alluded, it generally doesn't make sense for the base class to have dynamic dispatch methods that ALL immediate sub-classes don't implement. That is a scope for design improvement, along the thought process of what Christopher wrote.

 

The error shows up at run time, which is 'late'. You could enforce overrides, thus causing 'broken arrow' at edit time. When adding VI for override in a class, the Developer implementing this base classes can identify and add all the 'required' overrides at once. If the overrides are missing or do not match the connector pane of the base, the run arrow will remain broken.

 

0 Kudos
Message 23 of 24
(427 Views)

"Get Available Names Properties.vi" and "Get Property by Name.vi" are possible base-class methods that both your child classes can implement, even if your webcam turns out to have no named properties.

0 Kudos
Message 24 of 24
(416 Views)