ensegre

I sort of do, it's the CellParametersFrontPanel in the proj; I have one for each class. However, I want to keep the right one visible all the time in a subpanel of the main VI, rater than calling it once with a method. I therefore poll at intervals its output for changes, and live with that output being a variant. This is what I do for now, till I see a smarter way.

Well. Again, my initial picture reflected my initial (mis)understanding about arrays of heterogeneous children, and was not yet a design intent. Certainly it will be a good exercise to cast neatly the hardware collection of this project to a properly structured hierarchy, and to keep things tidy. I dind't mention that my Cells are Devices as much as the Pyrometer or the Manipulator are, that all Cells have one Shutter and one or two Heaters, that also the Manipulator has a Heater, and, and... Anyway, summing up, I learned two things: 1) Arrays of heterogeneous children lvclasses may appear (if you probe them, e.g.) to be of parent class, but their elements retain their individual child type, with all it imples. This was surprising to me because you can't, in contrast, build an array of simple clusters collating elements of different cluster structure. 2) it is not pornographic to pass a variant to a generic accessor, and to let its override decide what to do. In fact, with proper typedefs, it looks to me so far the most economic, in terms of code effort, way of passing my parameters to my different cells. But I'm still learning. For the record, I attach a series pictures of what I'm trying to do. Some class structure: Planned use: Examples of a write and a read (child) parameter accessors

in the picture I only meant to exemplify that one element of the array may be of type "Single Filament". My option is 2), I didn't get to write case selectors for that, sorry if I've been unclear. But sure if the caller BD would need case selectors, rather than selections being handled by the class hierarchy, design is questionable. Now I start to get a better picture. Indeed, "Set Rate formula" was for an example, I'm going to “Show Device Configuration UIâ€. In fact I need. My problems with clustering all children are that I don't know how to retrieve programmatically a cluster i-th element, save to replace it with an element of a different type (unless they are all variants), and that growing the cluster may be problematic; and with arrays of different device types, that each future device type would require a new array. Better to plan ahead.

Accumulating ideas while doing. I have now an implementation of my b), and start to think that now, having written enough typedefs, it would have been more compact a). Still experimenting, but as for yours, wouldn't that require that the hierarchy of Parameter.lvclass mirrors that of the device classes, hence on the long run more tedious to maintain? In my scenario A has its own parameters and B its own. In my present implementation the only do-nothing accessors are methods of P, like P.setParametersA, P.setParametersB. Then in A defines as override only A.setParametersA, doing the real thing. Not sure is yet the best option, but is a start. And do-nothing is really nothing, just a connector pane with the right number of inputs, where the parameter cluster is connected to nothing.

yes, almost. While I realize that casting all my children to an array of variants, as I initially thought, is an unnecessary and fragile detour, there is still a problem: each child has a different set of parameters. I can eventually cluster them and typedef them for convenience, but IIUC accessors and their overriders need the very same connector for parent and children. Thus I cannot just create a generic accessor "Parameters" for the top class, and pass a different argument to it for each children case, unless either a) I make that argument a variant (with the hassle of augmenting the caller with the logic for casting it back to parameters on read), or b) I create a set of do-nothing accessors for each possible set of parameters in the top class, and their individual overriders in each of the children classes. I'm currently seeing how far I get with b). In any case it seems that the caller will need some amount of casing "if children of type A, then call this accessor for A.parameters; if of type B, this other, etc." I have the vague impression that this obfuscates the beauty of OO, so maybe my design misconception.

Quite likely. This should exemplify part of my problem. It's clear I can't wire a parent object to a child accessor directly, and I imagine that I could write a generic accessor for the parent, to be overridden by the children ones. But my children have many individual different parameters, and I hoped to be able to avoid writing a huge number of do-nothing accessors for the parent, covering the joint set of all parameters of all devices. I figured out that if I would be able to determine the child class at runtime, I could properly cast the wire. In fact I meant to go further for an ambitious GUI, to pop up a different control panel for each element of the device array selected, perhaps using dynamically dispatched FPs, but first things first. Thanks, Enrico

I'm just dipping my feet in LVOOP, and hit a wall. I thought of a design -- possibly bad -- in which I maintain a list of devices as an array of instances of a few possible different lvclasses. To represent the devices as lvclasses with a hierarchy seemed me a good start -- all the devices have common parameters, and particular individual properties, for which I created children classes. I can have generic accessors for the common parameters, and children class-specific ones for the particular. It seemed also proper to me, to have override VIs to cause each particular piece of hardware perform a certain generic task in its own way. As for storing a collection, arrays obviously have the advantage of being growable and accessible by index, where elements can easily interchanged, whereas I couldn't think a way of doing the same e.g. with clusters. But if I group heterogeneous devices in an array, the array becomes of the ancestor class, and I lose the access to peculiar properties. Ditto if for instance I wire different class constants to the same output tunnel of a case structure, and rightly so. I thought of circumventing the problem by making the array an array of variants (and being responsible for filling it only with the right objects). I can easily cast my objects ToVariant, but I'm at odd about how to retrieve them back for fiddling with the details. I browsed fora, I discovered vilib/Utility/VariantType.lvlib/GetLVClassInfo.vi, I can retrieve my class names from the variants, but I miss a way to manipulate their contents before recasting them to variant array elements. There are VIs on the Cluster&Class palette like "Get LV Class Default Value By Name", but I end up not knowing what to do with a most generic "Object" with no internal structure. I thought I could use the class name to access its .ctl via its path, but that would only bring me in a cumbersome way to the private data. Is there some better way?

Crossposter. IIUC you can't. The 6212 can do up to 400KS/s aggregate, which is either to 25KS on 16channels, or 200Ks on 2 channels. If it has to be 6212, you'll need eight of them.

pinging in just to say that I tested that it works fine also in ubuntu 13.04, libv4l2-0-0.8.9.1, LV13.

In a further verge of insanity, I've beefed it up with "high level grab oriented" subvis, cleaned up a little the grabber example, and submitted the whole to the uncertified repository. Hopefully formatting it right, my first submission. @Darin: it doesn't really compare with OpenCV; this is only grabbing, while LV for linux doesn't have any image processing VI. OTOH I understand that within OpenCV you can grab via v4l too. However I don't know of any available LV-OpenCV glue besides Eran Herman's, which is commercial and for windows only AFAIK.

View File LVVideo4Linux Mostly for fun, I have concocted a way of acquiring video using Labview for Linux, to mend for the unavailability of IMAQdx on Linux. The idea is to grab via v4l2 (http://linuxtv.org/), actually through the handler libv4l2, and to display simply via the picture control. The package includes wrapper VIs to the public functions of libv4l2.so, high level, grabbing oriented VIs, convenient ancillaries and v42l typedefs. A proof of the concept webcam grabber, essentially a translation of the Appendix E example to the linuxtv API, is also included, as well as the trace of the process used for automatically building the typedefs employed. During the development, this was tested successfully with webcams at different resolutions on versions of LV from 2011 to 2015, on different installations of Ubuntu 64bits, from 12.04 to 14.04. This means, using v4l-utils from originally 0.8.6-1ubuntu2, 32bit, till 1.0.1-1, 32 and 64bit. The files are currently saved for Labview 2014 32bit, and can be run by Labview 64bit if a preliminary script, regenerating some of the typedefs, is run (details in the README). For the bleeding edge of this library, see https://gitlab.com/enricosegre/LVVideo4Linux Submitter ensegre Submitted 09/03/2013 Category Machine Vision & Imaging LabVIEW Version

Mostly for fun, I have concocted a way of acquiring video using Labview for linux, to mend for the unavailability of IMAQdx. The idea is to grab via v4l2, actually through the handler libv4l2, and to display simply via the picture control. I have tested this for the moment only with webcams at 640x480 on LV11 and 13 (both 32bits) on two different installations of Ubuntu 12.04 64bits, and it works. This means v4l-utils 0.8.6-1ubuntu2, 32bit. Attached is a proof of the concept, essentially a translation of the Appendix E example to the linuxtv API, saved for LV11. I include also a loose set of tools I built myself in order to parse the relevant headers and construct semiautomatically the necessary typedefs (LV13, no backsave out of lazyness). I have two questions: -Is this insane enough to qualify for this forum, or do I have seriously seriously to exaggerate? -Is someone interested in helping me to expand the exercise, checking portability on other distributions and versions of v4l2, other supported image formats, more robust packaging & so on? Intention would be to release a package under GPL. Enrico grab11.zip Import_headers.zip

But that's ugly... and would require a duplicate installation... I haven't tried if LV installs on wine at all, maybe someone did and evaluated limitations? ETA: found this couple of 2009 links on the ni fora: http://forums.ni.com/t5/BreakPoint/LabVIEW-Vision-Toolkit-in-Linux/m-p/1030238 http://forums.ni.com/t5/BreakPoint/LabVIEW-4-under-ReactOS/m-p/852977

No plans to support linux, by chance? I couldn't resist installing it on ubuntu12/LV2011, open a few vi's and replace references lvpython.dll --> lvpython.so, but to no avail (would have been pleasantly surprised if it did...)

Passing by, I found this boolean parser on the NI site. It's neat because it works also in linux, but doesn't support variables which is a hindrance for me, because the workaround is to string-substitute variables and parse the formula at each evaluation, which has a performance hit. Enrico