ensegre

Right click on [3] "Play video", "Record Button" Value change -> Edit Events Handled by This Case. What is the word Homework in the title of your window?

you have "Lock panel" on in handling your event case?

without seeing your code, no. My guess would be that, if you're following the usual way of the IMAQdx example, that is register a dynamic event for frame done, and handle completed frames with an event structure, your webcam is generating events faster than you can handle/the front panel is locked while you're handling that event or something the like. I remember having seen a number of webcams/usb,firewire,Gige genicams generating two events per frame rather than one with this scheme, for reasons I never understood.

So, after hours trying to pinpoint an UI bug, I've narrowed it to this: I have a main VI inserting a subpanel and calling it like this while the supbanel may decide to change the tip strip of one of its controls: It's obviously pointless to rewrite the same property every 100ms, that was the unspotted mistake of my original UI. Skipping whether that was dumb or not, here is the weird fact: if the tip strip property is written, cut/copy/paste into any of the subpanel controls using Ctrl-C/X/V won't work, no form of them (all content, selection, at the insertion point). Only Shortcut Menu/Copy Data & Paste Data work, on the whole content of the control, and, in linux, 2nd-button mouse inserts regularly the X selection. If, say, text background color is written instead, copy/paste is ok; I didn't try extensively other properties. Can this be called a bug or is it just a worthless idiosincracy? I've tested these snippets on linux, but observed the original bug which led me here on windows as well. SimplePanel.vi UncopiableContainer.vi

Note taken, thanks. In defense of llbs I can say: they are fit for me to unclutter small scale projects (up to a few tens of vis, SCC secondary), which are to be deployed as main.vi + ancillaries packed in a single place, when the development environment is anyway present on target. That is our common use case in the academia. We have a blanket license and don't mind installing the extra copy, lifetime of software may be very short (three days till the student realizes that he wanted something else, or that the measurement has to be performed differently), need for maintenance and adjustments onsite are a constant, and instruction is often part of the game. And plain llbs don't need a project.

At the risk of saying something obviously off mark, couldn't be that displaying the extracted numbers in FP indicators is the real bottleneck? (especially if you have a weak video adapter)

I'm on ubuntu with qgit (my comments about integrating LVCompare). I have tortoise for mercurial and am not aware of plugins for git, maybe they exist but I haven't researched too much.

doh! you're right. [excluding Dependencies/vi.lib, I assume]

Has anyone tried this on linux so far? I gave a shot to it and stumbled into the following: LVCompare opens a new session of LV at each call. I presume that it is screaming for me to change labview to labview -launch in the couple of relevant places within the script. Btw the mechanics of /usr/local/natinst/lvcompare/LVcompare involves creating a file /tmp/LVCompare.ini which contains the absolute pathnames of the files to be diffed and the comparison flags, which the closed vi /usr/local/natinst/lvcompare/supportVIs/_prolvcmp.llb/LVCompare.vi subsequently erases; however there seems to be no problem as long as calls from an external script are correctly sequenced and the files to be diffed survive until termination of LVCompare. I anticipate a problem if more that one file couple is compared at a time. Integration with common git GUIs. I've randomly tried in qgit (the one I use daily), gitk, gitg, git-cola, giggle. In none I could get diffing work nicely if at all. Common issues are: a) an external diff program can be configured, but inflexibly for all file types; b) the temporary files to be diffed are nevertheless treated as text, truncated at the first \n, and useless to LVCompare. What instead turns to be a non-issue, is absolute pathnames, because these guis pass it nicely to the configured differ. That doesn't mean that I might not try harder in future, studying harder the options of git config, or writing a diff script which calls either meld or LVCompare depending on the file extension, for perusal of the only GUIs which treat binaries as binaries, but for the moment my motivation is low -- unless someone has already a ready solution to share.

which brings me to rush to do it at this point, like this: but what should I do for *.lvclass (and other types which I possibly forgot)?

Thanks everybody. Will dip into the threads suggested. Good to hear that I'm on the right track.

Maybe a blurb of noob faqs, so apologies if I'm asking the obvious. I have used different SCCs for various text-based projects in the past, like cvs, svn, git, and I'm familiar with the idea. Now I decided to adopt git (namely hosting at gitlab.com this time, for convenience) for a big LV project which screamed for it since its beginning, and I'm tucking fine with that. . However, git itself is agnostic in treating all my vis, llbs and so on like binary files. That means to me that my repository grows in time at a quite fast rate, and that diffs are completely obscure. I am not able to tell for instance if an llb changed because a single vi was recompiled or because of more extensive changes. That may ultimately constrain my strategy of committing, for example avoiding llbs at all in favor of subdirectories in order to gain in granularity, or reducing the frequency of updates to limit size blowup. I'm also missing specific tools for, say diffing and blaming files in a LV meaningful way. This in contrast to text-based languages. In the present project my only text files are .lvproj, .lvlib, some xml configuration files and lyx documentation, not the core code, so that doesn't bring me very far. To compare two snapshots of the project I presume that I would have to create two copies of it on disk, rename some relevant VIs, load both copies in LV and compare them... not inspiring as a workflow. Is it all one can get, or am missing the obvious? I mean, after all what is this Tools/Options/Source Control/Provider name thing, and why does it display "<None>" in the pulldown? Oh, help: "On non-Windows platforms, LabVIEW runs a query to determine if Perforce is installed". So what, I can do SCC only if I depend on a single commercial service provider? Can't believe...

Indeed. I realized that only afterwards. leftover of my other attempts with other types, while trying to understand. Agreed. my aim was to detect value changes in the class object, hence I'll have to decide whether I still want to allow NaNs as data in it and go like this, or to change design. Thanks for your investigation and for escalating the matter for me!

Ok, I understood something: my object has some NaNs, so I'm essentially affected by (NaN != NaN) being true. However, there is still something which puzzles me: to test the differences between passing the data reference in a tunnel or a shift register I've put together this variation The class object and the cluster (or even a single NaN constant, for what matters) don't behave the same way I could speculate that the Equal? and the Not Equal? blocks are smart in some way that avoids the detailed comparison if they know a priori that the data reference is the same, and that the shift register must do a data copy at every iteration; however, something may be different in the mechanics for classes. Intriguing.

I ran into this. Two class objects which should be identical, result as different in the following: I've tried a few variations of the snippet, and it seems that the comparison of this particular class object with its data (but not other instances) diffs if the shift register is involved, while two static copies of it would result as identical. Intriguingly, if I pass the objects to the subVI Diff... they result as identical. Is someone able to shed light? I'm on LV2014/linux, haven't yet tried in other versions. ClassComparisonBug.zip

Would this be better? I've moved the generic referencing to my config panels inside the children accessors (and duplicated it for every children), using class specific typedefs. Maybe it is more boundary savvy, still I found no better way to conceive my "read from class object and write to config panel" and "read config panel and write to class object" than as accessors for a VI ref. Accessors for parameters config would result in a different cluster for each class, with the previous issues; and the FP reference is needed in order to insert in the caller subpanel.The VI ref has to be generic in order to be overridden, hence I can't use a Call by reference, and still resort to retrieving the configuration panel control as a variant, and cast it within the WriteConfig accessor. In any event, if I'm asking too much attention on this thread, I can pause, and walk a bit on my own feet. Your assistance has been very helpful!

I've been scratching my head thinking "is it me who doesn't see it because I'm fresh to OO, or" for a while... But there may also be design reasons for me to keep things like this (and fit to my competence level) for the time being. Among them: Variants: a side advantage of the present form is that I can detect a class type change as well as a value change within the same type, just with a single disequality. bundling and unbundling: I'm fine with them for the time being, because I'm still figuring out which parameters of each class to expose as configuration, and which as operational. And for configurations things may get a bit tricky: i.e. Cells may have two Heaters, Heaters may have Configuration and Setpoints, but it is not said that Cell.Configuration is Cell.{Configuration.Heater1,Configuration.Heater2}; for some kind of Cells part of the second may depend on the first, and so on. VI refs: my anticipated scope is the only two calls above in a single main VI, I don't feel the need of abstracting for now. Also, I fear that both configurator examples mentioned by Yair are an overkill for my learning curve, but AQ's one I'd rule out since I don't want to configure the whole Cell class, only some of it. My design choice is to split classes per hardware, not per functionality. And I wouln't want to create a parallel hierarchy of Configurations.

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.