LHarris

LAVA - the only tee-shirt with nano-wire sleeves especially designed to slice your arms off!

Good idea - and any new controls I add will be automatically added to this too. Thanks!

I need to add a routine that will re-initialize almost all the controls and indicators of the top-level vi to the start state (but retain a few that show history etc). Two ways spring to mind - a straight-forward wiring of required values (eg FALSE constant wired to all LEDs that should be off, etc) or use of an invoke node for Reinitialize to Default for each control/indicator. Invoke nodes have the advantage of always matching the default value set on the FP, but I could (and probably will) call the re-initialize routine at startup anyway, so that shouldn't be a big issue. Then I started wondering whether the performance hit for property nodes applied to invoke nodes as well. Granted I will probably use DeferPanelUpdates anyway to only refresh the FP once after all values are set, and the user won't mind a small pause at reset (in fact they'd probably expect it) but the function could be called frequently so I'd still like to make it efficient. Anyway, just wondering what other people think .....

Depends on the users - large bold red font can be enough to invoke panic & constant calls to support ......

Not yet - I'm still waiting on approval to purchase (big company so moving slow). I think cleaning up any extraneous data or noise in the image helps (using thresholding) as well as ensuring an accurate ROI & rotation point (center of the circle) - or as accurate as you can get. Other than that, I am just trying to filter ridiculous values - but of course that leaves me with no data on those comparisons.

The reference is the same every time because it is pointing to the same string element on the front panel, rather than a specific element of the array. Try this - have the array counter set on 0 so you can see your "a" "b" and "c". Click on C. Then change the array counter up to 2 (so "c" is in the top box). Click on the "write text" button and the text is still written in the 3rd box, rather than overwriting the "c" and becomes the 5th element (index 4) not the third. Ben - thanks, that's given me a couple of thoughts on things to try .....

Most of the time the IMAQ Rotation Detect vi seems to be doing a reasonable job (within the confines of single-degree precision), but occasionally it is giving me a drastically wrong value - for example, it says the rotation angle is 280 degrees, when it's actually only 3. I can't currently see anything distinctive about the images that produce this, but they are consistent (ie Image 329 will always produce the same problem). I'm currently working with the Eval version of Vision prior to (hopefully) purchasing it, so I can't look into the VI to see exactly what it is doing. Has anyone else run into problems with it, or have an alternative method of detecting rotation in an image?

Actually Defer Front Panel Updates didn't really help as there was usually only one or two items being changed at a time. I did find one other odd item - I would've assumed that if I only needed to change the text on an item, that would be quicker than adding a new item. However, modifying the second column of text (set the item as active, change the active column number & change the string) was pretty slow - it was quicker to delete the whole item & add it back in with the amended text, even if this was the middle item of a thousand or so. So I'm guessing there is something cumbersome in how it handles the second column.

Worse - imo - I find LabView invading my dreams ....... Many times I have woken from a dream of re-stringing wires and re-positioning icons to try & get something useful to happen (like killing the frog in the bathroom ....... )

Actually, I can do some user-tweaking ... this is currently an internal tool so I can be "tougher" than with a paying customer. But still good to have a user-friendly interface .... as I'll get to hear all the complaints In case anyone is interested - I tried a tree and an array of clusters (two ints for equivalent to tree childno & grandchildno, a bool for highlighting active line & two strings for the two tree columns). The items grew from 600 to 60000 over the course of the test. The tree was twice as fast at the low end (600 items), slowed at a fairly constant rate to about 30000 items, and then started to slow massively/exponentially. The array slowed at a marginally slower constant rate, but kept that all the way up to 60000. I'm guessing I could've got better results from an array of just strings, and done conversions to numbers/bool as needed, but this was enough for my quick test. So I'm going to go to the tree, but keep it small (only show the most "current" data) and dump everything in a logfile so it can be consulted if required.

If you want to play hunt the white block ....... this is the program I inherited a couple of months ago. Granted, my screen is only 1024x768 and a lot of that is blank space, but still .....

Agreed it's a timing problem. Make sure you use a nice long Wait (5-10 seconds, however long it would take you to see the break come up, switch screens, select continue etc) to confirm. If you can't figure out what item is the problem, you can try moving the Wait around your code until you can find which items are having the effect. (Personally, I find it easiest to just move the wait "back" from where you have it until it stops helping - whatever you just jumped is either the culprit or occurs at the same time as the culprit). Given LabView's asynchronicity, this can be a bit more complicated but you can probably still determine what things are going on at the critical moment.

Depending on the particular case, the data set could be as little as 100 items, or it could grow to as much as 20000 or more. Usually it will only be updating one or two items at a time, but this will be almost continuous (say update every second on average). What was "fairly quickly" (milliseconds, half a second, a couple of seconds etc)? I can see that being a good approach to give me the flexibility of an array while the user gets the tree display as they want, but if I'm only updating one or two tree elements at a time, then reloading the whole tree might still take longer than individual changes. I'll have to give it a try & see. Also, this would be at least a 2D array (there are 2 columns in the tree for now, but I can see possible future requests for more) so presumably that will take longer - unless Labview is just doing a memory blit for the loading. I had assumed that the tree object was a collection of references, so if I had three levels, parent, child and grandchild, adding or deleting a grandchild would only affect the child branch it belonged to. However, the time taken to add or delete the grandchild seems to be dependent on the overall size of the tree (and the number of children) rather than the number of grandchildren on this branch. Which seems to suggest the tree is actually just a giant listbox anyway, with a few special features. Anyone know if this is the case?

Is there any set of benchmarks or comparisons anywhere as to the advantages/disadvantages of using Trees, Listboxes or Arrays for display of text data? I have a heirarchy of data (but it's a very flat heirarchy, only a couple of levels at the moment) that will be frequently updated and needs to be fully explorable by the user (ie, they have to be able to scroll or click or whistle or make faces or do something to get to look at any particular item on demand). Currently I'm thinking that a tree would be the prettiest/best user interface, but slowest as far as updates go & most memory intensive, while an array would be a lot faster & easier to update, but not be so intuitive to the user. It's probably going to come down to how big a performance difference there is - so, anyone got any actual data on the differences? Or just opinions and preferences? [i know - this is LAVA, everyone has opinions ]