ShaunR

+1 for hate large terminals-waste of space.

Off the top of my head.... P/S : Single server to many clients, Single clients to many servers. (An example of Many to Many). P/C: Single server to single client (An example of 1-1) M/C: Single Server to many clients , Single clients to single Server (An example of 1-Many). Aggregator:Many servers to Single client, Single client to single server (An example of Many - 1) The list goes on but are variations on something to something and these too can also be broken down further. That's my understanding at least. (Oxygen is starting to get a bit thin up here )

Actually. thinking more (briefly). That is not a requirement of a Master/Slave. It is more an implementation of the example.In the same way that Pub/Sub is a subset of client/server, so is M/S and P/C. The differences are in the way that they realise the client/server relationship.

That's because we generally use the event structure to achieve this.

Producer/consumer is 1-1 master slave is 1-many. Also a producer/consumer is loss-less, master,/slave isn't.

Just because you use a class, doesn't make your program an object oriented design any more than passing a value from one function to another makes it dataflow.

The framing has also changed http://updates.html5rocks.com/2011/08/What-s-different-in-the-new-WebSocket-protocol

And you've also fallen foul of (reintroduced) the "close" property node being wired. An error on the wire means the dialog will not close (notice in Mje's example it is not wired)

A simpler (and proven) solution is to use the XPe box as a host for the USB devices and connect to it using the network interface.

If you are not using POOP (Predominantly Object Oriented Programming) then a lot of the POOP design patterns are no longer relevant since the problem that they solve becomes trivial and most of the mechanics gets handled by the language (yes I'm looking at you "singleton"). With POOP, the problem is usually "State", transitions of state and how to manage it. That's not to say that there aren't any in non-OOP languages, They are just usually called "frameworks" and tend to be more generic. The thing to bear in mind is that design patterns solve a well known problem. But that problem is usually a restriction in the language or paradigm you are using (sometimes called "Idioms" by the Architecture Astronauts). Therefore design patterns tend to be paradigm/language specific (not all...but most). But you have probably been using non-OOP design patterns for quite some time (State Machines, Producer/consumer, Publisher/Subscriber) Take Monads for example (a functional programming design pattern) Sound like VI's and terminals? We (as Labview programmers) have no need for this "pattern" because it is an in-built feature of the language (we chain VIs [monads] together using wires [pipelines] via their terminals [bind/return operators]). A good example of a design "Pattern" that IS useful in Labview is the Producer/Consumer (we all know that one - it's a template in Labview). Why? Because it addresses a restriction of the language (it breaks Dataflow). Most of the time dataflow is our friend (it automagically handles state and imposes strict sequencing in a parallel manner) but when we need asynchronous operations this is a simple generic pattern in our arsenal. So what POOP patterns are useful to us in "classic" labview? As a general rule -.those that break dataflow! So we have a use for things like the "Observer Pattern" or, as we muggles call it, "Publisher/Subscriber". But we also have uses for the more structural patterns such as Strategy (think plugins), State (think state machine) and Facade (think API). although these could arguably be called "idioms" for classical Labview usage. And those that aren't very useful? Well. Most of them Labview itself makes most of the issues associated with POOP patterns fairly trivial. Many are variations on a theme (Mediator and Facade for example). Many revolve around instantiating objects - Creational patterns (we generally define all objects at design time). And many are based around managing communications between objects - Behavioral patterns, (we have wires for that). Why aren't there many references to design patterns outside of POOP? Because they generally solve problems caused by POOP. Now where's my hard-hat.

There is.It also activates all the tool-kits and addons.

So does that mean that comms primitives (TCPIP, Serial, Bluetooth etc) are all going to be changed to arrays of U8? Strings/data....it's symantics. If it's not broke...don't fix it.

I never said it was. I was simply pointing out that NI wouldn't "cry" over a password protection hack and that since the licensing has been compromised; they would be more concerned about that-if at all

I know nothing about Ruby...and probably never will. But I would imagine the test tools for it are aimed at that environment in the same way as they are in Labview and (probably) not compatible. If you want to manage your tests in Ruby. Write the tests in Ruby! Whats the point of mixing and matching technologies and the headaches associated with getting them to play nicely (activeX springs to mind). Agile development is language agnostic. It is also discipline independent since it is a group of project management methodologies. So the answer to how do you implement it in Labview is "the same way you would for anything else". I personally use M$ Project and. at a push, will use Excel - it's not really important. The key point is for some of your incremental release gates (cycle results) to coincide with major milestones on a more encompassing, linear plan (since that is what the upper echelons of management prefer).

Nope, It affects the users more than NI. Ni are probably more worried that their whole licensing scheme has been compromised since 2009.

If it is..... I would choose No3. Each module is configurable to do No1 or No2 to it's immediate owner.

The year that it all went wrong

You are changing the requirements now

Or-ing "THE" =0.

Just OR the =0 with the stop and it will work without an extra occurrence and without a timeout..It is a sequencing issue rather than a race condition-as with AQs version.

I stand correct4ed (when did they add that then?) IMHO this is how the other primitives should behave (and that includes diagram, project and control refs). I've lost count of the number of times I have had to correct others' code because the refs aren't closed. It is these primitives that are counter and intuitive rather than the occurrence. Oh for the days when Labview meant you didn't have to worry about memory leaks. Seems to me that they work similarly to a notifier (since they have a timeout) without the pit-fall of memory leaks.

Because the local variable will be evaluated well before the first loop reaches the large number and will present a FALSE to the stop terminal. Everything (in the second loop) then waits for the occurance. Once Loop 1 actually fires; loop 2 then proceeds with the FALSE, goes around again and then waits, once more, on the occurance-which never arrives since the first loop has already terminated. This is why no-one uses them. Its too easy to get race conditions that hang your app because they don't have a time-out. It will work correctly IF you put the occurance and the local into a sequence structure that guarantees the local is read AFTER the occurance (another reason no-one uses them since they don't have error terminals and forces you to use those pesky sequence structures.)

That won't work.

I just set the block diagram background colour in the preferences. I use a different colour for each LV version so I'm aware of what version I'm in. I also use it as a "completion" indicator". I start out with all the diagram in a colour and set cases, frames etc it back to white once that frame/module or whatever is completed. That way I (or my colleagues) can see at a glance where I need to do some more work. Yes. It sticks with the vi.