drjdpowell

SQLite isn't a database server; it's intended to be accessed only locally, not over the network. See https://www.sqlite.org/whentouse.html.

Conditional Tunnels had no performance benefit in 2012, but beta testers of 2012 argued for higher performance, and for 2013 they were changed to use the same techniques used with indexing While Loops, which are much higher performance and not something one can do another way.

I would say the conditional and concatenating tunnel options are a very notable feature introduced post-2009.

If it's an additional "fix it up function" then I can support many versions easily. Might be slower, but one doesn't care about raw speed in a config file use case. But I'm wary of adding more extended features to the core functions, where I do care about speed and simplicity. As an example of the simplicity issue, currently one can overwrite whitespace when setting values in a JSON. I use this to allow quicker setting of items in the JSON, allowing update in place where possible. If I have 10 char of whitespace and overwrite 4 characters, I now have 6 char or whitespace. But if I have a 10-char comment, and overwrite 4 char, I now have corrupted JSON.

It's a Client-Server design, where the cRIO actor would be the Server. A disconnect of the Client has no affect on the Server and it continues to run. The Client (on the main computer or another RIO) needs to detect the disconnection and attempt to reconnect. Nobody needs to shutdown, though the Client will need to go into a loop of trying to reconnect every few minutes until the network is back up. See the conversation starting here, where bbean was dealing with the issue of the Client not being able to connect to the server.

Do you want to be able to programatically add comments, or just ignore them on reading? I am wary of adding features to the core functions as I want to protect its speed and simplicity, but I don't mind additional functions. In fact, I've been considering a function that is intended to take human-edited JSON and "fix it up", correcting common errors like leaving an extra comma when deleting. This could easily strip comments.

Error 1510 is "The requested service was not found as a registered service with the NI Service Locator.” Does the LabVIEW Example "TCP Named Service" work on the two machines? Did you use the right IP address?

To my understanding, the data type is fixed at design time but the Event Registrations are run-time dynamic. I think Jack Dunaway's excellent examples on User Events showed this.

I see your point there; a "read only on first call" input makes sense. Unfortunately, it doesn't just read the input on first call, and there are use cases (though perhaps rare) where one might feed in different refnums on each iteration. If you look at the example I posted, the input tunnel to the loop actually changes what it outputs, which breaks the dataflow rules. I agree they should not have changed the behavior that has applied for so long (especially without telling people).

It's too bad they didn't "fix" it by allowing this (where I take Shaun's original code and just delete the constant): Assuming an internal shift-register behavior in the Event Structure, then this "uninitialized shift register" behaves in a perfectly dataflow-like fashion, and it's even simpler to code. Unfortunately, it's also broken, as the Event Structure wont adapt to the type input to the right-hand Dynamic Event Terminal.

No, one can build that exact structure with Queues. The Queue is created outside the loop and never changes, so it can be passed in via tunnel and doesn't need to be "passed-through". The confusing issue is that the "Register for Events" node acts like "Obtain Queue" when called with no active Event Reg Refnum as input (as outside the loop in the example), but doesn't if an active refnum is supplied (as inside the loop). Unfortunately, the Events API is quite confusing.

Here's a modified VI with a breakpoint and instructions on how to see the non-dataflow behavior (LabVIEW 2015): evnt (with Breakpoint and probing instructions).vi

No, that's the way I've done it for several years. That's the dataflow-consistent way to do it. Your way of acting on a zero-refnum tunneled in that "magically" becomes an active non-zero refnum breaks the dataflow paradigm.

Try imagining the equivalent Queue operations. I found Dynamic Events confusing until I realized that the Event Registration Refnum is like a Queue, and the User Events are like a reference to an array of registered Queues. If I drop a Queue constant before a loop, then have "Obtain Queue" inside the loop, then if I want to enqueue or dequeue in another case of the loop I must feedback the obtained Queue refnum. I can't do anything with the original Queue constant (refnum=0). Similarly, if I feed in an active Queue and then destroy it with "Release Queue", I can never use that Queue refnum again but must instead feedback a newly created Queue's new refnum. This is standard dataflow-with-references behavior that Event Registration Refnums used to allow the breaking of. This was a mistake on their part, but "fixing" it is also a mistake as some prior code will be broken (worse, broken without an error message anywhere).

It's a constant Event Registration Refnum (refnum=0 aka null). Calling the Register function creates an event queue (refnum<>0); just using a constant does not.

Deregistering an event is like this: Note that this leave existing events in the event queue (one can Flush if one wants).

Sorry, I missed that you had already mentioned this method.

I think I once discovered this strange behavior (which I guess someone decided to "fix"). The code Shaun posts works even though it intuitively shouldn't, since the constant he feeds in is null (refnum=zero), and not an actual active Event Registration. Yet it does work. In fact, if I remember right, one could "retain all wire values" and then probe the null Event Reg outside the loop, and it would actually show the refnum of the EventReg created inside the loop! BTW, I do such delayed-registration this way, which does work still: This creates the Event Reg outside the loop, but with a null User Event constant, then substitutes the actual User Event later.

It seems strange that you feel your current Actor Framework project has "come out really nice", yet you don't want to use it in your next project because it "doesn't really need it".

Then it's probably JPEG data. Why are you trying to unflatten as a LabVIEW 2D Picture format (which is NOT JPEG data)? I think you need to research data formats and how to convert between them. Stop guessing randomly and read the documentation. Also use your probes to verify that what you put into SQLite you get back unchanged. You aren't having any problems with the SQLite part of your program; you just having issues understanding formats. This might help you:

Read the address and test it by one of these methods: The left one tests for a "Null" address (the standard parent "Send" object), while the right one tests that the reply address is still "valid" (meaning a message sent to it will go somewhere).

Note: JSONtext is now on the LabVIEW Tools network.

Are you familiar with the "Probes" in LabVIEW? I ask because you seem to be debugging by looking at the db file with a viewer program, but you could have quickly seen that "Read from Binary file" was only returning one byte by just putting a probe on the output.

I think you need to provide an example. Otherwise people can only guess what the issue is. For putting a binary file into an Sqlite blob l would just use "Read from Binary" followed by "Bind Blob".

JSON is starting to overtake XML for data exchange. JSONtext should work on RT, though I have yet to try it.