ShaunR

That's what I mean by the Channel Wires are in the wrong "View". It think also there is also a bit of imagineering going on too. Usually when we talk about cross platform we simply mean that code can run on another platform. LabVIEW is a cross platform programming language in that it runs on Windows, Linux and a whole host of other platforms. ,Cross platform compilers etc I wouldn't be surprised if cross platform just means it will be supported in the others in the same way that some property nodes are applicable in one platform but not another. I'd like to think that it is the start of a new technology that means we can control other machines just by looking at them and thinking really hard, though

It's difficult to know where to start with Windows 10. People are reporting that its background processes ARE malware

I'll answer #1, # 2 seems like a particular implementation issue. To encapsulate events, you need a way to share the reference. Since wires will not be passed, we need a way of identifying a particular event refnum and storing it where all instances of the VIM can retrieve it. Normally you could just use a normal VI or DVR with a feedback node or shift register for memory, and a case statement to make it self intialising - VIs that are not set to re-entrant are singletons. This is how LV2Globals work. VIMs are pre-allocated re-entrant, though. Even if you set the VI property to not be; it just gets ignored. So you can't use a feedback node (or shift register) as it will only exist for that instance. We want grab a single event ref wherever we plonk the VIM in whatever VI we choose. So we use a single element queue to provide a named memory storage for the event renum. We can then retrieve the event refnum by peeking, that is, reading without destroying, the refnum. We use named queues to make named events that work in re-entrant VIs because we are retrieving by name, not by instance.

Oh yes. does anyone know the frequencies and durations to play the A-Team theme tune with the Beep VI?

Yup. You've got it. I prefer to keep the generator separate because the register does some intelligent naming which could impact fast generation of events. It may be a personal preference, but I think I prefer less ambiguity between grabbing an event and generating one. I'd be shooting myself in the foot more often than not One thing that we can't get is the name from a connecting control the same way the queues and events do.An xnode would probably be able to get it but I settled on an old method of using a VI as a control and having a "name" field - a poor mans type-def.. It requires unbundling so it's not as concise but acceptably verbose, I think. I did think about putting it inside the Macro but didn't want to start making "special use" rules. This way its clear whats going on, IMO. Below is a demo use case showing one of the sybsystems (ACQUIRE) and one of its listeners (in Main UI). My architecture has queues in and events out so the Get and Send is a queue. That probably won't get replaced by a macro as it needs to be able to send a single command or an array of commands. For that, you need different diagrams and a polymorphic VI is more appropriate. So far. All the messaging, subsystems, user interfaces and project libraries are ~700 KB.

Then use SQLite. It's a file based full ACID compliant SQL database-no TCP connections, no servers, no IT, no hassle. You can abuse that instead and update the other local DB as you see fit.You could even use the same schema and just export the SQL to the other local database.

Yup. Now that's useful. If you can make it an isometric 3D view of all the VI icons that have queues, events, notifiers etc with switches to turn paths on and off. I'll be in Nirvana

I don't see how it helps. It's just another wire to trail around except it won't sequence execution like all the others do. If my subVI is truly asynchronous I can take that sub VI and put it anywhere. I can dynamically launch it. I can run it on a another computer. I just don't wire between loops - it's clutter that requires decoding. Its not to do with visualisation. It is encapsulation and breaking dependencies. I create self contained autonomous "nodes" that can be tested in isolation. Can be transplanted from project to project, Can be distributed as a single entity and can be worked on without the rest of the application. It just has the side effect that it really cleans up the diagram and makes it look much simpler than it really is. My mind is a dark and foreboding place I will describe how I see software and it may cast light on why I like LabVIEW over the others and how I currently use the VI hierarchy window and design software. Probably more than your asking for but it may help In a nutshell, I see dead people 3D systems. I don't see these systems as lines of code or flow diagrams or other abstract sensations at that level. I see them like in the hierarchy window but in 3D. More like Firefox 3D view but infinitely big. Where there are icons, I see real devices that I've used or know about. Where there are lines, I see TCPIP, Serial, broadband and satellite comms. I see mains cables, probes and sensors. I can also see the layers of that system like the layers in the Firefox 3D view, I can see cabinets full of devices and devices full of boards and boards full of software and a sometimes a rough BOM. You know when the girl in Jurassic Park turns security back on and locks the doors with the computer? That's a poor mans version of how I see systems in my head and I can envision them from scratch, from specs or discussions with a customer. At least one of those devices is usually a programmable device and that's where LabVIEW comes in. I can zoom around and in and out of that 3D hierarchy too. I can go to a particular device and inspect it. I can also switch views of that device. I can see it's UI menus and DIP switch settings. I can flip a brain-bit and view it as the wiring diagrams or as a high level schematic of subystems. I can see the exploded view of the accessories and attach them to the fascia to figure out wire routing. My thoughts are very visual and I can view it in many ways. This is also how I view the software. I see VI icons that represent the devices and the databases and all the things in the real world. I can move them around, change their menus and their dip switches-except they aren't menus or dip switches. They are configuration files and VI front panels. I flip my brain-bit to view the software wiring [vi diagram] and click on "Create SubVI" as I transition the subVI to a subsytem and the current VI to a high level schematic. Moving from the real world to LabVIEW is seamless to me. With other Languages I have to build those sub VIs and diagrams in my head and keep them there or reload them from a document/source file. LabVIEW lets me put them directly into code and leaves me free to think about the system not the memory location/pointers or other mechanics of the programming language. It gets the job done rather than being the job. So those new wires don't have a use for me. They are in the wrong "view". I always try to simplify, encapsulate and decouple the wiring diagrams in my code and part of that is reducing wire counts and breaking flow where appropriate.

This!!!!! Welcome to my world.

I think you maybe missing a trick here. (and probably over thinking the mechanics). Queues, DVRS and all that sort of thing are for moving data around. You don't want to be doing that at all unless it is really,really necessary - and it isn't. You have a local DB. If it's in memory you can lose it easily so by val, ref, DVR or globals is kind of irrelevant to that requirement.. If its on disk you can lose it, but it is much much less likely. Especially if you have an ACID compliant database. You know that. That's why you have two databases. You have a remote DB. That's good - all the managers can run their reports . You have a local DB - that's even better. That's your DB to abuse and misuse . So treat your local DB like memory storage. It's only performance that is the issue and its not much of one unless you are streaming, It's not as if it costs $ per write. Design your tables and as soon as you have a measurement, stick it in the local DB-don't store any measurement data in memory. Even configuration can be queried from the DB just before you need it. If the operator or anyone wants to see pretty pictures and numbers on screen. Query the DB and show them. It will have the effect of completely separating the acquisition/test system from the user interface. If you take a look at the SQLite API for LabVIEW it has an example of data logging (picture on the right with the sine wave). It saves data to a DB while at the same time showing the operator a plot of the data. It does it pretty fast, (about every 30ms) but you wouldn't need that performance. You'd just need more complex DB relationships and tables but the idea is the same. Data is acquired straight to the DB and never sits in arrays or shift registers or queues or DVRS or anything else.The UI queries the DB to show plot data about every 100 ms to prove it's actually doing something Use any architecture you like for your configuring of devices, keeping the operator amused and running housekeeping, it doesn't matter for the data storage. But you've already decided how your going to do that - #4, right?

You mean like the MDI Toolkit? That just uses a list and adding it to the list instantiates the window. Or is it something different?

Well. I think I've invented Named Events - my life is complete They are flakey (seems to want highlight execution on when you first start for some weird reason) . EDIT: Caused by a race condition. Hmmmm. Put thinking cap on. I'll knock up a demo at the weekend so you can play.

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?