Norm Kirchner

I am interested to hear how others divide up their distributions.

What is everyones opinion on this?

One of the problems with giving things this kind of standard name, is that what do do you do when 1 package meets two criteria.

Or worse than that, really doesn't fit into the definitions.

Trust me, it's possible.

So I pose this question, does the presence of this identifier really give you any extra value?

Does really a source (NI, NISE, LAVAG, JGCODE) + a descriptive name give you enough?

Also, now that packages can have verbose names different than the file names, does it still make sense to have these abbreviated names that also have things that are in other filterable fields as well?

I'm not so certain that it is.

The list in VIPM is going to get cluttered.... really cluttered because of the amount of packages that are going to be released over time.

So having a few extra abbreviated characters won't provide any information that I would search for when looking for a unique package.

One thing I'd like to see an example and brief explanation of is implementing inter-process communication.

Yeah, I'm working with a guy internally that has a knack for taking my ideas and concepts and working them into the least common denominator of understanding.

So although I could just toss it out there, I've gotta keep chipping away at it to have able to be understood by more people than me.

soon.... soon

In the meanwhile, I strongly suggest you check out the 'Actor Framework' on NI.

It is a different beast w/ different options, but will keep your mind whirring until I get LVx posted out.

Why would you use this over something much simpler?

Joe, this is a great question.

Other than the dynamic event registration of the 'User Parameters', what do you see as not necessary?

The 'App Init' section could be flat, but then that portion of the code gets REALLY cluttered, I have seen this time over time.

The Shifter could just be defined inside of some kind of init case like in the JKI state machine, but that gets REALLY crowded once you have a variety of things in there. and that frame just gets unwieldy.

Take out a case for error handling??? yeah, didn't think so

perhaps take out the 'default' case but what about the typos

Take out the Idle case? but what about when you want to have that

Take out the event structure, ok, but what about elegantly handling the panel close operation or killing the two parallel loops

Don't use 'User parameters' or 'Display Values' inside of the shifter..... but what about when a control value needs to be used in two places? Use local variables?....I think not.

The 'Much Simpler' option could be considered the built in, producer consumer template.

But what about all those things that you need to add every time, also what about the BD real estate.

The 'much simpler option' 8 times out of 10 needs one or some of the options of the better option.

So since you can start out with something that operates as quickly and agile as the 'simpler option' that gives you a scalable, clean, well organized and thought out design,

why would I ever consider going for anything else.

You say simpler, I say more work coding the same stuff over and over and less consistency in code.

I'm not saying mine is the end all design.... but if you don't like it, then you should make something with similar options for yourself to save design time and create a consistent coding experience.

It will provide a quality experience for the coders and those looking at the code.

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>

Did you try "LVx LabVIEW"? It brings up this.

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

Norm!

That's awesome. I remember seeing a discussion about that a while ago but completely missed the sync/async part of the topic, thanks for jogging my memory. I'll have to check that out first thing when I get in to the office on Monday. I worry though that since the behavior change from asynchronous to synchronous isn't documented, that it might be a bug and I'm not sure I'd be comfortable releasing code which requires that behavior. Still warrants further investigation though.

Funny you also play with the notifier. That's one of the ways I was thinking of being able to return a value from the events.

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?

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.

....after zooming i need to acquire the zoomed part of the waveform from the graph ...

can anybody help me out with this?

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>

Norm-

If I hold down the Ctrl key (when selecting items, when scrolling through cases, when I'm thinking, etc.), LVS will drop random functions. Is there a way to remap the keyboard "activate LVS" shortcut?

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

Norm-

I added "scalar to array" and "array to scalar" as we've discussed earlier via the QD interface (Ctrl-A created by Darin.K). It works when I highlight a terminal and speak "scalar to array" on the diagram, but not on the front panel. I added the code to the "BD" and "FP" cases in the QEC - Replace.lvclass:Execute QEC VI. See below for a screen shot of QuickEdit Command.lvclass:Execute QEC VI, which is reporting FP.IsFrontmost = False. I've highlighted the FP control before speaking "scalar to array", so the FP of my VI should be frontmost; however, the reference that I've probed (going into the FP.IsFrontmost method) points to the QuickEdit Command.lvclass:Execute QEC VI (not my VI).

Any ideas as to why this would work on the diagram but not the panel? (QD works fine either place.)

Thanks...

-Jason

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 />So, with a CSI (Common Scripting Interface) / USI (Universal Scripting Interface), if folks preferred (after R&D implements the following), they could just as easily use their LVSpeak, QD, RCF add-ons with Darren's <a href='http://labviewartisan.blogspot.com/2008/12/plug-in-vis-for-right-click-menu.html' class='bbc_url' title='External link' rel='nofollow external'>Plug-in VIs for Right-Click Menu Options</a>. There are probably already discussions going on about having a CSI elsewhere, but I just came across that Plug-in VI idea by Darren again, and wondered: Do we really need to have 4 different implementations for each scripting tool?<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.

Norm-

Thanks for the help. Regarding "remove and rewire", I followed your instructions and probed around but don't see any errors going into or leaving R.vi. See below for a screen shot with error probe and probe for the VI refnum input. Is that VI refnum what R.vi is expecting?

-Jason

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?

I'm having the same experience that John had above. "remove and rewire" doesn't work, but everything else does. I'm not sure that Execute QEC VI is running. I opened it and turned on Retain Wire Values. When I speak "remove and rewire", I see the command appear in the LVSpeak applet, but nothing happens. The wires in the Execute QEC VI are all empty. (Granted I'm a beginner with LVOOP, so I'm not sure that dynamic dispatch isn't running another memory instance of the VI.)

Can we tap into other QD scripting shortcuts (e.g. Darin.K's add-on for "change to array")?

Can we tap into JKI RCF actions (e.g. "wire nodes by corners")?

-Jason

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

Norm,

Thanks for the tip. Now my insipient Alzhiemers doesn't seem quite so bad.

By the way, just a tip you may want to pass along for some newcomers. On my computer the create ( control / indicator / constant ) commands seemed to be very hit or miss some reason. I finally figured out that the command only executes if I approach a terminal from inside the icon. Even though the wiring tool pops up from either direction, nothing happens when I approach it from the outside. Odd, at least to me.

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

So, are all of Norm's posts moderated to be funny?

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

xtal = Crystal