Jump to content

Norm Kirchner

NI
  • Posts

    823
  • Joined

  • Last visited

  • Days Won

    25

Posts posted by Norm Kirchner

  1. Shaun,

    I have to apologize that I have not released a new package for the LVSpeak QuickDrop Add-on for LabVIEW 2009.

    I have already made the updates necessary to get it to work in 09 (easy) but need to work on making a clean distribution file (harder)

    If you still would like to use LVSpeak with QuickDrop before this package is released. Replace that file in your directory with the one attached after doing a backup of the working one.

    Your choice.

    QuickDrop Launch Window.vi

    • Like 1
  2. And just to put a 'face' with a name with a photo that Veronica says is probably 'LAVA inappropriate' and 'the most skin LAVA has ever seen' (she must never have seen the Coyote Ugly photos)....

    post-208-124889629695_thumb.jpg

    • Like 1
  3. LVSpeak, that would be wonderful, but it doesn't seem to work on XP. It certainly doesn't work on MY XP. I got it to do the "Label Side" and "VI Properties" commands, but I was really interested in getting it to work with Quick Drop. I'm sure I'll get to use it someday, either it'll work with XP or I'll end up in another OS.

    I forgot it was in there, too.

    If you have Quick Edit operational (the component that "Label Side" and "VI Properties" uses, then LVSpeak is fully operational.

    Did you ever install the second package that modifies the Quick Drop VI's?

    Flip this thread over to the LVSpeak thread and we'll figure it out there.

    PS: Must give credit to Chad Bailey, another RF systems engineer that came up w/ the smashy smashy combo command.

    -Norm

  4. Norm;

    Why all these pictures are so cruel. I will not get (and buy) them at all!

    Can you draw something related to mankind, love, peace, help, respect, etc.

    I am a parent and would not like to wear such T shirts!

    um......

    You don't have to wear them. There is the stock NI Week 09 Lava t-shirt that is very plain jane and totally PC and not offensive or risky. (DISCLAIMER: Scripting4Life IS NOT an NI sponsored t-shirt. I do this on my own time and for myself....and others that like it)

    I agree it's a bit graphic, but you can see the original idea is not mine.

    I suppose I could make another one that shows people around the world and a diagram underneath that shows an array of people references w/ a connect terminals invoke node, and showing how scripting is bringing the people of the world together......but that's not as much my speed.

    If you want that shirt, it feels creative enough that I could be compelled to get one up for you on Zazzle.

  5. So something I have done a few times and never questioned the 'appropriateness' of it was the usage of the "Genereal Error Handler CORE" directly on my block diagrams.

    post-208-124881640574_thumb.png

    Now the ONLY reason that I like to use the CORE vi is because of the access to the "Stop Event Propagated" line that is not connected out to any of the other error handler VIs on the palettes.

    The reason this is important, is because you can offer the end user dialog type to have the option to "continue or stop" but you have no way of knowing if they hit continue.

    And I know there are a variety of things I can do, but before I start to investigate making my own dialogs and such, I want to get everyone's feel on what they think of the 'appropriateness' of using this "non-palette level" vi

  6. Shite....

    guess that's why I'm not in marketing

    I should have guessed as much with the way people go WTF after most things I say anyways.

    Maybe I should have used the Monty Python foot w/ the nail through it....

    I could see where it would be very confusing w/out the caption, but usually you here somebody say

    "Whatever 4 Life" when it's something they're devoted to or in this case, willing to live with a rusty nail through the heart.

    but I know, I know, you are probably all still going WTF.

    I was going for something like this which is a classic Sailor Jerry style Tatoo

    knife_thru_heart_true_till_death_old_skool_tattoo_card-p137176827360107650q0yk_400.jpg

  7. I have found that I can speak very quietly and still get picked up. None of my co-workers have started calling me crazy yet, so I guess it's not bothering them.

    My favorite part of this tool is the ability to quickly align code and labels in any number of ways. It saves so much time - especially when dealing with other people's code who might not be as fastidious as I am in keeping things pretty.

    You're using it?!!!! Really!! I've got my first official user!!!! HELL YEAH! I'm going to give you a reputation point just for that .

    Yup, the alignment is about the most used one, and then probably the quick drop integration.

    I have to say that I like the idea ever since I first saw Norm's demo of it last year, but I haven't used it all due to not wanting to install the speech recog utility or speaking all the time in the office.

    Another thing which I think is a major hinderance is the list of options. I think that what QE needs to really take off is a smart parser. This is certainly a tricky bit, but also important, due to the following improvements it could allow:

    1. Writing less code for the framework. To demonstrate this, think of the command "Label visible". Today, it has its own specific VI.
      In the ideal version, the parser would recognize the structure, use the word "label" to get a reference to the label of the object you selected and then pass that reference into the "visible" VI (which was only implemented once, for the GObject class). That would mean that you only have to write the code for each action once. Now that you've written it, "visible" would work all objects, their labels, their captions, etc.
    2. The parser could allow parameters. For example, "caption align left" would obtain the reference to the caption, then call the "align" action and pass "left" as a parameter. Immediately you have only one action instead of several.
    3. Synonyms - imagine if you could say "label visible" or "visible label" or "show label" or "label show", etc. That would make it a lot more "natural", although I admit it's a secondary objective.

    As I said, writing such a parser would be tricky. It's possible that maybe an initial version could use some explicit vocal separators to break the different parts of the text.

    Inside of the MS SAPI we have the ability to do this, although it requires a better understanding of it and more testing that I never got to.

    Actually Darren is hitting me up for this exact thing....

    I just have a hard time seeing how much more that will simplify things on one side for the drawbacks I can see on the implementation side.

    Can you give me 3 solid use cases, because the detect 'Align' then detect 'direction' will still require a unique piece of code for each direction, and the only thing it would make simpler, is that flat top level list of commands and it would make it hierarchical. Also, unfortunately not all properties are common in the VI Server Class structure. Like label is not a GObject item, and certain things require me to detect the specific type, or iterate through the valid ones (you might see this stuff in there)

  8. Being a little slow on the up take here, but which files do I need to download (now that it appears updates have been made since original post) and what other packages (rusty nails I believe you called them) do I need if any.

    Ok, was just about to detail it all out, but head to

    http://eyesonvis.blogspot.com/2009/07/lvspeak-automating-vi-development.html

    and the newest info/details are on that there.

    and once that's done come back here w/ questions

    Thanks,

    Norm

    • Like 2
  9. I have encountered that before, but it was because I wasn't properly separating source code and distribution code. (Using user.lib as a source code dev directory != good idea.) Once I adopted better project organization practices the problem went away.

    Daklu,

    There is a bit of a different situation going on than as you're putting it.

    I don't plan on having the user, use user.lib as a source code dev directory. I'm merely using it as a home for files that will be copied upon the start of a new *widget*.

    Said widget directory, currently under user.lib, contains all files that will be copied and the new widget home will post-208-124826603911_thumb.jpg user.lib.

    If you have a better recommendation for where a *Widget Directory* like this should be placed on a users system, I'm all ears.

    Just keep in mind that it's just 3 simple stupid files that do not warrant a grand and esteemed unique location on disk.

    But in actuality, I'm thinking that SciWare's trick is just what I was looking for.

    So now, this *widget baseline* can remain at user.lib and I can start a new widget from baseline anywhere else on disk.

  10. I have encountered that before, but it was because I wasn't properly separating source code and distribution code. (Using user.lib as a source code dev directory != good idea.) Once I adopted better project organization practices the problem went away.

    Understood, but at the same time, I'm looking for an appropriate single good place for a variety of tools and user.lib fits the bill, it just happens to be that this one thing (baseline template which requires 2 VIs and 1 Ctl) would have to have it's own special place just for itself which I still have not found an appropriate place for (which obviously can not be at a relative path)

  11. From what I recall and can see, is that VIs will look for their SubVIs at the relative location where they existed at the last time the calling VI was saved.

    I'm messing around w/ VIs in user.lib and attempting to copy an entire user.lib directory elsewhere on disk (w/ some renaming and such)

    But what I'm seeing in this situation is that the VIs copied from User.lib will not look for their SubVIs in their relative location first, but rather in their previous location in user.lib.

    Assume for the sake of argument, that these baseline VIs must start out in user.lib.

    Do you feel that the presence of a SubVI in userlib in a Top Level VI in userlib should not look relative first?

    You can replicate this expanding the simple attached VIs into user.lib and then copying the directory elsewhere and then opening the top level vi.

    I recognize this is a corner case, but am trying to see if anyone has encountered this issue before or if there is a better way of working around other than loading the vi hierarchy from their new location bottom up so that the callers see them in their new location first.

    UserLibLink.zip

  12. Definitely hang out on the forums and ask many many questions.

    I would say that if you want to learn how to program LabVIEW, find something that you want to do that would be solved with a program and just program it up.

    An interesting example is something as simple as a contact management program.

    A more involved but useful program might be tracking expenses quicken like.

    Or if you have a few dollars to spend, grab a USB Multi Function DAQ card along with a few relays, sensors and motors and automate something in your dorm room.

    My personal favorite that never got implemented was just a basic door opener or re-inventing "The Clapper".

    Actually I did do the code for the clapper to be honest, but never hooked up the relay to my parallel port.

    And if you're too young to know what the clapper is, just youtube it.

    • Like 1
×
×
  • Create New...

Important Information

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