Neil Pate

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.

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

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!

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.

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?

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

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.

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

This morning I started off the day by destroying a bathroom door with an axe to help release a friend who had gotten trapped by a dodgy door handle. Without a doubt the most cathartic way I have ever started a Wednesday morning...

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

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.

I used to see it quite a bit last year when there was the spam about watching videos online. I thought perhaps they were related?

Yes I have seen this frequently over the last week.

I think there may be an error in the library. The "main" VI is not actually part of the library and the library references a file that does not exist, so I presume some form of renaming (outside the IDE) has gone on? After fixing this I tried this on the one TIFF file I have but it is compressed and looking at the code it appears there is not yet support for compressed TIFFs.

Yamaeda, I do not know what is wrong with your code, but can offer you this advice. To the best of my knowledge .NET calls are actually very expensive in LabVIEW, a single call can be something like a few milliseconds! Now, it was a few versions of LabVIEW ago that I had this problem, but my understanding is that it is just the "managed" way of how .NET and LabVIEW operates that this is likely to always be the case. If you are trying to render lots of stuff I expect you will have lots of .NET calls so just be careful with performance. For reference, I was using SFML, it seemed like quite a nice library but performance was terrible from within LabVIEW.

.MOD for true authenticity :-) BASSMOD does all the hard work, I have just wrapped the DLL.