Norm Kirchner

Within LabVIEW Speak I have 3 commands that have proven VERY useful over time similar to this

Copy VI Path

Copy VI Folder Path

Explore to VI

So although not another way of doing the same thing, you may want to consider adding them to your list of commands

One of the best reasons to use them within a DVR is to take advantage of the new ability to create your own property node calls off of an object.

Another terrific reason to use them is that if you choose this design choice, you can take advantage of some awesome design that has been developed to aid in the management and extensibility of them

http://decibel.ni.co.../docs/DOC-12813

This tool gives you the ability to have Named DVR's and also adds extensibility to the first obtain and the last release.

The naming of a DVR is a major reason some people would stay with SEQ (Single Element Q), but with the ESF, that is no longer a limitation for DVR's

Add on top of that the ability to have 'first obtain' and 'Last Release' code seamlessly integrated into the flow w/ no additional wires needed...... you can't go wrong

I look forward to seeing your thoughts on the ESF - Extensible Session Framework

Norm Kirchner

~,~ The Captain was Here

PS if you need a good idea of a 'Hello world' style example with it, make a basic timer.

You've got a handsome family Omar!

Merry Christmas to you and yours!!!!!

LVOOP Property Nodes

Calling all CLA!

Head on over to the CLA Summit 2011 Page and give your comments please.

{EDITORS NOTE}:: It's in a private group so you must join first here

CLA Summit 2010 was a huge success and this years will be better yet.

Comments like "It was worth the airfare" which came from a CLA from Italy should convince you to not only attend but also shape the content and format.

So once again

http://decibel.ni.com/content/projects/cla-summit-march-2011/blog/2010/11/17/time-to-plan-for-cla-summit#comments

See you all soon

Norm Kirchner

Sr RF Systems Engineer

National Instruments

~,~

CLA, CTA, CPI, Defrock'd LV Champion

General RF Nuisance

My VIPM is crippled by my works proxy and rediculous IM rules so I was wondering if it is possible that these be shared in a non VIP format?

I will continue to try and get the VIPM solution fixed but at the moment I would love to see this design pattern if it is at all possible.

If you can at least download the file then you should be able to view the files by extracting them w/ a .zip extractor.

Let me know if you can't even get that far

Best,

Norm

I had to do some cleanup on the BD to figure out what was going on, I thought I would share the re-arranged version so everyone doesn't need to go through the same exercise as I did.

OpenCL Lib Test.vi

I noticed in the AMC documentation that it is suitable for use in machine to machine communications over TCP/IP networks. Is LVx implementation superior to the AMC implementation?

It's not quite a fair apples to apples comparison between the two technologies.

I would not say that it is 'superior' but it accomplishes some different things.

The primary difference, is that LVx is an event driven system. Where you have a Component of a System (an implementation of the TLB) which acts as a receiver of requests. That component registers for multiple events that it can receive from external sources (or internal).

Also the biggest difference is that LVx is setup (by default) as a command response architecture. Where each command/request can contain both input parameters and response information. It allows you to create true 'virtual instruments' and send commands to them as you would any instrument and get information back in the response or simply just sending commands.

As a secondary, because I use LVOOP as the core of the data which flows, there is no need for flattening or unflattening of data as there would be within the AMC.

So LVx covers some more ground in what it accomplishes out of the box. (Event driven, LVOOP based, response embedded)

And as soon as I greatly simplify the process of making a new command elegantly, we'll all be much further down the road to using it for a variety of things.

In the meantime is there any good documentation on TLB and the AMC class that it uses extensively?

The AMC is on NI's website and was developed by another Systems Engineer Christian Loew.

Documentation on it is listed there.

The TLB's documentation is ..... in work although the presentation is a good starting point.

Most parts other than the dynamic event registration are straighforward, but the rules of thumb and guidelines need to be well noted somewhere.

Also this work appears to be a derivative of your previous LVx work. Also previously packaged as RFSE Tools. Do the examples created for LVx apply in the TLB state machine?

Mark,

Thank you for bringing this up. You are correct in your observation that the two technologies (LVx and the TLB) work together and work together well.

However one is not reliant upon the other, just as the JKI exports were not critical to the overall JKI SM.

LVx is the technology that enables the interprocess communication and has been in a state of preparation for mass distribution for a while and that statement still holds.

Currently the process of making a new command is too cumbersome and desperately needs tools to aid in the process of creation of new commands.

That and some good documentation (although the code is very clean)

So if you use the TLB, because of the structure, adding LVx (LabVIEW Exports) to your baseline implemented code should be simple.

I am very tempted to post the current version out here, but then the process installing a package once I finish it will cause conflicts, so I hesitate for a minute.

Will you be able to wait a little bit till I package it up in a VIP?

Since the campaign seems to have worked, and this thread seems to have wandered off-topic anyway... every time I go to IE I wonder, "What's the difference between a 'Hot Idea' and a 'New Idea' "? Any guesses from anyone out there?

Edit: I get that "New Ideas" is actually a list of *all* ideas (all 69 pages of 'em). So the question is really about how "Hot Ideas" -- also a list of all ideas -- is sorted.

New Idea

http://www.google.com/imgres?imgurl=http://www.inclusive-solutions.com/images/lightbulb_idea%255B1%255D.jpg&imgrefurl=http://www.inclusive-solutions.com/ideas.asp&usg=__G6EUYs6gle_kMTs1m1MnEDp1Wlo=&h=400&w=400&sz=22&hl=en&start=2&zoom=1&tbnid=UKYIg9_iatTsEM:&tbnh=124&tbnw=124&prev=/images%3Fq%3Dnew%2Bidea%26hl%3Den%26safe%3Doff%26sa%3DX%26rlz%3D1C1GGLS_enUS355US355%26biw%3D1680%26bih%3D965%26tbs%3Disch:1%26prmd%3Divnb&itbs=1&ei=9TKSTMHxD4TJnAeQnrz_Bg

Hot Idea

http://www.google.com/imgres?imgurl=http://i223.photobucket.com/albums/dd150/racha_chyank_vandy/head_on_fire2.jpg&imgrefurl=http://www.myspace.com/6689806&h=404&w=300&sz=37&tbnid=k5RmyOxEXrVGrM:&tbnh=261&tbnw=193&prev=/images%3Fq%3Dhead%2Bon%2Bfire&zoom=1&q=head+on+fire&hl=en&usg=__1IQ0zqS7vEFyE-kYxBqKQ_1o7ik=&sa=X&ei=tDKSTIXCLcSBlAeC8ISmCg&ved=0CBkQ9QEwAA

All,

Amkor Technology (www.amkor.com) is currently looking to hire a skilled LabVIEW developer in the Phoenix AZ area.

This developer would be involved in the design and development of a semi-conductor ATE platform utilizing NI hardware and software.

I can't give too much more information at the moment, but I have been informed to pass along the instructions to

"have them go to the amkor web site and apply to the test engineer job posting in chandler. also give me their names"

I have worked with, and will be working with this team; they are doing some very exciting things.

If you are interested please follow the above instructions and PM me here so that I can pass along your information.

Best Regards

Norman Kirchner

Norm.Kirchner@NI.com

~,~

I still contend that N could probably be high enough to implement at least 20 of the relatively simple ideas there without endangering the overall stability goal, including this one, although I could obviously be completely wrong).

I would bank on the latter....just saying

I can't remember off-hand how to get th BD reference (cannot seem to find it in the list). I'll have to dig into my old code

for a refresher example (is it only available if scripting is installed and activated?).

Yes, grab it from ni labs

And to clarify the challenge, make a sub-VI that takes an array of GObject references input and converts both constants and control terminals into indicators

Hmmm. Now I see no difference between the "string" based system and this one apart from the "string" one will always do it first time, every-time (if it can) but this method has to try a few different ones before either it hits one that works or it runs out of options. Same number of cases because there is no common denominator and each operation has different properties and methods.

It seems to me that the graph example is indeed a one-off scenario where you save 1 case.

Ok then, replicate the code that I have that can handle changing both a control to an indicator and a constant to an indicator.

How many cases would you need for that w/ the string based implementation?

Functionally I don't think it's any different, but there's a HUGE difference in readability. I suspect Norm has been spending a lot of time looking at customer's code lately.

(Personally I really dislike nested case structures. The logic is too hard to understand at a glance. If I can I'll usually execute all the logic tests, put the results in a boolean array, convert it to a number, and wire that into the case structure. Then I drop a comment explaining the logic. It's much easier for me to check the code that way.)

Oh, and without going back and watching the videos again, what was the first word Norm said on all four of the videos?

SO.....Dak, the problem is that it is functionally different. Check out the second video again. If someone made a piece of code that only had String Name case structures for ClassName WaveformChart & WaveformGraph, their code would fail to execute anything if those were the only two cases handled EVEN THOUGH the WaveformGraph case could have handled the XYGraph just fine.

Really? Its easier to read 0,1,2,3... than WaveFormGraph, WaveformChart, XYGraph... ?

Shaun, I agree that having the Class Available in the case selector would be better and maintain the robustness and flexibility of the pattern, but that requires a new type of stacked frame structure in LV to exist outside of a feature request

You mean the difference is that instead typing in the class name you wanted to handle you, would just "Copy Case" and change the cast constant instead?

No, I'm saying w/ the design pattern, you don't have to make a special unique case for the XYGraph at all because the cast to WaveformGraph will not fail.

Not really. Because unlike graphs the a property node accepts all the numeric classes for the common properties.

But as you've seen, not all common properties in class trees are common

Certainly waveformchart,waveformgraph and xygraph don't have child classes.

Excuse me?? What?? Um, U B mistaken sir. XYGraph is a child of WaveformGraph

Neither do boolean, cluster etc

Numeric types are consistent (whether they be a U16, DBL, slider, knob,gauge or whatever) since all the common properties can be wired to the same property node.

Thats assuming that you're trying to access properties and methods that exist in all cases for the common ancestor

(after all wise words from NI are never to be taken lightly).

You give me far too much credit sir.

Working in the tower has it's perks, but not the midas touch of LV wisdom.

Although easy access to the 3rd floor is damn nice.

Unfortunately I seem to have remembered correctly (what? No crying emoticon?) as this works as I would expect

However, Plot color isn't available, yet it is still common to all plots.

Which brings me back to the summation that you have really highlighted a problem of inconsistency of the property node for waveform types since this also works.

So. You don't have to create a case for every class and subclass. Only the parent (if at all). Apart from some properties of waveforms (there maybe others but waveforms are the only one I've come across).

SO.... this gets to the heart of your argument and the weakness in my example.

I stand by my example as a good simple case of showing why the string based operation fails and if someone was trying to make some generic code for waveform graphs they would easily miss the XYGraph case and need to go back and re-code

BUT!!! Where this code really shines is while doing LVScripting, where you end up with an array of GObject often and need to operate on a variety of types which a common ancestor with the needed functions can not be assumed or found.

EXAMPLE:

<object id="scPlayer" class="embeddedObject" width="944" height="566" type="application/x-shockwave-flash" data="http://content.screencast.com/users/NJKirchner/folders/Jing/media/4175933d-db01-4105-b527-c9935b5bc59f/jingh264player.swf">

<param name="movie" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/4175933d-db01-4105-b527-c9935b5bc59f/jingh264player.swf">

<param name="quality" value="high">

<param name="bgcolor" value="#FFFFFF">

<param name="flashVars" value="thumb=http://content.screencast.com/users/NJKirchner/folders/Jing/media/4175933d-db01-4105-b527-c9935b5bc59f/FirstFrame.jpg&containerwidth=944&containerheight=566&content=http://content.screencast.com/users/NJKirchner/folders/Jing/media/4175933d-db01-4105-b527-c9935b5bc59f/2010-09-11_1240.mp4&blurover=false">

<param name="allowFullScreen" value="true">

<param name="scale" value="showall">

<param name="allowScriptAccess" value="always">

<param name="base" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/4175933d-db01-4105-b527-c9935b5bc59f/">

<video width="944" height="566" controls="controls">

<source src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/4175933d-db01-4105-b527-c9935b5bc59f/2010-09-11_1240.mp4" type="video/mp4;">

Your browser cannot play this video. Learn how to fix this.

</video>

</object>

By all means, keep using the 'Class Name' based selection of your code, but I believe you will find that, although it potentially meets your needs immediately, you have introduced a point of weakness into your code that unnecessarily would need modification to handle cases not originally though of. But why would you?

Hmmm.

I don't really see he difference between your using the class name "problem" example and using an iterative apart from the class name has a descriptive case name and the iterative "trial and error" just has 0,1,2 etc. You still have to have a case to handle the particular type to do the correct cast but with the iterative approach you have to try all the previous ones first before deciding its not supported. With the class name its either supported or not.

Is there another benefit I'm missing?

You did not see what happened with the XY graph did you?

You would have to account for EVERY possible child string.

EVERY CLASS NAME.

If you had some VI that had a GObject come into it's terminal,

you would need to manually enter the 'Class Name' for EVERY Class Name of EVERY child class that you wanted to handle.

If GObject was the input and you wanted to do a bunch of operations on all, or even a subset, of numerics types,

you would have to figure out every class name possible,

and then type it in perfectly in the case selector,

and then hope and pray that NI doesn't release another item in the GObject tree that now your code won't work with.

It's all about Scalability, robustness & re-usability. You do not get that w/ the string

So all we're talking about here is having the hooks added and possibly Darren's code or ours should we choose, right?

If you code monkeys force me to 4224 instead of 5335 and tag .ctl or .lvclass on the end of all of my controls more than you already do, I'm going to take my pikachu down to the 3rd floor and demonstrate some hand to hand knife fighting moves on him.

http://twitpic.com/2c6s2s

David,

There currently is no real easy way to know what terminal is currently the 'active context'

BUT! there are a few different methods that have been implemented, one of which is in LabVIEW Speak that can spit out a terminal reference to whatever is currently hovered over on a specific VI.

Watch around minute 4 http://www.screencast.com/users/NJKirchner/folders/Jing/media/dd8c0257-e118-4819-b113-d434046b7c0c

If you install the tool, you'll find the Quick Edit Command plugin for creating at

C:\Program Files\National Instruments\LabVIEW 2009\resource\QuickEdit\Plugins\Create\Execute QEC.vi

from there you can find the function that takes a VI reference and spits out a terminal reference to whatever was hovered over (if anything is being hovered over)

<a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/32467ab6-d1e3-498e-882f-c123898f90ed/2010-09-10_1029.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/32467ab6-d1e3-498e-882f-c123898f90ed/2010-09-10_1029.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/32467ab6-d1e3-498e-882f-c123898f90ed/2010-09-10_1029.png" width="788" height="367" border="0" /></a>

This VI is currently password protected and I forgot my password.....

So I'll see if I can crack it back open and show the how's

How does the event structure inside an event structure work?

When do you put an event in the the innermost one and when do you create one in the outermost?

The basic idea is that ALL registered 'User Parameter' fire that generic event case, but if one of the controls needs to have a more specific action fired as well then explicitly register that specific 'User Parameter' for that inner event structure.

It works just as you might imagine, and they must be nested to ensure that the 'Update User Parameters' get's enqueued first.

So although unorthodox, the flow of data and events and states are valid and useful.

There are other ways to skin the cat, but really this one is resistant to issues caused by changing control labels and the removal of controls.

An example is one of a device handle.

Although considered a simple 'User Parameter' and expecting to follow the same flow, when you change the value, you likely would like to close the session to the previously selected item.

So in this case, the instrument handle selector would be a 'User Parameter' amongst the rest, but I would have a specific nested event that is registered for the Instrument Handle specifically that enqueues the command 'Disconnect Instrument'

Why did you decide to run as a "wizard", was that to show a "working" example of the template? I like that it creates not only the template, but all the supporting files as well nicely packaged in a project. Are there any other reasons?

I'm assuming that you're talking about the springboard as a tool. It's because a side effect of using this template is that there are supporting files. And the only elegant way to make a new version of a template and it's supporting files is to copy a library. Doing so maintains linkages and namespaces the VI. So by having my create wizard, I save the end user the cumbersome process of copying an existing library from disk to create a new one.

I believe you mentioned it during the presentation at NI Week, but I don't remember exactly, so, why do you use the dynamic event registration as opposed to adding event cases for all the individual user parameters?

Have you ever had 15 things registered for the same event? How wide was that case selector, How difficult was it to see what was registered for that frame, how easy was it to add a new registrant.

By using the dynamic events, I keep the case selector compact, I easily add elements that are registered, and I easily can see and understand who is registered

So, why did you use colors? I like it, because it gives you a "map" of where you are at and ... well... it looks "pretty"

I did it for those reasons, and it helps focus your attention to an area of interest.

For those still questioning this decision, What do you feel is easier to look at? Which makes it easier to follow which section to go to?

A more detailed question: Why a sixteen element queue?

??? where do you see a sixteen element queue?

Or are you talking about the data structure of the AMC?

I should have used an emoticon, sorry. I agree that BD size is not an issue with the TLB.

that's OK that you didn't.

It gave me a chance to put down in words a response that will be needed at some point to someone that really does feel that way.

It doesn't fit on my screen.

Before I go into this too deep, are you operating at at least 1024x768?

Assuming that you are, let me lay out why this design holds up against the 'bigger than 1 screen argument.

We'll start big and work our way down.

Vertical resolution of at least 1024 (1280x1024 or 1600x1050)

You will easily see the code that you will be working with 98+% of the time (Event handler loop and Primary Execution)

Does the fact that the other 2% or less of the time you can't see that other code?

Personally I would rather have more real estate to route wires cleanly and document than cram. period. end of story

Also, in this case, you will only need to scroll in one direction, which by most of our standards, is ok style practice if the situation warrants (see previous point)

Resolution of 1024x768

Although you lose visibility of 40% the architecture at this low resolution take into consideration what is the largest loop.

The Primary Execution Loop, the one that you will interact with 93% of the time or more.

So although there will be a lot of scrolling when working with the other sections potentially, you are still able to follow the primary flow of your program without needing to scroll in the process.

In summary

You will find that although you have an architecture in front of you that goes beyond your monitors display,

as you implement code, the containment of sections of code into monitor digestible sections makes it Very usable.