Philip Timson

QUOTE (Dan Bookwalter @ Nov 28 2006, 12:01 PM) I'm currently working on trying to implement a Hardware Abstraction Layer, and I'm considering OOP with dynamic dispatching as a solution among others. Mike Piehler from Boeing gave a good presentation at NI Week on this topic: ftp://ftp.ni.com/pub/events/niweek/pdfs/p...ions/ts1111.pdf ...however it seems a little over-simplified. It also seems like a lot of overhead to create a 1 for 1 wrapper class for each instrument driver, but if that's what it takes it may be worth it. The main purpose I would implement a HAL is to allow for a "system" driver to change without affecting released "applications". I believe most people implemnt a HAL so that their "applications" don't require huge changes when switching instrument drivers, but I'm trying to take it a step further so that ideally I don't even have to touch or re-release the application if an instrument driver changes. I'm struggling with how this could be done using LV classes. In Tomi's example above, if the application uses the My Hardware Implementation.lvclass, both that class and the parent class, Driver Interface.lvlib get included in the application build/package since they are dependencies. Now if I needed to add a new Dynamic API method 4 for a new instrument, then I have to touch the application and re-release. Perhaps it would be possible to not touch the application if the class references are passed into the application and dynamically dispatch a child class. For example: if a parent class, Parent Driver.lvclass, is referenced in the application and a child class, Specific Driver.lvclass object reference is passed into the application, then you could define other "specific driver" classes outside of the application and dynamically load them during run time. Or perhaps in the application build/package, you exclude the classes altogether and make sure they are on the system before running... Am I missing something? Thanks, Philip