drjdpowell

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.

That seems to say it is the f1 patch of 2017 SP1, rather than SP1 itself.

Thanks, both of you. Sounds like the only major issue with the CVT is the non-atomic update of sets of values, which presumably can be managed by clusters of related info.

I'm helping a new client that has existing code that heavily uses the Current Value Table (CVT) library and the network extension CVT Client Communication (CCC) Reference Library. Does anyone use these libraries and what are peoples opinions on them? I would particularly like to know if it scales well to large numbers of CVT values. The authors of these packages seem to have moved on to DCAF, which makes me worry that there are issues in using CVT-CCC.

Are you aware of "Get Numeric Information" in the vi.lib\Utility\Data Type? Gives you the enum strings. One doesn't need to use Flattening to work with Variants anymore.

I notice that you reopen the DB file on each query. If you instead opened the file once on initialization, then you'll be less affected by an intermittent file access problem. The issue might be anti-virus software, or some other software that trolls through files for some reason, temporarily locking them. Has any such software been added?

I have not done any PPL work, but the basic first step is to build Messenger Library into one or more PPLs. This may involve changes in library membership to properly group things into PPLs (so it might be a bit of work to convert over existing projects). Then (I think) one just has to make your code reference the new PPLs and build your own PPL. If you want to try it, make a fork of Messenger Library, through all the extra bits of it into the main "SendMsg" library and see if you can make a PPL.

Repo is on Bitbucket. The VIPM build is "Flat Controls.vipb". See if you can build it under VIPM 2016. Even if you can/t, you can just take the controls directly from source.

I'd have to remind myself but I think the text has to be on top of the decal (so the User can click on the text), so you can't colour the text background, but you can colour the outline box that sits behind both.

I'll update the documentation. Thanks. To be honest, I don't think I have written code to actually shutdown a Metronome actor in five years. I just let them shut themselves down automatically. Sometimes I don't even want to adjust the period at all and then I don't even bother wiring out the Metronome Address. For example, here I need to limit the total size of debug log files and check them once an hour (3600000 ms). It's "set and forget"; no shutdown code needed.

This is Issue #9. Unfortunately it's a "pick your poison" situation as to which undesirable situation to have, a bug that sometimes locks libraries or having ActorNR non-reentrant actors fail to launch subactors. I am unsure what to choose. Either way is annoying. A workaround is either to have the Top-Level actor be reentrant (as you found), or (assuming you don't need it to be "launched") just rename the VI so it is no longer part of the "Actor.vi" set of Dynamic Dispatch methods (the fact that the non-reentrant ActorNR can theoretically recursively "launch" itself is the thing that LabVIEW is chocking on).

Did you send "Shutdown Actor"? I don't use "Shutdown" as a command anymore, because it is sometimes used as a notification that something has shutdown. "Macro: exit", BTW, come from the JKI Statemachine that I used to use as an actor message handler.

Any objections to moving SQLite LabVIEW up to LabVIEW 2013 (from the current 2011)?

Note the difference in the quote marks. My Mac replaces the generic double quote with starting and ending quotes (which, presumably, are higher Unicode code points). Your computer (Windows?) does not. I think these character codes are getting mangled during site upgrade, leading to gibberish. Does anyone else post from a Mac (and Safari)? An Edit made from Chrome (same computer): "Test from Chrome" --> no fancy quotes, so this issue may only affect Safari Users

My posts seem to gather these corruptions whenever the site gets upgraded. I post from a Mac, and that might be part of the issue. Seems to be the various types of quote characters. “Here is a Test” to see what'll happen in future.

A “last element” VIM would be clearer than using “delete”, as it could have an icon that suggests the last element I use a “first and last element” VIM because I often need both to determine ranges.

With integers you can do ranges like <=3 and >=4, and there is no gaps. But with non-integers you cant: <=3 and >=4 misses out all numbers between 3 and 4. But you also can't do <=4 and >=4, since then 4 falls in both ranges. So you have to do <4 and >=4, and thus have a range (<4) which does not include its endpoint, confusingly. Strings are actually more like floats, than like integers; between "c" and "d" is "ca", "cz", "czzzzzzzzzzzzzzzzzz", etc. Even if "a..c" included "c", it would not include "ca". There is no way to do non-overlapping-but-complete ranges with strings without not including one endpoint. Unfortunately, people intuitively think of "a..c" as anything starting with "a" to "c", but it isn't.