Neil Pate

Neat! It sure beats the stuff I did in university...

I recently took a peek at some C++ I did in post-grad. Ouch! "Clever" variable names, swearing in comments, massive functions... The things you do when you are young

Thanks guys. The code in question was written by myself some time ago (circa 2007). I was creating a NaN by dividing by zero, I suppose at the time I did not even bother to consider the "correctness" of the conversion, it worked and I just accepted it and moved on to the next thing. I find it really educational to look back at my old code and see how my style has changed. Coercion dots all over the place, no defensive programming techniques etc etc.

Hi All, I am in the process of porting a LV8.5 application to LV2013. One thing I have noticed is that there is a difference in behaviour when converting a NaN (DBL) to U32 using the To Unsigned Long Integer primitive. In LV8.5 NaN is converted to 0 In LV2013 NaN is converted to 4294967295 (the maximum a U32 can hold). Does anybody known when this changed, and does this seem like a reasonable change? This could lead to some very strange bugs!

Name: Rubiks Cube Solver Submitter: Neil Pate Submitted: 03 Apr 2014 Category: *Uncertified* LabVIEW Version: 2011 License Type: Creative Commons Attribution 3.0 This project is a 100% G based Rubiks Cube solver that I coded quite a while ago (2007) and then forgot about. I must have saved it it more recently in LV2011. The algorithm is based on the 7-step method, which is totally sub-optimal for solving a cube, but relatively simple to understand. Please note this code is not representative of my current coding ability, I just upload it in case anybody is interested. If I get time I would like to do a 3D representation of the cube and allow the manipulations to be done in this view. Run instructions: set the show boolean to True click randomise! pick a start colour click solve! The buttons on the left hand side can be used to do manual manipulations of the cube. Click here to download this file

Absolutely!

The point I was trying to get across (unsuccessfully it seems!) is that even with a timeout a lot of CPU is used up waiting for the DMA buffer to have enough elements. This is probably contrary to what most people would expect.

Yes, I did mention something like that in the line before.

Just to add to Jordan's post for those that don't know. His picture shows an efficient way of reading from the DMA FIFO, first check to see if there are enough elements by requesting zero with a zero timeout, this will return the number elements remaining. Then only perform the actual read if the number of available elements is equal to (or more than) what you want. My understanding of this necessity is that although the transfer occurs via DMA, if there are not enough elements yet then the CPU actually polls (using a lot of resource) until the number of elements is achieved, and this can really kill performance.

I feel your pain Mike, This advice will probably come across as totally patronising (it really is not meant to be), but I really recommend nightly builds of all executables, committed into your VCS. Doing this generally saves a whole bunch of time when LabVIEW throws its toys out the cot.

For those who do not know me in person, Neil Pate is my real-world alias.

Indeed, a worthy cause. I was browsing the donation page earlier today and spotted a few familiar names there

This is what I ended up doing. I spent days trying to figure out which dependencies were required, and gave up in the end after trying many different "sensible" permutations. I have gained a whole heap of Inno Setup knowldege and random installer stuff now though, so I suppose it is time well spent.

Although this process is painful I am learning a tonne of new things about VirtualBox and InnoSetup. VirtualBox is a mighty impressive piece of software, I cannot believe I have not been making more use of it (especially snapshotting).

Thanks for the tips guys, I am getting there, slowly! This is my current [Run] section [Run];Filename: "{tmp}InstallDotNET4dotNetFx40_Full_x86_x64.exe"; Parameters: "/q"; WorkingDir: "{tmp}InstallDotNET4"Filename: "{tmp}LVRTE_Extractedsetup.exe"; Parameters: "/q /AcceptLicenses yes /log /r /disableNotificationCheck"; WorkingDir: "{tmp}LVRTE_extracted"; Flags: waituntilterminated

Yeah I have that feeling too, it just feels so unnecessary to package the whole RTE with my application. Also, it makes the install process a bit weird as the user has to click through the LV RTE install dialogs. If I could find a way to supress those I would settle for that. This should be possible, I just have no idea how

Hi All, So I have spent a large portion of my weekend either changing nappies or trying to get a LabVIEW application running on a fresh PC (in a VM). Basically I am trying to streamline the RTE (using a technique similar to Jack's described here). I will admit I have not made very much progress, I can run a very simple app, but have not yet found the magic sauce for making .NET4 DLLs work, or WebServices. I have two simple builds that I am trying to run. One is a simple .NET DLL test, the other a WebService test. The first fails to run properly with a broken run arrow, the second runs, but I get a LabVIEW error the same at the original post in this thread. Any tips here on which parts of the RTE I should be using? Note I tried the components described in this document to try and make the WebServices work, no luck. Edit: ok figured out the .NET portion (maybe) needed to include VC2010MSMs. Help! Neil

take a look at the VIs in vi.libutilityeditlvlibslvclass I believe that renaming the class also resets the mutation history.

Thanks guys, I have done a bit of tinkering with InnoSetup (and the Script generation GUI) and really like it. Now I just have to figure out how to include the various bits and pieces of the runtime engine, webservices and .NET client.

"Glad" to hear I am not alone in my frustrations here. If you don't mind me asking which 3rd party setup generation tool did you settle on? From speaking with a few others it seems that Inno Setup is quite a good option.

More info on this error in case anybody else stumbles upon it. I still do not know what causes this problem, and the only reliable solution I have found so far is to install the LV runtime engine manually before proceeding with the application installer. This is not a very satisfying fix for the problem, and am not devoting some time to looking into alternate install creators as I do not think the one built into LabVIEW is doing a very good job.

OK, hopefully gotten to the bottom of it. Looks like it was just a messed up installation of LabVIEW. Removing everything NI related and re-installing the runtime seems to have fixed it. Is there a holding thumbs emoticon?

Hi All, I have a strange error which manifests itself on some of the PCs I am trying to run a built application on. I stripped everything out and have traced the error down to a single VI, OpenHandle.vi in the HTTP library which ships with LabVIEW. The error code I get out seems to point to something fundamentally wrong with this PC as it is saying "Failed to load library". This does not happen on all PCs, only some. Does anybody know if the HTTP VIs call some DLL or something (the VI is password protected) that I should be distributing with the application? Has anybody seen this error before? Google does not seem to know much about it.