PJM_labview

QUOTE(mballa @ Oct 19 2007, 06:50 AM) Mark, Try this VI (LV8.5). This does work with and without the ini keys (I just tested it). It is pretty much the same that Ton post, except it does not use event registration. Notes: The VI Activation provide the app instance, so no need to launch it from any place special. To be able to see this event (to create it in the event structure) you have to enable the ini keys. Since (I believe) the Navigation Window is using this event to find out which VI has the focus, it has to work on every machine, regardless of the ini keys. Download File:post-121-1192810815.vi PJM

Did you try logging out and back in? PJM

QUOTE(Jim Kring @ Oct 17 2007, 02:54 PM) <Warning Thread Hijack> So true, and don't even get me started on the hierarchy windows which has become unusable since LV 8.0. Used to be snappy and handy in 7.1, no longer the case... </Warning Thread Hijack> PJM

QUOTE(JDave @ Oct 17 2007, 01:44 PM) David: 1) I hardly ever have controls on my FP that I do not want to connect to the connector pane. 2) Best attempt at connection will do the following (in order of priority): Connect error clusters (if present) to lower left and lower right respectively (regardless of the connector pane pattern). If references are present (like ref in, ref out), connect them on the upper left and upper right respectively. Connect any control/indicator pair having the same name pattern (ex: data in; data out or data in; data dup) at the same level on the connector pane respectively on the left and right side. Connect the remaining controls like they are mimicking the connector pane (see example below). http://lavag.org/old_files/monthly_10_2007/post-121-1192664578.png' target="_blank"> 3) If there are controls/indicators I don't want to connect, I am not sure what the best approach is. Maybe if the controls/indicators are not in the visible window frame, it should not be connected (yes I think I like this). PJM

QUOTE(mballa @ Oct 17 2007, 10:58 AM) Mark, This zip file seem to be missing a bunch of "universal utility" files located in user.lib. http://lavag.org/old_files/monthly_10_2007/post-121-1192650375.png' target="_blank"> PJM

Very nice tool. This is still a little bit too much work and is against my work flow. I think, for my use case, I would like a tool that auto connect to the connector pane, given the relative position of controls. So I would position my control the way I want (no grid), then run the tool (which will attempt to connect doing its best effort, following a few simple rules). It will default to the 4x2x2x4 (4815) connector if no connector selected, else use the existing one. But this is still a very nice utility :thumbup: (I might even use part of it to write my version of it). PJM

Go even further and start from a classic control and you will get system scrollbar. You can then make it look like a system one.

In the same vein, here is another very poor experience I had today with the NI installer builder. I have a project (8.21) that depend only on NI DAQmx 8.6. So in the additional installer I have selected: LV Runtime 8.21 NI DAQmx 8.6 So after swapping cds and DVD for about 40 min (by the way with the Aug 07 device driver, when the installer say "insert Aug 07 cd1" one has to read "insert DVD"...) I end up with the installer builder asking me to insert NI Vision 8.0 CD!!!! I have the vision stuff install on my Laptop, but my project does NOT depend on vision, my customer does not even have vision ... To make a long story short, since I did not have (nor did my customer) the NI vision 8.0 CD, I was not able to build the installer, and I had to install the executable (and NI DAQmx) manually on the target machine. It used to be a lot more straigthforward to create an installer in LV 7.1 and lower; since LV 8.x has been released, the installer builder has - in my opinion - getting way more difficult to use. PJM

This feel so wrong... Note: Original Page

Here is another thread on this topic (on LAVA). PJM

QUOTE(PJM_labview @ Sep 30 2007, 10:43 AM) Just a quick note. It turned out that LabVIEW does just that for file that were created prior to the existence of the grid (I just noticed this on a LV 4.0.2 file). PJM

Here is my perspective/use case for this. I have been using the grid for both BD and FP for years. None of my colleagues or customer ever use the grid, but LabVIEW is not aware of this fact, because by default there is always a grid setting selected (whether the grid is visible or not). When I opened a VI created with this invisible default grid, I have to change the grid to my defined preference every single time (and I have been doing it for years). If the VI is a User Interface I understand your argument of why it could be useful to preserve the FP grid, but honestly I do not do it. I have no problem not messing with the existing controls, and if I have to add some user element I have no problem using the arrow keys and alignment tool. So what about adding a couple of ini settings to LabVIEW: If no grid settings are selected (either on the BD or FP) on a given VI, apply the user defined settings automatically. Always overwrite grid settings with user settings (which is basically what I have to do manually constantly) and let the user deal with the consequences. PJM

QUOTE(Aristos Queue @ Sep 28 2007, 10:37 PM) I have to say that the reasoning behind this does not convince me. So develloper B grid is 13, and he can't snap his new control to be aligned with the existing one, and??? He can still align it manually ( ) or use . In any case, in my opinion, the fact that develloper B wants to work with grid 13 outweight any other considerations.PJM

I am also VERY interested in finding out if this is possible. I looked for such settings a while back but I could not find anything. Since I have to change this settings manually constantly for every VI I worked on that I did not create, having a way to do this programmatically would be very handy. Below is what I want to be able to do programmatically: From: To: Basically I hate to have to do this operation several times a day... PJM

I am not sure I understand your problem. If you put a breakpoint on a template the instance will still brake at the breakpoint location once you run it. PJM

QUOTE(Ben @ Sep 21 2007, 05:38 AM) Ah, I missed this nugget. Anyway, this is such a cool feature that I guess we can talk about more than once PJM

Thanks. I had not realized that the point32 input was an absolute coordinate and not a relative one. PJM

Has anyone ever use the Byte Offset from Point string method? What does it do? How does it work? NI help is quite parse on the topic, and everything I try (in LV 8.21) returns 0 for Byte Offset from Point... Thanks PJM

QUOTE(tcplomp @ Sep 20 2007, 10:34 PM) Thanks. I am not sure what happened to get that "http:\\blog\" in the begginning. This is fixed now.

Hi All, I've written a new article (has been a long time since the last one!), titled: Advanced Numeric Formating Most of you have probably used the Format and Precision tab of a numeric, but how many of you have ever used the advanced editing mode... Read more Cheers, PJM

QUOTE(Gary Rubin @ Sep 20 2007, 11:39 AM) This was on a PXI chassis (1031 DC). The "Brain" was upgraded from a NI PXI 8196 to a NI PXI 8106 (dual core), and I believe they took the memory from the old one and put it on the new one (2Gb Total). Other than these specific CBR recursive VIs, everything else run smoother and faster. PJM

QUOTE(Gary Rubin @ Sep 20 2007, 09:39 AM) While I would not necessary expect improved performance, I certainly would not expect worse one. But this has happened. You are probably correct regarding the code not doing anything in parallel though. This was a bunch of VI doing recursive CBR call. PJM

QUOTE(Gary Rubin @ Sep 19 2007, 05:46 PM) This is not quite that easy. In some instance your code may run faster, in other it may actually run slower. What I have noticed in LabVIEW 8.21 is that when you get a multicore the load end up spread more or less evenly between the two core, but for some reason it is "harder" to reach high processor usage. So in some situation, you may have some code that may use briefly 90% of a single core processor and take about 1s to run and the same code on the multi core will be balanced at about 50% on each core and take 2s to run. With LabVIEW 8.5, if you use timed loop, you can explicitly point (if you want to) at which core the code inside the timed loop run. While this feature is market at RT systems, it appear to works just fine on window. I which NI had gone one step further though and did the same thing for while loop and for loop. It would be very nice if I could right click on a while loop and select "run on core1" for example. Fortunately, it seem that you can trick LabVIEW in doing so by wrapping the code you want to run on a specific core inside a time loop (not very elegant at all, but the test I run seem to indicate this work fine). In conclusion, when you migrate some code from a single core to a multi core, it *may* run faster from the get go, but this is not an absolute certainty. PJM

I believe this is a bug. In previous LabVIEW version, the property "FP.IsFrontMost" was working regardless of the windows state. Now in LabVIEW 8.5, if the window is set to floating, this property is no longer working. Anybody has any idea for a workaround (short of not using the floating state of course)? PJM

Here is my rule of thumb: Whoever open the reference shoud be in charge of closing it. Here is some of the rational behind this: One of the main reason to proceed like this is to improve code clarity. Another reason is to prevent bug. If you close the ref deeper in the hierarchy you might be tempting to branch the source wire upper in the caller to realize later the reference is no longer valid. Therefore, in your example the caller of the SubVI should be in charge of closing it. Just my 2c. PJM