ShaunR

Nice. Now if only VIMs could do that There was a dependency on an OpenG function. I've replaced it with a native LabVIEW one. SREventXnode.zip Are you thinking about putting the xnode in the CR?

This seems to work with a standard user on Windows 7/8 but like I said. Your mileage may vary. What windows are you using?

2009. Sheesh. Its true what they say about software - you support it for life I had a query to ask if I had the 64 bit version of Diskinfo. I didn't because it was written in Delphi 7 which only had a 32 bit compiler. but I did pull out the WMI part from another of my little side projects and recreated DiskInfo (for 32 and 64 bit Windoze) . Your mileage may vary. Have fun.

And just to follow on from Rolph wise words. If you are using LabVIEW x32, you don't care about 64 bit DLLs because you can't use them and yes, you are fine working with the 32 bit DLL in 32 bit LabVIEW on a 64 bit Windows machine.. It just if you are developing DLLs that it is a. consideration because if you supply only a 32 bit DLL, people with 64 bit LabVIEW can't load the DLL in a CLFN. As to where to place them. Well. I place them where I damn well choose and always in the same directory as the application and with my own name (usually namex32.dll and namex64.dll if they have to coexist) because, well, it just save lots of hassle with DLL hell.

That's the 32 bit directory on a Win64 platform. What is the LabVIEW bitness that you created the Executable with?

LabVIEW 32 bit can only load 32 bit dlls regardless of your platform bitness - although you can't install LabVIEWx64 on Win32. You don't need two computers, you need two LabVIEW versions to compile both 32 and 64 bit executables that will then use the 32 and 64 bit dll respectively. That's why we use the conditional disable because only the end developers' (not the end users') bitness counts for when they compile the executable. Bottom line: Executables are either 64 OR 32 bit and each can only use the corresponding DLLs.of that bitness For the OP. I expect the paths are not what you're expecting them to be or you are missing some dependencies of the DLL.

Send doesn't always sit in a Top level VI that has meaning at the system level. You can send a message from much further down or higher up the hierarchy whereas Get always sits in the top level VI of a service and there is only one of that service type (you can have sub services, i.e. turtles all the way down , but we'll leave that for now - it's a semantic segregation). The VI name is always the Service Name (FILE.vi and SOUND.vi in this case) and anyone can send a message to a service even from another machine and even using non LabVIEW software (you just need some sort of TCP/UDP Service - I use a websocket one ) The sender is just a label that can be used for anything you like (filtering events and debugging usually) but by convention I use the Process Name or IP address. An important distinction is that the SENDER field does not dictate the return path!. You may notice that the SENDER for MAIN.vi is actually called "UI" rather confusingly. That is because it used to be the UI - nobody is perfect The beauty is, though, I only have to do a text search and replace (apart from with arrays, it seems) and its all fixed with no recoding/relinking at all Can a mod move this and the few previous ones to another thread, say, "VIM Demo-HAL"? so as not to pollute this thread too much? We are way off the OP now

Yes. I say that in this post but if VIMs ever get released, it would be nice if they did it so we didn't have to go through the Xnode madness or my old school way. I have demonstrated the use case with some pretty eye candy so hopefully it sticks in someones mind when/if they think about productionising VIMs After all. VIMs are Xnodes already (\resource\XMacro.xnode if you want to hack )

You mean it worked? Probably not as hard or as much work as may be thinking. There is really nothing complicated or hidden in there and its only 1.5MB excluding the wav files. The message library is only about 150K so all the code is for doing something and doing anything that manipulates the UI in LabVIEW always makes it look complicated . There is an empty place where the "Services" icons are in the Main.vi and if you look at previous images you will see a TCPIP icon that goes there. Since you got it up and running; do you want me to post the Telemetry service? Maybe this should go in another thread or the uncertified CR because it is 99% application and 1% VIM I notice this a lot with later LabVIEW versions regardless of application. It's like the compiler seems to decide that the VI really does need some more recompiling when you run it.I don't think it is specific to VIMs. Thanks. It will be interesting to see if it is the version that is the reason for the breakages and a lot of the "issues" or it is down to the object cache. If it is the latter, then the versions you supplied will also be broken. I can use the VIM on all versions on multiple machines but sometimes it breaks. If someone from NI decides to have a play maybe they can figure out a workaround Two reasons. Neither are set in stone and mainly due to my programming style. Put them outside if you wish. I would normally put both in a sub VI (look inside the get VI) so that get refnum and Generate event is a single VI, drop in replacement, for the Generate primitive. As I said before, The "Name" is preventing me from doing that and I'm still umming and arring about it because I don't like that it is not a single VI. It annoys me enough that I keep the "Name" unbundle even though I could make it a separate terminal on the "type VI" to remove it, It keeps me thinking about how to get rid of it.as it is a blight in all VIs I have to work on The whole point of my implementations is that you can put them anywhere - pretty much care free - so you can reduce wires. So they are placed where they make the diagram look cleaner (to me). Optimization is one of the last processes to be preformed in a development and arguable whether needed at all for demos.

Attached is a demo using the VIM events. It works pretty well, when it works, but the VIM technology is far from production ready as we were warned.. If you don't see any broken arrows, don't go changing anything until you've run it . You will probably find there are no icons where the VIM should be but don't let that put you off. If you have broken arrows then you will have to go around re-attaching the VIM to the events. Sometimes event names get detached, especially when you are changing the VIM. It gets very confused which instances are attached to what so you have to beat it into submission There are two demos. One is just a few of the events in while loops that exercise the event VIM - you have seen the diagram already in a previous post. The other is a fun demo that may or may not work for you out-of-the-box (make sure the sound is on ). VIM Msg Example.zip

+ and - primitives use the compound arithmetic node, IIRC. I expect you set the first terminal to invert? What do we win if we get it right?

You know you only have 1 month to revert back if you decide you don't like the upgrade, don't you?

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.