PJM_labview

The "Not A Number/Path/Refnum" primitive does not work on TDMS file refnum. The help says: "Note VI. For semaphore refnums, use the This function only works on references generated by LabVIEW functions. Do not use this function to determine the validity of a rendezvous refnum, semaphore refnum, or any refnum created by the GOOP wizard, LabVIEW Database Connectivity Toolkit, or the LabVIEW Internet Developers Toolkit. For rendezvous refnums, use the Not A Rendezvous VI. For semaphore refnums, use the Not A Semaphore VI. For all other GOOP refnums or toolkit refnums, use the VIs defined by the refnum creator." Therefore, since the TDMS file "appears" to be primitive functions (not listed in the exceptions), I am expecting the primitive function "Not A Number/Path/Refnum" to work on TDMS references. See example below. Download File:post-121-1171317741.vi PJM

The LAVA forums are definitively faster. Thanks Michael :thumbup:

Actually, activating on the left click instead of the right is fairly easy. If you use the "mouse down?" filtering event you can dynamically tell LV which button has been clicked (see image below). So far, the trick for dynamically firing the menu activation event would be to be able to dynamically fire the "mouse down?" event. If we could do that, the other part is easy. PJM

Oh well, I was afraid of that. Thanks for the quick answer. PJM

I was about to report this as a bug until I read the following addendum to the obtain queue primitive. "Note If you obtain a queue reference in one application instance, you cannot use that queue reference in another application instance. If you attempt to use a queue reference in another application instance, LabVIEW returns error 1491." The problem I was experiencing appears to be tied to this help addendum (I am not entirely sure). In my application, I had a process running in one app instance (basically the NI.LV.Dialog) which was communicating with another one running in whichever app instance the user is currently developing his code. I was using named queue. Suddenly the code stopped working in LV 8.2 (everything was working just fine in 8.0), and in my case there was no error 1491 since I was not attempting to reuse the same refnum but to create a new one referring the same named queue. I think that this new "feature" (bug?) is really unfortunate. PJM Note: The Notifiers seam to also be affected by the same issue.

Thanks, this will come in handy. Thanks jimi PJM

Fortunately, NI was nice enough to leave all the alpha infomation in the image data coming out of the read PNG, so it is possible to write your own draw flatten pixmap which can handle this. The end result is that it is possible to simulate alpha blending in a picture control (see attached screenshot). Note: This will only allow to do alpha blending within the picture control. This does not provide alpha blending from the picture control with other objects on the front panel. PJM

Ton I think that it does happen for all data type. I certainly have seen it happening a LOT since LV 8.0, but it is possible that this might be happening only for typedef or strict type def... Cool! I knew that the Package Builder was having issue above 8.0, but I never spend the time to investigate what was the issue. Now that we know what the bug is this should be easy to fix. Good catch. PJM

As seen in the attached example, sometimes (unfortunately quite often) the coercion to variant is no longer working properly. The nameless type always coerce well, but the named type (data has name) do not. The data name is lost most of the time or, as seen below, another data name instance is substituted ... If you play with the attached VI, you will see the name changing from empty to correct to incorrect under no specific circumstances that I can reproduce (although in this case the fact the it use the other typedef instance name seam to give some indication of the direction to dig for NI people). Download File:post-121-1169710597.llb This bug has been present since LabVIEW 8.0. The only work around that I know of is basicaly to never coerce to variant but instead use "To Variant" primitive ( ) on all the wire that will be passed to a variant input.PJM

Justin, I think you can use the attached VI to get access to the LV 8-bit color map. I think the colors are the same than the one used in VI icons, although I might be wrong. Download File:post-121-1169663044.vi PJM

A long shot: Try to delete your LabVIEW.ini This *might* help. PJM

I like this idea :thumbup: PJM

Gerry, Attached are some drivers for the MKS 647C. They are coming form this location. Download File:post-121-1169185646.zip Good Luck. PJM Note: Please, be more careful in the future about where you are posting your requests. This thread has a lot more to do about certification than hardware driver

I would argue that this is a bug. I have come to expect the behavior that Michael mentioned (fit as you drag) in LV 8.0x. If this this not a bug, then where was it documented that this was changed? I don't remember reading anything about it in the upgrades notes. If there are 2 possible behaviors, then I would expect to be able to access both programatically. In my opinion, resizing the windows content after you have finished resizing the Panel is the wrong behavior. I can not, on the top of my head, think on any applications that follow this behavior in windows. PJM

I guess somebody found a new way of throwing money out of the window... PJM

btw, Brian, using a template does indeed seem to be significantly faster. Good idea. PJM

I did check before I post. I notice a significant slowdown (not in the 100 magnitude, but in the 10 magnitude). Here are screenshot of the before and after runned in LV 8.01. Before After The after is about 10 time slower. I dont know for sure that this is the same issue, but it look very similar. Also, recently I seem to have experience the slowdown (in LV 8.01) with VI that do not appear to operate on references (I have not yet characterize this for sure Edit: such as the OpenG "List Directory Recursive__ogtk.vi"). I have not figured out the trigger mechanism (the one you describe for the reference in for loop or while loop, do not trigger it). PJM

Jimi, This is great news! :thumbup: Now that there is a fool proof way of reproducing this, it should be fairly easy for NI to fix this. PJM

I think this might be due to the fact that member of lvlib are marked (a feature I really dislike). When you are dynamicaly generating the properties VIs, they are probably not marked and therefore the lvlib does not know it belong to itself. Just my guess. PJM

Adam, Thanks for your post. The information you provide are very interesting for some applications. I can already see a couple of system I am working on that could benefit from this thread balancing setting change. Unfortunately, in the case of applications where one does not have access to the end user computer or when the computer changes, asking the end user to go through all these loops so it can run a piece of software (just becasue it is written using LV) is not a realistic option. This need to be fixed. Thanks PJM

I am pretty convinced that this issue is not linked to the run continuously button. I used the run countinously button to characterize and benchmark the problem, but in regular applications (not running continuously), the problem is still there. So far I have isolated the problem on VI operating on LV object reference in a for loop or a while loop. I am not 100% positive, but I don't remember that minimizing and maximizing does improve the performance at all. Next time I am in that situation, I will try to see if this has any impact. I have also noticed this (since LV 8.x) but I think this is another issue (more like an editor issue). I dont like this, but I can leave with this since it does not affect my buid app. The other issue I mentioned affect build app as well as app running in the IDE. For example we had report from some user of VIPM that sometime it start/run very slow (I have also experience this as well). This, I definitively linked it to the same issue. Typically, I hardly ever change thread of my VI, and when I do so, I don't put anything in the UI thread (since there are already so much stuff running in there). The top level caller of the first particular VI I used to characterize the pb (Get all FP Controls) is a UI running in the UI thread and since I left the default thread setting to same as caller, I *think* this VI was running in the UI thread. But, next time I experience the slow down, I will try changing the threading explicitly. Jimi, Here you go, but please note, this issue happens in many VIs (like the second one in my initial post that I wrote on the spot to characterize the problem). Download File:post-121-1166801608.vi I never experienced anything even remotely comparable to this slowdown in LV 7.1.1 (of course it does not mean that it is not there). PJM

See this post on the LV 8.20 bug list. PJM

I have been experiencing this bug since LabVIEW 8.0. I have not report it until now because it is VERY hard to reproduce. Nevertheless I have characterized it. Note: I (and other coworkers) have encountered this bug on several machines running XP and LV 8.x or 8.20. This bug is present both in dev mode and in runtime mode. Background: In some instances, some LV code suddenly slow down so much that in most case it gave the impression that the LV prog has hanged. Typically this seem to happen once or twice a week (I am using LabVIEW everyday) and only on some VIs. Clicking, and shaking the hanged program title bar "unstuck" the prog temporary. Restarting LV (or if in runtime environement, your program) fix the problem until the next time. Characterization: In one of these instance when the bug occurred, I spend several hours characterizing the issues. I have first characterized this by comparing run time of a particular VI both in LV 7.1 and LV 8.0. Note: 1) The slow down was happening on two VIs, one with a for loop another with a while loop. I just picked the one with the while loop to compute the stats. 2) The VI was run both on LV 7.1 and LV 8.01 for the same test set. 3) The VI was running continuously when the screenshot were taken. Below are screenshot and benchmark data of that particular VI. This is on LabVIEW 7.1. Total run time (for 91 iterations) is about 10 ms with an average per iteration of about 0.11 ms (processor usage is 50%). This is on LabVIEW 8.0.1. Total run time (for 91 iterations) is about 1616 ms with an average iteration of about 17.8 ms (actually the value are all over the place, from 12 ms to 25 ms). Processor usage in this case is very low (about 4%, in the noise level of idle) Please Note: 1616/10=161. This VI is running 161 time slower on LV 8.0.1. This first experiment let me to believe than this might be some optimization that went very bad and that it seem to happen only on VI manipulating LV Object References. Further Investigation: In another instance when my LV got in that slowdown state, I further narrowed the issue to the following: This particular slowdown appears to happend only when operating on LV Object Reference in a For Loop or in a While Loop. Below is a screenshot of the VI BD I used in both LV 7.1 and 8.0.1 to get to this conclusion. Once the statistical code is exclude, this VI is very simple. It just open a reference to itself, get all the Object Reference on its panel, then close the array of reference in a for loop (this last operation is benchmarked). Then for comparison sake, another identical for loop (doing pretty much nothing) is run for the same number of iterations and benchmarked. This VI was run both on LV 7.1 and on LV 8.0.1 (when in the "slow down state"). Below are screenshots of the results. The Left side statistical data of the Panel is about the for loop that is indexing the array of Object reference. The right side statistical data of the panel is about the No Op for loop. On each side, the first plot is the delta t of the for loop run time and the second does average the delta t over each iteration of the continous run. This is the VI running on LV 7.1: This is fast. Typically the indexing loop run in less that 0.2 ms This is the VI running on LV 8.0.1: This is very slow. Typically the indexing loop run in more than 44 ms Note: 44/0.2=220 This VI is running 240 time slower on LV 8.0.1. Note: The No Op loop does also appear to be slower on LV 8.0.1 but the value are so low, I am not sure this is significant enough. In any case, this is a very serious issue that I hope will be fixed. PJM

Jimi, This is a nice trick (I can't believe there is no easier way to do this!). However, the attached VI appears to be non functional when the mouse up event does not appen on the header (ie, when you finish resizing inside the MCListbox but not over the header). Also, for performance sake, I would set the image depth of the get image method to 1 (Black and White). PJM

Here is the windows direct link and the mac direct link.PJM