Leaderboard

When designing block diagrams, I tend to spend way too much time making sure things are aligned perfectly, down to the pixels. It's really annoying. This is most noticeable with bends in wires. I don't like having "uneven" bends, or bends where they aren't necessarily needed, or wires that cross unnecessarily. For instance: Now you might wonder why I have bends there if I can just move the wires so they look straight. Well then they won't be perfectly aligned with the node's terminal. For instance: Of course, when there are bends, I want them to be even. For instance, these are the steps I might take to "fix" this sequence of property nodes (that I wouldn't likely put together in practice to my knowledge): Does anyone else have issues with trivial things like this? I find myself using the arrow keys a LOT on the block diagram to fix these kinds of things. Am I alone in that?

If you search ni.com/downloads and narrow by 2013 and NI Developer Suite you should be able to see the downloads for the three Platform DVD if you have SSP on the account you are searching with. The search URL I used is here - http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/en/pg/1/sn/n1:2013,n8:142,ssnav:pdl/ Hopefully that works for you! - credit to Altenbach for the quick search path

You've probably even considered writing your own diagram clean-up utility, haven't you? Admitting you have a problem is the first step to a cure. Hi. My name is Jim and I'm obsessive about a clean block diagram. <everyone> Hi, Jim! Here's one of my symptoms, manifested as a Quick Drop plugin.

Everyone thinks that the CLAD exam is to test for understanding. It isn't. It is a test for Compulsive Labview Alignment Disorder. So all certified programmers have this pre-occupation.

Instead of 12 Steps we have 12 States. We admitted we were powerless over LabVIEW OCD alignment—that our lives had become unmanageable Came to believe that through hard work and determination, ourselves could restore us to sanity. Made a decision to turn our will and our lives over to the block diagram cleanup as we understand it. Made a searching and fearless moral inventory of ourselves. Admitted to ourselves, LAVA, and to another human being the exact nature of our OCD. Were entirely ready be content with these wiring defects. Humbly asked developers to review their code and accept it when the review is complete. Made a list of all developers who did not adhere to the LabVIEW style guide, and became willing to make amends to them all. Made direct amends to such people wherever possible, except when to do so would injure them or others. Continued to take personal inventory, and when spending too much time adjusting wires, promptly admitted it. Sought through research and discussions to improve ourselves, for knowledge of other developers for us and the power to carry that out. Having had a acceptance and realization as the result of these steps, we tried to carry this message to other LabVIEW OCD wire addicts, and to practice these principles in all our affairs. You would be surprised how little this differs from the actual 12 steps.

Okay I don't think I'm as bad as some of you guys but I too find my self moving things one pixel at a time some times to line them up nicer. But there are a few times that I hate the terminal choices used by NI. Here are two times that I can think of that irk me. Why do these not line up? Seriously NI? Seriously?

BTW, a Database is not a good example to use for considering “actors”; a database is already well-designed for handling concurrent access, so someone reading may not see much value in introducing actors. Instead, how about a piece of hardware that can only do one thing at once, but may be needed by multiple concurrent processes. A part-handling robot, for example. An actor that handles all interaction with the robot can rewritten to mediate concurrent requests, perhaps through some kind of “transaction” system. Eg: ProcessA —> Robot: “Request robot transaction" Robot—>A “Transaction Started" ProcessB —> Robot: “Request robot transaction" Robot—>B “Busy; you are in job queue" ProcessA—>”Do action 1" <robot working> ProcessC —> Robot: “Request robot transaction" Robot—>C “Busy; you are in job queue" <robot working> Robot—>A “Action 1 Finished" ProcessA —> Robot: “End transaction" Robot—>B “Transaction Started" etc. The Robot Actor would either refuse any “Do action” requests from a Process that doesn’t have an open transaction, or consider such a request as implicitly being equivalent to a combined “Request transaction; Do action; End transaction”.

Oh yes ... and that sounds like a great strategy with the arrows @neil. Now right-handers (like my self) wish we had a left-hand keyboard like this one http://www.fentek-ind.com/modular.htm#kblhusbsb

Don't forget to also show your appreciation by clicking "Like This"

Good luck with it. Xmodem_VISA.zip

There's a really handy couple of VIs in vi.lib\sound2\lvsound.llb: 1. Get Num Devices - this lists the number of input and output devices in your system 2. Sound Device Info - returns the *NAME* of the sound device associated with a number I normally use #1 to set N on a for loop, and populate a ring control with the names out of #2. Shaun