Jump to content

drjdpowell

Members
  • Posts

    1,920
  • Joined

  • Last visited

  • Days Won

    166

Posts posted by drjdpowell

  1. 4 hours ago, Rolf Kalbermatter said:

    And together with the SO_EXCLUSIVEADDRUSE flag this makes new requests to create a socket on the same port fail with an according error, since the port is technically still in use by that half dead socket. That socket gets eventually deleted and then a new Create Listener call on that port will succeed, unless someone else was able to grab it first.

    Are Listener ports affected by this "half-dead" issue?  I would have thought this is just and issue of TCP Connections (with a connected remote party) rather than a Listener.

  2. 11 hours ago, ShaunR said:

    What's the error?

    Sadly, I don't know as such an error would get lost in the code as written.  This is a rare error in code deployed code on a low-powered single-board computer.  Appears to be a loss of TCP connection, followed by the Client not being able to reconnect (which is why I suspect the Listener dying).  An added clue is that an additional third-party non-LabVIEW TCP server seems to fail and restart itself at the same time (according to entries in its log file.

  3. What work does Type Cast need to do with arrays that it doesn't do with strings, which are just arrays of bytes?  Seems to me that the fastest cast would be something like array of U64 to Doubles, as those are the same size and don't require any length checks (unlike, say, a 9-byte string to array of 8-byte Double).  Is the problem not a missing optimization for U8, but instead nonperformance code for numeric arrays?

  4. Here is a quick hack from some existing INI parsing code I had.  See if this works on NI-MAX files.

    2022-06-22 09_59_21-INI to JSON Example.vi Front Panel on Untitled Project 2_My Computer.png

    This VI converts the INI items to JSONpath notation, converts the values to JSON strings unless already a valid JSON value (such and numbers, true, etc.), and uses the JSONtext VIs "Unflatten JSONpath Array to Object" and "Pretty Print" to convert to JSON.

    INI to JSON Example.vi

  5. 1 hour ago, dannyt said:

    I had an issue building a executable using the package as it introduces a missing Item within Malleable Buffer.lvproj

    That is the Project I use to develop the library; it isn't meant to be used after install (and doesn't update the various paths, such as to teh examples).   I should probably not include it in the VIPM.    If you'd like to fork the package and develop it, I'd recommend forking the Git repo. 

    That menu should have been installed by VIPM, though.  

  6. 16 minutes ago, Mads said:

    The reason I though the $.[0] notation should work was that if I tested it with https://jsonpath.com/ it (almost) seems to find what I wanted...

    JSONpath doesn't have a specification, unfortunately, and so you can't really rely on different implementations matching on edge cases.  I also haven't implemented everything (just due to teh effort required that I don't have time for).

  7. 17 hours ago, Mads said:

    I did successfully rewrite the demo to work with JSON using JSONtext, but then I just treated each array element as a separate JSON string and ran Set item on each of them with the path $.<Label.text>

    That would be a perfectly good choice.  You could also use an array of paths like '$[n].Enabled' and call Set Item in a loop.  

    Aside: Note that you could also use a JSON Object rather than an array to hold your list of targets.  Like this:

    {
      "My Inst X":{"Enabled":true,"Hello":-2,"Hi":6},
      "My Inst Y":{"Enabled":true,"Hello":-2,"Hi":6},
      "My Inst Z":{"Enabled":true,"Hello":-2,"Hi":6},
      "My Other Instrument":{"Enabled":true,"Something Else":true}
    }

    I mention this as I have noticed that LabVIEW programmers often get stuck in a mental model of JSON Objects and Arrays mapping onto LabVIEW Clusters and Arrays.  In particular note that JSON Objects are not fixed type and number or elements at edit time (unlike Clusters), and JSON Arrays are not restricted to all elements having the same type (like LabVIEW Arrays).

    I also made the last instrument in my example one with a differences in its config structure.  By using JSON, you can still let your User change common settings (like "Enable") even with instruments that cannot be represented as the same LabVIEW Cluster. This is an example of "Duck Typing", which can be difficult to do in LabVIEW otherwise.

  8. 17 hours ago, Mads said:

    and try using Set item with the path $.[*].Enabled e.g. when that value changes, it returns an error. Accessing just one of the indexes ($.[0].Enabled e.g.) fails as well.

    You should be using $[*] or $[0] to indicate Array elements; $.[*] indicates all items in a JSON Object and $.[0] is the Object item named "0".  Look at the detailed Help page for JSON Path notation in JSONtext.

    • Like 2
  9. Two suggestions:

    1) Consider using JSON as your config-data format, rather than clusters.  Using JSONtext to manipulate JSON will be faster than using OpenG tools to manipulate clusters.  

    2) Programmatically get an array of references to all your config-window controls and register a single Event case for Value Change of any one of them.  Then use their (hidden) labels to encode what config item they set.  For example, your control with the caption "Baud Rate" could have the hidden label "$.Serial Settings.Baud Rate" which is the JSONpath to set in your config JSON (or config clusters).

    • Like 2
  10. On 3/19/2022 at 2:08 PM, Dataflow_G said:

    The LabVIEW 2021 SP1 bug fixes mention a fix (bug ID: 1596011) for vims and erroneously broken wires, but I've not tried it out yet. I really hope that's the end of the broken wire quirks with malleable VIs, as they're a really great feature.

    Thanks. I see there is also this one that may be the problem I'm having:

    1513139        Malleable VIs Are Sometimes Erroneously Broken When Operating on Cluster Data Value References

  11. @AQ,  I've incorporated most of your improvements, and made some changes myself.   Question, though.  These VIMs seem plagued by (in LabVIEW 2020) strange recompile bugs: broken wires that are usually fixed by doing a manual force recompile on the VI.  Though often this still leaves some broken wires in a runable VI?!?  See image.

    1579043869_Brokenwireyetrunnable.png.c7f4ede40ed758cb65fcc478d4aca4da.png

    What do you think causes this and is there a way I can avoid it?  

  12. 18 hours ago, Виктор Зиновьев said:

    I tried to add &cache=shared or with ? to the file's path but it does not work

    Did you add "file:" to the front to make a URI path.  And what do you mean by "does not work"?  What are you expecting shared-cache mode to do exactly?  Shared Cache has nothing to do with multiple computers accessing a db (and yes, that is something you would be better off using Postgres).

×
×
  • Create New...

Important Information

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