Norm Kirchner

For reference, these are sung in this fashion Here A girl, once named Joline who had reviewed my queued state machine said “No matter what you put through, Your data never quite fills the queue.” But, I told her six is both average and mean. Aye aye yai yai your program only works w/ 'run continuously' so sing me another verse that's worse than the other verse and waltz me around by my while loop A crowd of chicks from R&D were impressed by my large VI Tree. They’d all hoped for a squeeze but I said, “Ladies please, I must limit my queue size to three.” Aye aye yai yai your error wires have always been funky ..... I once knew a girl from japan who was looking for a block diagram I pressed control E and saw his dependency tree and swam all the way back to San Fran Aye aye yai yai If you like that one head over to 'Kiss & Fly' ...... I once knew a girl from floor three who said she had her eyes on me She liked my VI’s most So I wrote her a blog post and now I can’t keep her followers off of me Aye aye yai yai Christina please forgive me for that one...... I once knew a man from Racine who invented a finite state machine meally or moore, it could't keep score because it didn’t even fit on one screen. Aye aye yai yai nobody likes my block diagram colors ...... I once knew a man from Peru Whose for loops only went to iteration two........ aye aye yai yai If you didn't groan at that you've got issues ...... I once a girl named Alli whose while loop had gone to iteration three and then it stopped.... aye aye yai yai You leave breakpoints in password protected VI ...... I once knew a girl I thought hot Who I saw had a grey coercion dot When I took her to bed The damn thing turned red and I ended up in a memory leakage spot aye aye yai yai If you like that one your a sick M@#$% F@#$()* {slowed down} So sing me no more verse........ thats gotta be the worst verse.... and press my abort execution

For those of you interested in the LabVIEW limericks....for your viewing pleasure <object width="480" height="385"><param name="movie" value="http://www.youtube.com/watch?v=qjUn96SV5SQ?fs=1&hl=en_US"><param'>http://www.youtube.com/watch?v=qjUn96SV5SQ?fs=1&hl=en_US"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src="http://www.youtube.com/watch?v=qjUn96SV5SQ?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></object>

Thanks for the link, I doubt I could have found it. There has been a major update (memory leaks and usability improvements) to the framework. There is a very basic example within the package I've made but really, to make a new command is a 7 step process that warrants proper documentation or a Utility VI to do most of it for you. But once that's done, luckily, usage is straightforward. I'll give my obligatory "I'll do what I can to make something shareable and understandable" which unfortunately I've fallen short on over the years

Just to poke an old horse, LVx (LabVIEW Export) was designed for this exact process. The problem is that the lack of proper documentation has always scared people away, but at the core of it, it provides an event based messaging system that has already built in it, the ability to go synchronous or asynchronous. Each different command is a different child class of LVx and an individual command is comprised of both command parameters and return response. So you send your command across, and if you have it configured to wait for response, then you get your command back loaded w/ the results. It's quite handy and I use it for all interprocess communications (it's all over LabVIEW Speak fwiw). It has the added benefit of working not only from VI - VI in the same application instance, but also across application boundaries and even network boundaries. Nancy Hollenback recently went crazy with it and even deployed it to a RT system successfully. There is a learning curve, but if the key fits, it's easier to turn a key than pick the lock. With NI week coming up, i'm going crazy getting content ready. LVx might be one of the packages I get ready for it. Does this sound like something you could use for this?

There is a little trick I found out about a little while back. You can register a UserEvent with a callback VI What this means is that every time you fire a user event, a VI gets asynchronously fired. Now I thought this had a lot of potential because finally we could start a VI running asynchronously and pass it parameters w/ out needing to use crappy VI server methods. The problem is that the Fire User Event node, which up until this point, under all conditions, ran asynchronously, now is blocking, waiting for the Callback VI to complete. See this video http://screencast.com/t/MDQ0NTk1ZGMt <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/0ff19684-4f74-4d3c-97fe-059b5492f207/2010-07-24_2159.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/0ff19684-4f74-4d3c-97fe-059b5492f207/2010-07-24_2159.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/0ff19684-4f74-4d3c-97fe-059b5492f207/2010-07-24_2159.png" width="889" height="401" border="0" /></a> Well this dashed my plans for world domination, but it seems to be that this behavior is wanted in your case. Attached you will find the Main and Callback VI that demonstrates this. I'm curious to hear your thoughts on this tactic. -Norm UECallback.zip

Francois, I like the way that you've coded this up, but there is a minor yet major point you've missed. Although this will work great for things like numerics and such, things that have hierarchical layers of properties will fall very short. I've been trying to eat the beast from the inside in order to make this possible through scripting by being able to get the full hierarchy of properties exposed through VI Server, but have fallen short so far. There are a few classifications of property 'types' that warrant having some time spent defining. I really think that an waveform graph is probably the most inclusive of all types and also the one that needs this ability the most (think XControls) Unless I really mis-read your code, and it actually does this exact thing. (if so, feel free to steal one of the beers that I've got lined up for me @ ni week this year) -Norm

I am so ecstatic that others are trying to push the process of using dynamic user events w/ objects in with LV and bundling/collecting references, as I've been attempting to do the same for a long time and felt pretty alone That being said I'll toss a minor alternative to the 4 that does not require the use of an explicit typecast. Although the same process, the code gets a little cleaner and w/ some creativity you could VI script some interesting helper VIs to make this easier for you (like burying stuff inside of a sub-vi that the scripting VI's know how to properly edit But the basic premise of this change, is that you use a register event node to properly name everything, and then when it comes time to actually wire in the references, that portion of the code is a bit cleaner.

I would suggest that you look into the XScale.Range property From this range as you can see from the image below, you can determine the max and min of the currently displayed waveform. From that point it will be up to you to use the proper functions to crop your waveform <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e7e24f33-c471-459c-b127-1036a9352247/2010-06-01_0035.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/e7e24f33-c471-459c-b127-1036a9352247/2010-06-01_0035.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e7e24f33-c471-459c-b127-1036a9352247/2010-06-01_0035.png" width="532" height="624" border="0" /></a> I would suggest bundling your data into a waveform data type to take advantage of the 'Waveform Subset' function available to that data type <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/055343d7-062d-4df0-8aa2-1e289ea16243/2010-06-01_0038.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/055343d7-062d-4df0-8aa2-1e289ea16243/2010-06-01_0038.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/055343d7-062d-4df0-8aa2-1e289ea16243/2010-06-01_0038.png" width="986" height="498" border="0" /></a>

I've run into the same thing before and know what you mean. To answer your question, definitely. Unfortunately it's a hard code in the software at the moment, but it is indeed configurable. Open the VI C:\Program Files\National Instruments\LabVIEW 2009\project\_LVSpeak\ENGINE - LVSpeak.vi Within that VI you will see a callback registration and some user parameters. This is where you'll change your values There will eventually be a re-architecture of this that will happen that will make this configuration easier to change, but for now this is the way it needs to be done.

I know it still says *.* all files, but how does this fit your bill <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/d00d39d8-7634-4949-bef6-fdbbbce48a26/2010-05-05_1210.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/d00d39d8-7634-4949-bef6-fdbbbce48a26/2010-05-05_1210.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/d00d39d8-7634-4949-bef6-fdbbbce48a26/2010-05-05_1210.png" width="509" height="312" border="0" /></a> <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/164a2592-2d5a-4740-8401-7014f8b58bbf/2010-05-05_1210.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/164a2592-2d5a-4740-8401-7014f8b58bbf/2010-05-05_1210.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/164a2592-2d5a-4740-8401-7014f8b58bbf/2010-05-05_1210.png" width="733" height="296" border="0" /></a> Tool - File Dialog_Multi Patern.vi

I'll look into it, but it happens to be a command I already built before Darren's shortcut so I've never seen it not work. (I call mine pluralize, but I suppose his is more descriptive).> > I just looked at your image though, and you've caught the wrong reference. Unfortunately when debugging you have to be extra careful what is active when you invoke the command. As you have shown is the QEC execute as the active VI, which I assume to not be correct.

<br /><br /><br />Once again, you're spot on. I've spoken with both Jim and Darren and we're all in agreement (almost) Each of our frameworks implement the same flow (get input from user -> execute a specific VI), but the specific differences make things a little more complicated (not impossible though) and just need more thought put into. A great example is that QD has a default user field that people can type into. How does that flow work into QD or LVS? another example is that RCF has an 'Options' ability and cascaded menus. How does that flow work into QD or LVS? But before you start to try to answer those questions (already have some thoughts on it) realize this; LVSpeak is not 'just' a speech recognition engine... well technically it is, but the LVS package also includes Quick Edit. IMHO: Quick Edit is intended to be this central unifying engine that enables users to invoke a VI through whatever mean they so choose (speech, QuickDrop typing, right clicking). Because of it's plug-in and object oriented approach each of these enabling technologies can take advantage of it in the same manner that LVS has. This does not mean that it has all capabilities ready to rock and roll to ensure no loss of functionality for the other methods, but at the heart of the issue QD shortcuts are a hack on the QD window. And RCF, although very feature rich, has the meat of the code that does the work 'very' tightly integrated within the framework. So what is needed (and I feel QD as is, is a good step in this direction) is an engine that JoeLVUser can tap into to execute VIs to help his development, Scripting, ordering pizza, or just dropping structure. Would you agree with this from what you've seen?

Jason You are indeed correct and apparently in phase and frequency locked with the way my brain is spinning. Well done. Yes, I'm thinking that making unique sub-classes for QD and RCF plugins is in order to address these exact kind of issues. WRT the 'end undo' this is just a byproduct of how Darren set guidelines for ppl to create QD shortcuts (explicitly handle the undo action in the scripting VI rather than the framework doing it for you). This is a totally valid stance and at the end of the day, the cat is still bald. So regardless of if it's FP or BD, if the person who created that plugin, took into consideration Darrens guidelines, we can presume that all QD shortcuts will need to prematurely end the QEC undo operation so the QD transaction can begin. You would find the 'end undo' within the parent call of Execute QEC.vi <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/96c8d298-b581-40a4-9eba-017a8429d87d/2010-04-16_1027.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/96c8d298-b581-40a4-9eba-017a8429d87d/2010-04-16_1027.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/96c8d298-b581-40a4-9eba-017a8429d87d/2010-04-16_1027.png" width="371" height="290" border="0" /></a> If you didn't notice, I actually call the parent class twice, once at the beginning and another at the end. The nice thing about this design, is that now when it comes time to make a QDS QEC class, we can structure these parent level calls to indeed call {QEC::Execute -> QDS::Execute (which will end undo) -> QDS_SHORTCUT::Execute (Specific Shortcut via enum case within ) Making one for QD will be pretty darn easy. RCF I imagine will be much more difficult because of determining if/how we can circumvent the framework and just execute the needed code. At this point, it's a time and resource issue for me. But it needs to be done at some point so we can converge our methodologies.

Your probing the right place, but the reference is invalid, Because of the nature of working within a tool that tries to figure out what is currently selected/active/hovered over, you must not interact w/ the VI your debugging in the process. So set the probe in the same manner, and most likely a breakpoint as well, go back to the VI of interest that you're attempting to operate on and then perform the operation. The Execute QEC should breakpoint and the probe be correct. Take a picture of that, and if it still is not functioning properly then we have identified the source of the bug ***** EDIT ***** Ok, the source of the bug is known and I thought I already dealt with it actually. Guess I inadvertently undid a fix which is funny due to the nature of the bug. What is happening is that I already setup an 'UNDO' session in the first VI in the QEC command, and there is another 'UNDO' session being set within the remove and rewire VI. If you haven't figured it out by now, that is a no-no. The fix, that I'll roll into this, is to artificially end the undo session before calling remove and rewire using a transaction.end undo method before you call 'remove and rewire' I just tested this out on my PC at home and that fixed the issue. What will need to happen is that either I make a generic plug-in for all QuickDrop shortcuts that addresses this first. or make a sub-class of QEC Command that is specific for QD shortcuts, that all QD shortcut LVS implementations use. Thoughts? Did you try the fix?

Jason, I'm really excited that you've taken to LVSpeak the way I hoped many would. To address the questions you have, I've noticed the way remove and re-wire behaves, but hadn't taken the time to fully debug myself (not often used by myself). But the way you would debug is to invoke the command "Show Quick Edit" or right click the notification tray and use that same right click option. once open you should be able to put a breakpoint right before the dynamic dispatch call 'Execute QEC Command'. Once the program breaks at that point, 'step into' the QEC command and it should dispatch you to the BD of remove and rewire. You have to take this convoluted route because Quick Edit operates in the NI.LV.Editor context and the only way to debug in these contexts is to hack into a VI in non-traditional ways. Ideally, I should put some debugging code in there that properly reports any errors of a variety of styles. WRT other editor assistants like QD shortcuts and JKI RCF plugins, you most definitely can tap into their IP. For QD Shortcuts, the process is as simple as making a new plugin that calls the QD shortcut VI like for remove and rewire and assigning it a speech command. Ideally, I would create a plugin that just scans that directory and assigns names based on one of their properties For RCF, the process is a bit more involved, because there is not 1 predefined VI that the action code exists in. So you need to open the plugins, find the needed code in their framwork, and then plop that into the appropriate case for the Execute QEC command. I'm not sure if all of that made sense to you, but please ping me back w/ other concerns or findings while you debug. -Norm

Anyone looking for a job at NI....there might be an opening in the RF Segment soon

I'm concerned w/ the update rate if you are working on a LAN. How much data is being displayed on this Remote Front Panel? In my experience the Remote Front Panel was a great tool for simple applications, but unfortunately fell flat when you tried to push it too much. And I have not noticed(before in the walls) or heard of (inside of the walls) any grand effort to improve upon it. But I'm far from all knowing.... somewhat

I ran into this a ton back at TI wrt wanting to not have the system need to compile anything at load time....that's just sloppy. But then I had to balance against checking in a file a ridiculous number of times for re-compile. In the end I just gave into having a ton of useless check in's I think this is something worth someone @ NI addressing our stance on (which I really don't know but figure it'll be "just check in a bunch" I'll try to pass this onto some other folk, but no guarantees. Keep bitching about it though and maybe some proposed solutions my 2c

It should have no difference where you approach it from, but it does matter if you are actually over the physical bounds of the terminal. What this means is that although the Sub-VI show's it's whiskers to the terminals, and traditionally you would be able to right click a whisker (which isn't over the terminal) and do all the terminal operations, the 'Create' command will not operate. The 'Black Magic' simply harvests ALL terminals on diagram of interest, and then does a bounds check to see if the cursor point is within the bounds of one. So although you think that you're there because of the whiskers, you may not be. If you can, take a Jing screencast of what you're experiencing and post it. ***SIDE NOTE**** and known bug ftm If you have a stacked structure (Case, Event, Sequence) and there is a terminal on another layer (not top) directly under the terminal you are trying to create upon....it might create that (whatever) on that other layer. The bug is known, and fix relatively figured out, just not implemented yet. -Norm

The person referred to as Norm has officially stopped posting and this is merely an AI bot installed to make his account not go inactive

= <Comment Edited Out by Board Administrator for Inappropriate Public Forum Adjectives>

Norm Kirchner /LAVA 2.0 NJKirchner / LAVA 1.0 NJKirchner /NI Captain / All the ladies BWHAAHAHAHAHA hopefully I didn't cause anyone to do a on their monitor.

I've been working on this and made improvements and yup... it definitely needs a better getting started example than whatever I have released previously. But luckily I have worked on it w/ ppl who haven't seen it before enough to finally put together some good getting started docs. Although the non-OO implementation is where this idea got it's roots at, I'm not sure if I would ever go back to that or recommend starting from that. I've weighed the pros against the cons in terms of needed understanding and difference in paradigm, but over the years that I've worked with/on it, all those minor improvements I've made would not have been easy and/or possible to include in anything that had already used it. In other words, you can start out w/out OO, but the minute you want to add some capability, fix a bug or get creative w/ your design.... you'll wish you hadn't made that tradeoff. Editors Commend: The LVx concept is definitely Scott's design (and is a work of genius! ) . I just took it an ran w/ it (some would say over the edge). But if you ever look into the guts of LVSpeak, every bit of interprocess messaging and even intraprocess messaging is done with LVx-OO and boy am I glad I did. I'll do what I can to sacrifice some sleep to get a long long long overdue package of this out. Don't forget the 'message pump' as well. Never did get to fully appreciate the capabilities of that but always felt that it was a strong contender to LVx although different in a couple key ways.

I'm sorry Dave.... I can't do that. Had to do that But that aside, you absolutely can get that list in 'text' form. If you look into the Freaking Fast Drop plugin within <lv>\resource\QuickEdit\Plugins\FreakingFastDrop The each plugin overrides the parent QuickEditCommand(QEC) "Supported Commands.vi" and outputs the list of strings that are registered. For the case of FFD, it outputs all Contro/Function palette items and the QD shortcuts.