drjdpowell

Here it is, for what it’s worth. From 2008, I think, LabVIEW 8.6. It’s rather too complicated for a first time programmer. You should either see if the Example program works on a NE-500 or NE-1000 and just hack that, or use the low-level communication subVI “New Era Pump CommandResponse.vi†along with the New Era manual (which contains the text commands for it). New Era Syring Pump.zip

I’ve used New Era NE-500’s before quite successfully and could possibly dig up some code for it.

Oh, I missed that case structure (I can’t read VI snipits on my machine). So you are building a Listener history.

Hi Paul, Are the current LVLIBs the best for the use case of “collections"? If you were to reuse most of your Commands in a modified component in a new project, but with some replacement Command classes, you would not be able to do that, as a Class/VI can only belong to one library. You could reorg things to have a “CommonCommands†library and a couple of “ExtendedCommand for XYZ†libraries, but this requires changing the namespacing of your original project. Aren’t LVLIBs combining too many features into one construct? Also, to all: It may be the case that “Best LabVIEW Practices†will naturally lead to use of Libraries that is non-problematic. But reasonably good LabVIEW practices should produce reasonable good (and reasonably easy) solutions. LVLIBs don’t currently allow that, at least in combination with LVCLASSes.

I don’t think you an avoid a history recorded somewhere. Your solution above won’t get notifications that occur between calls to “Wait on Notificationâ€. Though if you were to keep a history of listeners in the Notifier structure (in contrast to the current LabVIEW Notifier that keeps a history of Notifiers in the Wait node), then this might be better, as the list of Wait nodes should be finite, in contrast to the potentially limitless number of Notifiers.

That’s just it; the LabVIEW IDE is not removing unused functions. The EXE builder might, but not the IDE. It is compiling them and otherwise using them fully. If a C IDE had compile-on-the-fly where it compiled all those unused functions then it might well have performance issues that annoy some C developers. I would be happy for unused library members to appear under dependancies, greyed out to show the compiler is ignoring them.

Wait, never mind, I think it is a Mercurial/TortoiseHg problem (or User error in using it). Reverting back to a month ago, then reverting forward to today fixed the issue. I think the class file wasn’t being reverted correctly. After reading replies: Compiled code cache, of course! Should have thought of that. Reverting far enough back may have triggered a recompile thus clearing the error. Thanks guys.

I cannot figure this out. I made some changes to the private data of a class that caused the various unbundle nodes to get mislinked when they tried to auto-select the right new elements, leaving several broken methods. No problem, I thought, I will revert to the previous clean copy in Source-code control (using TortoiseHg). However, whenever I reopen the class, the unbundle nodes are still mislinked and VIs are broken! I reverted the entire codebase to a week ago to be sure I had a good copy, and I rebooted the computer — still broken! All my methods, even the unbroken ones say they need to resave because “Type Definition modifiedâ€. My question is: what is modifying my “Type Definitionâ€? It can’t be any of my source code, so what can it be? Where is the change located on disk?

Can we get rid of LVLIB “libraries†then? Or at least rename them as they don’t match the English meaning of library? Libraries are not "collections of books that cannot be read except all at onceâ€. And can we have an actual library construct that does collect related VIs with namespacing and scoping? Why don’t we have proper libraries in LabVIEW?!?

It is more intuitive, quite true, but it also has the potential ability to consume memory until an app crashes, which is a possible argument for keeping it advanced. Personally, I would advise against using Notifiers in complex ways like this regardless.

I’m all for advanced stuff to do advanced things, but I don’t want to have to build a carefully-structured dependency injection just to use a utility subVI. I’d rather just leave it a library orphan.

That’s alright. Polymorphic VIs certainly have the same issues. Though at least with them I can see why they might entail loading unused code, while with the library thing it seems entirely pointless. Similarly with Classes; I can see why one might need to load all Dynamic Dispatch methods, but not why LabVIEW insists on loading classes or static methods not used by any in-memory VI.

This is a standard thing to learn with SQLite, which is an “ACIDâ€-compliant database. The “D†is for durable; by default SQLite is durable against power-failure of the computer, meaning once a transaction has executed, in can be relied on to remain, and not be corrupted, even if power is lost in a subsequent transaction. Durability requires that SQLite verify proper writing to hard disk, and as hard disks spin at about 100Hz, this mean that the number of durable transactions is limited to an order of 20 per second. You can disable the durability requirement, but a better strategy is to group multiple INSERTs into a single transaction by wrapping them in BEGIN…COMMIT SQL statements. See on of the Examples provided with the package to see how this is done (you just need to execute “BEGIN†before your loops and “COMMIT†after**). For simple INSERTs, one should get greater than 100,000 per second. **also see SAVEPOINTs in the www.SQLite.com documentation.

Oh yeah, DUH, this is why the “Advanced Notifier Waiting†subpallet exists, isn’t it? I’ve never used notifiers in such complex ways and so I forgot about it. If one doesn’t need the many-readers ability of notifiers, one is better off sticking to queues. The “Future Token†class, which is what I use to solve “wait for something to reply†problems like the OP’s, is a Write-Once, Destroy-on-Reading, single-element queue. I shall add a "Wait on notification with history†method to my NotifierMessenger class in case people find uses for this. Thanks.

Is that wise? What if your API optionally interacts with some other API, and you have optional methods to support easy interoperation. It’s possible that a particular programmer my want to use one or the other APIs by themselves. Where do the optional VIs that depend on both go? An example might be: I have a message-passing API, and a TCP API, and I want to pass messages by TCP sometimes, without tying these two APIs forever together? And without having the extra burden of stewarding LabVIEW to do the obvious: don’t load it it it isn’t used.

I couldn’t ID the problem. The code looks like it should work but doesn’t.

I use the menu of the picture control, dynamically built in the “Shortcut Menu Activation?†event and let the User insert after the clicked-on icon. Sadly, I do not. Should your “objects†know about the mouse? My “analysis pipeline actorsâ€, represented by the icons, do not know anything about the picture UI used by the top level VI. The top level determines what was clicked on and does the appropriate action or sends the appropriate message.

True, but how do I identify real dependancies from all the fake ones? LLBs don’t seem to be equivalent (though I never really used them). No namespacing, no Private scope.

I’ve used a single 2D picture control for similar work (no drag’n'drop, but I have full mouse-click logic including insert, delete, cut and paste, as well as “settings†and “disable†buttons built into the picture). It’s not that hard once you have made a “what is the mouse over†subVI that accepts mouse coordinates (you’ll need a cluster/class to hold the known coordinates of your icons). I would suspect that the VI server route would be harder.

Something I did not appreciate till today: If I have an LVLIB library in which I use one of its VIs, then any LVCLASS class referred to by ANY of the LVLIB’s members will be loaded into memory (along with all their dependancies). In addition, the fact that all library members show up under “dependanciesâ€, even if only a few are actual used, makes it difficult to get useful information about real dependancies. So, should I ditch the use of LVLIBs altogether as a hopelessly-flawed tool? — James Added later: Must be getting old, as I forgot that I already knew this. But the question remains of what to do about it.

I’ve modified the code to only escape ‘/' if it follows ‘<‘ (so ‘</‘ becomes ‘<\/‘), as it’s use in HTML <script>..</script> seems to be the reason that escaping of ‘/‘ is allowed in JSON.

I had never noticed that JSON allows, but does not require, / to be escaped as \/. Googling suggests this is due to some use of JSON embedded in other formats such as HTML that do use / as a control character. I believe our library as it stands should accept both versions. But what should it do on output?

The latest JSON package, where I have fixes some issues with corner cases, mostly by changing the string escaping (failed on strings like “C:\\“). Also extended escaping to the name strings of JSON Objects (which we had neglected to do). I will make this the latest CR version in a week or so if there is no objection. lava_lib_json_api-1.3.1.25.vip

I would say putting common logic in the parent is desirable behavior. And I don’t mind if some children will want to override the default parent behavior. For example, I have a project at the moment that uses cameras and “lockinâ€, the extraction of a periodic signal in the image. Most concrete camera types just override the "Get Image" method, and the parent’s "Get Lockin Image†method uses "Get Imageâ€. But one camera model has a built-in lockin mode, so I override “Get Lockin Image†in that case.

It’s worth breaking through whatever conceptual block you have, because the code you have shown is considerably more complicated (and will require a higher level of competence to execute correctly) than the OOP solutions shoneil and I are talking about. And there are no advantages I can see to the way you are doing things.