Joseph, no, I've never used MAX before for that kind of thing. Can you give me a pointer for how to get started looking into it?

[crcarlin]

'Twas a joke, for. Hence the lighthearted smileyface.

On the negative side, let me put it this way: If I tell my users that LabVIEW can't provide one-object-per-device operation, they'll ask why we're using LabVIEW. Which is a fine question. If LabVIEW doesn't provide the functionality they quite reasonably want, that's not the fault of their wants, but the fault of failures of LabVIEW to provide the solution. My users are already kinda pissed about LabVIEW's lack of development on Linux.

On the positive side, when this stuff DOES work it's pretty great: being able to swap one object for another faster than one can swap one device for another means LabVIEW doesn't stand in the way of replacing failed meters and can support situations where a measurement has to be taken with whatever happens to be onhand. But that all falls over in the simple case that a meter can measure more than one thing.

And from my perspective as a developer the lack of interfaces/inheritance/whatever means I have to do a lot more work that's more error-prone.

So no, I'm not looking to have a sit-down with my users. I'm on their side! They ask for a reasonable thing that benefits me as a developer, and if LabVIEW can't provide it... that's not call for us to change our demands.

[GregFreeman]

I still think the initial problem is that you are combining measurements and devices into a single class. I think you need to do as follows, you can take it or leave it. I also suggest you post over on the LAVA forums in the OO section.

Define a Device base class. That class has a VI set to must override called "read device data." All your devices inherit from this class.

Create a measurement class. That measurement class has a VI called Take Measurement. All your different measurement classes inherit from this class. Put the measurement classes that are applicable to a device in that device's private data. For example, if your device can measure temperature and pressure, you put the temperature and pressure measurement classes in the device class private data. If you want to use Dynamic dispatching you can also have an array of measurements, make the Take Measurement dynamic dispatch and loop through the array, calling all appropriate take measurement functions. In this case, you would want that array in your parent class, most likely, since all devices will have it.

Now, when you override the "read device data" VI, you call all the different Take Measurement functions for that device.

If they want to add some new device, it's easy. You add the new device class, override the read device data for that class, put the measurements it can take in the private data, and boom you're done. Does this help at all?

[GregFreeman]

---

@for(imstuck) wrote:

If they want to add some new device, it's easy. You add the new device class, override the read device data for that class, put the measurements it can take in the private data, and boom you're done. Does this help at all?

---

I should add, if you put an array of measurements in teh base class, you don't have to override the read device data VI. You will always call the base class read device data method, which will loop through the array of measurements for that device.

[crcarlin]

Hmmm: interesting, interesting. It's more complicated that I'd like, but it's something I haven't thought of. I'll have to mull over it in the morning.

One thing that strikes me is that it might preclude passing units. In the past we've had catastrophic (that is, multi-hundred thousand dollar) failures that I suspect were rooted in unit inconsistencies in LabVIEW programming, so I insist on applying units ASAP. I don't want to give users an array of unitless numbers because I don't trust them to deal with units properly.

But I need to think this through tomorrow. There might be a way to make this work.

[GregFreeman]

---

@crcarlin wrote:

Hmmm: interesting, interesting. It's more complicated that I'd like, but it's something I haven't thought of. I'll have to mull over it in the morning.

One thing that strikes me is that it might preclude passing units. In the past we've had catastrophic (that is, multi-hundred thousand dollar) failures that I suspect were rooted in unit inconsistencies in LabVIEW programming, so I insist on applying units ASAP. I don't want to give users an array of unitless numbers because I don't trust them to deal with units properly.

But I need to think this through tomorrow. There might be a way to make this work.

---

Complicated is relative here . I think you will find this to be less complicated in the long run. Although the initial design may take a bit more time, the separation of the device from the measurements it takes will be much more flexible, allowing you to add additional measurements, without adding new devices, or adding additional devices which can use existing measurement types. Best of luck, I hope you get something to work out for you. I'm sure you will, sometimes it's just not the initial thing that jumps to mind. 

[M_Peeker]

I get a feeling that your users are asking for a system that is flexible and easy to use. Flexible enough to solve your problem at hand, easy enough to keep the one object per instrument paradigm. They need to understand that this is not an easy combination (Steve Watts rants about this here), and this is not due to the development environment that is chosen.

When it comes to interfaces, yes, you'll need to implement them. There might be solutions out there for you to use, here and here are a few links on LAVA, but using them will still need for you to convince your users that they need to accept a new design.

[crcarlin]

Oh, but in this case it IS an easy combination BUT FOR the development environment.

This isn't some monstrously difficult or sprawling project. Essentially it's simply a way to do the bookkeeping on which devices can do what and which commands to send. All of the design complexity is coming from finding a way to work around LabVIEW's shortcomings. That points the source of failure here squarely at LabVIEW itself.

And so that would be the message I give my users: You ask for something reasonable, and LabVIEW can't do it. Sorry.

Maybe in other situations we could talk about the users asking for something crazy where it would take months of designwork just to figure out how it would fit together, but not here.

[Joseph_Loo]

Have you thought of using Max in combination with your objects. You can create a base device for analog values. Put all your error and include the task name in the device. In the intialization, you load the object with the proper task name associated with the device.

In max, you define the global task name that you want to use. In addition, you setup the conversion formulas in Max.

When you instantiate the object with the instrument, it will now read the correct values associated with the instrument, temperature, pressure, ohms, etc..

An advantage of this, is that the device position or channel can now be made independent of the device and the location. You just need to make sure MAX configure the item correctly. This will allow you to change your setup ver easily without changing your program. I use an ini file to set up my system to read the different items. Note, you will need to set one up for bolean and integer.

Don't forget to export the max configuration. That way when you export like system, you can bring it up easily on the systemwithout too much configuration changes.

[crcarlin]

Joseph, no, I've never used MAX before for that kind of thing. Can you give me a pointer for how to get started looking into it?

I tried poking around just now, and I can't create a global virtual channel or task without a physical device, but I don't see a way to register a meter (connected by serial) as a physical device in the MAX system.

If there's a way to let MAX handle the interaction with the device and just pop out a measurement when requested, I'm more than happy to go that route!

(Side note: my objects take a VISA address as input to an instantiation vi, so moving stuff is no problem, and switching between meters is only a matter of popping in a different instantiation vi)

[Joseph_Loo]

Joseph, no, I've never used MAX before for that kind of thing. Can you give me a pointer for how to get started looking into it?

Open up MAX. click on your device. In the menu, you will notice that there is Create Task in the next menu.. This will allow you to create the task you want. In the task for analog there is additional things that will allow you to modify the output. I am assuming you have the Labview drivers.

I tried poking around just now, and I can't create a global virtual channel or task without a physical device, but I don't see a way to register a meter (connected by serial) as a physical device in the MAX system.

Assume the serial device operates similiarly. You can create a base class to interface with the serial lines and have that as your input. You can then create an object that the class has and allow you to convert the values into your values you need to display. Again in the initialization, you can init the base class with the proper class for the conversion. Then you can use the device name as your basis to select your data. Note, you should name your serial device with a name and not use the standard name generated. Tah way you can control the deviceand setup more easily.

If there's a way to let MAX handle the interaction with the device and just pop out a measurement when requested, I'm more than happy to go that route!

It depends on the device driver. I had a series of boolean values and did just that.

(Side note: my objects take a VISA address as input to an instantiation vi, so moving stuff is no problem, and switching between meters is only a matter of popping in a different instantiation vi)

You will discover naming it to be much easier to do. Lesson learned when I had a fieldpoint that was moving in different location on the bus.

[Joseph_Loo]

I tried poking around just now, and I can't create a global virtual channel or task without a physical device, but I don't see a way to register a meter (connected by serial) as a physical device in the MAX system.

Assume the serial device operates similiarly. You can create a base class to interface with the serial lines and have that as your input. You can then create an object that the class has and allow you to convert the values into your values you need to display. Again in the initialization, you can init the base class with the proper class for the conversion. Then you can use the device name as your basis to select your data. Note, you should name your serial device with a name and not use the standard name generated. Tah way you can control the deviceand setup more easily.

If there's a way to let MAX handle the interaction with the device and just pop out a measurement when requested, I'm more than happy to go that route!

It depends on the device driver. I had a series of boolean values and did just that.

(Side note: my objects take a VISA address as input to an instantiation vi, so moving stuff is no problem, and switching between meters is only a matter of popping in a different instantiation vi)

You will discover naming it to be much easier to do. Lesson learned when I had a fieldpoint that was moving in different location on the bus.