PJM_labview

Hi Keiran First a reminder. Scripting is not support by NI and is not complete at this time. There are a lot of thing on can not do. Now, what exactly are you trying to do ? are you trying to set the value after you create the waveform chart ? Or are you trying to figure out where that 21010 come from ? or something else ? Sorry that I can not be more hopefull at that time. PJM

It's a really interesting idea :thumbup: . I do not know how easy it will be to implement in some cases (ex people doing only close source software for a company), but nonetheless, this is quite an original idea. I like it :thumbup:

Hi all I just spend a couple of weeks struggling with that new support policy, and here is what I finally learn today. The SSP if for one person only, so for example if you have several people (non labview specialist) putting some hardware together (using NI hardware of course) and that they need support this is an extra $295 per person! The "product" is called "Software Service Program for Driver Software" [PN:930999-01.] This is becoming jus plain ridiculous. PJM Note: It took me several weeks to resolve this issue. Our local NI sale rep was fortunately very helpfull

Hi here what you should try to find out. 1) Contact the manufacture that made your shutter controller to find out if they have labview driver and/or a command manual 2) Pending they do not have one (driver and are not wiling to give you the command manual), they certainly provide you with an application (non labview) that can control your hardware. From there there are two approaches 2.a) If the application they provide accept command line parameters (quite rare) then you can pass these parameter from labview 2.b) If the application does not accept command line parameters, Download the free portmon from http://www.sysinternals.com/ntw2k/freeware/portmon.shtml and observe (spy) what command are passed from the application that come with your hardware so you can then used them later from labview to control your hardware. PJM

Jean Pierre, I actually investigate this quite a bit about 8 months ago, and I could not find a way to intercept the merge call. One thing that I was trying to do was to drop some VI that will execute upon merging with the BD; again I was not sucesfull. It did not occur to me to think about CIN (CLIN), may be it will work. The only way I was partially sucessfull was through the use of "custom" express VI. When the flag "configure express VI immediatly" is set to true, Express VI can launch some code. While it does work, I though it was not generic enough to be very usefull. Because of that, I start a project to extend the existing LV palette (I called it "OpenG Palette Extension"). The goal is to have a palette with the "feel" that the existing LV palette, but where we can associate methods to each click on an icon (ex: run, Open FP, Open Diagram ...). I have not investigate about merging code or primitive with the diagram using that tool, but I will in the future. PJM

Naruto, there are several things you can try. 1) Use a classic control 2) Try to change the color of part of the control; you might be able to achieve what you want by just doing that 3) Make the whole control transparent and add a flat decoration frame 4) Edit the control (edit>>customize control) PJM

The Bug (Copy of dir.mnu in user.lib prevent lv7.0 from restarting) is still present in Labview 7.1 PJM

The Bug (Autoscale Property Bug) is still present in Labview 7.1 PJM

The Bug (Blinking controls and SubPanels not compatible) is still present in Labview 7.1 PJM

The Bug (Abort Vi Method Will Generate Vi Mouse Events) is still present in Labview 7.1 PJM

Hi Deep_Blue Library structure Pros Moving and copying the whole program is easy, just one file ... if you don't count any extra dll- and ini-files. Unused files are automatically removed from library at save time. ?? Do you mean when you recreate the llb in a new directory ? otherwize, as far as i know, unused file stay in llb. Upgrading your software to newer LV versions is easy because libraries can hold all the device drivers as well. LLBs can contain VIs from different version of labview (actually a pretty handy feature when one has to distribute an application with specific behavior in different LV version). Library structure Cons Returning the files to directories can't be done, or at least I don't know how. [This is actually wrong, go to tools>Vi labrary manager to do that.] Referencing a file inside the library might be possible, is it? I think not. [Do you mean saving a file other that a VI type is not possible ? if so this is true. If you mean using VI server on a file in a llb, then this is possible.] If naming is not done correctly, it can be a drag to find a certain file from large library.[true] Since the llb is one file, you have no directory structure to organize your VIs (ex: Configuration, Custom Controls, Globals, Hardware Control ...) Directory structure Pros Easy to group logical set of files to different directories [yes]. With dynamic calls, run time editing is possible (so it is in llb?). Directory structure Cons Upgrading LV version changes device drivers to new version also. They may but more probably may not work. (again not so sure about what you mean here). In my opinion, one should use directory structure when developping an application and use LLBs only when/if distributing the app. PJM

Someone was asking for such an utility on the developper exchange. http://exchange.ni.com/servlet/ProcessRequ..._&UCATEGORY_S=0 I am not sure that it is very usefull, but here it is. PJM Download File:post-29-1084249946.zip

Michael, I run your example, and I experience exactly what you described (OS:Win2K). This is a nasty one. I tried a few things to see if there was an "easy" workaround and I could not find anything (other that replacing the Open FP method by the old FP.Open property). PJM

This is true, but it introduce a little annoying (for me at least) side effect when you do that. The reentrant VI appears to be linked to the VI where the static VI reference is. So if for example you are dynamically instanciating that reentrant VI and you are expecting it to show up in the VI Hierearchy (when is sucessfully instanciate), it will never happens because it is "linked" to the VI where the static VI reference is. It does make debugging, in this particular case, a little more difficult (like reentrant VI need to be made more difficult to debug ! ). PJM

Hi Mike It seem that you need to initialize the parent first (outside the loop). By doing so I got the following: a |_3 |_2 |_1 Cheers PJM

Hi Keith, you can check this web site as well: LabVIEW Programming Standards Regards PJM

Hi Everyone, as a follow up to this post: Set alternating diagram colors I made a utility that will generate Labview 7.0 Familiy Tree. It is not optimized for speed, but one does need to run it only once (and the result is saved to a file that is included in the zip file). Caution: the resulting tree seem accurate but it might have errors. PJM Download File:post-29-1082645475.zip

Michael Here is how I do it (In that case it is linked to a Class Specifier Constant) PJM

Jim, Actually I just remember that the "to more generic class" has broken wire if one does not wire the appropriate class (in the appropriate "order"). So this way it should not be necessary to get a reference to the a valid VI server Object. To find out if a wire is broken or no, one just have to invoke the run method and a broken wire should return an error (Wire conflict probably). PJM

Hi Jim, Hmm, I dont see any elegant way to do that. The only approach I can imagine is brute force (meaning create a class specifier constant, then create the "to more specific" primitive then create another class specifier constant wire everything (all using scripting of course) and see if the first class specifier constant can be downcast (to more generic) to the second class specifier constant without error then repeat this process for all classes). Well someone might have a better idea (or inspiration might struck me ) ... Sure, I am willing to donate what I have wrote so far to the OpenG community. PJM

Hi Michael That utility was far on my todo list but it was there. Thanks for shorting my list ! You are welcome. This scripting is indeed extremely usefull. This was indeed what did stop me initially, but once I recognize (like you did) that a diagram is very similar to a giant cluster, I went on writing my own recursive VI to get different type of objects on the diagrams (such as Functions, SubVi, Diagram, Wire, Decoration, All Objects ). Since my grasp of recursion using Call by ref is weak, I wrote a recursive VI using a while loop (see Attached image). Also, I notice the following class hierarchy (can simplify the recursion): Structure [downcast to = (-->) ] -->MultiFramStructure ------>EventStructure ------>CaseSelector ------>Sequence Loop -->WhileLoop ------>TimedLoop (Whatever it is) -->ForLoop FlatSequence is alone (downcast to nothing) So really, when trying to get for example "All Objects" one does have to recursively check only for Structure, Loop and FlatSequence. There are actually so many things that can be done with it, that it is quite hard to select what to try next . I have made tools like VI inspectors that look for certain type of objects (it did actually help me to uncover more exposed srcipting features among other things ). Another one that I made is called "Relink SubVI by Name". The possibilities are endless.

Hi everyone Attached is a tool that demonstrated how to generated private class controls (and constants). It does used the technique described in the following post: Public And Private Classid Names Enjoy PJM Download File:post-29-1081403689.zip

This bug has been reported and confirmed by NI Following is part of NI Response:

David, Usefull indeed ! That one was on my todo list PJM

The following is a repost (with a bonus) of a post I made on the following developer exchange discussion forum: Discussion Forums:Where can i find the classID list for Labview 7.0 Now for the bonus. This is possible to do the same thing with private class refnums (you can see some of them in LabVIEWroot\vi.lib\Utility\XNodeSupport.llb\XNodeParts.vi) Since getting these ClassID (between labview crashes) is time consuming, check the attachement for both (public and private) ClassID Name. Download File:post-29-1080017192.zip