ShaunR

Hi Pete

This is a common problem and I’ve seen many people going down the road of having one Power Meter object and then calling it like PowerMeter.GetPowerFromSnesor(1..n).

I don’t like this approach because if you only start with only needing 4 sensor (assume that the Power Meter only have support for max 4 sensors), then your top application only needs to create One PowerMeter object.

Then you suddenly needs another PowerSensor, then you have to create another PowerMeter Object and know which sensor ID and which PowerMeter every sensor is linked to.

Instead I would go for the PowerSensor objects.

Remember that the objects should reflect the reality, and it’s Power Sensors you are dealing with.

If you need to have the knowledge of the PowerMeter I suggest that every time you create a PowerSensor object, just also creates a PowerMeter Object if needed and adds a reference to it.

When I say needed, I would use named objects of the PowerMeter and if the PowerMeter this sensor is using has not been created yet they create it, and if it is already created then refer to the same object.

Of cause this requires object by reference.

This is how would have done it.

PowerSensors.zip

(LV 8.6, using GOOP3 object from GDS)

Now I like someone to give me the solution to do this with ByValue objects. ( my reference objects )

Cheers,

Mikael

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.

I'm hoping someone has run into this and can point me in a good direction.

The test machine I'm using is a 2.79 GHz Pentium 4, WinXP, 1 GB RAM system with a PCI-7831R card in it. I'm running LabVIEW 8.6.1.

I'm trying to stream data from the FPGA to the PC over a DMA FIFO. I've picked 250 kHz as my current benchmark as that is significantly above where the actual system is going to need to run. The FPGA side uses a fixed time interval (4 usec) FIFO write. The PC side uses two loops, one to read a latched timeout flag in the FPGA and one to read out the FIFO in a 20 msec loop.

This works most of the time until I do something like minimize Windows Task Manager. The CPU usage doesn't blip and stays at ~25%; the number of elements remaining in the FIFO jumps to 30,000+ and I start to lose data points as the FIFO write in the FPGA times out.

I've attached my test code.

I appreciate any light people can shed on this.

Tim

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.

Buzz kill?! It appears the whole thing is dead...

we've decided to remove the LabVIEW Add-ons Idea Exchange and merge the ideas posted there into the LabVIEW Idea Exchange.

Yup. Jacks fault

Oxymoron?

(:<))

Ben

Hyperbole

I really love this one, but .........

I often wonder where people get the time, do they live in some parallel dimension whereby they do not have to do the dishes, take the child to hockey or gym or whatever and all the rest

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

Doesn't work.

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

I've got numeric indicators in my block diagram. The numeric indicators show the temperature and the graph is supposed to show the numbers running. Like for example when I put Annealing-90 degrees, Denature-60 degrees and Extension-55 degrees, the graph is supposed to plot those temperatures in order of Annealing, Denature & Extension. Anyone can help out here on what I can use to make this work?

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

You've got it, we need the VI server types to be thralled like LVOOP.

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"

I see where you're coming from. Agreed.

When I open up the VI with the generic control ref, I'd expect it to only know about the generic control ref. That's the interface the VI has set by virtue of its connector pane. What would be ideal though is if the VI had some way of recording continuity between the input and output. This facility does exist in LabVIEW, for example with dynamic dispatch method for classes it is indeed required. I have no idea how this gets sorted out for static methods given that the same requirement is not in place (maybe internally the compiler is still aware of in/out continuity?). It would be nice if refnum in/outs had the same functionality, or you could have another type of in/out connector that mimics the behavior of classes for refnums, such that explicit coercion does not happen when passing child refnums to parent methods.

I suspect though that the details lay in how refnums are actually implemented. Something tells me we are not dealing with a strict inheritance implementation which will always force a coercion: there is no actual polymorphism happening with refnums (or dynamic dispatching in LabVIEW language). It's probably the same fundamental difference which results in the limitations imposed on class DVRs which prevent dynamic dispatching.

Now that I've thought this through, I suppose it makes sense why it is the way it is. I still don't like it though...

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).

Right! But it would be good if the compiler were smart enough to know not to coerce it, just as it does for classes.

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..

The same thing is not true with VI server references. A boolean reference that runs through a control reference will still contain the boolean reference number, but the wire will be a control reference. You need to recast to boolean to be able to call methods that act on booleans.

Yes. Because it is coerced!

What Jarrod was saying is that your example is flawed because you upcast the object yourself. If you just wire the child class directly into the parent VI it would propagate through just fine (assuming there's no overriding VI in the child class).

This, of course, can only be done today using LVOOP.

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.

I think what is wanted is that there is not a coercion dot, because the coercion never happens. The type should be propagated across the subVI without changing.

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'm actually looking for the opposite of run-time polymorphism. I'd like a way for static compile time info to somehow be propagated. Take for example how you can wire up a parent method of an OOP class in the middle of a child class wire, without the wire being coerced to a parent class (shown in the bottom of the screenshot). LabVIEW is smart enough with objects to be able to figure out when type information can be propagated through a VI call with objects at compile time, it would be wonderful if that could also apply to refnums...

Is that more clear? I'll point out that this is more of an "I wish it existed" post than "Is there a way to do it?" post...

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

Try this.

Perhaps this is an easy question but I'm banging my head against a wall.

Trying to monitor files on a bunch of production test computers that operators have access to. I have a computername, login name for a local admin, and password for each computer.

Obviously if my IT department would configure any one account as the admin of all these computers I could access it that way, but they won't.

The files are all in a common location on each computer, say \\computername\c$\etc

Windows will cache the login/password of each computer if I go there first manually, and then it works. But that doesn't allow me to share the file monitoring tool with anyone else.

Is there a way to specify for each directory path exactly what windows user I want it to connect as?

Easiest way is to "map" a network drive and use different credentials. Then you wil end up with X:, Y:,Z: mapped to the different accounts either to the same remote dir or different ones.

I'm not sure what your asking here. Type information? If you mean the controls class (e.g boolean, string etc) then it is propagated (if you inspect the class name you will see it).

If you mean you cannot connect a parent class refnum to a child class refnum and have it automagically choose the appropriate refnum then no. Because "classic" Labview doesn't support run-time polymorphism. You have to go to OOP and use dynamic despatch (which wouldn't be much different from creating your polymorphic VI).

The only way I know of that you could achieve a similar behaviour in classic LV is to make all your refnums variants and coerce to the specific class within each VI. But then you can connect anything to anything so it wouldn't flag up (for example) that you had connected a real control rather than a refnum until you ran it.

There is the possibility for update requests to pile up pretty quick. If for example a user holds down the increment/decrement button on a numeric control, dozens of value change events can get generated in a second, each of which will require an update to the tree, which seems to take on the order of a half second. I also like the idea of tinkering during timeouts.

I suppose the other way of doing things is have the tree update be entirely asynchronous. Just keep it notifier based, or something such that multiple requests don't pile up if they are generated faster than they can be consumed.

As an aside, I still can't believe tree controls are this busted. Changing UI properties for non-displayed items should be near instantaneous. If NI won't implement it, I wish they'd expose more events such that we could apply updates more intelligently. And for the non-believers, if I disable all the tree operations in the screenshot I posted above and instead blindly operate on all elements in my variant/hashtable, my updates happen in mere microseconds, so it's not my interaction with the variant or my subVI that was choking things off.

Once I get an initial code out there that works, I might tinker with dropping a custom .NET control into there or something that...works.

Have you tried using the .NET TreeView control.? You have access to all TreeView functions and you can add callbacks (if you need them). You can even do things like embed other controls. Not that you need to, but it just demonstrates the huge feature set. It should be a lot faster for your purposes.

I'm not a fan of .NET. But "The needs must as the Devil drives"

Try here

Another method is you can overlay a boolean array (flat square classic buttons work best) where the booleans are transparent except for the true state border colour. Then you just use the number to boolean array primitive to set one or more booleans "True" for the value or values you want to highlight in the main array. This will create a border around the value. But if you move it behind your array and make your array transparent, you can also make the boolean array "True" state bg coloured and it will look like you changed the background.

is there anything i can do so that the uploaded image will stays on the VI.. i need to do this image to run the simulation.. is it possible to make a 3D simulation using LabVIEW?

I suggest you re-read my response on your other thread asking exactly the same question.

http://lavag.org/topic/13269-how-to-upload-image-into-labview/page__pid__79462#entry79462

tq..what is other type of files that can be used?? i need to simulate a rocket flight control sys.. and can u tell me how to upload the image plz..

Well. I can only talk about Solidworks. But it wasn't an image. It was a VRML file and you wrote a VI that solidworks could interact with. As such, you created a Solidworks plug-in.

If you just want to get the image on the front panel, you can just download a jpg or png and use the "Import Image To Clipboard" and paste it on the front panel. . You could overlay Labview controls like dial gauges etc which you could use to simulate the controls with programming. But I don't think you will be able to define everything in the 3D package and just "import" to get a working simulation.

Jeez! I'm not that old.

Sorry

And I take back anything nice I've ever said about you. If there was anything. So there. :P

That must have been on LAVA 1.0 then

It's been over 10 years since I've done anything with databases and back then we were programming in VB6. At the time one advantage MSAccess had over other solutions was that it had a pretty easy ui that allowed users to query data. Do the other solutions offered have good data viewers available?

I use "phpMyAdmin". But of course it needs to be part of a web-server.