Jump to content

drjdpowell

Members
  • Posts

    1,970
  • Joined

  • Last visited

  • Days Won

    173

Everything posted by drjdpowell

  1. JamesMc86 is suggesting the possibility of writing a by-val class and allowing the application level to decide on DVR use (or not). The other options are writing a class API that takes DVRs as you’re doing, or use DVRs internal to the class (as todd mentions). If one is doing a class API that takes DVRs, then I agree you probably want to restrict use of the IPE to within that API.
  2. Some random thoughts: 1) I tend not to have an actual “UI actor”; instead I have each actor have it’s own UI on its front panel, and have the main actor present the subactors in one or more subpanels (or just open their windows. This involves less messages to pass around. 2) One can also deal with needing lots of messages for lots of UI controls by treating the controls generically using techniques illustrated below. This is a “Control Server” example that I don’t think is in the version of “Messenging” in the code repository, but will be in the next version. Changing any control in Pane 2 of the “Control Client” sends a Variant Message that then fires a Value Change event in the Control Server. You can do the same thing with “Notify”, and you can also write generic code for setting cluster items using OpenG functions. Would this kind of stuff help reduce the programming burden? 3) The above technique in (2) is event driven (User pushes button —> sends message —> fires Value Changed event). In contrast, using a DVR requires the receiver to poll for changes to the UI settings it cares about. It also works remotely (the example above works over TCP), though that is often not needed.
  3. You mention “actors”, but one of the main points of the Actor Model is to use message passing instead of sharing by-reference data. So why not just send update messages when the User changes something?
  4. Unfortunately it’s on the restricted CLA group, but here is a very interesting presentation on XControls: Round Table Discussion - XControls
  5. It’s supposed to work with enums, and my test case seems to work. "Variant to JSON" delegates enums to OpenG’s “Scan from String” which calls OpenG “Set Enum String Value”, so it should work. What error did you get and what enum string did it have?
  6. Have you tried recreating the parent “Execute” message from scratch?
  7. Yes. It shouldn’t matter how deep in the call chain the reference is created. BTW, what is the semaphore for?
  8. I’m sort of A, but the large amount of C involved makes me consider B. Thus: D.
  9. XControls? A) Yes B) No C) <Head banging against wall> Thump…Thump…Thump... D) All of the above
  10. Would it be better to have a “ConfigGUI” object that was recursive (contained an optional subConfigGUI)? Have a “Get ConfigGUI” method that has a “subConfigGUI” input. The parent implementation would initialize the generic GUI and add the inputted subConfig GUI. Child implementations could override the method to initialize a specific GUI and pass this in to the parent method. The “display” (or whatever) method of the ConfigGUI object would enable the button if a non-default subConfigGUI was present. That avoids any class introspection. It would also work at any depth (so your more specific GUIs could themselves have even more specific sub-GUIs).
  11. In any “command pattern”-style process the messages are part of the process, so if one can write or load new messages then one is modifying the process.
  12. Version 1.8.6

    1,837 downloads

    A logger and log viewer using an SQLite database. The logger is a background process that logs at about once per second. A simple API allows log entries to be added from anywhere in a program. A Log Viewer is available under the Tools menu (Tools>>Cyth Log Viewer); this can alternately be built into a stand-alone executable. Requires SQLite Library (Tools Network). Notes: Version 1.4.0 is the last available for LabVIEW 2011. New development in LabVIEW 2013. Latest versions available directly through VIPM.io servers.
  13. View File Cyth SQLite Logger A logger and log viewer using an SQLite database. The logger is a background process that logs at about once per second. A simple API allows log entries to be added from anywhere in a program. A Log Viewer is available under the Tools menu (Tools>>Cyth Log Viewer); this can alternately be built into a stand-alone executable. Requires SQLite Library (Tools Network). Notes: Version 1.4.0 is the last available for LabVIEW 2011. New development in LabVIEW 2013. Latest versions available directly through VIPM.io servers. Submitter drjdpowell Submitted 03/08/2013 Category Database & File IO License Type BSD (Most common)  
  14. Version 1.3

    771 downloads

    A pair of subVIs for connecting a cluster of enums and booleans to a set of options in a menu (either the right-click shortcut menu on control or the VI menu bar). Adding new menu options requires only dropping a new boolean or enum in the cluster. See original conversation here. I use this heavily in User Interfaces, with display options being accessed via the shortcut menus of graphs, tables, and listboxes, rather than being independent controls on the Front Panel. Relies on the OpenG LabVIEW Data Library.
  15. Name: Shortcut Menu from Cluster Submitter: drjdpowell Submitted: 06 Mar 2013 Category: User Interface LabVIEW Version: 2011License Type: BSD (Most common) A pair of subVIs for connecting a cluster of enums and booleans to a set of options in a menu (either the right-click shortcut menu on control or the VI menu bar). Adding new menu options requires only dropping a new boolean or enum in the cluster. See original conversation here. I use this heavily in User Interfaces, with display options being accessed via the shortcut menus of graphs, tables, and listboxes, rather than being independent controls on the Front Panel. Relies on the OpenG LabVIEW Data Library. Click here to download this file
  16. No, the DD methods are not per child class; they are just methods to do stuff (which the children can override). Child DUTs can also provide new methods, and messages can be written that call them by casting the DUT input to the correct child class. — James Added later: here’s an example “execute” method (though called “Do.vi”): “VI Display name" is the message; it calls two methods on “Logger Daemon” to complete its task.
  17. Your Message class should have an “execute message” dynamic-dispatch method that has a DUT input. Inside the execute method you call dynamic-dispatch methods of DUT. So you can make child message classes that call different DUT methods, and child DUT classes that override those methods.
  18. I made one yesterday. Here is the only public API method, “Send Message with Reply Timeout”, which is identical to my regular “Send Message” method but with a timeout input and an optional input for the Timeout message to send: Works by an asynchronous call of a small “watchdog” that waits on the reply and returns either that reply or a timeout message. It then shutsdown. I should add that this only works for a system where the address to send replies to can be attached to the original request message. Hard to define a “reply timeout” without a defined reply. — James
  19. Well, timing out would be an error, and one could handle that error in multiple ways: log error and shutdown anyway, display error to User and wait for input, trigger hardware emergency safe mode. My point is that one’s code may require awareness about something, that is supposed to happen, not happening in a reasonable time. It’s obvious how to do that with synchronous command-response, but not so clear if one is staying fully asynchronous. I’m thinking of creating a “helper” VI for my framework that can be configured to wait for a message. If it receives the message within the designated time it just forwards the message to its caller and shuts down; otherwise it sends a "timed-out” message instead. That way the calling loop can send a command that it expects a reply to, and execute code to handle the case that the reply never comes, while remaining fully asynchronous and unblocked.
  20. Question: Doesn’t a fully asynchronous message system still need the concept of a timeout? In your shutdown example, the UI loop is at some point waiting to receive the “Exited” messages from Loops 1 and 2. If one of those messages fails to arrive, won’t it be waiting forever?
  21. Could you point me to that thread? I had a quick scan but couldn’t find it.
  22. I mean if you can’t service the queue as fast as elements are added, then you’ll eventually run out of memory. — James PS, if you recall this conversation we had, one can use a timeout in a way that is guaranteed to execute the desired code on time
  23. mje was talking about using a “zero or calculated timeout”, a technique I’ve also used. If a zero timeout never executes your actor’s gonna fail anyway.
  24. I was thinking more of the use of a message queue as a job queue for the actor, rather than what to do about filtering messages, but the general idea would be to have the actor’s message handler serve as supervisor or manager of a specialized process loop. The manager can do any filtering of messages, if needed, or it can manage an internal job queue. It can also handle aborting the specialized process by in-built means that can be more immediate than a priority message at the front of the queue (like an “abort” notifier, or directly engaging a physical safety device). It wouldn’t be a hollow shell.
  25. I particularly second this. Actors should endeavor to read their mail promptly, and the message queue should not double as a job queue.
×
×
  • Create New...

Important Information

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