Two Monitors for more LabVIEW code view

[Grey]

Hi,

I see a guy who is using two monitors at a time from one PC.

What i seen is that both monitors are synchronise and act as a single monitor. ultimately you have more visible area.if you move the mouse it goes one monitor to another.

if you open more applications you can see all of them using two monitors. you no need to minimize them.

what i'm thinking is that i can view my Labview code in same way.

(my code always keep on going left to right so that i need to scroll more .. i know this is bad).

Any idea who is using this type of two monitors setup?

[hooovahh]

So alot of people have their opinions (several in this office) but I use UltraMon to manage multiple monitors. It adds a second task bar to the other monitor, and it can be configured to only show windows on the taskbar that are on that monitor.

Additionally I use the Hotkey (setup in UltraMon) to allow the CTRL + Space to move the window to the next monitor. Keep in mind this replaces the quick drop feature in LabVIEW which I don't use. If I need to find something I use search. My left hand is almost always on the home keys, and so hitting this set of keys is a quick way to organize Block Diagrams on one window, and Front panels on the other. I can also use this technique to open two projects and have one on each monitor.

UltraMon also adds other not as useful features, like multiple desktop images, monitor cloning (built into Windows 7 now), multiple screen saves, and a few other things I don't use.

There are other free alternatives that I hear work just as well.

EDIT: Sorry I didn't fully read your post. If you want code to span both monitors, UltraMon can add a Maximize to Desktop button. This button appears next to the minimize button of all windows, and when pressed will maximize over all desktops. I don't recommend coding this way. It is useful in Excel, where you open two workbooks and what to view one on each monitor, so you maximize the master window then position the two workbooks independently.

[COsiecki]

I do it all the time! The only thing that I would warn you about is that front panels and block diagrams open where they were saved. If they were saved on your second monitor and then opened on a system with only one screen, they will open off to the edge of the screen. This can be a little annoying for you, but if that happens to the user, you'll certainly hear about it. Other than that its great! I have dual monitors set up at work and home. I was fortunate enough on one project to get a triple monitor setup. That was live heaven.

[dannyt]

Hi,

I now always work with two monitors, I do not konw how I would live without two. I work in the same ways as hooovahh but use the free version of http://www.mediachance.com/free/multimon.htm.

Our coding standard still insist that a VI block diagram fits on one standard screen, though we will allow a little left /right scrooling on some occasions. This is because we all have two monitors on our development setup but not on the shop floor nor at home. Also I feel it tends to breed bad habits in coding thinking you have all that realestate.

[ShaunR]

I like using 2 monitors (when they are availabe-I just use the inbuilt windows extend desktop).

However. I still maintain that diagrams greater than one screen is shoddy. I use them in a slightly different way in that I will have diagrams on one screen and FPs on the other. It saves a lot of hunting through the myrriad of windows and moving FPs from over diagrams when you switch to a VI (if you aspire to one digram being less than 1/4 of a screen , you can work on 4 VIs at a time with no fuss )

Edited April 10, 2012 by ShaunR

[Ryan Podsim]

When I made the change to using two monitors, I felt same as when I went from a CRT to an LCD , I don't know how I managed before. Having the extra space is wonderful, I can have the FP on one screen and the BD on another or have reference material (Spec, Deisgn, Lava) on the other. It's not uncommon for me to have 15+ windows open at a time. (Browser, LV, Different Directories, Specs, etc) Still trying to justisfy a 3rd monitor.

I do agree with ShaunR and Dannyt, that a BD should fit on one monitor. Though for some VIs (property node heavy) do run horizontaly onto the second monitor. As a rule I try to stay smaller then 1024x768 since that is the resolution we do code reviews on. The same FPs, I tend to design for 1024x768 since most computers support atleast that now adays.

COsiecki does make a point about how VIs open in the location it was saved, the same with BD. This have been an issue during code reviews, as we use a projector. We created a simple utility to center VIs on the primary monitor just incase one ends up off screen.

[Grey]

Thanks for the interesting replies from all of you guys.

Now i 'm in a move to work out for my two monitor system.

[Minh Pham]

We always working with 2 monitors for our LabVIEW development. Normally we have 1 standard size monitor (19 inches) to build our front panels since our apps will normally be running on this size in the manufacturing and production rigs, and 1 bigger size mornitor (22-23 inches) for block diagram/coding/debugging...purposes. Much easiser to work with 2 screens side by side, nothing to complain at all

[crelf]

my code always keep on going left to right so that i need to scroll more .. i know this is bad.

no No NO! Having code span more than the available screen resolution isn't inherently bad, and anyone who tells you so is a fundamentalist¹ itchin' for a fight

I don't have any problems with code that scrolls in one axis (ie: left/right OR up/down), and it's often impractical to code some architectures without doing this (eg: FPGA, ActiveX or any other property-/method-based work, some UI designs). It's when you need to scroll in more than one axis that I get cranky.

PS: I love having 2 monitors: one for FP, the other for BD - awesome when you're debugging.

^1. Each to their own. I don't have a problem if anyone feels the need to have their code fit on one 640x480 screen, but I prefer to be practical, which means my time is more valuable working on things useful to the world than crusading (often only if with themselves) for something like this.

[Val Brown]

no No NO! Having code span more than the available screen resolution isn't inherently bad, and anyone who tells you so is a fundamentalist¹ itchin' for a fight

The real problem with fundamentalist's is that they really take out all of the fun. They actually should be called ..."damentalists".....

[KWaris]

Just connect the other monitor using VGA or HDMI port to your laptop/pc and configure the settings in control panel

[hooovahh]

Just connect the other monitor using VGA or HDMI port to your laptop/pc and configure the settings in control panel

Or in Windows 7 press [Windows Key] + [P], and choose Extend. This is normally used for projectors to clone or span.

[Daklu]

I don't have a problem if anyone feels the need to have their code fit on one 640x480 screen, but I prefer to be practical, which means my time is more valuable working on things useful to the world than crusading (often only if with themselves) for something like this.

I agree. I believe the "single screen" standard probably started with good intentions--creating code that is easy to read--but somewhere along the way the standard became more important than goal and readability/clarity is often sacrificed for the sake of fitting it all on one screen. My goal is to write clear code. The block diagram will be as large as it needs to be acomplish that goal. (Yes, sometimes they'll even require scrolling in two directions.)

Sacred cows make the best hamburgers, and the "good code fits on a single screen" cow needs to be slaughtered. (I've carved off a chunk and I have to say it's mighty tasty.)

[ShaunR]

I agree. I believe the "single screen" standard probably started with good intentions--creating code that is easy to read--but somewhere along the way the standard became more important than goal and readability/clarity is often sacrificed for the sake of fitting it all on one screen. My goal is to write clear code. The block diagram will be as large as it needs to be acomplish that goal. (Yes, sometimes they'll even require scrolling in two directions.)

Sacred cows make the best hamburgers, and the "good code fits on a single screen" cow needs to be slaughtered. (I've carved off a chunk and I have to say it's mighty tasty.)

That's a bit arse-about-face. It promotes readabilty and forces you to think about modularity. There is no excuse for scrolling all over the place, it is a symptom of poorly thought out modularity and hierarchy. It has become more "acceptable" because it is so difficult to encapsulate queues and notifiers - hence my preference for named queues with a string input (it enables very simple encapsulation of them).

[crelf]

My goal is to write clear code. The block diagram will be as large as it needs to be acomplish that goal. (Yes, sometimes they'll even require scrolling in two directions.)

(single screen coding)... promotes readabilty and forces you to think about modularity. There is no excuse for scrolling all over the place, it is a symptom of poorly thought out modularity and hierarchy.

I think you're both right: I would never say that you should keep all code to one screen*, and I would never say you shouldn't keep all code to one screen. Neither of those statement makes sense to me, and they're extremist views, albeit in opposite directions. I think that there's a middle way here - it's like when someone says "never use globals" - to me, globals are fine when used appropriately. Try not to fall to far on one said of the fence on anything when it comes to software engineering - because all you'll do is limit yourself, your capability of thinking, and your code. State your view (as you have eloquently), and, if others don't agree with it, you can either maybe try to see a middle way, or ignore the naysayers

*Define "one screen", because I'm thinking my screen is a different size to yours

Sacred cows make the best hamburgers... I've carved off a chunk and I have to say it's mighty tasty.

Mmmmm barbque...

[Daklu]

It promotes readabilty and forces you to think about modularity.

Not inherently it doesn't. It doesn't surprise me that it does that for you; you're an experienced developer who knows how to make code readable and how to modularize a system. You use the size constraints as a code smell--a trigger to indicate you might want to take another look at the design or layout.

Readability is all about creating appropriate abstractions and managing interactions between the abstractions to help the developer understand the software model. Wrapping code in a sub vi is only one kind of abstraction. Norm's TLB template is an example of spatial abstraction. A QSM states are another form of abstraction.

For the typical LV user bumping up against the size limit means dumping a bunch of "big stuff" in a sub vi. They don't typically think too much about how to design that sub vi to fit in with the rest of the application's api. If you're lucky they will give some passing thought to making it reusable. Their primary concern is to save space on the block diagram so it won't be too big. A 'single screen bd' application with poorly chosen abstractions is much harder for me to follow than an equivalent application that is larger than a single screen.

There is no excuse for scrolling all over the place, it is a symptom of poorly thought out modularity and hierarchy.

I agree really large block diagrams often reflect poor designs. But telling a user the bd should fit on one screen doesn't improve their design skills. It just makes more abstraction you or I have to sift through to figure out what's going on. Also, restricting the block diagram to a specific size almost always requires inserting abstractions for the sole purpose of saving space, not because the abstraction makes sense from a software design point of view. This further complicates things.

If the goal is readability and modularity, then make readability and modularity the goal instead of instituting an artificial proxy requirement.

and I would never say you shouldn't keep all code to one screen.

You misunderstand. I'm not asserting people "shouldn't keep all code on one screen." I'm asserting the claim that "code larger than a single screen isn't good code" is passe and misses the target. I think it's essentially the same as your view, except I don't go to great lengths to make sure users only need to scroll in one direction. (i.e. I might have multiple loops stacked vertically with initialization and clean-up code before and after each loop. Vertical and horizontal scrolling might be necessary to see all the code, but it is organized and clear what each section is for.)

[John Lokanis]

How about: You should strive to keep you block diagram the minimum size possible without impeding the clarity of your code.

I have seen some noobs simply maximize the BD on every VI even if there is barely any code in it.

Personally, I try to keep my FP and BD as small as I can so I can fit more open ones on the screen at once. This helps me with debugging. I also use 2 monitors but rarely let my BD extend to the second one. The main exception being VIs that use a lot of property nodes, as mentioned above.

And I don't make sub VIs for the sake of making sub-VIs. On the other hand, a sub-vi does not need to be a reusable component. It just needs to have a single functional purpose within the application. If you find yourself writing a second of code and commenting it with statements like 'here is where we calculate the blah de-blah blah thingy' then consider that a candidate for a sub-vi.

My end goal is a BD that is a simple string of VIs with the minimum number of connections required between them and that clearly show the flow of actions within the application.

As for BD size, our coding guidelines officially state:

Size considerations

The block diagram shall not exceed the size of a standard monitor. This would be 1440x900 in most cases; however this could change in the future. The size of the diagram should be kept to a minimum while still including a reasonable amount of white space for readability. If the diagram becomes too large, sections of the code should be refactored into sub-vis.

Obviously, I sometimes violate this standard, but it is a good rule to try to live by, if for no other reason than it makes the code more 'portable' when viewed on other dev's machines for code reviews.

[Darren]

I currently have 3 monitors (two up top, one in the center below). Hope to get a 4th soon.

[drjdpowell]

I do all coding on a single 15”-screen laptop. High res, though: 1680x1050. Don’t require things fit on the screen but they mostly do.

[Daklu]

FWIW most of my block diagrams do fit on a single screen. Often vis with continuous loops will not. That includes actor ExecutionLoop vis, non-trivial UIs, etc.

Size considerations

The block diagram shall not exceed the size of a standard monitor. This would be 1440x900 in most cases; however this could change in the future. The size of the diagram should be kept to a minimum while still including a reasonable amount of white space for readability. If the diagram becomes too large, sections of the code should be refactored into sub-vis.

Well, since you posted it....

If I were king for a day I'd change the last sentence to,

If the diagram becomes larger than one screen, review it and look for opportunities to improve readability and reduce size by inserting appropriate abstractions.

It puts the emphasis where it should be--on the readability. (Which, by its nature, is entirely subjective and resists definition by objective rules.)

[John Lokanis]

Fair enough, but consider the audience too. If most of your devs are CLADs (or equivalent) the best option is to steer them in the right direction for now and worry about exceptions later.

[ShaunR]

it's like when someone says "never use globals" - to me, globals are fine when used appropriately.

Indeed. A good example.

The "never use globals, they cause race conditions" is a one line, easily conveyable axiom, that you should adhere to, until you can put forward convincing arguements for using them and demonstrate that you understand the implications/pros/cons.

The "no bigger than one screen" is the same. The only major difference (for me) is that I have not come accross a single scenario where it cannot be achieved or, even, where it is not an improvement. Show me an example where you think it is better to have a sprawling diagram and I'll attempt to "improve" it.

Try not to fall to far on one said of the fence on anything when it comes to software engineering - because all you'll do is limit yourself, your capability of thinking, and your code. State your view (as you have eloquently), and, if others don't agree with it, you can either maybe try to see a middle way, or ignore the naysayers

Sitting on the fence just hurts your arse

*Define "one screen", because I'm thinking my screen is a different size to yours

"Single screen coding" are words you put in my mouth. I have already intimated that I "aspire" to 1/4 (of my) screen for diagrams. That should still fit on yours even at 640x480

Not inherently it doesn't. It doesn't surprise me that it does that for you; you're an experienced developer who knows how to make code readable and how to modularize a system. You use the size constraints as a code smell--a trigger to indicate you might want to take another look at the design or layout.

Not really a code smell. I iteratively develop. So I design in a very much top-down manner but develop bottom-up. As each increasingly higher layer gets laid down, so natural re-use appears and gets encapsulated (within the framework of the design). Each bottom segment goes through a few iterations before it is "worthy" of becoming a module. That happens module-by-module, layer-by-layer. Eventually you get to the UI and all hell breaks loose.

Readability is all about creating appropriate abstractions and managing interactions between the abstractions to help the developer understand the software model. Wrapping code in a sub vi is only one kind of abstraction. Norm's TLB template is an example of spatial abstraction. A QSM states are another form of abstraction.

I came to the conclusion quite a while ago that our brains are wired differently (not in a bad way, just different). For me it is just breaking the code into bite-sized chunks that I can paw over. I find it much easier to analyse a small VI and only have to remember its terminals when thinking about interactions with the next. It is the same as only having to remember the API interface, not the details of the insides of the API (so yes, encapsulation). To me a diagram is more akin to a UML model than code and the sub-vis are layers within the model.

For the typical LV user bumping up against the size limit means dumping a bunch of "big stuff" in a sub vi. They don't typically think too much about how to design that sub vi to fit in with the rest of the application's api. If you're lucky they will give some passing thought to making it reusable. Their primary concern is to save space on the block diagram so it won't be too big. A 'single screen bd' application with poorly chosen abstractions is much harder for me to follow than an equivalent application that is larger than a single screen.

So (learning from Crelf) What is a "typical" LabVIEW user?

I think a LabVIEW starter thinks in this way. But by (initially) requiring less than 1 screens worth of spaghetti, they eventually start to see the patterns emerging that experienced coders see in the minds eye (this I think is the beauty of LabVIEW). So yes. The sub-VIs may not be encapsulating correctly or "as the book says", but from module-to-module, project to project. They soon start realising that they have done that before or that "the VI I made last week almost did that". After a while they have thier own little set of "utils" that appear in every project they work on. If you allow them to just throw code at several screens worth. That never happens (couldn't resist).

I agree really large block diagrams often reflect poor designs. But telling a user the bd should fit on one screen doesn't improve their design skills. It just makes more abstraction you or I have to sift through to figure out what's going on. Also, restricting the block diagram to a specific size almost always requires inserting abstractions for the sole purpose of saving space, not because the abstraction makes sense from a software design point of view. This further complicates things.

If the goal is readability and modularity, then make readability and modularity the goal instead of instituting an artificial proxy requirement.

Like I said. Bite-sized chunks and the modularity/re-use drops out.

You misunderstand. I'm not asserting people "shouldn't keep all code on one screen." I'm asserting the claim that "code larger than a single screen isn't good code" is passe and misses the target. I think it's essentially the same as your view, except I don't go to great lengths to make sure users only need to scroll in one direction. (i.e. I might have multiple loops stacked vertically with initialization and clean-up code before and after each loop. Vertical and horizontal scrolling might be necessary to see all the code, but it is organized and clear what each section is for.)

Good code is code that works, flawlessly. Thats all the customer is interested in. It doesn't matter if it is one digram that fits on a whole roomfull of screens. I am proffering that more than one screen is shoddy programming. Why? Because I have to run the whole screen in debug to see one bit of it (and assume I don't know which bit I want to see yet).

If you have 4 while loops on one screen (that I have to keep scrolling around or it keeps jumping around to see where it is executing) it makes it so much harder to debug. Compare that, say, to 4 icons in the middle of the screen. Instant 4 breakpoints. Instant 4 probes (i.e their front panels) and I don't need to go chasing dots around with the scroll bars. Plenty of room for notes and comments and (if you have sanely labelled, used distinguishing icons and a put in a tiny bit of thought into the design) I can identify identical functions at a glance and have a pretty good guess which sub-VI I'll probably be looking into first. I can also run them separately, two at a time or any combination of the 4. I can wait until the FP controls have some data in them that I'm interested in. Stop it. And run it over and over again whilst looking inside.

Oh. And it looks better

Edited April 17, 2012 by ShaunR

[Michael Aivaliotis]

I think the most underutilized feature in LabVIEW is the SubVI. Use more subVIs people! Sheesh.

[crelf]

As for BD size, our coding guidelines officially state:

Size considerations

The block diagram shall not exceed the size of a standard monitor...

Obviously, I sometimes violate this standard, but it is a good rule to try to live by, if for no other reason than it makes the code more 'portable' when viewed on other dev's machines for code reviews.

The IEEE9001 standard requires "shall" statements to be met, and shown to be met - never violated. You just failed an audit, my friend!

If the diagram becomes larger than one screen, review it and look for opportunities to improve readability and reduce size by inserting appropriate abstractions.

That's a great way to look at it - and we look at BD size, and many other metrics, with that in mind. For example, we try not to say that a VI with a high GOB count is bad - it's just a flag that it should be reviewed. There are several edge cases where high GOB count VIs make perfect sense, and the same goes for large BD VIs.

Sitting on the fence just hurts your arse

Then you're doing it wrong.

I think the most underutilized feature in LabVIEW is the SubVI. Use more subVIs people! Sheesh.

Maybe by CLADs, but not where I work. I often get berrated for using too much abstraction and too many subVIs. I like to think the berrators just don't understand my brilliance.

Seriously though, subVIs are great, and, just like everything else, should be used when appropriate. Just to get a little BD space is not one of them IMHO - using them in that way is obsfucation - which may be appropriate, but you need to be mindful that you're doing it.

[John Lokanis]

The IEEE9001 standard requires "shall" statements to be met, and shown to be met - never violated. You just failed an audit, my friend!

I am well aware of that. I purposely used shall to make this an enforced requirement. But, since I don't have to meet ISO or IEEE9001, this is more of a 'do as I say, not as I do' requirement...

BTW: your post resulted in LAVA sending me 8 emails! Seems a bit excessive for a quoted reply...

Edited April 20, 2012 by John Lokanis