Norm Kirchner

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

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.

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.

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?

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 would bank on the latter....just saying

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

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?

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. 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 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. But as you've seen, not all common properties in class trees are common Excuse me?? What?? Um, U B mistaken sir. XYGraph is a child of WaveformGraph Thats assuming that you're trying to access properties and methods that exist in all cases for the common ancestor 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. 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?

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

When working with dynamic code, sometimes we end up with a generic reference that we need to cast to complete our operation. Example: You make a sub-VI that extracts the plot color of a waveform chart or a graph. The reference input to that VI must be of a common reference type (GraphChart) The problem is that this property, although it exists for both types of references does not exist in the common type. Proof: http://content.screencast.com/users/NJKirchner/folders/Jing/media/d223f6b4-83a2-43dd-a830-be17877c9715/2010-09-10_1849.mp4 So if you want to have a piece of code that can operate on both types of references, what do you do? Somehow you need to have a switch in your code that will conditionally run the correct code based upon the specific reference you wire in. The way some people do this is by utilizing the 'Class Name' property into a case structure but this has problems w/ flexibility Proof: http://content.screencast.com/users/NJKirchner/folders/Jing/media/9f771182-303a-40d2-96db-3701ee43ff7f/2010-09-10_1903.mp4 This is a simple case where there is only 1 or 2 sub-types. What about a numeric w/ all of it's myriad of sub types (slider, guage, etc). The appropriate way to handle this is by doing a type cast, but people typically solve the 'Many Cast' design pattern VERY POORLY through nested error structures. Which looks really ugly Proof: http://content.screencast.com/users/NJKirchner/folders/Jing/media/7c0e0bfe-966a-458a-8bc8-c44bf6a91cc5/2010-09-10_1913.mp4 So what is our alternative? Introducing the very useful, and practically perfect in every way 'Many Cast' design pattern. It's stackable It's scalable And it even tosses errors properly Proof: http://content.screencast.com/users/NJKirchner/folders/Jing/media/55e8e391-bb10-4cc2-9a15-2e2a46912bb6/2010-09-10_1933.mp4 The Code is attached, not as a package 'yet' Demo to Follow in the subsequent post Design Pattern - ManyCast.vi

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

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'

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. 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 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?

??? where do you see a sixteen element queue? Or are you talking about the data structure of the AMC?

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.

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.

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.

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.

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.

Name: TLB - Top-Level Baseline Submitter: Norm Kirchner Submitted: 19 Apr 2011 File Updated: 19 Apr 2011 Category: *Uncertified* LabVIEW Version: 2010 License Type: BSD (Most common) This is the official release of my LV State Machine template; the TLB - Top-Level Baseline. It was presented at the State Machine vs. State Machine presentation at NI Week 2010. This is worth using because it implements most of the common functionality that you end up creating w/ most / all LV state machines anyway: Error handling Idle cases Interactive event driven execution Shutting down parallel loops gracefully String based queued states Handling the Panel Close? event Some techniques used are not immediately intuitive, but each design decision was made with the idea of scalability and ease of use in mind. Please post your 'Why did you do that?' questions and I'll gladly inform and instruct why the design choices were made (including why did I use colors) Click here to download this file