-
Posts
823 -
Joined
-
Last visited
-
Days Won
25
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Norm Kirchner
-
-
I guess since Norm is always using LVSpeak, you can locate him by ear
That's just the sound of LV bending to my will....
-
Works fine on my XP.
FWIW : If he has those other two commands working, then the speech recognition is working and any problem is with the link into quick drop and not to do with the OS.
-
It's only inappropriate in that it doesn't show enough skin Welcome V - see you at the barbie.
it had more..... she made me take it off
HA! a Barbie at the barbie, clever
-
-
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
-
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.
-
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.
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
-
Wow, other than parental interaction in my life age 3 to 28,
this is possibly the most misunderstood I've ever been.
-
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
-
Same here.
Rusty nail.... Loving scripting... get the rusty nail through the heart..... shit... didn't think it was that hard to get.
-
-
My official Twit ID : NJKirchner
Be sure to keep that ID handy on Wednesday of NI week as you can virtually follow me as I give a tour to the 4 lucky people who win the LAVA BBQ Door Prizes!!
Don't forget to sign up early for special rates!
-
Did you find any solution for the grammar problem?
I can't say that I've ever tried to implement it on another language.
Have you adjusted any of the settings for speech under control panel?
-
I'm to the point that I get annoyed if I have to code without it. That, to me, is the sign of a good tool.
But have you used 'Get Pizza' yet
-
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:
- 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. - 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.
- 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)
- Writing less code for the framework. To demonstrate this, think of the command "Label visible". Today, it has its own specific VI.
-
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
- 2
-
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 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.
-
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)
-
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.
-
Am I missing how to do that? Not that I would just give Mike a kudos for asking for one or anything.
-
Back to top is back.
And improved from the looks of it! Thanks guys
-
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.
- 1
-
Sounds like wishful thinking to me...
Should be because I'm pretty sure you were one of the people I owed a beer to
-
Does anyone else see a few updates missing from this listing?
I'm pretty sure I had at least 4 or 5 people on my list by now?
New QuickDrop shortcuts not working
in Development Environment (IDE)
Posted
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