PJM_labview

Pierre, We do have a customer application with similar statistic (6000+ VIs but only around 100+ classes) and the build does take about 15 hours. Like you we have a lot of problems with the build (it is very easy to brake it for no obvious reason and when it take so long to do a rebuild this can very quickly eat weeks of your time). Here is some info that might help you. We notice that adding xcontrol can brake our build (ex: adding the 3dsurface plot xcontrol did that [took us 2 weeks to find that this was the issue]). Make sure your build output is as close as possible to the root folder (ex: C\build) so you wont hit the "path too long" issue that plague windows OS. Build that fail do sometime succeed when we do a control+shit+run arrow (re-compiles everything in memory) and a resave. Build that do fail on "regular" 32-bit OS do sometime succeed on 64-bit OS. Sometime adding more memory to the build machine helps. When none of the above succeed we have to try to figure out what was change since the last successful build. Note: we try very hard to do build very frequently to alleviate these issues. We have several machine (for instance Virtual Machine) where we can try several builds in parallel to speed up the debugging. So my first suggestion would be to let the build go until you get an error as it can take a very long time. Also, if you have not done so, make sure you can try the build on several machines (using VMs [Virtual Machine] is really ideal for this tasks). I feel your pain, and I wish you the best of luck. Please report back here when you found out what was the issue. PJM

Unfortunately I have seen this a lot as well. I think I saw this first around LabVIEW 8.0 (for sure I never saw this in LV 7.1 or earlier). I don't have a fix, but I have a work around that sometimes help get better number. Before your application run, start the "profiler" Click on the snapshot button a couple of time (<- this is the trick that do sometimes help) Start your app Hopefully this will be useful in your situation. PJM

Mark, I dig up my code that do what you described. It is made of 2 VIs, one to do the string update + auto scroll and one that count the number of line. Since you seem to have a good handle on the auto scroll, here is the one that count the number of lines: Hope it help. PJM

Mark, Although I know that I have a utility that do exactly what you described I do not recall exactly how I did it. At lease now you know that it is possible. PJM

If you change the cRIO IP address using MAX, does your cRIO executable code stop working? If this is the case, you might want to consider the following (although at this time this might be too much work for your project). Instead of using "naked" share variable, use the share variable API (Function>>Data Communication>>Share Variable). By using this palette function you are able to use string "path" reference (NI Call this this string the "Share Variable reference In") to address the share variable. This string path reference look like this: ni.var.psp://IP Address/Mod#/IOName. So for instance: For code running in the cRIO, the IP address will be 127.0.0.1. For code running in the laptop the IP address will be the cRIO IP [ex: 192.168.10.125]. Mod# is the module number (ex: Mod2). IOName is the name that you gave that specific IO on that specific module (ex: External Interlock Status) Withe the above parameters: in the cRIO the SV path reference is: ni.var.psp://127.0.0.1/Mod2/External Interlock Status in the laptop this would be: ni.var.psp://192.168.10.125/Mod2/External Interlock Status If you do something like this, you can the store the cRIO share variable configuration string path reference in ini files (possibly one for the cRIO itself and one for the laptop). Now when you change your cRIO IP Address, you just need to change your IP address in your laptop ini file and everything will work fine. I am using this method on a shipping instrument that can have various IP address and this method works great. I Hope that this help. PJM Note: Now, the crazy/cool thing with that approach is depending on what is in your cRIO code, you could potentially run part (or all) of the cRIO code directly into the laptop by replacing the cRIO IP Address from 127.0.0.1 to its "real" one (ex: 192.168.10.15).

Just as a long shot, I see that you are using LabVIEW 2010. If you have enabled Separating Compiled Code from VIs, try to clear your cache (where the compiled code is). This might help (or do nothing). PJM

I am assuming that you don't want to do that (change the IP Address) in MAX. Please note that the IP address is not defined in the executable per say (as far as I recall) but somewhere else on the RT target. If you feel adventurous look at the "Automated LabVIEW Real-Time Deployment (RTAD) Reference Application". This tool does more than just changing the IP Address of an RT device, but if you look at the code I think you will probably find what change is required to change the target IP address (most of the code is not pwd protected). I did use that code to create a simple utility for one of my customer to do just that (change the IP address of the image). On a side note, if you have instruments with an embedded cRIO controller, I will strongly advise considering using the above mentioned tool to avoid future driver set upgrade/downgrade issues when trying to deploy your exe. The above utility take a complete image of the entire cRIO device (OS, driver set, executable [everything]) and allow an image to be created and deploy to target(s). Good luck PJM

Actually, I don't. This is one of my pet peeve about using class in this instance because the class "pkg" become completely incompatible with existing native NI image manipulation VIs. Case in point: the icon editor has some interesting code (it use its own set of classes), Vugie also has a great image manipulation tool (but this is using its own class). Now because of this it is impossible to go a grab one reuse tool from one toolkit to extend another. You have to get all or nothing (or you have to be willing to reconvert all the stuff that you want out of the classes [and this can require substantial amount of work]). I am afraid that I am not following. What is the problem exactly? Is it an issue with the circle having different center? PJM

Mike, Nope I did not forgot anything this time This is essentially the manual alpha blending method I mention earlier. I have some VIs that do something similar (generic alpha blending). My method is somewhat different. I add the alpha data in the image [ ] in the form AlphaRGB and then I have a modified "Draw flatten pixmap (with alpha).vi" that know how to handle the transparency (using the same trick that you have of inspecting the image behind the alpha pixels). I do agree that the picture control is awesome and that everything can be done using it. Now, if NI would ever add hardware acceleration support in rendering image in the 2d picture control, this would make the picture control even more awesome. Cheers.

Ah, I did not notice that the circle was filled with alpha (partially transparent) pixels. This is going to be significantly harder to do. As far as I know, except for "draw grayed out rectangle", you can not have alpha pixel in a picture control. You can simulate this behavior though by: preserving alpha information in your image once loaded into LV (LV tend to strip this). inspect the pixel behind the alpha pixels and blend them with the alpha one yourself. Doing the alpha yourself will works fine, but you will need to invest some time to get it going. Based on all I (now) know of your requirements, I will recommend another approach. Have a set of different sized circle (use png images to have alpha pixel) and load each png image in a pic ring (your alpha pixel will be preserved). You can then select the right size and move the pic ring as needed. This would be the quickest and most efficient approach. What you loose in flexibility (only a few sized circle available) you gain in performance and coding time. PJM

Use another "floating" picture control just to do that "Google map like indicator" and move the transparent floating picture control on top of your other control as needed. PJM

Just use the "set color" tool and "paint" it transparent. About performance, I am pretty positive that if you have no anti-alias that you should not notice any performance issues. Just make sure the you are redrawing only what needs to and only when need to. Additionally, defer panel update could be used if needed. PJM

Like mje says, you can use a transparent picture control and just draw the circles in it. For such simple thing the performance will be fine. Now, if you want to implement the "blur" (aka anti-alias) this will definitively requires a lot of effort (and result in performance penalty but it should still be fast enough). Note: If you thing NI should have the anti-alias native in the picture control, go vote for this idea: Add Antialias support in picture control

Not exactly what you are asking for, but if I understand your description of the configuration, I don't see why you need the DLL in the first place. Just buy one of the various USB to RS232 converter (I personally use Keyspan) then use VISA from LabVIEW to communicate (over RS232) with the DUT. I realize that this is probably not an option at that stage, but I though that I would mention it. PJM

Olivier, I have exactly the same problem in one of my virtual machine with LabVIEW 2009. Have you tried to restart LV with a clean LabVIEW.ini (rename the old one)? Note: I have not tried the above suggestion. PJM

Hey Jack, Welcome to LAVA! PJM

I did not noticed all these new post. "show terminal": you are right there is a situation where it works the reverse that it should. "fast typing": As far as I can recall this issue was always there (before I even made the customization). If there was a bug fix for it by NI, I missed it. "not installing in 2010": I could change that easily but since I do not know what was improved / fixed from 2009 to 2010 by NI, installing this version will not benefit from these potential improvement / fixes. "eraser": I also noticed the need for repeat click. I am not sure if this is something that I did (could be). Was this working in 1.6? PJM

But the built in one only works if you have a project open (it does not when you just have a class or an lvlib {not in an opened project}) [at least this was the case in LV2009]. PJM

Version Affected: This bug affect (at least) LabVIEW 2010 and LabVIEW 2009 (I did not test it on any more version) Platform: Windows (XP and 2007) Description: If you have a tree control with filter event case for "Edit Cell?", "Item Open? and "Item Close?" then clicking the node expand/collapse glyph (the"+" or "-") while editing another column will result with the text entered be applied to the node column (the first column) instead of the column that was being edited. More info: See attached video and attached example VI (treebug.vi). <object id="scPlayer" class="embeddedObject" type="application/x-shockwave-flash" data="http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/jingswfplayer.swf" height="471" width="587"><object id="scPlayer" class="embeddedObject" width="587" height="471" type="application/x-shockwave-flash" data="http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/jingswfplayer.swf" > <param name="movie" value="http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/jingswfplayer.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/FirstFrame.jpg&containerwidth=587&containerheight=471&content=http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/2010-08-05_0849.swf&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/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/" /> </object> treebug.viLabVIEW 2010 <param name="movie" value="http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/jingswfplayer.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="flashVars" value="thumb=http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/FirstFrame.jpg&containerwidth=587&containerheight=471&content=http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/2010-08-05_0849.swf&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/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/"> </object>

This is probably because in the option window you pointed the "plugin development source dir" to the installed plugin location (hence resulting in 2 instance of each plugin). This should point only to your source plugin dir (the one you are working on). This dir (plugin development source dir) is typically different than the installed dir (and should remain empty if you don't have source plugin). PJM

New Version available: Version 1.7: [New Feature] Add a condensed pixel font that allow for longer text to be entered. [bug Fix] Synchronize the "Edit>>Show Terminal" menu with the "Show Terminal" check box. [bug Fix] CAR 186982: "[iE] Wrong Icon is loaded in Icon Editor". Get it here. PJM

Ya, I figured that much. PJM