Jump to content

drjdpowell

Members
  • Posts

    1,982
  • Joined

  • Last visited

  • Days Won

    183

Everything posted by drjdpowell

  1. Sorry guys, I was on holiday when Stobber asked his question. Rolf has answered better than I could. I have only used polling to identify changes. I tend to have timestamped data with the timestamp as primary key, and getting MAX() of the primary key is very fast. One could also use triggers to increment some field whenever something of interest changes, and then poll that field.
  2. That 15-30 sec figure, at 1.5 to 3 ms per line, seems an order of magnitude too slow to me.
  3. I've just got the evaluation kit for an sbRIO with RT Linux. I ran the example with 'Instrument' on the sbRIO; I found that the OpenG zlib compression library did not deploy to RT Linux. So I had to disable zlib with the following Project Conditional Disable: ZLIB_Compression == OFF Otherwise I didn't make any modifications. But I (so far) have not been able to get my custom probes working on RT, so I'm investigating other RT-usable tools. -- James
  4. OpenG was written before proper recursion existed in LabVIEW, and uses (slow) VI-Server calls to dive into clusters. MGI is more recent and uses proper recursive calls, so should be significantly faster. Personally, I use JSON for configuration files.
  5. Why are you not just (plain-old synchronously) calling the subVI?
  6. References are “owned” by the "VI hierarchy" that created them, and are automatically destroyed if that hierarchy goes idle. Asynchronously-called VIs run in their own independent hierarchy (even if you use the Run method instead of ACBR). In your example, the DVR was destroyed when the launched VI finished.
  7. Why? Actors are tools. One configures a tool for a specific task. You know the task; the tool doesn’t. Why would the tool be responsible for configuring itself?
  8. I use messages containing JSON for configuration, combined with a subVI for handling "Set Config” or "Get Config" messages that accepts config info as either a variant cluster or an array of control references. Once set up, adding new configuration info is trivial.
  9. You could extend your Action Engine to have a “Register” action, which takes a User Event and saves it in an array internally, then posts to the Event whenever the config value changes. Then processes loops can register if they need to be informed when something has changed. Then you have a hybrid AE/messaging system.
  10. What are you meaning by a “thread” here? Users don’t create threads.
  11. No, because you didn’t identify what package you want.
  12. Added to 1.8.1 version now in the CR. Please test it for me.
  13. Sure, Ben. I haven’t needed such thing (yet) so I hadn’t put it in. Is it just the number of elements in the queue that you need?
  14. Some refs are static; they always exist and you are neither creating or destroying them. “This VI†and control refs are of this type. “Closing†these refs is a no-op. Other refs are both dynamically created and involve holding resources open of some kind (like an open file, or a Queue or something). Here is where one worries about ‘memory leaks’.
  15. Basically a function call on a server. Used for controlling the server. “Calibrateâ€, “Measure Sampleâ€, etc.
  16. The speaker who called it an anti-pattern was Dmitry, at the recent CLA Summit in Berlin. I don’t think he posts on LAVA, but I suspect he might argue that calling code should decide if “data being dropped†is acceptable or not and thus either dropped data should be an error (with calling code forced to decide what to do) or it should be a separate output, such as a “data dropped†boolean, which calling code should immediately either handle or explicitly choose to ignore.
  17. The VI ref was created by the calling code, and the calling code is responsible for closing it if/when it needs closing. If I were updating this VI, I might add a “VI ref out†output to visually prompt the developer to deal with the ref.
  18. Many LabVIEW developers don’t use warnings, and I recently saw a talk where they were described as an “anti-pattern†(a common software design that has more negatives than positives and should be avoided). You are right though, that a toolkit like OpenG shouldn’t be dropping warnings that pass through it.
  19. Thanks Neil, The toolkit gives off a “not quite ready for prime time†vibe to me (including that annoying partial implementation of events, poor documentation, minimal single example, etc.) so I’m glad you are happy with it. I suspect it is an incomplete version of OPC-UA (no method calls?) but probably sufficient for the simple server I need to make. Thanks again, — James
  20. In case the OP wasn’t aware, there is an Actor Framework group on NI where there are more AF users who might respond. Waiting on things that are reliably quick is often the best thing to do, IMO, as it is often simpler.
  21. Hi Neil, I'm looking in to using LabVIEW's OPC UA implimentation, both client and server, and wondered what your experiences were with it. Would you recommend it? -- James
  22. HI Rob, Have you looked at the example code (and video linked to) here? It’s a TCP example. Standard Request-Reply and Register-Notify should work seamlessly over TCP (as the various TCP actors route the messages back over the connection) without needing to do anything special.
×
×
  • Create New...

Important Information

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