drjdpowell

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 know, people should be trained not to stop the execution that way, but this will happen. I don't want to hide this button, since it might be necessary to kill the program from time to time during development. So I'm looking for another way to handle this.

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.  

Why not just wait until you come back when the others will have been addressed too?

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?

Question is how do I get the actual values of these lookup tables rather then the indexes to the fields of the lookup tables?

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.  

I didn't install it using VIPM though.

How did you install it?

What I wanted to do now is to code a simple standalone viewer for the database so I can see what my testrig is doing while I'm in my office/at home. The problem is: when I try to run the compiled code, it simply does not work...

It compiles and runs nicely, I have no access to the database though. Nor any error message. And I didn't even try it on another machine, it's still my lab-pc running Win7 and LV2011.

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.

Needing to capture a peak value. Not willing to rely on sofware timing for fear of missing the actual peak in between LabVIEW read cycles.

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.

^{[citation needed]}

A discussion here.

• Could you expose a read accessor for "database path"? It'd save me some effort when wrapping the API in higher-level classes.
  

I can do that.

• Could you remove ".lvclass" from the class Localized Name (in the Properties dialog)? It'll make class property nodes smaller on the block diagram.
  

Wait, what?!?  How can I have missed that little option for so long!  Thanks.

• I would make the tunnel mode "indexing" on "Get Column Template Code.vi", since that's how it's used 99% of the time.
  

Can one set a while loop to index by default for new tunnels?

• Please put your package in <addons> or <user.lib>, not directly into <vi.lib>!
  

As I understand it, vi.lib is now recommended for installed packages.

• This would be backward-incompatible, but I'd like to see the VI names changed so they're more "Quickdrop friendly". At present, there are names like:
  • "(,,,) FROM.vi" which is hard to type
    
  • "Get Column Template code.vi" which I think is confusing to read and remember
    
  • "Open.vi", "Close.vi", Step.vi", etc. which are hard to discern from other libraries (and primitives!!!) whose palette items share the same simple names.
    
  • Many (all?) of the VIs don't appear in QD unless the API is added to my project. This might be due to the API not living in <addons> or <user.lib>.
    

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.

Regarding the inverted dependency...

In LapDog.Messaging, the MessageQueue class depends on the Message class, but not the other way around.  Slide #3 of your presentation shows the Msg class having a dependency on the Send class.  Originally I though you were implementing MyMsg.Send methods similar to some of the early AF prototypes.  However, if I understand correctly that dependency exists only because you built the ability to reply into the your base Msg class.

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”.

On which part?  100% visible/invisible?  Overriding Send?  Inverting the Message/Transport dependency?

How would you do it?  (Though you can explain what you mean be the Inverted dependency thing also.)

Earlier you said, "Other methods of RemoteTCPMessenger can send alternate messages to TCP Client to control it."  If the RemoteTCPMessenger.Send method wraps all incoming messages in a SendViaTCP message so the TCP actor will automatically forward them through the network, RemoteTCPMessenger needs other methods to send messages to the TCP actor without wrapping it in SendViaTCP.  Either a general purpose RemoteTCPMessenger.SendButDontForward method or unique methods for each public call.  (RemoteTCPMessenger.SetPortNumber, RemoteTCPMessenger.Close, etc.)

Well, the methods that send messages meant for the “TCP Client Actor” are dynamic-dispatch overrides of “Create” and “Destroy”.  The only extra API method that RemoteTCPMesenger adds to the standard Messenger API is “Remote Service”, which is called first to define the IP address and service name to connect to.

But I’ve lost the chain of thought.  Remember, I need RemoteTCPMessenger to work in an extensive body of code that works with the generic “Send” and “Messenger” classes, thus I need to have it work through a predefined simple API (Create, Send, etc.), not some new TCP-specific API.  Large parts of the codebase must be blind to the fact that it is using TCP.  If the internals of RemoteTCPMessenger need to be slightly unclear to achieve this, that is no big problem, as the user of the messaging package doesn’t need to know this internal detail.

If this means what I said above about making the network layer either 100% visible or 100% invisible to your main app, then I agree.  I don't think overriding Send is the best way to get you there though.  (Your system inverts the message/transport dependency from what I'm used to, so I may not be fully understanding how the elements are used.)

Could you expand further?  I send messages to an address, after someone has created the address; which I think is the same as how Lapdog does it.

Here, BTW, is an example I’m going to add to the next version:  A TCP client that communicates by request-reply with a server, and receives the messages back (for demonstration) in three different ways (by queue, User Event, or Notifier).  The only TCP-specific API method is the “Remote Service” VI called first.