Mellroth

...you could also just load it into memory by including it in a case structure where it will not be called. Put it e.g. in a true-case and wire a boolean control set to false to the case selector...

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.

...The ring has many items (65536) and non-sequential values...

...labview needs about 10 seconds to build it. Why is that?...

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

Nope. Those don't return errors. :-)

Ouch...

/J

...That's the only one....

Except bugs in the Close function code ;-)

/J

This is the specific error I keep repeatedly getting, but only when trying to read a channel of the NI 9237. Sometimes it stopps immediately, other times it chugs along nicely for a few readings first.

Error -200284 occurred at Inputs_Read_All.vi

Possible reason(s):

Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.

Property: RelativeTo

Corresponding Value: Current Read Position

Property: Offset

Corresponding Value: 0

Task Name: _unnamedTask<A89>

I can get it to run quite a bit longer by daisy chaining two 5-meter USB 2.0 extender cables end-to-end (routed under the door) but then, after enough time, the cDAQ itself momentarily fails to be detected and I get a "device not there" error. So that's no fix either. Alas and alack.

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

Totally agree with 1 and 2, what do you mean by 3 though?

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

... I just multiplied my acquisition duration by a constant to get the right output duration...

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

..Actually I meant the for loop that deals with adding the period ".". Can we just link the "previous character" shift register directly to this loop instead of using bolean to determine this....

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

I have now just placed it together as the final solution. The attached is in LV 2011.

Mellroth: The second FOR loop that deals with either 46 or 106, is boolean initiated, is there a reason for it or would it be the same if we just wire the 46 shift register directly to the FOR loop instead of checking if 46 is equal to the previous run.

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

...But you know what? We can do better....

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

Since the XControl is only being used in my application and in one spot I was able to fudge a little and use the following code. Note the plus 10 which I think is due to splitters or panes not being at origin. I think NI also has a similar issue with their tip strips that has been documented. If you hover over control that is in a paned window that is in a subpanel you will see it. The location of the tip strip can vary and to get it in the correct place you have to scroll the pane. Maybe this is fixed in 2012, but haven't switched from 2011SP1 yet so I'm unsure. Anyway here is the code that seemed to work good enough for me to get by.

Nice!

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

/J

Thanks for drawing my attention to the WireFlow ProgrssBar I have not come across this before, it looks quite interesting and something I think I should find time to play with.

Please can you post a link here when you have the demonstration clips on-line.

cheers

Dannyt

You can find the WireFlow YouTube channel at

http://www.youtube.c...ture=CAQQwRs%3D

/J

...

The equivalent LabVIEW string would be

%<%m/%d/%Y %I:%M:%S %p>T

...

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

/J

Very slick, surprised you have no comments on it in the last 6 years. I personally use the WireFlow Progress, available through VIPM. I wrap it in a functional global, so it is easier to use, and has my more commonly used functions exposed. I then wrap that into three sub VIs, Create, Update, and Close that behave as expected with only the needed terminals showing.

It does have a delay before being shown as well so it isn't seen for quick loading. It also has the ability to cancel, which I think is nice, especially because I can just turn on termination for my for loop, and wire the cancel into that.

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

I am attaching a printscreen of the node in question.

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

Crelf: Are you saying the LabVIEW.ini file reverts after you make changes and save it?

Eric: Yes it's true.

Ned: Just to confirm, you're not trying to edit the LabVIEW.ini file while LabVIEW is running, right?

Eric: No i stop Labview and modify labview ini and restart Labview.no effect if i creat new vi. Stop labview and look labview ini and then see conepane go back to old value.

Just another details: i have samethings on LV2009 SP1 and LV2011 under Windowx XP sp3..

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

...

I created references cluster (strict type def) to make things easier. Find attached a zip file. Uncompress all files to one single folder and run Initialization VI.vi file. An error message (1001 - Front Panel is not open) will pop up and Main VI.vi don't open, as it was to supposed to.

...

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

...I also want the load to take as little time as possible...

OK

/J

I appreciate the suggestion but that is not a solution. The help has this to say:

Hide loading dialog box—Prevents LabVIEW from displaying the loading dialog box when searching for missing subVIs of the referenced VI.

Note This option flag does not affect whether LabVIEW prompts you to find the missing VIs or not

So it sounds like if you use 0x20 LabVIEW will not show the loading dialog, but will still be searching for the missing VIs. I want to perform an Ignore All, meaning just skip missing VIs.

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

I guess a fairly simple question but for and my customer important issue.

What determines which control that are visited next when a user use tab to move to next control?

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

Old topic I know, but I tried using this VI in LabVIEW 2011 and it no longer works (at least for me it doesn't). Is there an update that will work?

I realize this VI was developed before the "Ignore All" button existed in the loading window, but I'm looking to open a reference to a VI programatically. Is there a way to open a reference to a VI on disk, and have it perform the same function as if I pressed Ignore All? Thanks.

How about using Open VI Reference with option 0x20?

/J