Component Outside of Drawing Area

[FluidPowerTom]

How many others often find themselves doing components outside of the drawing area and blissfully ignoring the warnings?  I heard soon you'll be able to disable the warnings.  Granted some applications require printing the logic, so in those cases of course you have to use the drawing area.  Other than application requirements, do people really tailor their programming around fitting inside of that title block?

I'll use the drawing area by default, but when I need to I think nothing of moving an entire section of logic outside of the title block.  Suppose you've got to drive a few handfuls of similar outputs with similar logic, and the logic for all of them won't fit in the drawing area.  Do most developers just start a new page and proceed to keep all of the logic inside of the drawing area, or do most others just extend their buses and keep going?

I'm pretty new to GUIDE, so in addition to being curious I'm also looking for insight from more experienced programmers.

Thanks,

[oiltronic]

I keep all finished designs inside the page borders and temporarily move things outside the borders when shuffling around.  I find the page size fits what can be seen on my screen, so any more than that and I'd have to scroll around to see what's going on.  More than a pageful can be too much to mentally digest to ensure everything works as intended.  If you have more than a pageful then there's almost always a candidate for putting inside a new page to reduce the complexity of the present page view.  Especially if you have a bunch of similar outputs with similar logic, as you described. 

And just like regular programming languages, there are probably heated religious arguments over the maximum acceptable lines in functions and subroutines.

[spittet]

There is a nice "Developpement Guideline" that Danfoss has release to help programmer do a better job. Readi it, it's pretty interesting :

http://powersolutions.danfoss.com/stellent/groups/public/documents/web_content/c017009.pdf

Sam

[Marbek_Elektronik]

But sometimes there are modules which have to be connected one behind the other.
So it will need a lot of place. And it would be better to place it in one page to understand.
I would prefer to make the border so large as the display of a monitor.
There is a little space horizontal but not vertical.
please make it a little larger in horizontal.
Sometimes I put the ports outside the area. Here, the compiler does not send a warning.

[FluidPowerTom]

There is a nice "Developpement Guideline" that Danfoss has release to help programmer do a better job. Readi it, it's pretty interesting :

http://powersolutions.danfoss.com/stellent/groups/public/documents/web_content/c017009.pdf

Sam

I've glanced at that guideline, but it strikes me as meant for somebody who has never programmed with function blocks before and is somewhat new to programming in general.  The fact is function blocks are messy.  I do my best to keep it clean and organized, but I've spent 10 minutes adding something that should take 2 minutes because I try to make it look clean in the cluster of wires and buses.  Sometimes I'll just grab my input or output bus and spread it out - completely ignoring the drawing area.

Organizing programming based on actual function makes sense to me, but having to program within a somewhat arbitrary title block seems only necessary if the customer requires print outs.

[Marbek_Elektronik]

Perhaps someone knows the software "LabVIEW", which is also graphical.
There is no frame and you should place all your code in one window of your monitor.
But, they also say: "if it is necessary, use more then one window, but please either horicontal or vertical!"

[FluidPowerTom]

Yes, LabVIEW is usually what I think of as the pinnacle of a function block programming platform.  Good point about working either horizontal or vertical.  My initial thought is ladder logic where you just keep working downwards, and the whole input and output bus thing makes GUIDE feel sort of like ladder logic in that respect.