07-01-2012 08:16 AM
LoL Altenbach,
I was, for 11.73 seconds, very tempted to put this image into my signature, who's the copyright holder?
On an altogether minimally serious side of this, however, a 3D view wouldn't be that bad, as subVI structure peek option perhaps. Or is it just me imaginging subVIs with layers associated, such that level 1,level 2, etc could be peeked into with a layer switch, e.g. Ctrl+Alt+up/Down, such that subVI inputs/output clusters and data streams would be indicated "vertically" in a perspective view?
07-01-2012 11:08 AM
Try boolean array to number. Make sure you completely understand what it does.
Vichine Masion wrote:I was, for 11.73 seconds, very tempted to put this image into my signature, who's the copyright holder?
I made that image myself. You can have the copyright for $2499/year. 😄
Vichine Masion wrote:On an altogether minimally serious side of this, however, a 3D view wouldn't be that bad, as subVI structure peek option perhaps. Or is it just me imaginging subVIs with layers associated, such that level 1,level 2, etc could be peeked into with a layer switch, e.g. Ctrl+Alt+up/Down, such that subVI inputs/output clusters and data streams would be indicated "vertically" in a perspective view?
The problem is not piling more and more code into an ever shrinking area of the monitor, then using 3D glasses to edit the code. With a well structures program, this should never be necessary. If you isolate common code into subVIs, the layering effect is already achieved. 😉
Look at my code alternative posted above. Compared to your disfunctional first draft, everything is right next to each other and everything is immediately clear to even the casual programmer. There is no need for 3D or tunneling into other layers.
According to Ben, NI has a patent on 3D diagrams, so your idea is not new or revolutionary. Once it is shown that it gives a significant advantage, we might see it. 😄
07-03-2012 11:03 AM
Compared to the price of LabVIEW, that's actually reasonable, what did you say the currency was, pe$os?
Boolean array to number is not my catch, I wasn't sure how that is related to my kidding at first. Discovered it's not. Speaking of which, I never said that a 3D diagram is new, revolutionary, or even an idea of mine, for that matter. Neither did I know there was a hidden nickname reputation contest behind every comment, but, I'll keep my eyes peeled then. For instance, for things such as NI patenting 3D diagrams, per se, which somehow are to define originality of ideas, should they be proposed on a public forum, that is, as this did not happen in this case.
Just curiosity, now that you got me more into this 3D diagram thing more than originally intended, how do you look at which 2nd level subVIs are contained in a 1st, while wishing to have an overall map of the total structure in front of you, let alone to see which Nth level subVIs feed data to the top level one unchanged? Visually, of course, for the sake of a graphical programming language. Or is it also something that should not be necessary for seasoned pros? I am just asking because I often encounter the exact same argument against graphical programming languages in general, from text-coders apparently annoyed by, and sometimes unable to comprehend the not-so-abstract abstraction of flow mechanisms when coding, I am sure you have heard these. So, we actually just may indeed see 3D LabVIEW block diagrams at some point, maybe not even on these conventional monitors. As for myself, I wouldn't be either uninterested or afraid.
I will have to assume that dysfunctional (is that what you meant?) first draft does not relate to me either, as I have not disclosed such, as well as I wouldn't, and shouldn't dare now, for sure.
But, never mind my wandering, and in any case, I absolutely loved the shoelace image for laughs!
07-03-2012 11:27 AM
"how do you look at which 2nd level subVIs are contained in a 1st, while wishing to have an overall map of the total structure in front of you, let alone to see which Nth level subVIs feed data to the top level one unchanged?
That's where View->VI Hierarchy and code reuse comes into play. You should have a clean VI tree as well as clean vi block diagrams.
07-04-2012 06:58 AM
It's clean, it's huge, it's viewing only (?), and I've never used it before. I'll keep an eye for VI Hierarchy for structural considerations from now on, thanks. I'd still vote for an actual 3D diagram option though, for development as well, not just viewing. Meanwhile, perhaps I should obtain a few extra monitors and a suitable controller..
07-05-2012 11:17 AM
This book helped me a lot. I bought a copy for my trainee it was that good. A second monitor really helps. I like to put the front pannel on one monitor and the diagram on the other. Two monitors is no excuse for expanding a diagram larger than one screen though.
07-06-2012 04:27 AM
Thanks, I'll probably grab this digitally. I do have a second monitor, but the first is that of a 15.6 laptop, and hence a little less tha ideal even in 1920x1080. Particularly so, as I work with vision, rendering the full HD resolution front panel actually just about satisfactory. This will be small later. Same with the block diagram of my current work, just enough on a full HD, with its one huge loop and numerous subVIs, both external and internal - I like to keep non-trivial image processing in the main VI until tested, configured, and all controls / deployed though, and compact it to a subVI once finalised to at least a good, externally configurable prototype level.
2 VGA streams with 2 displays each (I need to see the captured one for each, with further analytic data on the heavily processed one below). Even if I now overlay everything I can (some must be on the image plane anyway), this is 100*((640*480*4)/(1920*1080)) = 59.26% of my screen, plus manual controls of sensible sizes for mouse control. Now I am soon to have 4 cameras streams, and comparative graphs will be required for intuitive insight, too - no space left for my main block diagram I would just love to see at all times...
I also discovered that if I run my prototype (a real-time one) with its front panel on one (external) screen, and have some subVI fronts on the laptop one (usually data validation with a range indicators before I proceed along), my video stream overlays (but not the imaging) on my main VI front tend to flicker. A small annoyance only of course, but have you seen this? It can be resolved by deploying a global Merge Overlay VI on each iteration and stream, problem with that is unnecessary computational load for 4 distinct streams. My "temperature" view I strongly prefer to see on the capture sreams with this piece of work, also needs a LOT of extra CPU to replicate with actual processing in colour, whereas my working imaging depth is 8bit grayscale (therefore, the relative inefficiency overhead is particularly large). You can imagine the pain when it comes to binary images overlaid to form a gradient, which also mean a re-rendering to RGB if I merge overlays.
30" 2560x1440?