Jump to content

Michael Aivaliotis

Administrators
  • Posts

    6,196
  • Joined

  • Last visited

  • Days Won

    104

Posts posted by Michael Aivaliotis

  1. QUOTE (jlokanis @ Oct 16 2008, 12:25 AM)

    Thanks for the tip, but can you tell me why that is a red flag? Is there something about the shared clone vs. preallocated clone that is bad? I was under the impression that shared clones were good when you used a lot of reentrant VIs because they reduced the memory footprint. As long as you avoided FuncGlob types of VIs where previous states mattered, they should work the same, right?

    I will give this a try but I would like to know more about the difference so I can educate myself.

    thanks,

    -John

    If you've really been using LabVIEW since 1993 as your profile states then you've also worked through many versions of LabVIEW. From my experience if things have been working fine, you look at what changed. In specific you look at what changed in this version of LV and specifically, you ask yourself, "am I using any of the new features?".

    I've been burned many times over the years when jumping onto new LV features, and the shared clone feature was added in LV 8.5. I haven't personally had problems with it but let's just say, I have a hunch.

    In the end, using preallocate clone does not change the functionality of your program, so just give it a shot. If you still have the problem then at least you have eliminated one question in your mind, "could it be that?"

  2. I just stumbled across this thread and have some comments. I find queues to be the most rock solid feature in LV. Most of the time, when they do cause problems it's because I had an oversight and the VI that created the queue went idle so the queue died.

    One thing that I see as a red flag is the usage of shared clones. Disable shared clones, rebuild it and give it a spin.

  3. QUOTE (ASTDan @ Sep 24 2008, 05:54 AM)

    That looks like a good list. Is that ALL the LabVIEW books out there? That's not much.

    As far as the rating system. I think rating things using stars is not very helpful. I think a better thing would be to read reviews from those that have purchased the book. So, feel free to add your review below a particular book listing on the Wiki page.

  4. If you live in the US, you can help my son's small cub scout pack raise some funds so they can do some cool stuff this year.

    All you have to do is go online to www.orderpopcorn.com. There you can place an order for all different kinds of popcorn. If you don't want popcorn for yourself then you can even buy a popcorn donation for the troops. About 70% of the funds goes directly to the cub scout pack.

    On the main home page you will be asked for an Order key. Please use = tepys6d

    This will assure all orders are placed in my son Alex's name and the funds go to the right place. Once you are on the site you will find all the items you can order located across the top using the red buttons.

    Any help is always appreciated. :worship:

  5. QUOTE (gleichman @ Sep 16 2008, 12:22 PM)

    Who's bright idea was it to update the Report Generation Toolkit to LVOOP?

    :throwpc:

    You ain't seen nothing yet. Wait until you try to build an executable. I just got off the phone with customer support call which included remote assistance via copilot for about an hour. The customer was trying to figure out what these extra folders were in his build output. NI_Report, NI_HTML etc etc. Each folder was full of dozens of VI's. His quote: "I never saw these before in LabVIEW 8.5"

  6. This first version of the cleanup tool is just that. It's going to be improved. What we need to do is let NI know what needs to be improved for the next release. So far, every time I use it I have to undo it. I have yet to find a case where it does what I want. Playing with the settings doesn't help.

    One suggestion is that NI look at clean code that Pro developers like us create and find the key elements that characterize our layouts. Then, they could incorporate those elements into the cleanup tool as predefined styles that can be chosen in the options. You could even have several predefined layout styles. For example Style A, Style B, Style LAVA, and so on.

    I think that if NI doesn't receive and listen to feedback from us on what is considered a clean diagram then it will never be as useful as it could.

  7. I think you should be honest. Even if it means leaving ini keys that are not supported like:

    SuperSecretPrivateSpecialStuff=True

    SuperPrivateScriptingFeatureVisible=True

    I'm sure all of the LAVA members have those on. Regardless, it sends a message. I disagree with adding stuff you don't really use.

    Also, I don't mind to have stuff "fall away". Ya, I'm reeealy gonna miss "just-in-time" advice. No really? No, you're serious? That one is an example of a feature that everyone hated, but instead of removing it, NI decided to leave it in but turn it off by making the default FALSE. What is the point? If you want to improve the Options window try putting it on a diet and only include stuff that has an impact. The Options windows is what it is. A place to enable or disable stuff and it seldom gets a visit beyond the initial LV install and setup. Don't redesign it, trim it down.

    I just had to go through setting up a JKI virtual machine so I had to go through 4 LV versions to setup this stuff so it's still fresh in my mind. Here's my list of the LabVIEW options that should be removed and replaced with defaults (in brackets). I decide to skip the ones I consider personal preference since you can argue all day about that. These are a no-brainer in my opinion.

    1. The entire "Paths" category should be removed (LV defaults).
    2. The entire "Colors" category should be removed (LV defaults).
    3. The entire "Fonts" category should be removed (LV defaults).
    4. The entire "Revision History" category should be removed (LV defaults).
    5. Play animated images (TRUE)
    6. Blink Delay (1000ms)
    7. Use transparent name labels (True)
    8. Use transparent free labels (True)
    9. Delete/copy panel terminals from diagram (True)
    10. Place subVIs as expandable (False)
    11. Show dots at wire junctions (True)
    12. Show tip strips over terminals (True)
    13. (Diagram Cleanup) Move controls to the left of the containing diagram (True)
    14. (Diagram Cleanup) Move indicatorsto the right of the containing diagram (True)
    15. Show data flow during execution highlighting (True)
    16. Auto probe during execution highlighting (True)
    17. Treat read-only VIs as locked (True)
    18. Do not save automatic changes (True)
    19. Enable Just-In-Time Advice (False)
    20. Maximum undo steps per VI=99

    So there ya go. Yup, that's a lot of stuff but if I had my way I'd chop some more. I'm being nice.

  8. QUOTE (JiMM @ Aug 31 2008, 09:00 AM)

    QUOTE (Darren @ Aug 31 2008, 03:17 PM)

    Can you qualify that statement? I'm (obviously) biased, but I feel the LabVIEW documentation is some of the best I've ever encountered in the software world.

    Correct me if I'm wrong, but I think what JiMM is looking for is documentation on why the heck anyone should use the project (besides the obvious: "to build an exe").

    Yes, it's a neat way to organize your VI's but an OS folder can do that too. One of the primary benefits for me has been the ability of a project to wrap your code in a project namespace. You can open two or more projects at the same time and VI's within those projects can have the same name but you won't have the problem of cross-linking. One word of caution on projects. If you decide to use projects, you MUST use projects all the way. What I mean is that the very first thing you open, to start your work, must be the project file, not the VI. It's the boss.

×
×
  • Create New...

Important Information

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