Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/22/2013 in all areas

  1. 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?
    1 point
  2. Hi, To close the loop on this, the LabVIEW 2013 f2 Patch is released on the web and will be going out through NI Update Service in the near future. One of the fixes it includes is for this specific installer builder CAR 429282. The details for the patch are located here and the 32-bit download is located here Thanks
    1 point
  3. Make sure you’ve kudoed "In Place Element Structure Support for Variant Attributes”. It’s the copy at the first “Get Attribute” that is killing you. One way around this is to not use the actual value of your storage variants at all; instead keep the "content" of that tree node as a “NodeContent” attribute. Then your above code becomes just a “Set Attribute”.
    1 point
  4. In that case, perhaps more mods is the answer. I would be more than happy to clear out all the spam that I see each day.
    1 point
  5. Hello again! I'm back to report the problem / solution. The <Error generating preview> in the installer dialog is caused by a bad VI from one of NIs Toolkits! The Automotive Diagnostic Command Set in version 1.2.0 does update the compatibility to LV2013 and adds a new feature that causes my problem. Thanks to neil who made the suggestion to add an INI key to the LabVIEW.ini NI_Appbuilder_logging=TRUE The build log is created next to the *.lvproj file and directly shows the problem. Where the IDE dialog just showed me an error: -1! !!! error -1 !!! Here is the important line: The file at 'C:Program Files (x86)National InstrumentsLabVIEW 2013vi.libAutomotive Diagnostic Command SetDiagnostic Transport.llbOpen Diagnostic on LIN.vi' was expected to have the qualified name 'NI_Automotive Diagnostic Command Set.lvlib:Open Diagnostic on LIN.vi', but has the qualified name 'Open Diagnostic on LIN.vi'. This freaking VI forced me to clean up my project! ( I removed a whole bunch of orphan VIs, disabled structures, conditional structures, etc.. so it's good for the project ) As I'm unable to remove the offending VI from the library (password protected), I have to rely on NI to update the toolkit ASAP. I hope this prevents anybody else to run into the same problem. Thanks for the support and the helpfull suggestions, my project is now OCD conform
    1 point
  6. No, definitely not! 4*2*2*4 should be the standard and strictly enforced for all LabVIEW programmers, if I had a say in this! And anyone using the 6*4*4*6 for a VI that is not private to the library should be banned from writing LabVIEW programs.
    1 point
  7. 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.
    1 point
  8. 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.
    1 point
  9. NI does that intentionally just to see if you're paying attention. They can tell when they hear the "crash".....
    1 point
  10. 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?
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.