Neil Pate

Update: I'm now having serious problems with backlogged messages. I get messages out of the TCP Read buffer in bursts, and it seems the backlog grows constantly while running my app. This is breaking the heartbeat I'm supposed to send over the link, so each application thinks the other has gone dead after a second or two. Anybody know what might cause the TCP connection to lag so badly?

I have not messed about with this kind of thing in years, but perhaps it's Nagle's algorithm at play? You can disable it using Win32 calls, see here.

I used them for two years, and they repeatedly failed on their promise. Lots of errors thrown by the API that the application had to be protected from (including error codes documented only for Shared Variables?!), lots of issues with reconnection from the same app instance after an unexpected disconnection, lots of issues with namespacing endpoints, element buffering, etc. I never kept detailed notes on all of it to share with others, but the decision to use raw TCP was actually a decision to get the hell off Network Streams.

 

Certainly the buffering has it's oddities, but I have not come across the other issues you mention. I still think you are brave for going back to pure TCP/IP though!

Network streams?

You can attend the the CLA summit as a benefit of making it to the CLA certification level. If you are not a CLA then you shouldn't have access to the videos. The CLA summit is all about in person attendance and talking with your peers. And especially this year, there was an extra 2 days of awesome content that was a "must see". Even watching the videos doesn't do it justice, since I got the most value from one on one conversations. Perhaps in the future, this event will be open to all, but now it isn't.

 

Mark is not paid to record videos and has not been instructed to do so by NI or anyone else (maybe some presenters have asked - no idea). He does it out of his own passion. It's quite possible that NI might prevent him from recording videos in the future at all events. This is entirely in their legal right to do so. After all, this is paid content distributed for free (CLA summit and NIWeek sessions). So please be thankful and please don't stir the pot. If you know how to find the links and are lucky then great. The YouTube solution brings a lot of attention which I think Mark's recordings should not get, in my opinion.

 

As far as the presenters. There is technology today that you can use to record your audio and your computer screen. You can even attach a webcam if you want to be fancy. If presenters don't have their content online, it's not because it couldn't be done.

Michael, this is a slippery slope. I would have loved to attend the summit this year, but other commitments kept me away. The extra two days of content were restricted by an NDA, which I signed, so should I be allowed to see the videos even though I was not able to attend in person?

Regarding the other content, I feel it is down to the presenters on an individual basis to opt-in to allow their videos to be shown on youtube. I am pretty sure NI has no claim the the IP in those videos, and would be foolish to prevent non-restricted content from being made public. Although only CLAs were invited to the summit, but I do not really think it is fair to restrict that content from non CLAs who want to take the time (probably their own personal time) to watch it and perhaps learn something. The world needs more people skilled in LabVIEW in my opinion. The CLA summit is not quite as closed as you think to non-CLAs, there is actually a precedent already set in that the first CLA summit in Europe, held at NI UK HQ in Newbury was open to CLD as well.

OK, confirmed this is what is happening.

The .lvws is actually just a zip containing the Public (and I suppose Private if I had any in my project) Resources as well as the Web Service VIs packed into an LLB.

Hi All,

Can anybody shed some light on some strange behaviour I am seeing when deploying an executable with Web Services and Public Content.

I have an HTML page that gets served up as part of my application. My LabVIEW application interacts with a browser via Web Services.

Everything runs (mostly) fine, I can browse to localhost/ws/index.html and I get my web page.

However, I would have expected that HTML (and JavaScript etc) would remain on disk in source form so I could edit it after the LabVIEW application has been built, but this does not appear to be the case. Changes I make to the source do not get reflected until I rebuild my LabVIEW application.

Does the Public Content in the Web Service get packaged into either the .exe or the .lvws up as part of the build process?

I am really perplexed by this. I have tried all the obvious things like clearing browser caches etc. I even tried using a brand spanking new browser that had never been installed on my PC and I got the same symptoms.

I figure most people like being able to apply patches easily. Everyone auto upgrades most apps and even the OS these days. Why would patches for LabVIEW be any different?

Apps are mostly sandboxed. Upgrading DAQmx, for example, affects every version of LabVIEW installed on my PC. As a developer actively supporting software in multiple versions of LabVIEW on the same PC (because putting each one in a VM is still a pipe dream) this is a problem.

Edit: OK you did say only patches for LabVIEW, but even that is tricky. If you have validated a system using a particular version of LabVIEW all further incremental changes really ought to be done using the identical software configuration. Even something like going from LabVIEW2014f1 to LabVIEW2014f2 would probably require significant revalidation of certain software, or a lot of blind faith.

Hi All,

Has anybody tried recording continuously from the Sound Input Read VIs?

I have developed code that works quite well except every (approximately) 4.5 seconds I get a glitch of zero several samples long.

I have tried reverting to the old sound API, but this just seems to hard-lock LabVIEW.

Next step is to try things out on a different PC.

Edit: may have resolved the problem with updated audio drivers

Just to check the obvious:

Are you positively sure that there isn't a "\r" in the second array element? Are the strings not limited to a single line? Are there different settings on Environment -> End text with enter key? Have you checked the array string using code display?

Yeah I did check that just to make sure. There are definitely no carriage returns in the strings in the input array.

Something crazy is going on. I ran the LV2013 VI last night and had the same problem with the extra "\r".

Then I opened up the OpenG VI and put a string indicator between the Array To Spreadsheet String and Match Pattern, re-ran the code and it worked properly! Hmmmm...

I have tried opening my LV85 VI in 2013 and everything also works properly.

This is quite bemusing as I have four different applications (built as .exes) that show this behaviour, but now cannot reproduce it.

Whoa that's strange! Will check it out on another PC when I get a moment.

Hi,

I was made aware of a bug in an application I am supporting. It was originally coded in LV8.5 and has been recently saved at 2013. I think I have traced the bug down to an apparent change in the 1D Array to String VI.

In short, it seems that in LV2013 a carriage return "\r" character is being inserted at the end of the string. In LV8.5 this does not happen.

Inside that VI is quite simple, but it looks like the culprit is the Match Pattern primitive.

Any ideas when the behaviour of this primitive changed?

String Test LV2013.vi

String Test LV85.vi

Thankfully the vendor does also provide a more "usual" method of getting the data via a Read_Data function in the DLL. I just don't know why the LabVIEW example (which doesn't always work anyway) does not use it!

I can only imagine the VIs outside the loop internally save a pointer to the array and the VI inside the loop writes the new data to this memory location and returns the number of bytes it has written.

Yes, in the 4th VI an array is allocated (in LabVIEW memory space) and passed to a DLL, and passed out of the VI (that then goes via the tunnel into the While Loop). The DLL must then internally update the array via the pointer.

error terminals being in a nonstandard location on the connector pane.

I had not even spotted that one! At least they have kept the error wire straight 

So, this is the code provided by an instrument vendor for interfacing with a bit of measuring hardware.

Even though the input array should not change according to LabVIEW's dataflow rules as it should be a "constant" after it enters the While Loop, the data in the Channel A indicator actually gets updated!

Horrible...

I have seen some weird things happen with charts before (not even embedded in a sub-panel). Occasionally if you minimise the LabVIEW application and then restore it the chart has screwey data. Similar happens if you cover the chart with another window.

NI will probably blame my graphics card drivers (which I think is nonsense), and these issues are very difficult to recreate.

You are probably using the charts correctly and I would say this is a LabVIEW bug. What version of LabVIEW are you using?

Am I missing something?  Has there been some underground points program for years?  Because as far as I know the re-certify by points program came out less than a year ago.

 

The first I heard about it was the CLA summit in Paris, so that is nearly two years ago.

I have just checked my email archive and I submitted my re-cert on 2013-09-26 and got my results on 2013-11-22

So I just started trying to submit some activities for the "CLA-R by points" program.

 

Does anyone know what's going on behind the scenes, or why there have been so many delays? Is NI still planning on supporting it? Based on the comments I'm reading on the recertify board and a few conversations with other CLAs, it seems like things have been slow for a good long while.

 

I guess there was a brief period last year when they were responsive, but then the replies have slowed down to a crawl again?

Mike, I got my CLA-R by the points program, but this was several years ago now. They were a bit slow to respond even then, I had to send a few chase emails.

Not the way I expected this sentence to end.

I would not have been so proud had the sentence ended the way you perhaps expected it to...

Turned off, no luck. 

 

And this is done in Firewall tool?

Yes, but if the firewall is totally off then it will not help.

I have a UDP connection setup on a Windows 7 machine that runs an IMAQ code. The machine can send and receive udp connection so long as data being sent it is on the same machine. When I send the code from a different process (running on Windows 7), I am able to read the data on the RIO udp receiver VI (running on the Windows Host) as well.

So I changed the sending program to a labview code and the udp receiver won't pick up the data.

Could there be something I am missing?

Attached are the PNG files (lava1 is the talker while lava2 is the receiver).

Any clues would be appreciated.

Check your Windows firewall. Turn it off completely and see if this fixes it, if it does then you perhaps need to add the LabVIEW.exe process to the whitelist for UDP.

If this does not work, check the firewall again. Seriously I have lost hours debugging these kinds of issues only to find out it is usually Windows protecting me from myself.

Sounds great Jeremy,

This will be my first trip across the pond to Austin. Do you have any recommendations for hotels in the area? I know La Quinta Inn has been suggested, do you think is this a reasonable selection?

Looking forward to seeing everybody soon. 

Sometimes this error message could occur if some other code in the project is broken. Very often it is a class VI that is not actually used in the main code (say a test VI that has been broken as the API changed, and the dev was a bit too lazy to go back and re-run all the tests).

When I get these errors I start pruning the main VI until the build works again, however this is very timeconsuming (and frustrating process) and I would say that most of the time the error is related to one of the recent things I changed.