Neil Pate

So what do you do when you need to execute a reasonably complicated bit of code which requires various bits of "data" in this cluster (i.e. a portion of code that screams out to be made into a sub-VI, which in my opinion is virtually anything non-trivial)? Do you unbundle the specific elements and pass them into a sub VI? I know it may be frowned upon, but by having the cluster typedef'd I then just pass the whole thing into/out of a sub-VI. Of course you could pass in a non-typedef cluster but we know how that is going to end...

It would be nice if the template could include a typedef for the main cluster on the shift register, I normally end up creating one.

Just to chip in here, I recently had the same problem (2013 SP1). Bundling in a "variable" wire did not cause the class output "cluster" to be updated. Bundling in a constant (in this instance it was a string) did cause the "cluster" to be updated correctly. Probably entirely related, editing some code in this class would cause the IDE to hard-crash, so I figure I just managed to get my code in a state that was not consistent. I fixed my problem by deleting the VI that caused the crash and re-creating it from scratch. I think the inconsistency happened when I renamed a class VI to something that had previously existed in that class.

I think this is actually possible in the IDE, but not in built applications.

In LabVIEW (and perhaps all Web Services, I am not sure here) the connection string is in the form: host_address:port/WebServiceName/QueryString so it just seems to me that something is redundant here. You can infact have multiple Web Services on the same port when running in the IDE, but then I suppose there is only a single application (LabVIEW.exe) that is bound to the port. However as soon as you have built applications this paradigm breaks.

Something to add (note, this is just something I "figured" out, it is completely uneducated and could be totally wrong) on the handle vs a pointer to a handle... Dealing with a pointer to a handle is a mechanism that allows the underlying memory allocation mechanism to do stuff like defrag or completely change your memory allocation without affecting your running application. Your application has a constant "memory address" that is the pointer to the handle. Then any actual requests to memory always go through the lower level manager (i.e. LabVIEW's memory manager) which actually does the translation between the handle that your app knows about, and the actual physical memory address. No doubt I am using all the wrong vocabulary here, picture me waving my hands in the air to get an idea that I only have a vague notion that I know what I am talking about.

Sure, your comments pretty much echo my internal dialogue. I can't figure out what the point is then of naming the web service? If all traffic to the IP address and port gets directed to the single instance of the web service why bother identifying it by name?

This NI document confirms my suspicions.

I was being a bit facetious, but I did not know about it only being TLS, so I forgive you. I have a ten week old at home, I didn't get to sleep with anybody last night

Just tried out something that I would have expected should work, but doesn't. As a Web Service is identified by a name I would have expected I could run several of them on the same system with the same port. This does not work, whichever service is started first works, the other does not. Moving the second Web Service to a different port works properly. Am I being unreasonable with my expectations here? I know enough about ports to be dangerous but that is about all, is there some underlying restriction of the OS (Windows in this instance) that only allows one application to bind onto a port? The reason I am doing this is to try and create a test environment so that I do not affect my production Web Service application.

It's a good thing NI never got around to making an SSH toolkit

So, most of you here are probably aware of the Heartbleed bug in OpenSSL. How seriously is everybody taking this? Seems like a good time to change my password; "12345" was probably due for an extra digit on the end by now ;-)

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.