ShaunR

@ JG

Why have you slowed it down? (those arrays were inside the for loops for a reason )

@JK.

You are right. The original Trim Whitespace+.vi (thanks for pointing out the two chars I missed JG-are they considered whitespace?) was a direct replacement for the built in Trim [whitespace] function. However. the Fast Trim was more useful on comms strings (especially serial) where you can have all sorts of non-printable chars and not just "whitespace".

Why is everyone's avatar all messed up? Is it just my eyes after writing LabVIEW all day?

JG always looks like that

I am stuck on how to be able to generate new tab pages on the fly. In the meantime I will just have some number of blank subpanels within parent tab pages.

Use the system tab rather than the Labview one. It has the method to create them on-the-fly (if I remeber correctly).

Try unchecking "Remove Polymorphic Instances" and verify that you have no broken VIs in disabled structures.

This is a real pain and gives no indication whatsoever where to look.

You get it after building an application exe that works fine in the IDE and usually find that a diagram disable structure somewhere isn't doing what it says on the tin.

Making optical fibres listen.

Hey Shaun

I have an API for interacting with the project, I do similar things with builds for exes and installers so I thought I'd give PPL a go and see if it works.

I was able to get it to go however, I don't use the AppBuilder_API (I have never really), instead I use PN's and set the XML tags.

You should be able to replicate from this quick video:

That's sweet. I'm not a great fan of the app builder API either. At what point does the build.vi get executed? Is it run whenever you create a new project? (wasn't clear from the video which I had to scroll around to see...lol)

MANY users wanted "stability" over "new features" and IMO that is what they got in 2011

My point is that you shouldn't have to pay for stability and upgrading to a new version is not a bug fix, it is a project risk.

I love how both the graph in this article and the one presented at NI Week have no Y-Axis labels. Also love the bar graph during the Tuesday keynote that was only upwards trending. No title or labels. Don't get me wrong, a lot of the features seem cool. It's just hard to buy into a better bug reporter as a key feature...

Paying for bug fixes by being forced to upgrade has always been my major criticism of NI (what about my 2010 and 2009 installations?). I would also question if many of the speed improvements are really much faster than 2009. 2010, yes. That was a slug. But compared to 2009? Maybe in some circumstances (FPGA?), but I haven't seen many yet. Personally, now I have had a chance to play with it, I don't think there is much in it from a user experience point of view. From an execution view point, I have seen 1 instance where 2011 x32 was faster and 2011 x64 was slower than 2009 and all the rest about the same for identical code. I have already commented previously that 2010 was about 3x slower at compiling, loading and saving than 2009 so when the "selling" point is speed and stability. Is it worth paying thousands for a more stable 2009? (Well. It is since, the bugs in 2009 won't get fixed )

If you ask me (I know your not...but I'll pretend anyway ). One of the biggest improvements that I would have paid a ton of gold for (in recent history) was never a major selling point.- 32 AND 64 bit compilers. Although I can still find something to moan about with those too

Adam Curtis

Improved Stability

I would be very interested to see a similar graph for CARs raised by customers for the different versions.

We thought about trying a dll, but none of the C programmers here are experienced with that sort of thing (they are all UNIX programmers and are having enough issues trying to deal in the Windows world) so we dropped it. We're going to write files to a ram drive. It's low enough datarate, plus the fact that all the data is available once a second and not spread out, makes that a pretty good option. Hopefully. :-)

My next move is to kick this to NI, I guess. It's such a narrow issue -- I doubt many folks are doing loopback TCP in LabVIEW on a regular basis -- but my concern is that there's some underlying issue with LV that may affect other TCP functions.

Well. If they have difficulty with DLLs (SOs on linux) then kernel level drivers will slay them. The randrive.sys driver is no longer available in windows 7 (hope they weren't thinking of using it ) but there are a few 3rd party solutions I think.

One final thought. Turn off the nagle algo. It is known to play hell with things like games and it is known to silently introduce delays in packet sending through the loopback. It is off for my setups for this very reason, although I never saw 2 second delays.

And then there's always the fact that this works fine in C without having to change any settings...

Windows 7 x64 with LV 2009 x64.

Indeed. My problem was just sheer throughput and it didn't matter what it was written in.

I know it's curing the symptom rather than the problem (and it will be blocking), but have you tried getting the C read and write stuff compiled into a DLL and using that instead? Just a thought to see if the specific problem goes away.

What do NI say about it (after all it is repeatable by a number of people)?

I hope this doesn't just get appended to my last post. That happens a lot on this site. I must have something set wrong somewhere. Anyway...

Test results:

Windows --- LV --- Result (passed = ran for over 4 hours without failing)

XP --- 8.6.1f1 --- PASS

XP --- 10SP1 --- PASS

7 ------10SP1 --- FAIL

7 ------ 11 -------- FAIL

7------ 8.6.1f1 --- FAIL

Anyone else see a trend here?

FWIW, all Windows 7 boxes have been 64-bit.

I'm going to run the write and read on 2 separate Windows 7 computers for a Long Time again, since I probably never ran much longer than a couple hours before stopping with no error. For completeness sake, I should do a 4 hour test. Because if *that* fails, there's a really big problem somewhere.

Thanks again for all the help/suggestions and especially thanks to those of you who were running tests for me!

I have v1.0 of Desktop Execution Trace Toolkit. This should actually be a small enough program for it not to choke. I can try it even tho it doesn't say it works on Win7.

Network analyzers aren't a lot of help since the data never actually leaves the machine.

No questions are dumb!

Hmm. Yes. A bit of a trend apart from LV2010. And it may be why I cannot see any problems on my machines (none of the examples fall over after running for 29 hrs now ). My windows TCPIP is highly modified from a standard install. It was the only way i could "reliably" get TCPIP transfer rates of up to 80 MB/sec. (Not in loop back; across the network). The sorts of things that were changed were the TCPIP auto-tuning, and Chimney Offload. Also had to play with the TCPIP Optimiser, but can't remember exactly what now. This was in addition to the TX buffers. But i wouldn't have thought 25MB/sec would/should be that much of a problem, but I guess it is windows eh?

Wow. So maybe it's a Win7/LV10 problem...

I'm installing LV11 on my Win7 homebox as I type. I'll try it on that.

BTW, I ran both sides on my XP/LV8.6 machine this afternoon for over an hour with no problem. I'll try a longer test tomorrow.

I really appreciate you running these LV/OS combo tests.

I know it's one of those silly questions (especially since the C program would suffer from it too). But has to be asked.....

Are you sure the power saving is turned off on the network card(s)

Hmmm......

I knew LV2011 would be the answer to all my problems!!

Wait for SP1

Every once in a long while I'm presented with a problem I just can't figure out. It's been quite some time; I guess I'm overdue. I've run so many different tests I'm seeing them in my sleep, but here's the summary of tearing my hair out for the past two weeks:

The basic problem is to write 5MBytes of data from one program to another, on the same computer, every second, via TCP. In its original configuration, this data is literally 5MB all in one TCP write every second, not paced out. It uses payload size to determine the end of the data.

If the two programs are written in C, it works. I was incorrect in my orignal statement that if both programs are in LabVIEW it also works. It doesn't, or rather I haven't been able to figure out how to make it work. It does work if both LV programs are on different computers, but not if they are on the same computer. And if the LV is doing the write, the C read works fine. So the issue seems to be the LV read, on the same computer with any type write. The two programs connect and are sending/receiving the data for several minutes (2-50). Then both sides stop with various errors. With both sides in LV, most often, the read errors out with a timeout (56), and the write errors out saying the system caused a network disconnect (62).

Here are some things I've tried that made little or no difference:

running the LV programs together on a different computer

Intermediate mode read (thanks for the suggestion, Rolf)

breaking the 5MB write up into 10 500KB writes and 100 50kB writes

breaking the 5MB write up into 10 500KB writes and pacing them out over 750ms

reading the 5MB all at once

breaking the read up into 500kB and 50kB passes

Shaun, your suggestion to play with the TCP buffer sizes helped in that instead of failing in a few minutes, it would go for several minutes. Oh, and controlling buffer size on a Windows 7 machine is a PITA. Check out this article if you're doing it on a Win7 platform. I tried every buffer size possible, but it never really helped much more. I even posted to serverfault.com with the problem, and also many other questions about Win7 TCP buffers that no one seems to understand, and have gotten a deafening silence in response.

At this point, I'm going with Plan B. I've configured a ramdisk on the computer and we're just going to write/read files. In retrospect, this may actually be a better solution, but dang it, I want to know why the TCP way isn't working.

I'm attaching a couple of very simple vis to demonstrate the problem. Just run them on the same machine, with that machine's IP address (it's an input instead of default for testing on 2 different machines). Written with LV 2010 SP1 64-bit on Windows 7. About all I haven't been able to try is a different combo of LV version/OS. The longest these test vis have ever run has been 50 minutes, and that was much longer than the norm. If anyone has a chance to run these vis, please let me know how it goes.

Thanks,

Cat

Try it this way....

New crash reporter

But it definitely feels more responsive than 2010.

I guess it won't help then.

Rolfs got a point, but immediate really puts a burden on the CPU since you've got to (wo)man handle characters as they arrive. Then concatenate and terminate the loop on whatever it's supposed to terminate on (number of bytes or term char).

This is the sort of thing:

As you can probably see from the snippet. there is a (small) possibility that the first 4 bytes are garbage or maybe you read 1/2 way through a string and therefore expect a huge number.

So are you using character terminated or pretending a payload size? You haven't said much of the inner workings. Example perhaps?

Each of the data streams is ~ 8 M/B, so worst case thruput is 24MB/s (counting P2 --> P3 twice). I've been staring at Resource Monitor a lot. The network (1Gb) is loping, the CPUs are loping.

Thanks for the vi. Any chance you've got a "Get Buffer" vi? I'd like to know what the buffers are set at before I start playing around with them. I tried to reverse-engineer the wsock32.dll call in "Set Buffer" but can't really test it here on my home box.

Well, that's not a huge amount. Even the default LV examples should be able to cope with that.

The default windows buffer is 8192 (if I remember correctly-don't have the getsockettoption....maybe later in the week). There are a few ways of calculating the optimum size dependent on the network characteristics, but I usually just set it to 65356 (64K) unless it's a particularly slow network (like dial up). It really makes a difference with UDP rather than TCP (datagram size errors). Note, however, that it only makes a difference if you are setting the "Listener" connection. It has no effect on "Open".

It''s strange that the C program doesn't exhibit the same problem. If you are doing the usual write size, write data then you can try and combine it into one write operation (just concatenate the strings) but I haven't run into a problem with the former. If you have the C code then you can take a peek to see if they are doing anything fancy with the sockets....but I doubt it.

Are you trying to send and receive on the same port? (Cmd-Resp) or do you have two separate channels; one for sending and one for receiving. If the latter. What part disconnects? The receipt of the data or the send of the data (or arbitrarily both) and what is the error thrown (66?). If you get timeout errors on a read, then you should see that in the network monitor (task manger) as drops but you say that it "lopes" (had to look that one up..lol). That's normally indicative of a terminated messaging scheme where the terminator gets dropped for some reason..

What sort of throughput are you trying to achieve? You could try and give LV a bit more time to service the TCPIP stack by increasing the buffer size.

Three words: Kill the cat

Ooooh. You like living dangerously eh? .

Yes. Each Event Structure has its own events queue, and it dequeues from that queue in the thread that it is executing that section of the VI. The default is "whatever execution thread happens to be available at the time", but the VI Properties can be set to pick a specific thread to execute the VI, and the Event Structure executes in that thread.

The "Generate User Events" node follows the same rules -- it runs in whatever thread is running that part of the VI. UI events are generated in the UI thread, obviously, but they're handled at the Event Structure.

Hmmm. If that is true. How is it reconciled with the events of front panel controls which surely (neck stretched far) must be in the UI thread. I could understand "User Events" being able to run in anything, but if bundled with a heap of front panel events; is it still true?

I couldn't agree more. The best thing I took away from the CLD is that my approach was way too complicated for what I was being asked to do. My submission was good-enough to pass, but I didn't complete all the features. I've really concentrated on the KISS principle ever since. Thanks NI!