ShaunR

Indeed. You would find it much easier with a "dispatcher" so you could have asynchronous to the UI and synchronous to the device.

Well. If it doesn't show up in those two then, by elimination, you know it must be the third one. Which toolkit is it? The NI one isn't password protected.

Nothing specifically. It's not a technique I have much of a use for so my "instinct" is probably biased to that end. But realistically, it could be anywhere. Not sure how easy it is with your code, but what I quite often do is just put indicators on each of the message input queue to collect them in arrays. Then when you have a few, change it to a control, save as default, and just play them back over and over again with a while loop in the module.

My first instinct is that it is probably the "dynamic registration". You seem to have fairly well partitioned application (into 3 parts). I would suggest making 3 separate exes with each of the parts and see which one (if any) the leak occurs in. That may narrow it down a bit. I'm afraid however, without any code. for us It's like trying to swat a fly blindfolded.

Couldn't have said it better myself Applications that I work on are typically in the region of 5,000-10,000 VIs (no classes generally, but a couple have crept in now and again) . Compile times are at most 1 hr and the IDE only slows down on xnodes (like regex). I think if I were to do the same in classes, then you can quadruple the number of VIs and compile times (Anecdotally, compile time "seems" a fairly linear correlation to the number of VIs). Large applications? Yup. Machine control is about as large as it gets.

Send me the LabVIEW source and I'll propose something <crusade starts here> Since, by our own admissions, we are both guessing as to what and how LabVIEW does what it does. It's a bit fruitless to put forward solutions and, to be frank, it's not our issue. All we can do is put forward "requirements" and let NI find the solutions-such is the nature of closed source!. Very difficult is not an excuse not to do something though. IF this was enabled by whatever means was required it would (I think) open up a whole host of other events that the event structure could handle and maybe we could get the overhaul that events have been crying out for for several years. Wouldn't it be lovely.to have OnLoad, OnLoaded, OnUnload, OnPanelOpen, OnBringToFront et. al that all the other languages have? Or how about VISA events that can be wired directly to the event structure for proper event driven comms <crusade ends here> Indeed. There are lots of functions that have the proviso that it runs in the UI thread, not in run-time or loads panel into memory. If it is stated in the help what the limitations are, then it is up to the developer whether to utilise it or not.

User events aren't processed in the UI thread so the event case structure is capable of processing events without this limitation. I'm not sure where the "Open VI Ref" comes into it since the callback (event) would be internally generated by the LVRT and would appear as one of the default cases under <Application>. If the run-time uses the Open VI Ref internally when loading a hierarchy from disc (I high highly doubt it) then this would be moot anyway since it would mean the whole load process is already in the UI thread.

All you need is an "onVILoad" event that can be hooked (callback or maybe the event structure). Granted. LV may not know how many vis there are in the hierarchy before it begins. But it will be a fixed number that the developer can type in once he has stuck a counter on it.

All software is "prototype" until at least 20 people have complained about it

Neither is mine. But it goes much faster and is easier to control than an Audi with a caravan on the back

Having a "senior" moment?

You may regret saying that

It's much more fun discovering the passwords than removing them. You find out what the NI techs' favourite TV shows are and which expat bands they like

That could be overcome with a bitmask check.

Indeed. But that is more to do with recovery than isolation. All machines (production included) that we spec nowadays are raid (invariably Raid 10 depending on chassis) and that's irrespective of the topology. Hard drives are cheap! Getting production to check stuff is really a maintenance issue. The only way it can be practically resolved is with training and procedures. I work closely with customers' maintenance departments and supply checklists and procedures along with [preventative] maintenance schedules. This however is insufficient and unless entries into maintenance logs are a requirement - always skipped. A maintenance log is the first port of call and the second is shift "handover" procedures (the latter usually being a mixture of hardware and software checklists). But unless you get someone to sign or initial something (make them feel responsibility for the equipment) then you are on a hiding to nothing.

Yup. this is the "dirty" PC that I mentioned. The goal is to provide isolation (or gateway as you put it) where you can limit exposure and run all your virus and malware scanners et al. In the past, I have set up servers using two PCs. One that the production line stores and gets it's configuration from (SPC database) and a mirrored one for access from the offices (a read-only copy, if you like). This means that changes can only be made on the configuration machine, but anyone (who needs it) has access to the data (usually via a web interface and a web API). Periodically, each will scan the other (and sometimes the production machines dependent on the topology) for viruses , malware and any anomalies as well as their own drive. If something does get on either machine, there is an intrinsic back-up of the data and a high probability that at least one of the machines will detect it. Additionally (although nothing to do with virii), if one machine goes down, you have a ready replacement that you can just hook up in minutes whilst you wait for a new one to arrive (I have also managed to automate this with alerts to the admins, telling them of the fact, meaning seamless transition - 0 downtime). The hard part is getting them to order the new PC since it all still works....lol.

Being a programmer that mainly deals with automation machines (some of which could take limbs off) I have always been aware that if my software wasn't working perfectly, or, if some malicious person fiddled with the code. The effects could have extreme consequences both in terms of injury and hardware failure. So it was no surprise to me when I read How Digital Detectives Deciphered Stuxnet. Since LabVIEW is extremely hardware oriented and specifically targeted at the sorts of applications that Stuxnet and the later Flamer could target. I thought I would post some of my thoughts. Writing automation systems has made me a bit of an amateur virus enthusiast, not least because if a virus gets onto a machine; I'm the one that has to sort it out. As I have considered the scenarios over the years it, I have done what I can with my limited knowledge to make it as difficult as possible for a virus to get onto a machine and, if it does, that it does limit it ability to spread to others. We all know that Windows is a hot target for any "script kiddie" and, whilst not a silver bullet and certainly not protection form the most determined malicious user. The items below are simple to achieve and go some way to making it more difficult for accidental infection and limit the scope of the propagation. Turn off "Autoplay" - The easiest way to for a virus to propagate via USB. Enable Extensions to be visible - It won't stop a virus, but it may prevent someone (including yourself) from clicking on one. Change the "*.vbs" extension from "Open" to "Edit" - Make the default action for visual basic scripts open in a text editor rather than run. Most "script kiddies" rely on this and the extension hiding to trick the user into executing malicious code.. Place USB ports and CD drives behind "Locked" panels - Use USB ports that are at the rear, not exposed and that are internal to the cabinet of the machine and disconnect those on the front at the motherboard. Only allow USB/CD access to "trusted" and knowledgeable staff and use USB drives specifically set aside for the machines (one per machine). Insist they must be scanned before use (use the maintenance log!). Boot into your program as the shell - This will remove all the tools that people are generally used to when dealing with windows (like the task bar) and only enable the access you program into the software. If you also disable "CTRL+ALT+DEL", not even explorer will be available (if they know how to get to it without the explorer shell). Run your software under a User account and not under an Administrative account - Once installed and operational, your software should not require admin privileges to operate (as a design goal). Use a User (or if you can-a guest) account and specifically grant privileges that your software requires. Auto-login to this account. Take a "Disk Image" of the vanilla install of the machine when the machine is isolated from others. Aside from backup, this is a convenient way of completely removing a virus once infected. Make sure you don't have a virus first! Run the machines off of a separate, isolated network - Connect the machines on their own network with their own routers. If a virus gets onto your systems, or, if the IT dept gets a virus (more probable), then the other network will not be affected. If access must be provided to the office infrastructure, use FTP access (preferable) or dedicate a "dirty" machine (not one of the production machines) to act as a sentry. Don't let the office IT dept anywhere near the machines. - From experience, most IT departments will not support the machines but they will still insist on pushing a load of corporate profiles and updates that may bring the system to halt (there have been a couple of exceptions, but the vast majority won't have anything to do with something they neither have the knowledge for or control over). Most network propagated virii are introduced via the office networks and usually IT just shrug their shoulders and leave you to sort it out with one hand tied behind you back due to their security policies. Production machines going down due to a virus actually cost money and a lot of it. So submitting a help ticket that they might get round to eventually is not an option. It is far better just to close off that attack vector and not involve them at all (if you can. ) I view virus scanners as the last line of defense and, for some machines, a scanner cannot be installed.Therefore, these are a few of the simpler things I routinely implement. So how do you try to mitigate malicious code?

Not so much loading FPs into memory but definitely running in the UI thread, reference

I use string messaging for passing data between UI and action loops/VIs. The command channel is usually a queue and updates are via events. Basic setup is that the UI only handles operator input and control updates (usually only control name and data). As in your case, those strings then get passed to either another loop in the same VI or, more often than not, a dynamically launched "controller". (strings will typically be of the form "VIName->ControlName->Command->ControlData") This is straight forward for most controls, but the tree view is a bit of an anomaly. To get round the property nodes being required to manipulate the control, I flatten the controls reference as part of the data payload The controller knows how to interpret this payload, retrieves the reference and updates the control according to the command. For treeview type controls this often means that those controls have a controller loop/vi in the top level VI specifically for them since I generally consider the Top level VI to be only for UI interaction and it separates other processes that can be run (as I previously said-dynamically) without forcing the front panels into memory or risking them being run in the UI thread. Since I consider the top level VI to be for UI. Why bother with a separate controller loop/VI. The reason is that you can also run a TCPIP process and, using exactly the same string commands, control it remotely.

Sweet. My apologies. I always call them "Call Library Nodes" through laziness. Perhaps you might have got there quicker if I had used the correct acronym - CLFN). A "Like" point will be more than sufficient

I've always found the TCPIP to be rock solid (at least as far as crashes). Look for CLNs.

Many thanks to all of you that tested on the Mac. Seems to work fine on i386 with 10.5 and up (PPC was dropped by Apple a while ago and will not be supported) . A new version of the SQLite API For LabVIEW with Mac support will be released in the next week or so for those who are interested.

Sounds like a library call problem. All later labview versions are extremely non-resilient to pointer failures. The fact that it works fine on x32 but not x64 kind of points to an invalid pointer being passed (usually passing a fixed size pointer rather than a pointer-sized). I don't know what the GDS is, but are there an CLNS in the code?

Hmmm. I'm not sure what you have in mind (need to see the diagram I guess). The serializable just has a time (in whatever base format you like-integer, double, etc.....but something useful since that will be the default) it's just of "type" string. The "formatter" is still the modifier from this base format. The default serialize is obviously whatever you decide is the base. But that can be overridden by the formatter to produce any format you like.