Onno

Hi Jean, You've hit into one of the things that also puzzled me at first with the AF Attached, you'll find a "fixed" version of your project. Let me explain what's going on here. What's crucially important in your understanding of the Actor Framework, is that LabVIEW objects are by-value, not by-reference (see the NI Whitepaper on LVOOP). So every class wire in your Block Diagrams has class private data clusters flowing through them, following the same data-flow rules that would apply to other wires. Let's have a look at the Actor Core.vi of your Secondary actor: The private data cluster of Secondary.lvclass comes in at the "Secondary in" terminal (top-left), but the wire splits in two branches. The branch labeled [1] goes off into the base class' Actor core, which contains an 'infinite' while loop that processes all incoming messages, and calls the "Do.vi" methods of your message classes. The branch labeled [2] goes into your parallel While loop. So, effectively, the above VI looks like this: What happens if your Secondary actor receives the Write my String message? Well, all this message processing takes place in the bottom While loop! Whatever happens to Secondary's private data cluster there, will stay within that bottom While loop, due to the way data flow works. The "my String" update will never reach the upper loop. All this means that getting data updates from your messages to your Actor Core's front panel is a very fundemantal 'problem' in the Actor Framework. The only way to solve this problem, is to somehow work with references to data, instead. There's two ways to do this: Use a Data Value Reference (DVR). Add a DVR to your actor's private data cluster, and use this DVR to communicate data between the upper while loop and the message processing VIs. (As a sidenote, you should be aware, if not already, that continuously updating your Front Panel like you did in your example project, is not very efficient). Use control refnums to your Front Panel controls and indicators, and store those refnums in the actor's private data cluster before the class wire branches off into [1] and [2]. You can then update Front Panel controls elsewhere in the code, whenever necessary. Strategy 2 is the one I've chosen in the attached sample, and also the one I've been using in my real-world AF project. It's a bit cumbersome, but works very well. I hope this clears a few things up! Best, Onno (Actor Message Learning_fixed.zip)

Getting the same error here (LabVIEW 12.0f1 32-bit). The project looks very interesting though!

Removing the "*.*" option will not remove the user's ability to show all files, and execute potentially unsafe programs. Just try entering "*" in any file dialog, and you'll all the files, no matter what the currently selected filter is. What you really want, is a way to lock down program execution on Windows. That is actually possible. It seems to be called Software Restriction Policy (SRP). Read about it on, for example, MS Technet.

Thanks so much for recording these, and making them available!

I've been playing around with Mercurial briefly, but went back to TortoiseSVN, both for reasons of stability and convenience. Especially getting Diff/Merge to work nicely with TortoiseHg was a major pain (not unsolvable — see other posts on LavaG — but too much of a hassle in my opinion). Not sure about TortoiseGit though. By the way: would there be any specific reasons to prefer a DSCC over SVN? Those SCCs seem to rely (*) quite heavily on merging, which is still a rather messy job with LabVIEW anyway. (Given the binary file format, custom diff/merge tools, and LV's propensity to modify files at will). (*) Maybe "rely" is not the best word to use here, but they do treat branching/merging as much more of a first-class citizen than SVN — which, for me, would be the most important reason to switch, I guess.

XML and JSON are probably much better options for inter-language communication. Not in the least because that's the way people have solved this problem before. XML is of course well-supported, but I'm not sure about JSON. There's a Labview-JSON library, but that only works for encoding JSON, not for decoding it.

Please, no! I guess something is to be said for removing visual clutter, but they've taken the minimalism way too far in the latest Visual Studio. And, as far as I know, putting things in all-caps is a well-known usability no-no. Besides, if NI decides to spend time on improving the IDE's user interface, I think there's other ideas that would have a much more pronounced effect on usability. And, on-topic: I'm fairly sure the new toolbar was introduced with LV 2011. I personally like it a lot, it looks much fresher!

Haha, maybe I'm lurking too much But I'm doing my best to chime in where it seems useful! I couldn't agree more. But it's not my project, and I don't get to decide anything... But I'll definitely do my best to get that message across! What a coincidence I might just happen to, by pure chance, pass on your contact info, but it's going to take another month until the guy in charge of the project is back here. So don't hold your breath

Thank you, all, for the advice; it's very helpful! An especially warm "thank you" to you, crelf, for the extensive post I'd never have thought of the cFP/cRIO systems, since I have absolutely nil experience with them. But yes, come to think of it, it makes a lot of sense. The guy in charge of the project should be back from holiday by the end of August, so I'll discuss it with him then. But as far as I'm concerned, I'd definitely consider bringing in some external assistance. Just not sure if the research budget would allow for it! If I end up getting involved in this, I'll post back some time in the future with my experiences!

Hi all, Here at my university, someone asked me for advice on how to build a process control VI for a scientific experiment. What he described seemed like a stereotypical LabVIEW application: the computer has to control a couple of pumps and switches, and apply some basic PID control to keep, for example, the pH (acidity) of a solution constant. All was well, until he added that this experiment has to run for at least a year; any interruption of a few seconds in the process control would mess up the experiment. Oops. So, it seems this should be a high-reliability LabVIEW application — something on a scale with which I don't have any experience. So I'd like to ask you for some advice: how to handle this? Any experiences you'd like to share? A few things that seem obvious: disconnect the controlling PCs from the network; disable Windows Updates (but that follows from the previous point, really); have two PCs, and implement some sort of failover mechanism (but how?); get a UPS, or maybe even a backup generator; test extensively, by simulating all sorts of failure scenarios (any tips here?); extensive logging and monitoring. [*]Anything else? [*]Do you know about any good whitepapers or examples? (I have tried Googling around, but haven't been able to come up with much useful information). [*]Or should we ditch the idea of building this ourselves, and get some professionals to look at it? Any pointers would be very welcome; thanks a lot in advance! Best, Onno

It's going to be really hard to help you out without seeing the code, I'm afraid. (Or maybe it's just me, and someone else is able to give some advice here?) Do you think you could create a small example project that demonstrates the problem, and post it here?

Ah, of course, that's completely clear. Thanks!

Thanks, Daklu, for the interesting post! I really enjoyed reading about your problem & solution — same goes for AQ's response. About the latter, I have a small follow-up question: Could you maybe elaborate on that? Why would polling the future's state every once in a while be such a Bad Thing? In my view, you're just pointing out a very fundamental problem of retrieving information from a parallel process, one that has nothing to do with futures in particular. It's the problem of having to wait for the requested info to come back, without locking up. That problem is universal to all approaches, right? Be it async messages, synchronous messages or futures. So I'm a bit confused: what's especially bad about this use of Futures? Thanks a lot Onno

The LabVIEW community has a large number of incredibly useful tools (RCF, QuickDrop extensions, OpenG), but they're rather spread-out, difficult to find for newcomers, and not always very well mainainted. Over the past year or so, I've slowly accumulated a collection of these tools, but it'd be really difficult to explain to a new colleague where I found them all As such, some sort of "official community patch" sounds appealing: it'd make it way easier for relatively new developers to "upgrade their LabVIEW experience" (hm, that sounds cheesy). And I guess those people would be the main audience for such a patch? (Since most of the people in this topic already have their own sophisticated customizations, presumably). I do wonder about the technical difficulties, though, given the already mentioned "different workflows for different developers", and the non-trivialities of maintaining a modularized LabVIEW installation. VIPM may be a perfect implementation of a "community patch" — but that would also mean that more of the already available tools and libraries would need to be packaged. With important parts of VIPM's functionality being reserved for commercial users (esp. the creation of VIPCs), this might be an obstacle. Nevertheless, I would be interested in seeing how this develops! (If I could help, I would!)

Having worked with LabVIEW for a few years now, it seems to me that such dynamic user interfaces are simply nigh-impossible in LabVIEW. The way the front panel / terminal / block diagram system has been designed has some strong advantages, but dynamic control instantiation seems to be fundamentally incompatible with this paradigm. If you really think this type of UI is useful, you should consider using a different tool — .NET for example. There's plenty of extensive libraries for this sort of thing in the .NET world. You really don't want to solve the intricate usability issues of docking/undocking etc. yourself, if you don't have to On the other hand: does the UI you have in mind really solve concrete user problems? My experience thus far tells me that often a well-designed, static UI trumps an overly-configurable, dynamic UI. Especially for "your average user" (whatever that may be), too much configurability makes an application harder to use. For a good example on this, read the interesting story of how the Microsoft Office Ribbon UI was conceived. There's a reason Microsoft turned its back on the mess of floating toolbars, dynamic menus and over-configurability that was MS Office 2000-2003. (Even though, personally, I quite liked it!) One additional tip, to make this downer-of-a-reply a bit more useful: you can look into LabVIEW OOP (Object Oriented Programming), and the Actor Framework, to see some examples of how you can make a UI more 'customizable' — by, for example, making multiple versions of the same UI, and decouple those UIs from the underlying actual program. Let me know if I'm being too vague here, or if you'd like some more concrete pointers. Best regards, Onno

Thanks a lot for all your replies! I'm currently distributing the application as source code, since that seems to be the easiest. I spent a lot of time getting the executable version to work, but kept hitting snags here and there (especially with the application's LVOOP-based plugin system; but that would be food for a different forum topic). Unless I'm overlooking major advantages of an executable, I'll probably go with a source distribution for now. Hm, I considered that. I'll have another look at it, thanks! (Side note: it might also help me with properly integrating my application into the LabVIEW directory structure — so far, I've avoided dealing with all the 'user.lib' folders, pallettes, etc., and just put everything in one .lvproj and a clear directory structure). Ah, I'm afraid I wasn't clear. People only ever use "tagged" versions/releasese, which are guaranteed to be working; they should never check out the trunk, for exactly the reason you mention. That's a great idea, Ton. I'd love to switch to a DVCS, but that'd also mean re-building an infrastructure I have already invested quite some time in. But I should try this in the near future! You seem to have good experiences with it? Thanks so much, Xavier, for sharing your experiences. Given the relative homogeneity of the environments I'm targeting, I might actually end up choosing a route similar to yours. But I'll first give the VIPM a try, see if that's a better option for me now.

Hi! I'm currently pondering a way to distribute and version a software package that's used within my scientific research group for data acquisition and instrument control. I'm considering Subversion as a solution, but the idea seems a bit weird. So I was wondering if someone here would have some feedback on this? Or pointers to other, better ways to solve the issue? The issue: Basic versioning: the application should know its own version (for display in an About dialog, etc.) Update notifications: the application should alert users if they're using an outdated version. (It happens quite a lot that people are using outdated versions without realizing it). Easy installation/upgrade. (The only installation step is extracting a directory tree with VIs, really, so I don't really need a sophisticated installer, per se). Now it seemed to me that having everything as a SVN working copy makes it all easy: Installing? Just do a checkout. Current version? Just check the URL of the working copy. (If it's, e.g., svn://url/to/repo/my-project/tags/1.2.0, it's version 1.2.0). Update notifications? Just do an "svn list svn://url/to/repo/my-project/tags" to list all the tags, and compare the highest one with the current version. You can easily check for local modifications to the source, as well (just do an "svn status"). Upgrading is as easy as doing an "svn switch" or an "svn update". What do you think? Silly idea, or good solution? Thanks a lot for your thoughts on this!

Hm, haven't tried that yet. But doesn't that lead to other typedef issues? That's a good point. Maybe I should try being extra careful when making such changes, and make sure all my VIs are in memory somehow. Thanks!

Hi! Thanks a lot for posting this! This is going to be extremely useful for a project I'm working on right now... I'm not sure about the experiences of other people here, but I keep running into this nagging issue in LabVIEW (2009/2010/2010 SP1). I'm using strictly typed enums for controlling a whole bunch of state machines in my project. Quite regularly, LabVIEW resets enum values all over my project. This of course leads to all sorts of nasty bugs. I was first able to track this down to certain types of modifications I would make to the enum value list in the typedef; LabVIEW would get confused, and then reset all enums of that type in the project. However, I've also seen cases where there's no clear reason for this global enum reset, or where LabVIEW would only perform this reset in some locations. I was actually considering to give up on the enums, and switch to Strings; but I'm wary of performance issues that might arise in some tight loops. In any case, this tool may well help to keep all enums in control. Thanks again!

It sounds like your LV application is not running with Administrator permissions. Since Windows Vista, access to certain disk folders, as well as a few registry keys (including HKEY_LOCAL_MACHINE), has been restricted to improve security. If your LV application is compiled into an EXE, try right-clicking on the EXE file in Explorer and selecting "Run as Administrator". Otherwise, I think you'll have to do that with LabVIEW itself, and run your application in this copy of LabVIEW runnign with Administrator permissions. I hope this helps! (See also Wikipedia's "User Account Control" topic)

Ah, of course, you're right. Thanks a lot for the correction! In that case, I'm also very curious...

Isn't the LV 8.6 one prone to a race condition? (Imagine two VIs trying those queue operations at the same time; if the timing is unfortunate, the two would interfere). I believe that the in-place element structure (IPES?) has an internal semaphore mechanism to prevent such race conditions.

Thanks so much for the insightful, inspiring write-up! Plenty of food for thought, I'd say I rather like the idea of wrapping messages with method VIs, to ensure data validity. It does seem a bit cumbersome, but I guess that it may well be a lifesaver in bigger projects. I'll have to consider it... One small question: what's the data type of your queues?

Well, er... It seems I cannot reproduce this error — not even in the original project. I guess LabVIEW was fried when I tried this last Friday. I'll remember for next time that I'll first restart my computer before posting something like this My apologies to Aristos! Anyway, this means that my problem is more or less solved now: I can put my plugins in separate projects. As a sidenode: the trick for only getting a dependency on "Plugin Interface.lvclass", without adding the file itself to the Plugin project, is the following: Add "Plugin Interface.lvclass" from the Main project to the Plugin project, by "adding an existing file" in the Project Explorer. "Plugin Interface.lvclass" will now be in both Main and Plugin. Create your descendant class. (This is not possible if you haven't done step 1, as you can only choose parent classes that are part of the current project). Now remove the "Plugin Interface.lvclass" from the Plugin project again. LV will automatically add "Plugin Interface.lvclass" to the Plugin project's dependencies. Done!

Good question actually. My thought was that I'd rather not have people add their plugin code to the Main project. There will likely be quite a few plugins floating around in the group, and I don't want code changes in those plugins to affect the main project. Does that make any sense? The workflow I had envisioned, would go like this: someone checks out the Main project from source control. He then creates a separate project for his plugin (based on a template). He can then go and write his plugin, save the plugin code into his own version control, etc. However, the Main project doesn't change (the plugin files are not added to the Main project file), so I avoid having to deal with lots of commits from other people in the group. What do you mean by "reusable component"? In any case, the "Plugin Interface" class is the class that plugins derive from. Does that answer your question? Sincerely, Onno