drjdpowell

Any comments on this? Too complicated? Too simple?

You can use lots of them; I often prepare several statements once just after I open the database connection.

But does it leave a path of easy steps for new programmers to learn? If you can only use technique X if you also use techniques Y and Z too, then you’ve introduced a high all-or-nothing step in the learning curve.

Here’s the long neglected Idea Exchange entry for that very worthy idea.

An alternate is below, using synchronous “queries”, where the subVI waits for the remote actor to reply to the command (we don’t care about the contents of the reply, just it’s existence). This seems a lot clearer. It’s disadvantage is that the Main message-handling loop is blocked while the two subActors start up, but in this case that is no problem, as we are preventing the User from doing anything anyway with the Busy Cursor.

I’m hoping to add some sample projects to my “Messenging” package, and I thought it would be easy and instructive to rework one of NI’s templates, “Continuous Measurement and Logging”, as it is already somewhat actor-like with three communicating modules. Attached is a (back-saved for 2011) copy of the NI project, with my version included (run “Main.vi” for the original, “Main.lvclass:Actor.vi” for my version). I kept the basic functionality the same, but couldn’t resist changing some of the UI (in the old code, “Main” controls the UI; in the new code, published state messages from the Acquisition and Logging Actors set the UI). Continuous Measurment and Logging with Messenging.zip Any comments appreciated. Is this example less clear than the NI original? Why? How could I improve it? In particular, is code like this (the most complicated interaction, I think) understandable without heavy documentation? It’s a “Start Logger, then Start Acquisition, then Unset the Busy Cursor” three-actor chain message: I’m thinking of making a “Send Chain Message” subVI (that accepts arrays of addresses and message labels) to replace the above code. — James

Though recently all my multiple event structures have been in separate VIs (often with front panels assembled via subpanels), I don’t see any reason why multiple ES shouldn’t be on one block diagram. And I certainly had such on multiple occasions in the past.

I make a project that holds EVERYTHING that references the classes involved and then rename classes and move things about in the Files tab. Once the set of things referencing it becomes too big, or I have it in a reuse VI package form, then I’m stuck with Darren’s solution. — James

I looked into zeroMQ with the idea of using for actors, but I couldn’t really identify how it would work for me better than just using TCP connections. ZeroMQ has many communication patterns, but none really matched up to what I need in an “Actor’s address”.

For anyone using this package, I’ve uploaded the latest version (should really have updated this more than once a year). I’d like comment on the following new features: This is one of three asynchronous dialog boxes. This can be used in a “delayed message to oneself” form of doing a continuously updating process (as opposed to using the “Metronome” helper actor or the (ill advised) timeout case). Intended for when the reply is uncertain. With this VI, a process can be confident that it will get a message of some kind back, and thus does not wait forever. Observes an address and triggers a response if that address goes invalid.

I had original made similar probes using an Xcontrol, with the idea that display customization would then be easy (and clean, using right-click menus). But after a lot of head banging I abandoned Xcontrols as unsuitable (lossy if asynchronous; too slow if synchronous) and wrote this package in an afternoon. They are, thus, very 1.0. Haven’t felt much need for a pause option, as I can always just select a different probe for that, and I use these probes in debugging communication between parallel processes; pausing one process while the others continue can be unhelpful. Adding a “pause the probe” option is very easy, though, and I see that Saphir’s probe has this option (labelled “Freeze display”). I’ll consider that for the next release. Thanks.

As an aside, there is also LabbitMQ, a LabVIEW interface to RabbitMQ, to consider.

View File Cyclic Table Probes A package for creating custom probes with "history"; showing the last N values rather than just the latest. Values are displayed in a cyclic table, which wraps around automatically when it reaches the bottom of the display window. Developed to support messaging systems, where messages can be handled too quickly for the eye to see with a last-value probe. Included are some standard probes, for strings, variants, objects, and some numerics. Also included is a "Text Variant" probe, for messaging using a cluster of such, and a "JKI State Queue" probe for use in designs using the JKI "state machine" template (see image). But the expected use case is for very easily creating custom probes for whatever messages one is using (just modify one of the included probes). Also includes "Quick Timer" probes to rapidly time execution of portions of code to accuracies of as low as 10 microseconds. Now hosted on the LabVIEW Tools Network. JDP Science Tools group on NI.com. Requires VIPM 2017 or later for install. Submitter drjdpowell Submitted 11/16/2013 Category Custom Probes LabVIEW Version 2013 License Type BSD (Most common)

Try adding a method to your child classes. That seems to make them stay under “Dependancies>>items in memory”.

Anyone get a chance to test the new modifications on a system experiencing 1097 errors? I’ve encountered no issues with the new package, so I’ll release it to the CR soon.

I like to go a step further and try and represent things graphically. For temperature control I plot the "Proportional Band”, the range of temperatures where the heater output would be between zero and 100%, on the same graph as the process variable. Tuning is still by intuition, but with more visual information to go on. You can see the effects of the PID parameters in the twists of the proportional band.

Your device likely only has one ADC, with a multiplexed input, that can do 200kS/sec in total on all channels, or 200/16=12.5 kS/sec on each of 16 channelschannel.

Actually, turns out the client was running XP when they had an error. But, my XP is running on a virtual machine under Parallels on a Macbook, so perhaps that changes the memory protection and is why I have never had this error in testing.

Attached is a new VIPM package (beta) with modifications to how “Prepare" works to avoid reading outside the allocated memory. I do not know if this will solve the problem, but as an added benefit the new method will give improved performance of “Execute SQL” for multiple SQL statements. Please give this a try and report if it eliminates the 1097 errors. drjdpowell_lib_sqlite_labview-1.2.0.28.vip

“Badly formed query”? Excuse me?!? Yes, that comment form is valid SQL. Beta version, seems to be working: Does the LabVIEW string to C string conversion explicitly, allowing the difference between the two pointers to be used to calculate the number of bytes of remaining SQL.

Well, this has just become a lot more relevant for me as a customer just emailed me this: First time I’ve seen it. I use Windows XP while the client uses Windows 7; I wonder if 7 is more unforgiving of “reading someone else’s memory”?

In this code I had the problem that the SQL statement is passed into the “prepare” dll function by pointer, but I don’t have access to that pointer, so I can’t calculate the length of the remaining part of the statement. So I instead copy the maximum amount, including any invalid junk off the end, and then walk the string till I hit the null terminating byte (done inside “pointer to C string”, where the junk bytes are discarded). Can “reading someone else’s memory” cause an exception? If so, I’m surprised I’ve never had this error myself. If someone can confirm this as the problem, then I can rewrite “Prepare” to convert the LabVIEW string to a pointer first, then do things by pointer.

I still cannot see what might be causing this error. You should defiantly have a shift register in your code, to guard against the case where the for loop is called zero times (is there any LabVIEW developer out there who didn’t learn this the hard way?). But I can’t see how this could cause the described error. Here is the code of the “Prepare” method: The error can only happen if: 1) sqlite3_prepare_v2 dll call runs without error. 2) “Statement” handle is returned greater than zero. 3) “Remaining SQL tail” pointer returns zero or invalid. I would expect most problems (invalid dll path, for example) to violate (1) or (2).

Do you use multiple levels of abstract classes? File.lvclass<— LVfile.lvclass<— VI.lvclass, for example? A HasBlockDiagram method would be defined in the LVfile class (default result FALSE) and would be overridden in VI.lvclass to return TRUE (but not overridden in LVLIB.lvclass).