Jump to content

Onno

Members
  • Content Count

    29
  • Joined

  • Last visited

Community Reputation

3

About Onno

  • Rank
    More Active

Profile Information

  • Gender
    Male
  • Location
    Amsterdam, The Netherlands

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2011
  • Since
    2007
  1. 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 cluste
  2. 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.
  3. Thanks so much for recording these, and making them available!
  4. 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 fil
  5. 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.
  6. 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!
  7. 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
  8. 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
  9. 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 — somet
  10. 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?
  11. 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 app
  12. 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 audi
  13. 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/und
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.