Neil Pate

Indeed, the writeup on how they managed to get CGA to display 1024 colours is fantastic (and way way over my head).

http://trixter.oldskool.org/2015/04/07/8088-mph-we-break-all-your-emulators/

Is that like home-sickness for birds?

This is quite interesting. I really hate doing any real programming on my laptop using the touchpad (on a flight for example). Sounds like the Surface solves this problem!

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.

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?

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.

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...