ShaunR

Indeed. For me it depends on whether I want (or need) to spend a day thinking about an elegent approach for a trivial part of the program or just want the results. I'm not particularly a purist, so if its neat, easily understood but not the quickest piece of code on the planet, then thats fine.

Surprised me too . But maybe optimisations are coming into play. Not sure what you mean by "whenever possible". If you need to "iterate" then I don't really see any other alternatives apart from "while" loops which don't have inherent capablity to dynamically terminate on the array length. Example perhaps?

The thread that anything runs in is not dependent on the loop (LV 9.0and "for" loops excepted) but the "Execution System" that you define. Additionally, the number of loops is irrelevent. Its the vi's that count! The max thread count is 8x5x5 = 200 (8 per execution system x 5 execution systems x 5 priorities). The default is 4 per execution system with 0 for background . So if you look in process explorer you will probably see 21 threads (4x5=20 + 1 for LV itself). Therefore, if you have 4 threads and 12 loops in 1 execution system in 1 vi which is at "Normal" priority,then the LV scheduler will split the 12 loops between the 4 threads (black magic NI secret how this is applied....chime in here LV gurus!). If you want to ensure that a single loop runs in a single thread (not documented but works for me). Then run those loops in their own vi and in diiferent execution systems (I use other1 and other2 a lot) and in asingle vi. If you change the threads per execution, then you will see the threads grow in "Task Manager". Bear in mind, that LVpre-allocates threads, so you will only see the difference when youre-start LV. One further point. Don't confuse parallelism with multithreading. You can run 2 loops in parallel but LV may only run them in 1 thread and "timeslice" between them. A usefull utility exists in vi.lib\utility\sysinfo\threadconfig.vi where you can change the thread allocations. - Don't know. None of the PC's we use have AMD processors, but seems a bit unlikely.

Intriguing question. Well. For loop original 10000 runs = 5080 ms. No for loop 10000 runs = 2ms For loop with 10000 run loop normal but code loop // (2cores)) 10000 runs = 2887 ms For loop with 10000 run loop // (2cores) and code loop // (2cores)) 10000 runs = 2 ms

Don't know where the "attached discussion forum" is, but I've thought for years that "Elapsed Time" should be in ms resolution. It would have been useful then .

Unfortunately you can't because it uses serialised data. I've actually found very few scenarios (so far) where I can use that feature. That maybe due to how I partition my code and the type of implementations.

Now your just being difficult...lol.

Also you can type in 248 on your numpad whilst holding down the alt key. Works in anything (word, excel, labview, notepad). Alt Numpad codes

A while loop with nothing will be the fastest. But it will hog your processor (although I've noticed 2009 it only hogs 50% instead of 100%) and it will be hit and miss whether other similar loops get in or not. The next is usually a wait ms with a 0 wait time as it allows context switching so your other loops at least get a look in. Timed loops under windows are better used as a periodic function rather than (in the realtime context) a deterministic function since you are still at the mercy of the windows scheduler. The rule of thumb is. if its time critical......don't use windoze!

Labview is highly optimised for "for" loops. They are very efficient. Far more so than most other array primitives/operators. Try it.

Litteraly...you don't need the for loop. Still works because its only detecting zeros which (in both your examples) only exist in the gaps.

Ahh. You can. You don't need the for loop either

I bet you say that to all the boys

I bet it isn't

For this signal, you can just look for zeros in your data which will be the start and end of gaps.

Does it matter?

+1. I also don't like the fact that closing that huge probe manager closes all probes. I think it would be better if it was more of a dock, whereby we could drag them in and out and if we closed it only those inside it are closed.

I think your main problem is probably becase you are trying to mix and match LV x32 and X64 device drivers. You cannot compile 64bit applications with labview x32 and vice versa (bit short sighted in my view) hence the reason I have both installed. Time will tell if LV is able to choose the correct device drivers to compile with depending on which LV version I am running (havn't got that far yet). When I installed, the device driver installer chose either x32 or x64 based on the labview version I had just installed rather than the OS. I chose the device driver custom install in the labview installer which prompted me to insert the dvd and it had already chosen the appropriate bitness (is that a word?).

Tape at all signifies an engineer. Bolt standard geeks use plasters. First degree? How many have you got? Contracting is good money, but it has a lot of downsides and work can be sporaddic. So did they?

I'm running Labview 2009 x64 in Win 7 (In fact I have both the 32 bit AND the 64 bit installed dide by side). They both installed without any problems, although the Developer suite DVD didn't have LV x64 only the 32bit one so had to download it instead (interestingly the device driver dvd has support for both and automagically chooses the correct ones). You might check first that the Labview 2009 you have is indeed the x64 version and not the x32 one. If this is ok you can try booting up and pressing F8 to get the menu and selecting "disable digital driver enforcement" (There have been a few posts about Win 7 being a bit pedantic about signing) and then trying to install. And as "belt and braces" choose to "Run As Administrator" in case permissions are the problem.

Steeerike 1! Its rare that engineers have the discipline to keep documentation if the environment doesn't require it. Nice one. Well. That's the other aspect of documentation.....traceability. If the formal project process is followed, the code is traceable right back to the requirements spec (the SOW is usually the response to a requirements spec). True engineer? Does that mean we all weigh 5 stone, have chronic acne, wear wire framed glasses and have a hunch from sitting at monitors all day? Is that what he means? Its part of our standard document deliverables, along with drawings and a maintenance manual. 3 paper copies of each (One for the maintenance dept, one by the machine and one for the engineering dept) along with one electronic copy of each on CD. Design by committee never works. Too many cooks etc, etc. I'm quite surprised, however that training wasn't part of the deliverables You get overtime?....wow. I've also heard the "This time we're going to do it right!" one before. Next time thay say that ask them what the project risks are and what are the contingency plans to mitigate them. If they stare at you blankly, it going to be the same as the last one. If they bore you silly in the first 2 minutes with schedules and plans, there is hope! You know at least they have thought about it

I still must be missing something here. I still don't see the purpose behind the "Executive" other than a translator between the "tests" and SOAP server which itself is a translator to the Master system. Lets assume the C# bit doesn't exist. No better, is completely transparent so as far as you executive is concerned it receives information about a test (e.g. test name and limits) directly from the Master System. Your executive receives this info about a test to perform and does.....what? Calls a single test? Where is the logic that selects a test based on the info received (going by your drawings). I may just be getting confused by the main and user interface, but it seems that the "executive" should be able to call more than one test so instead of your drawing showing an executive and user interface for each test (the tests are hard coded you say). It could just invoke the appropriate test and show its front panel (which is the user interface). The test can still be run locally by just dbl clicking on the test vi and your "executive" can invoke 3,4, n tests to run concurrently sucking up the messages from your queues and relaying them back to the Master System. In this scenario, the "Executive" is the same as your suppliers interface and there is no "executive" only the tests. Hmmm. What about if I described the little bubble in my noggin this way. If you combined the Labview Server with the Executive. Removed the interface from the executive (hide its front panel) and instead used the Test Vis front panel as an interface. Then gave the Executive the capability to dynamically load tests (i.e execute one, leave it running, execute another, leave it running and monitor the queues). I think then you would have pretty much the same functionality as your supplier with less hierarchical levels. This bit does....lol. I think you are describing 2 tests that may be standalone tests in their own right, but may also have to pause/wait if other tests are running concurrently. For this to happen you have (as I see it) three choices (others people may be able to see more, that's the beauty of forums ) 1. A single all powerful intelligent sequencer (classic) that knows what to do and when, and orchestrates everything. 2. Get the tests to chat amongst themselves and only bug the "Executive/translator" when something important happens. 3. Or a (what I call) dumb sequencer (probably a good fit for your topology) that doesn't know anything about the tests (only which tests are running) but routes requests and messages from the tests (that only know about their test) which wait until they get the nod. You are probably used to the first one. Intimidated by the second and never heard of the 3rd....lol. The way the 3rd one works is this. Day 1. Test A starts running and says "hey can I run now?" and waits. The Sequencer Says "Sure" cos the sequencer knows that test A is the only test running. Test A says "ta very muchly.....here's the result". They all go home to the missus. Day2. Test A starts running and says "hey can I run now?" and waits. The sequencer is silent because it knows Test B is already running and test B must get to its lunch break before Test A can start. About 12 o'clock, Test B says to the sequencer "I'm off to lunch now" and pauses. The sequencer finally says to test A "Sure". A mightily relieved Test A says "ta very muchly...here's the result".Later. Test B comes back from lunch and says "hey can I run now?". The sequencer says "sure" because it knows test A slipped out the back door early and now Test B is alone in the lab. Test B says "ta very muchly...here's the result". And they all go home to Test A missus...lol. Personification aside. What the third option would enable you to do is allow interaction with the master server either by pausing/stopping/reconfiguring the tests or relaying status information back to the Master since the "Executive/translator" is in the message loop (functional events if you like). Waffle, waffls...lol

Now that's something I'd pay to see.

Pretty soon you'll have to buy a license for each pallet item the way they seem to be modularising and licensing. I'm already up to 23 activation codes for my developer suite. It grows by about 3 licenses every year and I've had the same suite for 4 years.

I had a funny one today in LV 2009. I had a sequence engine running and one other vi running (mainly keeping image references in memory so I could stop and start the engine). The sequence engine would only execute (by that I mean its state machine would only go from state to the next) if the diagram was in the foreground or I moved the mouse over menu items (in the main menu) if the front panel was in the foreground. How the hell do you debug that?