drjdpowell

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.

In my case, the CRC is because the Setting file lives in flash memory on the hardware, and is downloaded to the computer, so we are guarding against corruption. Customers (operators) never see this file, but internal people (techs) need to read them. They could edit them, if they wanted to do that instead of using the configuration tools.

JSON is properly escaped, so you can put any binary data in a JSON string. However, I do just standardise on JSON.

I started doing that, but switched to an "outer" JSON object with the sections "Rev" (data version number), "Settings", and "Other Info" (which records timestamp, User, computer, software versions, CRC-32, etc.).

I use JSON, and have a library for JSON, which has recently been added to the LabVIEW Tools Network. I don't modify the config files with a text editor, though; all config editing is done in the Application itself. I also do a bit of JSON in SQLite.

This is Issue 9, I think. It's an annoying "pick-your-poison" issue. The alternative is to accept the "locked-code" bug. The problem is that an "ActorNR" non-reentrant actor can theoretically try and launch itself, and LabVIEW is rejecting that possibility by preventing the launch of any actor (including "Metronome") if an "ActorNR" is run from the run arrow. A workaround is to rename the "ActorNR.vi", either to "Actor.vi" (and change to shared-reentrant), or to any other name (this means they are no longer "launchable" but you can still run them from the arrow). I may go to back to the design that has the "locked-code" bug with the next version, as at least that is more annoying than a true block, as you just need to reopen your project occasionally. But if I can make time, I might be able to come up with a better workaround. BTW, the newest Messenger Library now contains the non-TCP project (modified to work) as an example.

I was going to say I don’t do blanket shared-reentrant, as that create at least one copy per processor, and for lesser-used functions this is memory overhead that is often not justified. However, I’m not sure that is true of LabVIEW 2017 (seems to be only one clone).

Comments: 1) that error is what you get if your path-to-the-db is wrong. You are opening read-only, so it will fail if the db file does not exist at that path. So I suspect your path generation code is wrong. When I fixed it up I could then open the file. I opened it multiple times without error. 2) Your Query control was empty, and your various SQL constants referenced columns that don’t exist. I had to make up a new SELECT statement. 3) You can’t use dates in the format day-month-year and select on it, as alphabetical sorting is not time-sorted. I set your Start and End times as 01/01/2000 and 31/12/1999 and got every one of your records. Use ISO-8601 format (year-month-day). I advise you use the inbuilt support for Timestamps as Text (Bind Timestamp(Text), and Get Column Timestamp). Use Timestamps, not separate fields for Date and Time. 4) I used SQLite Expert Personal to test and inspect your db file. You can use this to aid debugging, as you can use it to build and test your SQL before copying to LabVIEW.

Make sure your VIs are the right reentrancy, as that dialog will happily change the parent methods in VI.lib. All "Actor.vi" should be shared reentrant, and all "ActorNR.vi" should be non-reentrant.

For me changing reentrancy is instant. You aren't accidentally saying "Yes" to changing all actors reentrancy are you? Just say no.