Jump to content

drjdpowell

Members
  • Content Count

    1,759
  • Joined

  • Last visited

  • Days Won

    137

Posts posted by drjdpowell

  1. 1 hour ago, Jordan Kuehn said:

    Thank you for the confirmation. I have done something similar using numeric types, but it is inconvenient at best. An NXG version of this toolkit would be fantastic. 

    Unfortunately, the NXG Web module lacks both recursion and VIs for determining the data type inside a variant.  This makes porting JSONtext to it very difficult.

  2. 5 hours ago, LogMAN said:

    For example, what is the expected outcome of this?

    That's sloppy on my part.   Arrays should not be supported at all and that should throw an "Unable to Bind Arrays" error.  The code for that is in the Disabled case of "Parse Parameters (Code).vi".  I was experimenting with the idea of allowing U8 Arrays as binding as BLOBs, and I seem to have not undone my buggy experimental modification.

  3. 4 hours ago, mramsdale said:

    1) Can parameters be used for writing multiple rows to a table?  (rather than the step method)

    Hi Guys,

    Support for writing multiple rows in this manner is on the Roadmap, but not yet existing, partly because I am debating multiple options:

    1. A new function, "Execute SQL Multiple Times", that takes a parameter input of arrays of clusters or a cluster of arrays and does multiple executions of one SQL statement. 
    2. Integrating it into the existing "Execute SQL" node.  
    3. Upping the LabVIEW version to 2017 and introducing a new VIM version of either (1) or (2).

    The problems with (2), which you guys are thinking should work are:

    • "Execute SQL" is a polymorphic VI with many members, and major changes to support functionality like this is very time expensive for me.
    • That function is already quite complicated, and increasing what it can do is going to make it more confusing.

    Usually when one is executing the same SQL many times, one is INSERTing rather than getting any results, so a new function (1) would only be one VI, and it could have documentation (and a different icon) that clearly describes using it on multiple INSERTs.   An advantage of the VIM (3) is that I can make the input accept only data in the right form (array of cluster, cluster of arrays).  

     

    This is not high priority for me, as I see it as about convenience rather than new capability.  You can already do things more flexibly and faster-executing using "Prepare Statement" followed by a loop, or you can do it easy (but slow) with "Execute SQL" in a loop.

  4. 1 hour ago, bmoyer said:

    I was wondering how you make the front panel display update lossy.  Currently, when I want to do this, I check the Time of the event, and if the event is, let's say >1s old, I don't bother updating the display/indicator.  If that how you go about it, or is there another way?  Is there a way to only get the latest event and ignore the rest?  I'm asking this mainly from the perspective of using your Messenger Library toolkit.

    It's documented in the DEV Template.  I use a feedback timeout that is default 0 ms from every case but the Timeout case (which feeds back -1).  This makes the Timeout case execute exactly once after the event queue is empty.   Use a "Display needs update" boolean flag to record if the display needs updating in the timeout case.

    550518896_2020-10-1615_42_09-DEVActorTemplate.lvclass_Actor.viBlockDiagramonAllMessangingRelated_lvpr.png.bf6bacb7d4c8afe7d52bf36859789f92.png

    One can do this with Queues as well.

    With this one is able to look at all incoming data, but do expensive display operations only as often as possible (but as quickly as possible).  So you could, for example, have information coming in a 100 a second, and display using fancy techniques (like complex 2D pictures) that take 100ms+.  This is more responsive and a look more robust than the "drop old stuff" technique.

     

    • Like 1
    • Thanks 1
  5. 7 hours ago, Reds said:

    In this type of scenario, I would normally use a Notifier, not a Queue. If the GUI loop can run fast enough to display all of that data, that's great. If not, some data is skipped. A lossy Notifier is perfect for this scenario.

    A Notifier is only usable is you only have one type of message coming in, and your display doesn't include any history, like a chart.  

    Personally, I keep the data transfer lossless, but just make the actual front panel display update lossy. 

    • Like 1
  6. 7 hours ago, Bhaskar Peesapati said:

    Looks like you do not like to use DVRs. I read and write to DVR as property in a class in the following way only. Do you still think I am might run into problems.  If so what do you suspect. The write or SET happens only in open place.

    image.png.d037b33f337ba3f2e714d2b6a91f01e6.png

    They way you're using DVRs here, pulling the full data out of the in-place structure, forces a lot of copying.  You have to do the work inside the event structure if you wish to prevent copying.

    • Like 1
  7. I suffer from the handicap of being located in UTC+00:00, which makes it difficult for me to spot bugs in local to UTC conversion.  I have to remember to switch my computer to the wrong timezone to test things, and I obviously didn't do that here.  Thanks for spotting this. The format specifier should indeed have a ^ in it.

  8. Only suggestions I have are:

    1. Is the exe in that "builds" folder.  The EXE xpects teh dll at "<EXE's folder>/data".   Your screenshot shows the dll at "builds/data".
    2. Could be a missing dll that libpq.dll calls.  Try downloading a full set of Postgres dlls and place them in the data folder.
  9. 1 hour ago, brownx said:

    Ok - let's talk about my example - it's basically a IO driver:
    - I need to support a set of hardware, each with N inputs and M outputs (don't matter what kind, they will be many)
    - it has to be easily scaled to add more type and more from the same type
    - has to be multithreaded and permit multiple instances of the same HW
    - data has to be accessed from a single standalone vi call (hard to explain this unless You guys are using Teststand which is a bit different than having one monolith Labview app)

    How You guys would implement it? Don't need complete examples, just a few keywords from where I can get a new viewpoint ...

    All my applications are developed with a package I wrote several years ago called "Messenger Library": https://labviewwiki.org/wiki/Messenger_Library  There are a few YouTube videos linked from that wiki that go through an actual example application.   It's motivated by the Actor Model, and so I take inspiration from frameworks like Erlang, Akka or the C++ Actor Framework.  The core concept is "messaging" to gain the benefits you list.

    • Thanks 1
  10. Remember that you are a User, and you only look at User Interface.  When you "open a class" a cluster UI widget is loaded to represent the class data.  But that widget is not the actual cluster.  When you "open a subVI", the corresponding front panel is loaded with UI widgets to correspond to the block diagram terminals.  But for most subVIs, that front panel is never loaded if it is not opened. 

    This is unfortunately counter intuitive, as every subVI has a User Interface (Front Panel) a new programmer will think that is significant, while an experienced LabVIEW programmer will intuitively understand that the front panel of most subVIs doesn't really exist at runtime.

     

    • Like 2
  11. Didn't not read the full conversation, but thought I'd point out to the OP that it is a common mistake for programmers coming into LabVIEW to mistakenly identify LabVIEW's UI Widgets (Controls/Indicators) as being "variables", and Control References (actually references to the UI widgets) as being "data references".  They also confuse the UI Widgets with the data that the Widget is acting as a UI for (which I suspect the OP has done when they talked about having many data copies in using "Arrays" and "Clusters").

    Performant data-handling code will not utilize the User Interface at all, and if a "reference" were to be needed, it would probably be a DVR.

    • Like 1
  12. On 7/9/2020 at 5:39 AM, Porter said:

    Bug? JSONText doesn't apply input default values to missing cluster items of array elements.

    image.png.cfac8c824a0c9d7cb52ca3a937cbf166.pngimage.png.8ae1b813f1c246373cf99f02b3bc8356.png

    I was hoping to see "Default", 1 and "2", NaN but instead get "",1 and "2",0

    I think that it is due to the behavior of the Get Array Information VI.

    The workaround is to convert the array elements individually as clusters:

    image.png.30316820d66dc9e23dc0c3ae7f3760c8.pngimage.png.4022f34cc2d9604696e4e09bf7fe0789.png

    Note: you can also do this (using the JSONpath for all array elements) because here one is specifying the element of the array (with default) rather that an empty array:

    254981577_2020-09-2315_44_57-Untitled1BlockDiagramonJSONtext.lvproj_MyComputer_.png.1c8917c4a3694ddfabfb593626f8e9f3.png

    • Thanks 1
  13.  

    On 9/11/2020 at 9:41 AM, LogMAN said:

    I found it actually much easier to just teach those few commands, than to increase the learning curve by adding another tool on top of that.

    TortoiseGit is an interesting middle way between command line and a "full-featured" UI tool, as it mostly just replaces text commands with menu selections, and it can be configured to show the basic few commands (with a submenu for less-used commands):

    291047577_2020-09-1410_48_14-Git.png.82fa70e93813e8ccdb51137b6fbac348.png

     

    Then on top of commands is the "log", which is a visual representation of the repo.

    • Like 1
  14. Tried GitKraken a bit.  Couldn't see enough improvement over SourceTree to consider a paid product (but I may be missing something).   If I were going command line, I would first look into Gitless, and attempt by Computer Scientists to fix the flaws of Git.  There is a paper on it here: Purposes, Concepts, Misfits, and a Redesign of Git.  

    Quote

    Abstract of  "Purposes, Concepts, Misfits, and a Redesign of Git"

    Git is a widely used version control system that is powerful but complicated. Its complexity may not be an inevitable consequence of its power but rather evidence of flaws in its design. To explore this hypothesis, we analyzed the design of Git using a theory that identifies concepts, purposes, and misfits. Some well-known difficulties with Git are described, and explained as misfits in which underlying concepts fail to meet their intended purpose. Based on this analysis, we designed a reworking of Git (called Gitless) that attempts to remedy these flaws. To correlate misfits with issues reported by users, we conducted a study of Stack Overflow questions. And to determine whether users experienced fewer complications using Gitless in place of Git, we conducted a small user study. Results suggest our approach can be profitable in identifying, analyzing, and fixing design problems.

     

    • Like 1
×
×
  • Create New...

Important Information

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