ShaunR

I had this problem recently.

My scenario was that the asynchromous consumers could either send a "completed" notifier immediately (no part present) or after some arbitrary amount of time (part has been processed). The sequence engine would wait for all notifications from the subsystems, index a carousel and then send a "Go" notifier to all of them . The problem was that if the subsystems sent it immediately, the chances were that the sequence engine wasn't waiting for the notifier at that moment in time, so on the next round would wait indefinately.

The elegant solution would have been the "Wait on notifiers with history". But this doesn't wait again unless you've cleared the notifier and since you don't know which is the last one in an asynchronous system, you don't know when to clear it. If it executed the number of times there were notifications in the history....it would be perfect! The normal notiifer will only execute when you are actually waiting (if ignoreprevious is true) or again, you need to clear it (if it is false). So that didn't work either since the sequence engine was unlikely to be already waiting if a subsytem returned immediately.

So I ended up with all the subsytems waiting on a notifier to "go" and a separate 1 element lossy queue for each subsystem to send back the completed (basically a notifier with a history of 1). Luckily I have a Queue.vi so it wasn't messy and just meant replacing my Notifier.vis with the queue one.

I was referring mostly to the difference between your two test codes. One does an operation inside a loop, the other performs the same operation on a vector. Of course, most of the time you're using a loop, you have no choice in the matter because of the need to iterate.

That said, one example is a phase wrap on a vector. The logic is: if a>180, a = a-360. if a<-180, a=a+360. Because LV's Select does not allow the boolean input to be a vector, my first thought was to use a for loop. Instead, I was able to come up with a more efficient vectorized approach using modulos.

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.

Ok, I get the factor of ~2 speedup from the 5.08 seconds to the 2.887 seconds, but I'm pretty surprised at the last line. I think I would have have expected no difference, as both cores should already be fully committed by virtue of the code loop being parallelized.

And now you see why I avoid for loops whenever possible. The Boolean to 0,1 likely has an allocation associated with it, which is why you don't want to do that in a loop...

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?

Thanks, but I'm after a little bit more info. It might've been my first post to the forums, but I'm not new to LabView (been programming 5+ yrs).

Some things I heard / read somewhere over the years that caused my questions.

They may be true, they may not...

- Timed loops only execute on a single thread, regardless of how many loops you have (4 timed loops, 1 thread...doesn't make sense to me?).

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.

- Timed loops are not compatible to run on AMD processors.

Clarity?

- Don't know. None of the PC's we use have AMD processors, but seems a bit unlikely.

Oh, right. I guess the shift register would get in the way... I haven't played with that feature yet (or LV2009, for that matter).

Actually, that got me thinking. I wonder what the performance difference is between your original looped approach from a couple days ago and the unlooped one. And does that change significantly if you multithread the looped one?

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

Or better yet, post me a comment in the attached discussion forum so that I can make it what people want it to be .

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 .

Ah, I like that one!

Especially if you're using LV9 on a multicore system and can multithread the loop.

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.

The output of your example just provides a mask that indicated when the data is valid.

I don't think that's his desired output.

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!

Ideally I need to find the start and stop of all the gaps. I need separate out and save the chunk of data between the gaps.

George

Using loops isn't necessarily a killer, but I do need to keep processing time to a minimum.

I think a SMA could work, but I think it'll be a little sloppy on finding the edges of the gaps (depending on how many samples I average).

Thanks for keeping the ideas coming. They may not work as is, but usually I get enough of a nudge in the right direction to figure it out.

George

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

I think that only does half the job. You'd still need to look for 2 consecutive 0's.

Try it.

While we're being creative, here's another way to do it. Again, it works for this particular sim data. Not sure it's any more efficient than the diff method though. Curious to see your approach.

Litteraly...you don't need the for loop.

Your comments got me to look closer at my simulated data. I knew my real data would be noisier, but it will also look more like a sine wave than the triangle wave I had. I bumped up the sample frequency and now it looks better. Sorry to say though that the contributed ideas won't work on the new data. I'm back to my original plan of finding peaks and differentiating. By finding the time between peaks in the differentiation I can get the gaps. OK anybody up for round 2?

George

Fing gaps 2.vi

Still works because its only detecting zeros which (in both your examples) only exist in the gaps.

Well you can't get much simpler than that.

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

..... for the finger exercise it gives me

I bet you say that to all the boys

Thanks I like your way better. Actually I've done something like that in the past and completely forgot about it.

I don't know for sure yet what the real data will look like. I'm sure it won't be this nice. But this is a good place to start.

George

Well you can't get much simpler than that. I'll bet Gary's method is faster though. I know I didn't make that part of the criteria.

I bet it isn't

I have a pulse train that I'll receive via a DAQ card that looks like this

I need to find gaps in the pulses. I've attached a VI that generates simulated data and does the analysis. Basically I find the indicies of the peaks and then take the second derivative of those indicies. The gaps in the indicies give a spike in the second derivative. I can then use those spikes in the derivative to find the gaps.

I'm just wondering if there's a more elegant way to do this.

Thanks,

George

Fing gaps.zip

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

Are you a software architect?

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.

Hrmm, interesting. I didn't try the "Run as administrator" option. I expected that as a Vista aware installer it would elevate itself properly.

I am installing the LabVIEW 32 bit and the driver installers realize I have a 64 bit OS and pick the 64 bit drivers. From what I could find on the web LabVIEW x64 doesn't have any toolkits other than Vision. I need Realtime, FPGA, Advanced Signal Processing, the trace toolkits, etc. From that info, I determined that what I need to install is LabVIEW x32 on my Win 7 x64 machine. Is that an incorrect conclusion?

The signed drivers may be an issue. I'll give that a try this weekend too. I did see the installer status mention driver signing for each driver. However, since it was the installer mentioning it, I assumed that NI had signed all of their drivers.

Regardless, I'm glad to see there is proof that I should be able to install LV2009 on Win7 x64.

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?).

A true engineer would use duct tape!!!

Oh no, no, no. Masking tape is much nerdier.

Tape at all signifies an engineer. Bolt standard geeks use plasters.

True confessions: my first degree was in English, so I don't have the usual aversion to the written word that most engineers have.

First degree? How many have you got?

We're a bunch of low-paid government engineers here. And until a year or so ago we would "max out", ie work for free, after an increasingly small number of OT hours. One test I was on a sub for 7 days. After day 4, I was working for free. I remember sitting across a table in the crew's mess from two contractors (Electric Boat) who were discussing how they got paid OT 24 hours per day while they were on a sub. I told them they were buying me dinner when we finally got off the boat.

Contracting is good money, but it has a lot of downsides and work can be sporaddic. So did they?

That is a good suggestion. I did a variation on that. I re-ran the setup last night with compatibility mode Vista SP1. I chose that because I need the installer to realize it needs to install 64-bit Vista drivers. Again, I got the same failure as before.

I think I will be forced to install LabVIEW into a virtual machine in VMWare. It will take a few days but I will get VMWare running, install Win7 32 bit and then see if LabVIEW is compatible with that. If that doesn't work, then I'll install Vista in a VM. It really shouldn't be this many hoops. Win 7 is really nothing more than an optimized Vista kernel with some new UI tricks. I installed plenty of Vista drivers in Win 7 early on in Win 7 testing when native drivers were much rarer.

My gut feeling is that NI's installers are doing queries that are looking for Vista-specific identifiers rather than querying for "must be Vista or newer". There have been several articles in the Windows 7 developer blogs talking about how there are many programs and installers using poorly designed OS detection methods. On the flip side, it looks like NI is using an MSI installer which is supposed to limit the chance of this occurring.

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.

Well, actually it took me all of 5 minutes to put my own notes into a more formal format and plonk it in his lap.

Steeerike 1! Its rare that engineers have the discipline to keep documentation if the environment doesn't require it. Nice one.

I understand what you're saying. However... Throughout this thread, I've been flashing back on a design meeting that we had with one of our user groups about a year into a major project. We had released the beta version of the hardware/software and they had come back to us and told us it was missing a key feature. Something that would take a few months and lots of $$ to add at that point. This project actually did have several hundred pages of design documents, but nowhere did this feature appear. No, it wasn't our fault it had been overlooked, but it didn't matter. These users couldn't do their job without that feature. So we added it. This sort of thing happens (albeit at a much smaller level) all the time.

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).

No, you just sound like an actual engineer. My team leader goes on accasional rants about how despite all our college degrees, none of us operates as a true engineer. I just tell him to put his money where his mouth is. That may have lead to the request for the SOWs.

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?

Wow, you deliver User Manuals?!? Dang!

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.

We delivered a $2M data acquisition system a couple years ago, and then had to go begging for money to get users trained up on how to install/operate it. We had put together a training manual, but no one wanted to pay our technicians/analysts for a couple days worth of time to take the training. The culture here is for on-the-job training, which was fine for older systems that weren't very complicated. This one had been designed by a committee of several different user groups and was full of all sorts of esoteric functions. The fact that most of the hardware was bleeding edge technology and prone to needing fixing at first (talk about a configuration management nightmare), didn't help, either.

Design by committee never works. Too many cooks etc, etc. I'm quite surprised, however that training wasn't part of the deliverables

So, here we are two years later, and we're still having to go out with the system when it's deployed. I'm a system developer, not an analyst or a technician. Some of my cow-orkers love the overtime, but as long as my software is working, I personally want to spend as little time as possible on submarines (the usual test platform). We're starting design of the next generation of our system, and I am finally in a postion to influence that. User-level Documentation will be a deliverable. There will be money for training. As we always say before a new project, "This time we're going to do it right!"

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

To address a couple of the statements in your post ShaunR I consider the three components inside of the red dotted area to be the executive and the test VI represents the test called for measurement at that moment in time. There have only been a few Test VIs written at this point but they all follow a Queued State Machine architecture. The Executive and the Test VIs each have their own queues, the executive starts both queues but either the exec or test vi can add to the others queue this allows the test vi to call for information from the Master test controller about DUT or to ask the Master test controller to change the DUT cofiguration via the exec which has control of the SOAP messaging. So I think I have a similar sub-language/protocol you discss that is aparant in the supplier software.

The C# sharp layer in the diagram is actually in 2 parts the first part is C# layer that is the best way I could find to create a SOAP webservice server, but, what it does is strip out the SOAP namespaces etc and then sends it through a localhost datasocket. The second part is a LabVIEW coded server that is loosely based on the XML-RPC server in the code repository (Sincere thanks to the dev(spoke to them before)) to monitor the localhost port and package the data into a native labview format from XML and place it on the queue.

What I was originally illuding to in my earlier posts is that I think y LabVIEW server could be promoted to a similar duty as the suppliers interface layer. In the main program/vi of the executive I currently examine the received execute messages from the LabVIEW server to discover which test to load this sort of task could also be promoted to the server and could also check for tester specific information that would help me to select the correct Test VI or queue to talk to which could also work with more than one at a time.

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.

Also I would like to add that my Test VIs are hard coded tests which may make my software not strictly a Test Executive in the sequencer sence but just executes and controls the tests as more of an interface. The tests become set based on the test parameters that are sent to them ie frequencies, powers etc. Allowing them to be generic in performance and I forsee there to be a growing repository of tests available to be picked from.

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.

The only problem is that in my system it may be easier to keep the system as it is but allow it to determine a pair of tests that run together and are both controlled by a single executive. But I am unsure how this could be done. Either system would require some sort of synchronisation. Both the synchronisation and queues would have have to be network dependant (which I have seen some things to help on this forum).

Does that make sense?

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

I think I'll need to get a trampoline for the office tho, so I can thoroughly test them.

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

It's in the upgrade notes that old code will not run without a licence in future LV versions.

So unlike the Event structure which is unavailable for editing in lower LV versions but can at least be USED, the mathscript removal also disses any past work which has been done.

I don't like the way NI is going about this.

Shane.

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.