MartinMcD Posted November 18, 2008 Report Share Posted November 18, 2008 Hello, I'm a regular Labview user but at the moment I'm trying to learn about OOP in Labview and about scalable architectures etc. I've been playing with this multiple-stopwatch vi for example: http://forums.ni.com/attachments/ni/170/21...leStopwatch.zip I'm about to start writing an application which I'll use to set an analogue voltage out as a request to a motor inverter and collect some data back in. Broadly, I'm looking to do this: -I always want to be able to set an analogue voltage output according to a user slider value on DAQ Device 1 -Some days when I use the application I will want to read an analogue input on DAQ Device 1, other times I won't care -Some days I will want to read serial data from a flow meter -Some days I will want to read pressure data from a USB-6009 -Some days I will want to read speed data from a second USB-6009 I could complete this in the usual way but I see it as an opportunity to learn about classes etc as a way of having a scalable application that will give the user the option at run time to include only those bits of the functionality that are required. (It probably is overkill etc, but it is a learning exercise.) As I'm at the start of a learning curve here I was wondering if anybody could point me in the direction of some examples/tutorials looking at oop-based DAQ design patterns and/or how to implement this modular architecture. Any help would be much appreciated. Best regards, Martin Quote Link to comment
mike_spacex Posted November 26, 2008 Report Share Posted November 26, 2008 I'd love to hear some ideas on this one. DAQ is so flexible and customizable it's near impossible to write something generic enough to handle all use cases. It's far from perfect, but I attached an example of the way I did it recently. I create an instance of my DAQ object for each input I want. I configure that instance by passing it a DAQmx Task and a 'Type', which describes the expected return datatype of the task. This design can be expanded by adding other 'task types' to the DAQ read method in my DAQ class, and other cases for handing graphing and display or logging. Obviously, the same pattern could be employed for DAQ output. By the way, has anyone ever written code that "figures out" from the DAQ task properties what datatype to expect to be returned? If so, this example could be made much simpler. Download File:post-4721-1227628289.zip Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.