PJM_labview

That's one hell of a SCARY desktop picture that you got ! I can't imagine staring at this all day... PJM

The official reason is that it is not yet ready (buggy ?) for release on LV7.x [other than PDA] (there was a thread about this a while back on info labview). Regarding how to make it accessible in your palette, this is quite easy. Customize your palette, add the VI with the comment structure then make sure to set merge VI (RMB). PJM

Didier I did notice this well. As far as I know there is no way around it (except define one button per size .... ). These ptc file don't seem to have any known header. PJM

NI "patched" all these exposed properties in labview 7.1 installation. So you can re install labview 7.0... or download the attached file (original LV 7.0 NI MAX\Assistants\LVCGen\ folder). Download File:post-121-1095545070.zip

Ok I think I got it The way I understand it, it does the following: In any "case", whether the control boolean is true or false, an array is build and wired to the shift register. So, initially, my guess is that the boolean control is set to true, and the array is build independantly form the subvi. Also my other guess is that once the boolean control become set to false, it will be reset to true quickly after. Then when the boolean control is false and if previous value from the shift register is not equal to the one generated when the boolean control was true, then call the subvi with 2048 as input then again (and here lies another problem) if the boolean control is still false collect all the values from the subvi and display then to the following locals (Barrier A, Barrier B, Dipper, Spare A, Spare B and Relay) then rebuild the array with this value and wire it to the shift register. This seem indeed to be legit code... It a nightmare to understand that what's wrong with it! PJM Note: Now that I am re reading this, I am not so sure that I understand what's going on ...

Well, the file work fine for me (and is in LV7.0). I just redownload it from the forum. Just in case I attached a 6.1 version (should not make any difference but who know). I any case, you have the screenshot to get you going PJM Download File:post-121-1094771598.vi

Odd, there no call to anything in that file (only labview primitive). What version are you running ? Meanwhile here is a screenshot of the block diagram. PJM

Hi Michael Use the "system exe.vi" in the communnication palette. PJM

Hi It is indeed possible to build express VI without NI toolkit. Check this post: http://forums.lavausergroup.org/index.php?showtopic=376 Read especially post #5 and #6 by Jim Kring. Also NI has a doc explaining some stuff about how express VI work. I will try to dig it up again if you need it. If you need more help, let me know. PJM

Check the attached example (LV7.0) PJM Download File:post-121-1094694806.vi

Right Click on the Knob Select Visible Items > Digital Display and make sure digital display is unchecked. PJM

Jean Pierre, Lately I was playing around with the OpenGoop Framework and I realised it would be usefull if we could dynamically update Strictly type VI ref num in each class (being able to keep typedef is important in this case). Attached is a llb that does that. Also, check out the following VI "Variant to Flatten String {preserve typedef}.vi", I think it could be used as a possible replacement/enhancement to the native Variant to Flatten String primitive. Cheer Philippe Download File:post-121-1093814922.vi Download File:post-121-1093814962.llb

Ah, I did not know that LV6.1 Variant to Flattened String was returning invalid type desciptor with typedef information. I did not realized until quite recently that Variant to Flattened String was not working (read was automatically stripping typedef) with typedef in LV 7.x. I think I figure out a way to get the typedef in the type descriptor using flatten to string with expose type def turned on and doing some stripping and "padding". This is not documented anywhere as far as I know, but it seem to work well in LV7x (a quick test under 6.1 seem OK). See attached VI. Also, I noticed that the only way to get typedef info from controls on VIs is to used Get All Control Values {variant} methods. Every other way return type descriptors with no typedef info. PJM Download File:post-121-1093760011.vi

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: You will be able to access conpane references and its exposed properties and methods Good Luck PJM

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