Jump to content

drjdpowell

Members
 View Profile  See their activity

  • Posts

    1,964

  • Joined

  • Last visited

  • Days Won

    171

 Content Type 

Everything posted by drjdpowell

  1. drjdpowell
    An experiment in crude pseudo-UML using the IDE (for a selection of classes, and subset of methods, in my current project):
  2. drjdpowell
    I have not. I should have a look
  3. drjdpowell
    Oh, I didn’t mean to cast doubt on the use of modeling; just noting the handicaps of using tools designed for languages with an X=F(A,B,..) syntax. It would be very nice if there where a UML tool that could interface with LabVIEW to present a class with all the methods as icons, with ctl-H bringing up the standard window showing terminals and descriptions. Modeling before coding might be slower, as you’d had to create shell VIs with terminals and rough-draft icons, but at least this will save you time when it comes to actually coding. And in return you get a much clearer visual diagram.
  4. drjdpowell
    Not used UML myself, but it seems to me that the terminals of a VI are much better specified in this way (not that available UML tools will support this ):
  5. drjdpowell
    You only have one subpanel, and a subpanel only holds one VI at a time (dropping the previous VI if you insert a new one). You also seem to be only creating one copy of your subVI (but you opened four separate references to it). If you want four copies (“clones”) of your SubVI, you need to use option 0x8 (Reentrant run) in the Open Reference, and you need four subpanels.
  6. drjdpowell
    Making a new “MoveStrategy” class tree is my first thought also, but another possibility is to create a HysteresisCapableAxis child class that by default has a Move method that just calls the parent method, but that can also enable hysteresis (via some “Enable” boolean). You can then enable or disable hysteresis without changing the class.
  7. drjdpowell
    You mean it is too slow when the reference is invalid? When it is valid then this method takes less time than testing for an invalid refnum and then using it.
  8. drjdpowell
    Even better than testing for an invalid refnum is actually trying to use the reference. Recreate it if you get an error. There is some post somewhere by AQ that points out the race condition in testing for refnum validity. Here’s an example of a “refnum created and maintained inside a non-reentrant VI” from one of my projects:
  9. drjdpowell
    A minor warning about that technique. A reference is destroyed if the top-level VI under which it is created goes idle. The “First Call” primitive is reset when the subVI it is contained stops being reserved for execution. If you are working with multiple top-level VIs (such as if using dynamically “launched” VIs) then it is possible to invalidate the reference without resetting the first call.
  10. drjdpowell
    It’s not a matter of “can be released”; all references owned by a top-level VI are required to be released as part of the process of going idle. This is a little-known but standard way LabVIEW treats all references. Changing this would break or introduce memory leaks into all sorts of old code. I use asynchronously launched VIs extensively and I actually find this feature very useful, though also quite complicating.
  11. drjdpowell
    Hi Neil, I don’t think that’s how it works. If you put a by-value object in a DVR, the data can’t disappear unless the DVR disappears. The DVR “owns” the object. Only if the DVR contains just a reference to something (another DVR, a queue, etc.) do you have to worry about its independent lifetime. The DVR, like other references in LabVIEW, is itself “owned” by the top-level VI of the subVI that created it (I think this might be called a “VI hierarchy”), and will become invalid if that VI hierarchy goes idle. This only matters if you are sharing the reference between multiple VI hierarchies (such as by asynchronously-called VIs).
  12. drjdpowell
    Check this conversation for info on the 2013 changes, and a subVI that can be used to fix the problem.
  13. drjdpowell
    Hi, I’m thinking of submitting my SQLite package in the CR to the tools network. Is “Team LAVA” still active? — James
  14. drjdpowell
    Oh dear, I think that paper must be badly written, at least when interpreted from your background (and the “copies on the wires” part isn’t strictly true). The whole point of by-value dataflow is NOT worrying about object lifetime.
  15. drjdpowell
    Yes, by-reference data allows one to be sure your not making copies. It can take a lot of experience before one starts to trust by-value data handling. Using in-place elements and always wiring straight through functions can give one confidence, even if those techniques are often unnecessary. But, a good by-value design can be at least as “copy-efficient”, if not more so, as a by-ref design even, while also having other advantages. Still says “queue”. Queue the data to the central analyzer and have it retain whatever info it needs to interpret further data (like the last battery voltage). — James
  16. drjdpowell
    You can’t have your cake and eat it too. If you want a low priority process to wait till later then you have to retain the data it needs. If you want no copies, then everybody else has to wait for that low priority process to finish with the data before overwriting it. “Passing wires” doesn’t make copies. Even branching wires doesn’t always make copies. Your app says “queues” to me, not “FGV” or “DVR". Queue all the measurements to a central analyzer. Queues are asynchronous, so can’t stall your acquisition loops. Access to a FGV or DVR is synchronous, so to avoid blocking acquisition you are forced to make a copy for lengthy analysis. Your description of the wide variety of measurements that can be produced definitely suggests LVOOP. A low-risk path would be to just start using classes in place of whatever type-def clusters you are using for measurements. That will force you to use the encapsulation that will allow you to extend using inheritance later on. To a copy. DVRs aren’t pointers; they have locking features that I don’t think could work for locks inside locks. Can you just use an array of DVRs to implement whatever it is your after?
  17. drjdpowell
    Matze, Can you probe to see what the pointer is when the error happens? The 1097 error happens if the pointer is zero.
  18. drjdpowell
    Well, to prevent copies you must serialize access to the data. A DVR does that, but if you have already designed a structure that serializes access (Collect—>Analyze—>Graph—>Store) then you won’t gain anything by adding a DVR. BTW, an easy way to reduce copies in your example code is to put the analysis logic inside the Functional Global (an “analyze" step rather than “get”). You can also serialize the graphing and saving. A more major change is to not deal with all the data at once. Stream data to disk, and only read, analyze and present a subset at a time.
  19. drjdpowell
    You don’t need the “Open VI Ref” dynamic-launch complexity; just use a static, strictly-typed ref (each one of which refers to a separate clone):
  20. drjdpowell
    Google translation: That error comes for the Call Library Node calling “MoveBlock” in “Pointer-to-C-String to String”. It’s writing into an array of bytes allocated by LabVIEW, so I can’t see how an error could occur. And I have not seen this error myself. Anyone else have this problem?
  21. drjdpowell
    Which version of “Launch Actor” are you using? The newer version shouldn’t be closing the reference to “Actor.vi” at all (link).
  22. drjdpowell
    How did they fix this? Given that the dynamic registration queues are independent of the static queues, how can events be ordered, other than by a timestamp of some kind?
  23. drjdpowell
    Nicely done. I made a similar tool for my actor-like framework, and I experimented with something for the Actor Framework, but I couldn't see how to do it without changing Actor.lvclass (make a child class, of course!). Like the “ping” ability.
  24. drjdpowell
    Are you actually working on a DB actor or is this just academic? Because you are in danger of spending a lot of time on redundantly recreating features that the database software already handles (and probably handles better; for example, a DB will only serialize transactions that actually need to be serialized).
  25. drjdpowell
    I disagree, if you mean you can update these lists of actors non-locally. For example, if Actor A launches Actor B, then only A has the address of B, and A cannot add B to any list of Actors held by any third actor, C, except via sending the address in a message. Having by-reference updatable lists shared between Actors is a definite violation of the Actor Model; the lists have to be by-value. Note that you can build structure on top of actors that do subscriptions or channel-like message routing, but these must all be built on top of messages. No by-ref data sharing. My “Observer Registry” Actor, for example, in my actor-like framework, holds by-value lists of addresses, and everything is done by messages. I say “my actor-like framework” because I can’t claim I don’t break the Actor Model rules, but I do try and know why I should be wary about breaking them. That isn’t using the names as a global link, so that is fine. Nothing wrong with not using the Actor Model for everything, but personally, I’d rather my missile not be mistakenly destroyed because of a bug is some forgotten unimportant subsystem that misspelled a queue name. If everyone needs to know it, then explicitly pass it to everyone.
×
×
  • Create New...

Important Information

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

  I accept