Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/02/2012 in all areas

  1. So here it is; a new and complete OpenG array library with 8 of its functions optimized for speed and memory usage. All the polymorph instances have been revised. I have also backsaved it from 2011 to 2009 (which is as far back as the Remove Duplicates function will go now that it uses the In-Place structure...). I guess this is as far as I can contribute. I really hope that we can see this (or even further improved versions) in an official release not too far into the future(?). Mads OpenG Array Revised R4 LabVIEW 2009.zip OpenG Array Revised R4 LV2011.zip
    1 point
  2. This thread seems to have diverged into a few distinct topics: Original thread topic: How to distribute updated "preferences" data to multiple processes. Ancillary topic 1: Using classes to define configurable data items. Ancillary topic 2: Using configurable objects within a "configuration editor" (or "preference dialog"). On the original thread topic: If multiple processes require configuration and these processes operate as some sort of state machine: there is probably a valid state in which editing configuration should be allowed (and disallowed in other states), and there is probably a transition during which configuration should be loaded and cached within that process. If other processes requiring the configuration are state-less (except maybe init & run), then they probably need to be signaled to re-init (i.e. reload the configuration from disk, DB, or FGV) after it has been edited. On topic 1: There's a tradeoff between the beauty of mutable version handling when loading classes serialized to disk and the convenience of human readable/editable files. If you're attempting to maintain multiple deployments & versions, or if requirements are frequently evolving, then it's probably best to just flatten objects to disk. I find it hard to come up with a compelling case otherwise. On topic 2: Shane's suggestion is good, "self-displaying objects", but it's easier said than done. How would you handle a configurable object hierarchy, where each child class contributes its own configurable attributes. After the self-display method is running in a subpanel how do you pass in the current configuration to display, how do you signal it to stop then pass out or retrieve the updated configuration? Is each object in charge of it's own disk read/writes or does the top-level config editor handle it all generically? There are many right answers here of course, it's not "one-size-fits-all". I find that most solutions are either highly extensible but relatively complex to use and non-trivial to implement, or they are simple but rigid and limiting. For those of you who have a good solution or idea, please describe context in which it is applicable. I know that Paul's solution described above used on the Discovery Channel Telescope works well for state-based systems that are deployed to one location, undergo little to no change to configuration datatypes, and require separate applications to edit and load configurable items.
    1 point
  3. Symbio is giving away 3 UML Architect GOOP Development Licences. FYI the new GDS release is supporting the Actor Framework, what better way is there to modelling your Actors in UML. //Mike
    1 point
  4. I strongly suggest you get a dedicated controller for the mission-critical tasks (think cFP or cRIO) and handle the non-mission critical tasks on the PC (like displaying data, logging to a database or wherever. This means that if the PC goes offline for some reason, the controller continues humming away at what it does best: determinisitc control. Then, you only really need to worry about infrastrucute support (eg: UPS) for the controller - it can continue to control and save data locally while the other system is offline. Also, if you go to the PC to get data off it (I don't expect you're going to run the system completely untouched for a year, right? Not even look at any of the data), doing so won't interupt the process. This is a common option in mission critical systems: we built a similar system a few years ago with 3 parallel controllers (PXI) that could take over from each other within 1ms of a detected failure (those specs are probably overkill for your application, but the technology remains the same). We achevied this using reflected memory (a PXI card with a fiber optic link between them, that all "shared" the same memory) - this worked really well. Another option is to stream reflective memory over a local LAN dedicated to the controllers. I've never been to Amsterdam... The answer to that question depends on just how important that determinism is. If you trust your engineers to make something that won't fail, then maybe do it alone. That said, if they misplace one bit, and the whole thing comes crashing down in the last month of the experiment, you might be cranky An even worse scenario (which I've seem many times) is when it *looks* like everything worked fine, but there's an offset or skew in your data that you don't find out about until you've published - *that* would be a nightmare!
    1 point
  5. In what has to be the most off-topic LAVA/OpenG BBQ door prize ever, I'll be giving away two advance copies of my graphical novel Rune: A Tale of Wizards and Kings, which is coming out in October.
    1 point
  6. Hello, I’m uploading the latest version of my framework, even though it isn’t polished, as I’m unlikely to have any time to polish it for months (baby on the way). It includes all the extra stuff since the last version, including the Actor Manager, and TCP-network versions of the Queue and User Event Messengers. It is in LabVIEW 2011. — James Messenging.zip
    1 point
×
×
  • Create New...

Important Information

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