Mellroth

In recent LabVIEW versions I usually recommend using Static VI references instead. /J

Like Neil and asbo already explained, it was the usability of a 65000 element Ring control that bothered me the most. I really thought you just used the ring control to have an easy lookup between non sequential values. Some ideas if you still want the user to go through all these key presses; * Put your sting-value pairs in an array of clusters, and keep track of the current index. When user presses the Up/Down Keys, move index accordingly and update UI * create an xControl and store the string-values array within the xControl data If possible, I really think you should post an example showing how this should work. Question; do you want to be able to find a specific value given a string, or do you want to get the string that is associated with a given value. /J PS. The thread I believe asbo is relating to is this; http://lavag.org/top...8757#entry98757 This deals with preventing roll-over from min to max or vice versa.

I think you really should consider another approach; the Ring control is a UI element, and is not intended for data storage. Without knowing the exact layout of your system, I would recommend that you use a LV2 global or something similar to hold your values instead. /J

Ouch... /J

Except bugs in the Close function code ;-) /J

We had a similar issue with the ethernet based cDAQ chassies NI-9188. In that case the solution was to define a higher sample rate than we actually needed, just to fill the transmit buffer on the cDAQ side, then decimate the samples on the receiving end. When we asked NI about this, the response was that it probably had something to do with the new DAQ Streaming engine. /J

I should probably have said Proxies (or at least that is how I see them), so that the code I'm developing doesn't need to know where the actual code is situated. I good example is when you call into folders that are not called by symbolic paths in LabVIEW. By putting a proxy caller under a symbolic path your code can call this code safely from any location, and if the proxy uses relative paths to the actual code it can be moved between platforms/computers/LabVIEW versions. /J

I don't get it, why do you call LabVIEW add-on VIs dynamically These VIs should/could be directly called on the Block Diagram; giving you higher performance, and less complicated code. For me, the main reasons to call VIs dynamically is either 1. to spawn parallel processes 2. to dynamically load plug-ins 3. to break the hard link to a specific set of VIs at edit time /J

Just info for the thread; if you want X samples you'll actually get X mod (4) * 3 samples out, or roughly 0.75X So the input should approximately be set to X * 4 /3 to get close to X samples out. I've seen this type of bug in another application a long time ago, and then it was due to the conversion from a 24bit stream to a 32bit stream. /J

Late Friday night and almost in sleep mode... AQ said that to really reach out to all customers we really need to give our code to NI, but since LV 2011 we have the LabVIEW Tools Network built in to LabVIEW and this enables each and every user to easily install features they need (from OpenG, LAVA or LVTN). LVTN has no restrictions for licensing that I know of, but NI still reviews and put code under the NI umbrella and even publish some code of their own. I currently know nothing about JSON, but from reading through the threads here at LAVA it is probably something I will look into in the future. And when I do, I like to be able to select the implementation that I want to use; NI version, LAVA version or any other version. Installing these from LVTN/VIPM mean that new features/versions are available to me directly and I don't have to wait until the next LabVIEW release. Bugs detected in LVTN modules are also likely to be fixed much faster since the fix can be released regardless of the LabVIEW release cycle. /J

OK, I guess you mean the Case structure, not the for loop? In that case; yes you could use the numeric as the selector, but in my experience you actually gain performance by using booleans instead of numerics in case structures. /J

The boolean keeps track of the LF/CR characters because the original code removed one of two starting '.' characters. Only checking for equal 46 would remove all occurrences of double '.', not only at the start of a new line. /J

And you can do even better still... Since the decoding is about removing escape characters, it is possible to reuse the input buffer and have a single FOR loop to do the decoding. The separate search for new lines is unnecessary since we can deal with these characters on the fly. Attached is a VI that I tested on the "NOT WORKING.rar". The original code (except header and footer removal) takes about 650ms and the buffer reuse version takes about 4ms. yEnc Decoder.vi It also think it is possible to speed up the footer search by performing the search backwards. To do this replace the footer search string "=yend " by "=yend .*$". /J

Nice! Personally I would get rid of that bundle/unbundle of Horizontal/Vertical coordinates, as it only adds confusion. /J

You can find the WireFlow YouTube channel at http://www.youtube.c...ture=CAQQwRs%3D /J

I'm very disappointed you didn't say "%^<%Y-%m-%dT%H:%M:%S%3uZ>T" /J

I was just adding a some links to YouTube clips demonstrating the usage of the WireFlow ProgressBar module and now I see it beeing referenced ;-) As hooovahh mentioned the module allows any application to get ProgressBar functionality with optional delay and cancel button. It is also pretty easy to create your own customized ProgressBar window. hooovahh: would you like to see the functional global approach added to the palettes? (just send me a PM if you have other requests) /J

We have added a number of YouTube clips to demonstrate the basic usage of the AppBuildSupport as well as the ProgressBar module /J

In a previous project we had a similar issue, but with a Ethernet chassie (NI-9188). The reason for the "hang", or rather a very long detection time, was that a previously used 9188 device (existing in MAX) was unplugged from the system. We solved it (I think) by refreshing the MAX configuration. /J

I believe I had the same issue on LabVIEW 2011. My solution was remove the defaultConPane key from the ini file and start LabVIEW. Stop LabVIEW re-add the ini file token /J

The reason you get this error is that you cannot register for FP events for controls on a VI that is not in memory. And, you cannot keep the front panels opened since you want to show hide the VIs in the SubPanel control. Event if you try to register for control events while the FP is in memory, the event registration goes invalid when the FP is closed. My best bet, even though I haven't tried it, is to use UserEvents instead. Or if you want to play safe, use Notifiers or Queues to do the signalling. /J

OK /J

Maybe I misunderstood what you were trying to do. I thought you liked to be able to silently load a VI even if it was broken? Option 0x20 really allows you to do this; unless you also set option 0x10, the VI will silently be loaded into memory. /J

You can specify the tabbing order from the Edit menu -> Set Tabbing Order..., at least in LabVIEW 2011. I think I recall that this was named something like "Set Frontpanel order" in earlier LabVIEW versions, but I cannot check right now. /J

How about using Open VI Reference with option 0x20? /J