drjdpowell

Thoughts on just watching it: 1) More pictures; fewer words. 2) I suggest starting with the Message-Handling Loop or QMH (that people will be familiar with) and talk about what restrictions would make this an Actor: — communicates with other code/actors ONLY via messages to this SINGLE loop. No by-ref data sharing or other communication methods. — no global addressing (eg. no “named” queues) 3) mention “high cohesion and loose coupling”; an actor is a cohesive unit that is loosely coupled to other actors.

Yes, that’s right.

If you want to update the graph only after events come in, but don’t want the overhead of updating every event in a “burst”, you can put a “-1” constant inside the timeout case and wire it back through shift register into the timeout, and set the tunnel out to “Use default if unwired” so that the timeout is zero after any event other than timeout.

My Mac is pre-retina, but have you tried playing with these settings?

I generally hide the toolbar on the front panel. One can still access the hard-stop button by opening the block diagram. I also usually capture the “Panel Close?” event and use it to trigger ordered shutdown, so a User can hit the X button to stop the program correctly. I’m not sure there is an easy way to clear the lock if this happens, other than restarting LabVIEW.

Just in case someone is urgently needing this bug fixed.

I’m about to go on holiday for two weeks, so I’m going to post a CR version with just the bug fixes made by James McNally, leaving other issues for later.

I may be missing something, as I haven’t used other OOP languages, but can't we already create “constructors” and “destructors” and get polymorphism through polymorphic VIs? Polymorphic VIs could do with an upgrade to interface more nicely with dynamic dispatch methods, but otherwise what are we missing? “Overloading” is not interesting to me because I don’t specify functions by typing their names. — James BTW, your “Singleton” example isn’t a singleton; I can easily call the constructor multiple times and make multiple instances of the class. Also, I didn’t understand the “DVR cannot be used for dispatching” issue; I tried making a child class with an override and it worked fine.

I scored 60% coverage and passed (barely).

Looks good to me. Any other changes before I make a new VIPM package?

You need to do a “JOIN” of your lookup tables to the main table.

Why are classes D and E not children of C, if they are to use C’s method?

Thanks.

Still down. I’m going to try “Report to Moderator” on this post.

Playing around with Queue tester, it was interesting how most of the slow queue performance is due to attempting operations in parallel. In a striped-down test (statistics removed) it was about 8 times faster if it was run in the UI thread (forcing serial access). It was 0.6uS per element on my relatively slow processor.

I noticed that sequencing the two “Enqueue” operations (by connecting the error wire) increased the queue performance greatly on my system.

How did you install it?

Do you mean you are building an EXE executable? I would suspect the problem is not getting sqlite.dll included. Check the “Preview” page of the build and see if sqlite.dll is installed under “data”. Sqlite.dll is part of the “Connection” class library and thus should be included, but I noticed just recently that the library, when installed with VIPM, loses it’s connection to this file. If this is the problem, you can fix it either by opening the “Connection" class and fixing it to include sqlite.dll, or adding sqlite.dll to the “Always Included” section of the build spec.

Can you provide a hardware trigger at the high point of your pulse peak? Then you could trigger the DAQ read at the exact peak.

A discussion here.

I can do that. Wait, what?!? How can I have missed that little option for so long! Thanks. Can one set a while loop to index by default for new tunnels? As I understand it, vi.lib is now recommended for installed packages. I’m not a Quickdrop user so I don’t notice these things. It looks to me like Quickdrop uses the VI title rather than VI name, so I may be able to improve things without breaking backwards compatibility (make the title of Open.vi “SQLite Open” etc.). Hey now, "(,,,) FROM” comes up as the very first entry in my Quickdrop so why do you need to type it? Actually, I’ve considered removing those two SQL formatting utility VIs as I haven’t found the need to use them. Have you found them useful?

Do you have a four-core machine? I ask because then four clones will initially be reserved of the various shared-clones at start, and then the fifth instance will require a new clone. In working with shared clone pools (through an 0x40 reference to "Open VI Ref”) I have sometimes noticed what seems to be a delay in getting that extra clone when it is asked for soon after the reference is opened. BUT, I have never seen this delay actually stop code from working.

Are you overriding “Pre-launch Init.vi” such that it might produce an error (thus preventing the sending of the enqueuer back to the Launch VI)?

You supply a reply address, and its optional. And the reply address does not have to be the sender’s; replies can be directed to any third party that the sender has the address of.

Ah yes, each message contains a reply address of “Send” class. So messages depend on “Send”, but not (I think) on any of the child classes of “Send”.