Jump to content

drjdpowell

Members
  • Posts

    1,964
  • Joined

  • Last visited

  • Days Won

    171

Everything posted by drjdpowell

  1. I’ve added this package to the code repository. The only major change since the last is getting it to properly include the SQLite3 dll in executables.
  2. Version 1.11.3

    9,016 downloads

    Introductory video now available on YouTube: Intro to SQLite in LabVIEW SQLite3 is a very light-weight, server-less, database-in-a-file library. See www.SQLite.org. This package is a wrapper of the SQLite3 C library and follows it closely. There are basically two use modes: (1) calling "Execute SQL" on a Connection to run SQL scripts (and optionally return 2D arrays of strings from an SQL statement that returns results); and (2) "Preparing" a single SQL statement and executing it step-by-step explicitly. The advantage of the later is the ability to "Bind" parameters to the statement, and get the column data back in the desired datatype. The "Bind" and "Get Column" VIs are set as properties of the "SQL Statement" object, for convenience in working with large numbers of them. See the original conversation on this here. Hosted on the NI LabVIEW Tools Network. JDP Science Tools group on NI.com. ***Requires VIPM 2017 or later for install.***
  3. Yeah, but how useful is that in LabVIEW? The basic use for “futures” in step-by-step text languages is very similar to the dataflow already present in LabVIEW. Only once we’re talking about message-handling loops does a “future” become interesting, and in that case it’s hard to see how useful they are when we’re already using asynchronous messaging. In your example application, it’s only the fact that you need multiple TransformData messages for only one DoCalc message that make the futures solution interesting. It’s that you can pass an array of futures to DoCalc, and thus gather your four separate TransformData responses together that is something you can’t otherwise do as easily. Not really. The helper actor I’m thinking of would be fully generic and reusable; it would be dynamically launched and configured with an array of Futures and index over them to get the array of messages. It’s API would be very simple. I noticed that your futures were very similar to the “message reply” system I use. I attach a “return address” to the message, and you attach the future. Both allow the direction of responses to arbitrary recipients. Though with futures, the recipient has to be written to specifically handle futures, while with replies it’s just an ordinary message. — James
  4. I was thinking about this a while last night, and I wondered if the real value of “futures” is in defining an ordered grouping of otherwise independent asynchronous messages. Imagine, for example, that one process needs to make requests of several other processes, with responses to these requests being dealt with all at once. The problem here is that the Response messages come individually and in any time order, meaning that “Consumer” needs to have logic to identify and store the messages, and determine when all are available. The advantage of using an array of Futures here (passed between Requestor and Consumer) is the very fact that it is an array; it is grouped and has a defined order. Thus Consumer need only index out the elements of this array and need not have any complex logic. The array of Futures serves to predefine a grouping of multiple asynchronous messages that have yet to be sent. As is, the Futures have the downside of requiring potential blocking or polling in Consumer. However, this can be avoided by using a small helper process that is dedicated to waiting on the array of Futures and forwarding the resulting array of massages: Note that the “Wait on Responses” Actor is serving to group and order the messages, before passing them to the Consumer. Requestor makes a set of requests, and Consumer receives a corresponding set of responses. — James
  5. One could also have a reusable process that waits on an array of futures, then forwards the results to the process that needs them. Then that simple process (that has nothing else it needs to do) would do the blocking. And it would have a timeout, of course, after which it would send an error message.
  6. Hi Daklu, A comment: If your “Model” was a complex, multi-loop construct like your last post diagram, it is possible that you might put your future-filling logic (“TransformData”) in a different loop than the Future-redeeming logic (“DoCalc”). It would then be possible for the future to be redeemed before it is filled, which for your DVR design would return default data, followed by an “invalid DVR" error message from “TransformData". A “future” based on a Notifier would instead just block momentarily if this happened, and would be a much more widely applicable construct because of that. Your DVR future can only be used in cases where it is filled and redeemed in the same loop, or can otherwise be assured it is filled before redeemed. — James
  7. If something takes 10ms and one delays blocking for 11 ms, then one has avoided blocking all together. I hadn’t appreciated, though, that you are filling your futures in the same message handler that is redeeming them, and thus in your case there is no possibility of ever actually blocking on the redeeming of the futures. Clever, and I can’t think of a cleaner way of doing it.
  8. A “round robin message” would work, but would be serial, rather than parallel. And I suspect a “Wait on all Futures” actor would be just as simple. I suspect we all have somewhat different ideas about what “futures” might be. My first reading on futures was some webpage (which I can’t find again) that gave a pseudocode example like this: future A=FuncA() future B=FuncB() …do something else... C = FuncC(A,B) Here FuncA and FuncB run in parallel, and the code blocks at the first use the results. Note that we can already do this kind of stuff in LabVIEW due to dataflow.
  9. Thoughts on Futures, as I understand them (and without reexamining Daklu’s implementation): 1) Isn’t the point of futures to block (not poll), just like synchronous operations, but to delay the block until the information is needed, rather than when it is requested? It’s “lazy blocking”. And very similar to standard LabVIEW data flow (blocking till all inputs available). 2) One use of Futures I can think of is if I wish to request information from several processes, and perform some action only when I receive all replies. I can send all the requests and pass the array of futures to a spawned “Wait on all Futures” process/actor that sends a single bundled-reply message back to the original process when all the futures are filled. This would be much easier than having to record each reply and checking to see if I have all of them. — James
  10. It will only work with by-value objects in limited cases. Every wire branch leads to a separate object. For example, in your last attachment, you have an “ImplementorInit” VI that returns five entirely independent “Implementer” objects; two in Child 1(at parent and child levels), two in Child 2, and an overall object that holds Children 1 and 2. If these were five references to a single by-ref object then you would be able to work on that object from any of your methods. But by-value you are working with different objects; changing one has no effect on the others. In the code I posted, I’m trying to keep all the by-value objects together, with no copies, so any method in one interface can call methods on any or all of the over interfaces. Child2 can access and modify the Child1. Child1 can access and modify Child2. — James BTW: Daklu has an interface framework in the code repository. He uses a by-ref object (using a DVR).
  11. Are your examples meant to involve by-value or by-reference objects? I can see how they work for by-reference objects, but they wouldn’t work with by-value objects (since your making copies at every wire branch).
  12. It wasn’t/isn’t clear to me what this idea is asking for that the conditional disable structure doesn’t already do. Could you give an example?
  13. Interesting. I didn’t know N2O had enough greenhouse potential to be an issue despite it’s small concentration. But it’s still isn’t significant, as the greenhouse effect of the N2O from vehicles is only a bit over 1% of the effect of CO2 from the same vehicles (if I read this correctly).
  14. An experimental modification: Run “Example B.vi" Interface B.zip
  15. The noxious gases that the catalytic converter works on are only a very small fraction of the gases produced, so it doesn’t make a meaningful difference. Also, the sun’s UV light will eventually complete the oxidation of the carbon in those gases to CO2. Too slowly to affect ground-level pollution, but fast on a timescale of climate change.
  16. To be Devil’s advocate, isn’t the need to put the word “unrelated” in there a bit of a problem? I’m not familiar with OOP interfaces, but isn’t the idea that interfaces are different ways of treating the same object? Representing a single object as a collection of different objects with no connections between them might work sometimes, but the instant you have a relationship (say, Child2 needs to call a method on Child1 in order to execute “Child2Info.vi”) then you have a problem. — James Fuzzy Idea: How about a design in which QueryInterface, instead of returning a copy of Child2 from Child1, takes a Child1(containing Child2) and returns a Child2(containing Child1)? I.e. the collective object is always the same (and each child can access the other), but the apparent identity switches between different interfaces.
  17. Minor point: catalytic converters don’t increase the amount of greenhouse gases, so this can’t be an example of “unintended consequences”.
  18. Latest version, with a bit of the documentation filled in. It now also works under Mac OS X (it links to the standard copy of SQLite3 included as a part of OS X): SQLite LabVIEW.zip
  19. I usually set my programs with the ability switch between using the sub panel, and opening separate windows (this is very easy to do). Then I debug with separate windows.
  20. Any further comments on this package? Or any comments on whether this is right for OpenG? I could alternately try and release it under “Team LAVA”. I could also use the help of people who use LabVIEW for Macs or Linux to try and test it with SQLite compiled for those platforms. It should work quite easily. It would be a shame to have a Windows-only package. — James
  21. UFTP is interesting as a UDP-based file transfer system (with the interesting use case of a broadcast to multiple receivers over a satellite link). moralyan should have a look.
  22. I googled it too and that was my conclusion. There were clearly tasks that cried out for UDP, broadcasting time-critical small pieces of information, but there was nothing suggesting one had to use UDP for sending large files.
  23. Oh, I didn’t know your were talking about Panes. I’ve not done that; just User Menus from controls inside a sub panel, which work fine.
×
×
  • Create New...

Important Information

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