PJM_labview

Michael, it is possible and much easier than I first thought.  Here (attached) is a working, and fairly complete solution -- it supports compound types including nested variants (variants containing variants).  It is currently sub-optimal for arrays, which can be improved... but that solution is also non-trivial  :laugh: 

Jean-Pierre (et al.), I was thinking that we could use this VI as a replacement for "Remove Typedefs from Variant" in the lvdata package.  Maybe we could add a "Recursive?" boolean argument that defaults to FALSE so that the original behavior is preserved for existing users (but would they even want the original behavior?).

Any thoughts?

 

Cheers,

-Jim

1279[/snapback]

Using "Variant To Flattened String" and "Flattened String To Variant" seem to do just that (remove typedef) by itself or am I missing something ?

PJM

Hi

Check this post Automatic Code Generation, How to DIY Auto Code Generation!! and more specifically this section:

VI:ConPane (The read version of it): ..\National Instruments\LabVIEW 7.0\vi.lib\express\express output\ExFileWriteConfig.llb\Configure Write LabVIEW Measurement File.vi

VERY usefull. I have made an utility using this property very similar to the call by reference but it is non blocking (using the conpane to pass data to the target VI)

You will be able to access conpane references and its exposed properties and methods

Good Luck

PJM

I have see this post before,but what puzzles me most is how to get the refnum specified to a certain object.For example,the nodes you selected in a block diagram or the vi's block diagram of which you are editing,how to get their refnums in another vi dynamicly.Only with this i can write a tool-vi to help programming when i am "drawing" with lv block diagram.

1267[/snapback]

Nil

Look at the attached image.

PJM

Note: NI "fixed" [read: re-password protect] most of the exposed VI in LV7.1. So you might have to download one of the example post on this board (if you are using LV7.1) to get at some of the scripting function

Norm,

Can you attach the original jpeg picture?

I have a few things that I could try.

First, try reading the image (read JPG File) with use 8 bit color table flag set to true.

Note:if it work and If you are still using LV7.0, you will have to do "set control value" on read JPG file, as the "8 bit color table" was disconnected (by mistake by NI) from the ConPane.

Or you can try this (copy from my answer on info labview)

"Check the Bird's Eye View utility.

For the LV6.x code I made a "fake" [read faster]

bilinear interpolation (the name is: Bi-Linear

Interpolation fake__Bird'sEyeView.vi).

It does improve the image - especially text

readability - but makes it softer (slightly blurry)."

PJM

John

The biggest disadvantage is that if in the future you decide to add a parameter (a control to your front panel) to the log file, then the old log file is no longer readable (compatible).

Also, the log file is monolithic. If anything happen to it, you loose everything.

All together I tried it but I eventually switched back to an "home grown" ini based data logging.

btw, I think that function has been there for quite a while now.

PJM

John,

You have to use VI server to open a reference to the SubVI and then use methods like "Set Control Value" or "Set Control Value [Variant]".

Attached is an example I made demonstrating how to do this for Sub Paneled VI.

PJM

PassInputToSub.llb - Image:

Download File:post-121-1089670309.llb

Hi

I have no experience with FP [so I dont even know if my answer is applicable at all], but if the issue where in labview, here is a way to go around without having to recreate an exe everytime.

The exe should be an "intelligent" launcher.

Upon starting up, the initial exe should load all the VIs from a specific folder (lets call it "Upgrade" folder) in memory (if any are presents) then it should load the "regular" (unpatch) code (present in a llb with no diagram for example). Now since LV always check for VIs name in memory first, the new program will be using the VIs from the "Upgrade" Folder. Of course, it is required to plan for this in advance (and also it is required to be able to save the VIs in the appropriate LV version), so it wont be very usefull in your current situation (but may be in the futur...).

hope it help

PJM

Didier

Ni website has a VI to do it (looking through the system registry).

Determining System Fonts and Programmatically Assigning Them to Controls and Indicators.

PJM

Norm,

I think trying to generate a picture decoration will be difficult. It would require programmatically accessing edit>inport picture from file. From there you can use copy and paste from clipboard scripting function. The difficulty reside in getting that picture in the clipboard (as I dont think they are any valid setting of style & object class that can be use with the new VI object primitive).

It is possible to have a VI open the target image file and to display it in a picture indicator, but if you copy this to the clipboard using LV scripting funtion, you do not only copy the image, but all the attributes of the picture control and you end up pasting a picture control in your target VI. One possible way to do it, would be to create a separate exe file (in labview) that will be called from the development environement. That program will open a image file, diaplay it in a picture control then script copy to cipboard then exit. Back in labview you *might* end up with just the image and not the attribute and you can then script the paste to your target control.

This is a convoluted solution that rely on executable, so I am not too excited about it. May be someone will come up with a better idea.

PJM

keiran;

Check this page too: 02-03-2004: Meeting Blog

PJM

Hi Norm,

While I have not tried this, I bet you will need to get reference to the control define in your ctl file (the same way if it was a control alone on a vi). From there you should be able to operate on the FP control elements (cluster, numeric, boolean..) programatically.

PJM

Norm,

LV7.x already has one (it's a locked VI). You can see it when you have a time stamp control with visible time/date browse button.

It is located:

..\LabVIEW 7.x root\resource\dialog\picktime.vi

Cheers

PJM

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

So if i may propose a peer certification program, perhaps LAVA "sponsored" where a review panel could award recognition. It could have different levels (journeyman (1-3 yrs, master (4-6 years), grandmaster (7+ years), etc). Recognition could be based on review of work, review of commitment to the LabVIEW community, time immersed in wiring, or other areas that the review panel could think of. Recognition would be free and based somewhat on the scientific research principal.

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

It is possible by scripting to create the VI reference to match the pane of the caller, programmatically doing step 2. Now how to trigger this script when the code snippet is merged on the diagram? Would it be possible to intercept the merge call?

One far fetch possibility is to add a CIN or CLN in the merged VI code and have the CIN(CLN) initialisation code (when loaded in memory) to execute the script. The script could also get rid of the extra CIN(CLN) node

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