ShaunR

Indeed. My gripes are a bit more fundamental than that though. All I wanted to do was add a "Clear" method,alternating row colours and make it accept arrays of strings instead of using the "Item Strings" property to a multicolumn list box. But the amount of effort in re-implementing all the standard stuff just doesn't make it worth it. Only took me 15 minutes to create the control and make the changes I wanted, then it looked like another 2 days to re-implement the standard stuff.

There is not supposed to be a wait. The read function will wait until it either has the number of elements requested, or there is a time-out. In this respect you change the loop execution time by reading more samples. If you are pegging the CPU then increase the number of samples (say to 15000) and increase your PCs buffer appropriately (I usually use 2x te FPGA size). 5000 data points was an arbitrary choice to give a couple of ms between iterations but if the PC is is still struggling (i.e there is some left over in the buffer at the end of every read) then it may not be able to keep up still when other stuff is happening.

Spooky I was playing with Xconrols this weekend too (not fr buffer stuff though). I shelved it in the end since I was really annoyed that a XControl doesn't inherit all the properties and methods of the base data type meaning you have to re-implement all the built in stuff.

Not really. The PowerMeter class has no dependencies its just a container used to manipulate the object you pass in to give the results context and meaning. PowerSensor Could Just as easily be an RTDSensor. You put it more eloquently than I in your previous paragraphs but basically we are thinking along the same lines. LVOOP! My other language is DelphiHorses for courses.

The "Othello" contribution in the "Examples Competition" uses property nodes. Othello

In other words free resource

I too was surprised at a lot of the finalists. Considering the purpose was to tender "Example" code, I think many of them are way too complicated and don't really demonstrate anything that isn't already there. I was expecting small simple, easy to understand demos rather than complex (1-2 MB) applications (although the games one might be the exception). Perhaps I misunderstood the purpose .

Then its your FPGA FIFO that is probably filling up. Try this for the read loop.

Why go for one OR the other. Surely a "PowerMeter" contains a collection of "PowerSensors". (amongst other things ) So my "PowerMeter.GetPowerFromSensor(1..n)" would actually be "PowerMeter.GetPowerFromSensor(PowerSensor)". I would also say you would need a lot of knowledge about the power meter since you probably won't be able to talk to any sensors and it will be the device that contains range, scaling, math functions and probably calibration data (unless the cal is on-board the sensor). So you will need things like PowerMeter.SetRange, PowerMeter.SetSamples, PowerMeter.Calibrate etc, etc. So from my viewpoint, the sensor is just a value. The PowerMeter makes that value meaningful. And PowerMeter, Ammeter, Voltmeter are semantics.

What's the FIFO depth? You need to set it both for the FPGA (when you create it) AND the host (default for the host is 10,000 if memory serves me correctly.) You'll use up the 10,000 n 40ms which can easily happen if you task switch in windows.

Yup. Jacks fault

Hyperbole

Nope. they live in the same dimension only aren't married

If you get rid of the imaqUSB.llb (usb is has been supported in MAX since V2009) you can just include the MAX configuration in the installer. USB Camera Error

Yes it does. It's just not what you think

There are many examples shipped with labview. Take a look at "charts.vi"

In fact. "classic" labview isn't that far removed from "lvoop". If you consider that controls are "setters", indicators are "getters" and inheritance is "create sub vi"

Indeed. Whats missing is that a generic refnum should have the option to "adapt-to-type" instead of being coerced. Properties and methods can already do this, so if the control refnum could also adapt, all the properties and methods inside your VI would follow suit. In effect, you would have a polymorphic VI without having to declare all the sub-vis (for these types of VIs at least).

Indeed. That's why I said it would be nice earlier. Although. If you think about it. When you open up the VI with the control ref. What should it display? The VI itself doesn't know what it's connected to; only the owning VI. The way "Classic" labvVew gets round this is the owning VI selects a VI with a compatible terminal and the only way you can tell it what VIs to select from is by defining a polymorphic VI. The fall-back is to coerce it, then a broken wire. Furthermore. If you think about classes (static ones). The owning VI is selecting the child class which you have previously defined. So in this instance there is no difference between a polymorphic VI and a Class (well. There maybe some but I can't think of any). After all. If you defined the "Boolean" class such that it wasn't a child (equivalent to a VI not attached to a polymorphic instance). You wouldn't be able to connect it either and Labview wouldn't even try to coerce it..

Yes. Because it is coerced!

Well. I read "I think what is wanted is that there is not a coercion dot, because the coercion never happens." to mean that even though there was a coercion dot, it wasn't being coerced. The comparison example was just to show that even in OOP, if you coerce (yes you have to do it manually) then the result is the same.

Agreed. It would be nice. But it kind-a indicates that coercion does happen. The VI's cannot statically change the control refnum without using polymorphism so it has no choice but to either give a broken wire or coerce the data on the wire to a compatible type. It gets even worse if you pop-up the right click menu on the boolean control ref and select "Include Data Type". You won't even be able to connect it to a standard boolean control ref. You will have to convert it to Bool(Strict) first.

I see what you mean. But your "Class" example isn't exactly analogous to the VI example (just being picky ). If you inspect your middle VI, you will see there is a coercion dot. So the equivalent class implementation would be As you can see. this also has the same issue. The class example is really analogous to creating a polymorphic VI