ShaunR

Hmm. Not sure you quoted the right bit by the context of your response, but I will assume it is the correct quote. No it doesn't. A manager requiring a passionate argument from a subordinate to make a decision is a test of belief and has nothing to do with the software or hardware. It's about one party convincing another about their conviction irrespective of fact. This is why I don't agree with the technique as a valid decision making process.. Sure but would a release manager have prevented it? (assuming they don't have one). I don't think so. From experience, those sort of foobars are usually attributable to a business decision to release in the face of opposition from the technical expertise. May not be the case in that instance but since the knew it was about to happen I bet it was. On many occasions I have been that technical expertise that said "I told you so"

Yeah. But a release manager isn't going to address that, is he? The way to stop that is via testing so its a case of "OK, you've found a fix where're the documents?" However, a Principle Engineer, at the very least, is much more likely to error guess or spot implications than a Release Manger. The Release Manager is really just a checklist that you drink coffee with. Here's the risk assessments, here's the test results, here's the bug fixes, now sign. The only thing he or she brings to the table is somewhere to apportion blame. Well. That's the Project Managers job Even is you think in terms of gates (RFQ, RFT, RFP etc) a Release Manager doesn't bring anything more than a signature to say "We really, really think it works now and here are all the documents written by others that say it too". Replace him or her with one of these

Yeah. I don't agree with this management technique. It's basically mistrust of your engineers and lack of technical understanding by the manager. It's actually a negotiation tactic which has been ported across to exert control and, in extreme cases, abuse. It's predicated on the requesting engineer having some sort of vested interest in gaining acceptance of an opinion from the superior rather than technical facts It tends to fall to pieces with East Asian engineers that just say OK as superiors' opinions are considered absolute regardless of the outcome.

That's what risk assessments are for. Fire the manager and distribute a spreadsheet.

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.