ShaunR

Don't we already have that with shared variables?

I understand their enthusiasm. I just think its the wrong aspect view. Wires have a definite meaning in the diagram., but what would they mean in the VI hierarchy? If I could look at the VI heirarchy and see where a particular VI contained a create node and which VI that create node was sending data to. That would be like a network map. If I could select a VI in the hierarchy window that has a create event (queue,or notifier) and see all the VIs that had its event registration. I would have a map of my messaging system If I could probe the wires between VIs; I would be frothing at the mouth.

Well. I don't know anything about RT Linux itself or should I say, I don't have one, but I expect it has SSH which pretty much all Unix-like systems have. It will use public key encryption for the SSH sessions.. If it has the NI webserver then that too would be using public key encryption for SSL If they are talking about special NI technology where you give a TCPIP primitive a certificate (like the HTTP API) then it will use SSL or some propriety protocol then that is interesting. If they have integrated it transparently into network streams that would be fantastic. If its just that it it gains a new ability because its on Linux rather than VxWorks or Windows. Then that is not very interesting to me. You'd have to be more specific though. For most public key encryption, signatures and certificates; the Encryption Compendium for LabVIEW has it covered. If you want to play around with PGP, encryption then I highly recommend GPG4Win as the tool of choice. Don't give me any of your command line rubbish . Get ye over to Linux, heathen

I've never really given it much thought. UI in LabVIEW is generally atrocious - just look at the enum editor. I don't think its any worse than others, but that probably isn't saying much. I still get caught out by not being able to right click copy and paste into controls That's a big claim there. Take your favourite action engine and make an xnode to replace it. Tell me how many days it took Having looked at this a bit now, I think my Data Aware controls need to be Xcontrols (just as hard as Xnodes, but with an extra dollop of flakey) They really need the facade. I already have some (as Xcontrols) but I'm not going to release because I would have to replicate all the right click menu options manually in the code. That is just too much of an ask for something like a Treeview and pretty much rules them out for 90% of where I would want to use them. I think anywhere that needs a custom UI that does not need to inherit an existing control or function is a good use case for an Xcontrol or Xnode so we could probably agree that they could replace Express VIs. Does an express VI automagically make its diagram representation? That would be a nightmare creating the node look and operation from scratch. I haven't looked or even used them ,really, but I suspect they are the same technology too underneath. It all seems to be just different cheeks of the same face The same underlying technology with specific, in built, interfaces to make certain desirable features easier fro muggles like me. I like that approach. That's how I try to design my APIs. They may be complicated under the hood, but should be intuitive and easy to use. Raw Xnodes aren't intuitive or easy Xnodes are the potters wheel when all I want is a crappy ashtray to put my cigarette out. But VIMs and polys are super easy. They are the blue tack and scotch tape when I want to put my posters on the wall. They enhance my productivity which would plummet if they were to go or be replaced with Xnodes. <shivers> Don;t say things like that.

Polymorphic VIs are aggregators. They allow the same functional grouping as Action Engines but without the verbosity of all controls/indicators on one conpane. Or, from a different perspective, you could consider them like overrides in a class that you select by the drop down rather than wiring an object but you are not limited to the same conpane as a class is. You achieve that just by adding existing VIs to a list. In the previous image; the polymorphic "REG" above also has the "Send" in its drop down (amongst others) so all the messaging is in one VI, to all intents and purposes. These are all completely different VIs just grouped as an API. An xnode would be a poor and extremely complicated solution to realise IMO. When you only have a hammer, everything looks like a nail.

I might have wired the input then deleted the wire. The VIMs seem a bit too sticky and sometimes don't always adapt to type when specifying an output when asked to. You also need to delete and re-place them when changing the diagram. The VIM itself is really pretty much just as I described. The Queue.vi with the wire moved and the name change by aadding "m". *and changed the icon colour so I don't get confused) Yes. The raw primitives can, but as you point out, as soon as you put it in a sub VI to modularise, they become fixed. Here is a typical use case for me.The "LOCAL" VI is a self initalising reference. Whenever you call it, you get a new Event refernce linked to the LOCAL event. If an event ref doesn't exist, it will be created on the first call (there is a caveat here, but will not muddy the water for now). We are on the same page, but using different dictionaries. You can see that this will only work with this particular event. I can easily multiply up to create multiple listening processes for that event as shown below. But what happens if I want to attach to a different event? Say, a Waveform instead of a string? I can merge another, already created, event with the cluster, yes. But I can't reuse that VI like I can with the Queue. I have to make a new one! I still need to remake the "LOCAL" VI that holds the reference (and name it REG). I end up with lots of specific event VIs that have very limited reuse. It is only reusable for that particular event and as that particular event is application specific-it is only reusable within that application. With the Queue encapsulation I don't need to do that and it is reusable for different datatypes in any application. It is reusable across datatypes, VIs and projects without modification and I don't have to create an identical VI with a different queue reference. I want the same for my events. Not sure at the moment. VIMs are re-entrant and don't honour the VI re-entrancy setting in the properties. My use case relies on self intialising globals and you need singletons for that. So I might have to use some queue trickery to create "Named Events" if that's even possible .

It's not my definition. You tell me. I'm pulling you up on It doesn't! (just mean)

That's progress No one uses Mac anyway On a more serious note: I'm not sure what you mean its not recognised.

I'm saying that dataflow, in a dataflow paradigm, has a specific operational meaning and is a defined concept. It is not is just an analogy to a river flowing to aid comprehension for data being produced and consumed. I'm just picking you up on watering down (no pun intended ) the definition by conveniently ignoring state. Do "Channel Wires", "Asynchronous Wires", "Pipes", "Conduits", "Meanders", "Dunaway Dynamic Data Doorways" or whatever you want to call them implicitly impart execution state? The answer is the answer to whether they are part of a dataflow paradigm or not.

One of my long standing annoyances was not having a completely generic re-use solution for encapsulating queues and events. As much as AQ thinks my vanishing wires is a no-no, it is a necessity to me to create reusable modular code that has the benefit of being clean and easy to read. Taking the backbone of my message systems as an example, the Queue.vi, I was able to do this somewhat but had to make a decision to forgo data typing. Since my messaging is string based, I could encapsulate but had to wire a string to the input of the queue and fix the datatype - I had to wire something. This meant for rare occasions when I did not want a string, waveforms, for example, I had to type cast or flatten. (I actually wired it to the name wire, but at that time it was just so a wire didn't cross another. OCD? ) This was ugly, but acceptable for the 10% of use cases. It would have been possible to create a polymorphic VI which could work for simple types (bools, integers et. al.) but clusters, a more probable requirement, would be back to flattening. A poly would also have bloated the code base by a huge factor meaning that a simple, single VI of 16kB would have taken up an order of magnitude more space and compile time. I wasn't OK with that either. A Xnode would also have sufficed, but Xnodes where not around in those days, are an unsupported feature even now and just too damned hard - if we ignore how flakey they can be. It's hard to justify any of the other complex technologies when all use cases are covered by a single small VI with some effort by the developer just for type casting. The thing that was missing was VIM style of polymorphism that would transfer the datatype to the underlying queue primitive, transparently, without defining all permutations and combinations up front and without having a supporting entourage of VIs just to turn tricks. That would make it simpler to use. Simpler to understand and maintain modularity. It would be more elegant! And now we know about VIMs. Woohoo! And I get all that (or should I say all that disappears) just by moving a wire and adding the letter m to the VI name , No code bloat. Still 16kB. Still a single VI. Whats not to like? The one down side is that it can now produce a run-time conversion error. In the old days that would have been a problem as there were virtually no primitives that could generate run-time errors so that would have ruled out this usage. With LVPOOP, though, run-time errors have become acceptable so it is a small price to pay. This is why I'm so excited about the VIM. Finally my Queue VI doesn't need the flattening and unflattening verbosity and can relieve the user of that burden making the code even more compact and cleaner. My OCD has been satisfied I was never able to find a generic solution to events, however. They were always application specific due to the registration refnum.. Now, though, I think VIMs will enable me to do to events, what I did with queues and that makes me even more excited.

Sorry. I'm not going to let you get away with that conflation. Dataflow has a specific architectural meaning from an operational stand-point. I won't let you conflate an abstract, analogous idea of data moving with an operational paradigm through tortured wording. It's like saying by-value is the same as by-reference because they both enable passing data by-something, right?

You sort of can. If you wire a boolean to numeric primitive inside the VIM then try to wire a string, for example. . The VI will be broken with the error: "You have connected a polymorphic terminal that cannot accept this data type" So it not only adapts to type and does some intelligent type conversions, you can force terminal types with with a bit of verbosity in function use. Sort of agree except about where they sit. Xnodes and VIMs aren't competing, but VIMs are closer to polymorphic VIs, IMO, without the code replication overhead of diagrams per instance that I always point out.. If you don't need to adapt to type for different companes, then these are the tool of choice to give adapt to type with a single diagram, single point of maintenance and no VI bloat or replication.

Lol. That's hoping a bit (from me ;P ) , If you'd put the wire in the hierarchy window, I'd be all over it So that's an admission that its a solution looking for a problem as I surmised?

What I actually said was breaking dataflow is a consequence, not a weakness. The issue I have with this is that wires have always been the method to be able to sequence execution. Its how data flows in LabVIEW and is very intuitive as an analogy! We have always been taught that we should use them instead of sequence structures and wire error clusters to make execution order unambiguous and repeatable. Well. This type of wire doesn't do any of that and if you think it does you are in a whole world of hurt. I can guarantee that people will expect it to though, especially when single stepping or highlight execution debugging etc. I also said. I'm willing to be convinced. When we do break dataflow it would be helpful to know where data pops out but why not do something with existing asynchronous methods like events? So. Show me the killer app. Lets see how easy it makes understanding the Actor Framework. Lets upgrade some existing software to use this technology so we can compare the benefits directly. Is it just a fancy global variable with a confusing wire type or is it like buffered TCPIP endpoints?

Holy crap in a cabbage!......Have 500 likes (compressed into one) To celebrate, you can all have data aware controls in the next release of the SQLite API for LabVIEW because I couldn't be bothered with xnodes.but this should work.

I chose 1 & 3. I thought that covered the most basic requirements with an offload of decision in strategy to the person who knows more. There is no need to flush a queue if you destroy it and my little queue wrapper means you can just crowbar queues and they get reconstituted if it really was being used. (effectively just clearing it) You will find the lossy/normal and limit choice in the Dispatcher and the queue size transmitted to the Dispatcher so the status could be monitored for each producer to assist the strategy decision (#1) . I never got around to a heartbeat or pinging and fail-over/retrying which was the next on my list (#3) before I got sidetracked by Websockets.. I wouldn't be too concerned about complexity of the API as such. As long as it is a simple interface. Things like heartbeats, pings, bandwidth management and fail-over etc can all be switchable features and completely transparent. Many of those don't make sense if your not traversing the network boundary but your design isn't limited to local processes Can't wait to see where you go with this.

OK. So what if a subscriber doesn't unregister but fails to service its queue? Both our systems are reliant on the registration being valid , up to date and the subscriber consuming otherwise messages start piling up. In mine, I have the TCPIP refnum that acts as a notifier for remote subscribers disappearing but locally I have the same problem as I bypass the TCPIP and place directly on subscribers queues like you do. What is your strategy here?

This is something the hierarchy diagram (HD) has needed for a while. The HD could be so much more useful for navigating the architecture - an interface like the Firefox 3D view. It would mean I wouldn't have to visualise the bipyramidal architectures in my head (the flat diamond is all you can see) and give real insight into multi-level state machines. Double click and open a VI diagram.....it'd be great.

I like this idea. Encryption is demonstrably faster on 64 bit machines than 32. SQLite performance is very disk dependent. There was a benchmark from NI to demonstrate VI call overhead to compare inline, re-entrant and normal which is extremely insightful (not sure where I saw it). There;s the disk performance comparison tests from NI used for benchmarking our SSDs. You've already mentioned Fourier. Sort algorithms are good for assessing computation capability. There used to be an issue with 64 bit labview when allocating memory so something to assess array performance could be used as a proxy for memory efficiency. During investigating the Ring buffer we bench-marked queues and while loops and stuff. Has to be lots around here for you to pull out and formalise into a test suite.

OK. So let me clarify some points here. There is a "distributor" which is launched dynamically and acts as the dealer to deal out the messages to a number of "registered" subscribers to that producer. So when you "create" you launch a distributor. The distributor is a permanent consumer for the producer (i.e. it prevents queue fill-up when no subscribers). It also is the "dealer" to multiply messages by copying a message to each subscriber's incoming queue, if and when they appear. So you have a Distributor per publisher that deals messages on a per publisher basis to subscribers. If I'm close in understanding; it might be worth looking at Dispatcher as it sounds like this is an almost identical philosophy where I call the "distributor" a "handler"

Leaving aside "what a wire means" in LabVIEW for now. There are two points I would raise here. If data flow isn't followed. That's not a weakness. That is a consequence of breaking dataflow in a dataflow language.LabVIEW is inherently concurrent and has implicit sequencing but go ahead and use your GO4 templated framework - just don;t come crying to me about needing extra language semantics to get synchronization back again for an architecture where you've specifically chosen to remove what the language gave you. I spend a lot of my time writing little bits of code to remove wires. I remove them for three reasons. 1) Modularity-I can just plonk the VI on any number of diagrams and it will just work (get rid of init, do something, deinit). 2) Break dataflow - Encapsulate events, for example, into an API where each call is atomic and refnum free. 3) Diagram readability-More of a side effect. I feel the example they show is rather contrived. Most of the time I would use such a system in different VIs because of 1&2 Generally I want to share data between processes, not individual while loops. Then the whole idea showing where the data comes from with a wire becomes moot and it is no different to what I usually use.....except more complex to create,, it seems. That said. I haven't played fully yet. So I am open to being convinced with a killer application of them.

Woah, there pardner. Apart from giving you many ways to confuse and shoot yourself and others in the foot. What problem do these "asynchronous wires" solve, exactly? At first glance, it looks to me like a solution looking for a problem.

FTFY

This is desirable in my apps too. I created a queue wrapper (umpteen years ago) that ensures there is always exactly one of any queue and is created when any queue function is called thereby removing the Init, Do Something. Destroy overhead and memory runaway from creating refs. Destroying the queue merely has the effect of clearing the queue which is reconstituted on the next call, Queue.vi

I gave you closure; move on. The List is here by the way.