Neil Pate

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.

Now with battle music and events posted to an Event Structure directly from within SDL (yay no more polling!), and the initial introduction of some helper classes to wrap the SDL pointers etc. http://screencast.com/t/gJVSNrtrpyCY

Those outcomes are possibilities, not guarantees. Not every application has 8000 VIs, and in a lot of situations the careful use of libraries can be really beneficial. I am not ready to give up on them yet.

Massive no from me on LLBs. I do not need to distribute my code like that, so really have no purpose for them. As others have pointed out, no namespacing, no access scope makes these a stale technology (for my situation at least) in LabVIEW. I still do use libraries though (and classes of course, which are also libraries), even with all the pain associated with the loading the entire contents etc. It troubles me too much me to have to manually namespace every VI, so I am not sure I will move away from libraries or some form of them any time soon.

That's a bit neater...