ShaunR

That gets covered in

Not necessarily. If you wire through and LabVIEW can tell the data won't change, then that "tunnel" may get replaced with a constant by the compiler. If you have dynamic data then shift regsiters can sometimes tell LabVIEW enough about the data to kick in some extra optimisations, but it's not a clear cut as shift regsters good, tunnels bad. I only have an intuitive workflow for using shift regsiteres vs tunnels based on experience, but I'm sure a NI guru can tell you specifically what optimisations can and cannot be enabled with shift regsiters and tunnels. Glad you got it sorted, though.

Don't let their familiars fool you. You can spot them by their lack of certification but insistence that with an object oriented framework you can cure all software ailments and even reanimate dead projects.

Ok. first off. Windows is not a real time OS so it isn't deterministic. I know that, you know that but your project manager probably doesn't so that was for him. Second. I bet you are so close, that if we can just optimise what we already have a little better, we will be home and dry. Sure. Then in 6 months the spec changes to every 7 ms and the project manager says "you did it before, now do it again - it's only 1ms". So. What is the problem? Ahh. Just poking over the 8 ms in places. Lets see if its what all the girls say that size does matter and bigger is better. Ah yes. No problem with under 8ms. The girls are half wrong and half right. Size does matter but smaller is better. (In fact it is linear. 400,000 will yeild about 3 ms, 200,000 about 1.5 ms etc). Easy answer 1. Reduce the data size in the global. But why so slow? Is it the array disassembling? Is it the reading from the global? Does it need more coffee? Oooh. Microseconds. My spidy sense tells me its the global. Easy answer 2: Don't use a global for big arrays if you're time constrained. That about wraps it up for reading. In the next issue we will cover: Oh my god. It all falls to crap when I write data.

Can't build 64 bit apps with 32 bit LabVIEW. We moved away from CLI with windows XP over 14 years ago. Us point and clicky people will drag you secretarial typists with eidetic memories kicking and screaming into the 21 century Begone to Linux

LabVIEW already supports 64-bit (File IO>>Zip). If you are after the OpenG stuff, it's all going on here.

Ahh. But to call yourself a LV Architect you do. They even have special orgies every year that no mere mortals, however capable, can join in. They speak in tongues and discuss spells and other voodoo magic that no non-architect can understand or even hear without going insane. Then they go back to their local covens to plan the next act of debauchery with the new curses and sigils they have learnt. Well. Read it now It looks like an ActiveX driver so there's the problem in a nutshell. If it wasn't for that, I expect Gerd would have not needed as much patience (but you are right, he is a saint)

Damn. I've been posting on the wrong forum all these years. I'm neither an architect, nor virtual although I am advanced in years .

If you can afford to be a frame or two behind, then you might want to split the resizing and unpacking into separate pipelines.

Indeed. However, by putting it into a sub VI it has only made it more application specific (what are the chances your global, global VI of refs has exactly the right datatypes and clusters from project to project?). For raw data on a particular project it doesn't really matter. You'll create all the queues and then discard them and create new ones from project to project.The advantage being "look Ma, no wires" rather than generic re-use. Once you start looking at messaging for control, however, you will be looking for a generic method and that is when named queues become far more attractive. This is a little VI you will find in almost all of my projects. I use to for command queues for services. It is not application specific since it does not have any application specific data types and look Ma, no wires. SR Queue.zip

Don't underestimate dynamic queue selection but to add one more - "re-use". If all your global non-rentrant VIs are the same type, (a variant, for instance) all your globals' diagrams will look identical (it's only the refnum you are really after). Then you will notice that all those global diagrams are identical AND all you are doing is enqueuing and dequeuing these. That should be smashing your brain with the Hammer of Re-use Reminding but you will find it oddly difficult to push the Get Refnum, enqueues and dequeues down into a reusable, generic subVI. It's the same issue with events.Encapsulation doesn't enable resuse and no matter how hard you try to encapsulate to create a generic form (a requirement for this type of re-use), you still end up with a specific implementation. However, encapsulation and genericism can be achieved with named queues due to the "Obtain Queue" and is the main advantage of queues over events.

Basically to echo what Neil is saying. I've recently been building and resolving these errors (I always get it with the package manager). Orphaned VIs or those in a conditional disable are usually the culprits. Sometimes VIs that are referenced on a diagram but not in a lib or project. If you get the VI search dialogue popping up (and you're fast enough) you can click on the dialogues' title bar to freeze it so you can see the VI its trying to load A failed search during build will always cause this error.

My guess is that your UDP read is timing out but, since you specifically ignore the timeout, your assuming it is receiving.

Well. It gives me the sh@ts (Queue the toilet humour )

I'm sure you are aware, but it probably needs to be stated that it is an infringement of the Mac OSX EULA to run it in a VM. They specifically code defensively against it (hence your abominable experiments) . Mac OSX can [legally ] only be run on Apple hardware.

Multi-platform binaries are far from trivial. LabVIEW makes cross platform development a breeze, but to create binaries for it to use is still very resource intensive especially as they have just added Linux and Mac 64 bit support in LV2014. That equates to a minimum of 8 different binary builds that must be created, maintained and tested on multiple operating systems, multiple hardware targets and multiple LabVIEW versions and lets not forget build tools, scripts and 3rd party stuff. Testing and debugging alone is a full time job in reality and Rolf has a life and paying work to factor in too. The good news is that once it is done. That should be it for a few years

There's an interesting RSA Animate by Dave Coplin. I'm not sure I agree with everything he says, but there are many salient points he raises as to why many feel dissatisfied with work.in the current age. Personally. I think the criteria for job satisfaction is a moving target and changes dependent on age and circumstance. In the beginning most people are primarily concerned with financial and educational reward (the latter mainly to enhance the former). Then family comes along and time at home and flexibility becomes more desirable and work is a means to an end rather than a personal journey. If you are middle class and in a specific field then once you have attained a certain competence in your field; exercising the limits of your knowledge and choosing the interesting tasks seems to be a primary consideration. Towards the twilight of a career, guarding that pension pot seems to be the primary driver. A rare few have a hobby that makes enough money to support a family with oodles left over for a car, house and yacht. Most are not in that category, but those that are tend to be extremely happy both in and out of work. There is a saying, where I come from. Job satisfaction is 20% of your wages. On the surface it seems rather trite except if you re-interpret wages to mean benefits. However, it goes some way to explaining why many are willing to do open source for pennies if not for free as long as a minimal survivable income is catered for.

Well. If it works, then it's probably enough. I'm a fan of graphs and stuff. What would be nice is if you graphed the points and either showed or allowed the user to select, with a cursor, the points on that graph - that's just me, though.

Well. Sort of relevant.... I have an automatic HTML document generator for help files. I looked at the LV Report Generation Toolkit but it was awkward and I settled on a templated system and regex replacement (header, body footer templates etc). I found that writing HTML with a WISWIG HTML editor (so you know what it will look like) and running a script against it with keyword replacement was easier and more flexible than building a HTML document with the LV Report Generation Toolkit for that use case.

I have never used a NI USB 8452 but...... According to the manual it has on board pull up resistors that need to be enabled for Vref ≤ 1.8 V. Whats your Vref?

You need to use "GetIpAddrTable" and then look at wType to see if it is MIB_IPADDR_DISCONNECTED. This just reminded me........ I was making fun of my Linux fanatic friend. I said you can tell the difference between a Windows and Linux programmer by how they approach a task. If the task is to tell if you are connected to a network. The windows programmer will call an API function to find out the network card state. A Linux programmer will monitor the LED blinking on the network card with a webcam, pipe it to a file then regex the file to see if the LED is on He scowled. Thought about it and then said, with a smile,. "Nope. We'd get an intern to watch the LED and SMS us on the yacht when it changes" - Touche!.

There is a lot of information on interpolation in LabVIEW including examples which you can find using the Example Finder.

Well. you have descrete increments that luckily correlate to the index. So if your user enters 110 you can just divide by 100 (quotient) and it will give you 1 which you can pass to the index array function to extract the row. The fun begins when you want to get to the closest higher or lower than the value input

Naah. You only want to replace your home-grown. memory/handle hungry, local object database. We all know of a self contained, blisteringly fast, serverless RDMS that would fit the bill nicely I don't understand folks that don't use it even if it's just for error logging.