drjdpowell

Green icons are OpenG toolkit functions. You can install OpenG with VIPM. I just used annotations yesterday to mark things on a graph, and reacquainted myself with their limitations. I think I’ll try your picture solution.

Powerpoint slides from a presentation I gave at the European CLA Summit: CLA Summit 2014 SQLite.pptx

I have recently added a Sample Project to my “Messenging” package that reworks the NI standard sample “Continuous Measurement and Logging”. I didn’t do it to illustrate actors, per se, but perhaps the comparison will help. To me, the key point about “actors” is that they are parallel processes that only receive incoming information via a single communication point. No shared DVRs/FGVs/whatever. Actors are parallel processes, but with design restrictions, restrictions that are intended to make them more robust against the kind of bugs that can afflict multiple interacting parallel processes.

If I were to spend some more time on probes, the next thing I might do is adapt my SQLite-backed logger to handle messages. That would give unlimited history with search functionality. My current probes do have variable history, but only to the extent of resizing the probe window (so not if you need quite a long history). I really should buildup the variant display to the level of Ton’s “Variant Probe”, but I find most “complicated data structures” in my code become objects, encapsulated against any probing. I also have a preference for small and simple probes, without a lot of controls that take up space or take time to configure, but a “pause” function does seem like a good idea. I have debated adding “trace” functionality into the “Send” function itself (and “Reply” and “Launch Actor”). Theoretically one could add lots of advanced features like tracing which message is in reply to which other message. But this would be a lot of work, and I shy away from loading down the basic framework (I would like the basic messages and messengers to be usable without the higher-level “actor” design). One can, as in this example, build up your own application trace window relatively easily, through having a message logging actor registered for all published information of your other processes. And, being custom, it can also be targeted; showing only a subset of the more significant messages. Thanks for the feedback. Have you considered posting your actor design as an example for others? — James

This sample project is now installed as part of version 1.2 of “Messenging”.

Version 1.2 has the following changes/additions: 1) A sample project that is a rework of an NI standard sample project, to illustrate the differences with using Messenging (original conversation): 2) New polymorphic VIs for writing messages and synchronous “queries” (send message and wait for reply). The new write VI is smaller and lacks error terminals. The new “Query&Read” VI allows immediate reading of the reply message. I deprecated the original “Query” polymorphic VI because of non-consistant error handling. When error messaged are “read”, they return the error cluster through the "error out” terminal; some of “Query”’s instances read the message, and some just returned the unread message. The most common use of “Query” I have found is to issue a command and wait to be sure it has completed without error, so it is desirable to consistently return the error cluster. 3) An internal change; the “ObserverRegister” publication system has been switched from an asynchronous helper actor to a synchronous DVR-based solution. This is to prevent messages sent by “notify” from arriving AFTER later messages sent by “reply” (because notifications goes via the helper actor while replies go direct to final recipient). For example, in the code below from the new sample project, the “Logging” and “Status” messages used to arrive after the “Reply” message.

Attached is Version 1.2 with all new features. I will add this to the CR in a few days if there are no objections. Please run this version with your projects to test for errors. lava_lib_json_api-1.2.0.22.vip

Could you save it in LabVIEW 2011 please.

I have added this to Bitbucket but I have not tested it much. Do you have a Test VI that we can add to the test suite?

Perhaps. But most types can be meaningfully converted. A SGL can be a DBL. The number 5.6 can be the string “5.6”. Even the string “Hello” can be returned as a valid DBL (NaN). But returning a Queue refnum as a User Event refnum is invalid. That may not be that important, since the invalid User Event will just throw an error when used,

The distinction between reference numbers and reference strings is unimportant; they are references. I’m not sure if it is valuable to include reference type information in the JSON serialization, but if we do, it would be best to do this a JSON Object, rather than special string formatting. Nothing in that case, other than type-checking and some human readability of the JSON. Same as the original encoding one. Why wouldn’t it be?

Sticking with the JSON spec, it might be better to encode LabVIEW refnums as JSON Objects: { "DAQmx Refnum": {ref:”SampleTask”, LVtype:”UserDefinedRefnumTag"}, "File Refnum": {ref:-16777216, LVtype:”ByteStream"}, } On converting back, we should throw and error on any type mismatch. This is rather verbose, but encoding refnums should be a rare use case, limited to “tokens” that are passed back to the original sending application where the refunms are valid.

Looks like it:

I have a fix and will post a VIPM package in a moment. The problem results from converting 8 and 16-bit types to 32-bit, and relying on the OpenG functions to down convert. This works, but when we have empty arrays, they are left as the default type, leading to arrays of variants that are mixed in bit length, which the OpenG function can’t handle. So I added explicate type-casts for the 8 and 16-bit integers. ... Here it is lava_lib_json_api-1.1.3.21.vip I have not fully tested, so this may not be the only issue; could you run your tests please? — James

Could you reattach with the control values saved as default?

If you attach a small project showing the problem, I can take a look at it.

I’m snowed under with work and about to go on holiday for two weeks, but people can check out the bitbucket repo and build the VI package to test it if they want (the VIPM build file is in the repo).

I have zero time to look at it at the moment, but it isn’t clear to me how one would use the 2013 JSON primitives dynamically. If I have static clusters defined it should be hopefully much faster, but what if I haven’t got static clusters? How do I take JSON configuration objects from several modules and combine them into a top-level JSON “config” object, without the top level code having the link-to and explicitly use the type-deffed clusters of all the modules?

As a rule, I don’t put classes in libraries at all, and the optional VI are in separate “support” libraries that only contain VIs. Other way around; the Optional VI uses the class (it’s really a static method of the class in form), so always loads the class, but loading the class doesn’t load the Optional VI.

Very problematic, but many VIs are naturally thought-of as methods of the class. What if you later need to override the Optional VI in a child class, for example? You’ll have to change the library membership, and thus namespacing, with the headaches that entails. And if nothing else, it destroys the usefulness of using libraries to organize related code, if you have to place closely related VIs in different libraries. It’s just ugly!

An LVLIB loads all its contained libraries and classes, but not its VIs. So it is OK to have lots of VIs in a LVLIB, even if not all will be used. It is only LVCLASS that loads all contained VIs. Note that if you have a class in a LVLIB, loading the LVLIB will load the class and thus all the class’s VIs. I generally do not put classes in libraries for thus reason. NI really should work at changing this. I can see why it might be necessary to load all dynamic-dispatch VIs, but not static ones.

I find I have to watch out for optional VIs that extend a class’s functionality by using another class. It feels natural to include the optional VIs in the class; but, a class aways loads all it’s contained VIs. So this means that the other class and its dependancies always load when the first does, even if the optional VI isn’t used. If the unneeded-but-loaded classes also have optional VIs that use still other classes, then those classes load. It only takes a few “linker” optional VIs to cause huge numbers of unused classes and VIs to load. The key is to keep these VIs outside the class they are naturally a part of (I organize them in LVLIBs, often with the same name as the parent class). I once created a new project and added my top-level “Message” class, and this loaded twenty to thirty unneeded classes, all traced to two half-forgotten “linker” VIs. From a name-spacing standpoint this is rather undesirable, but until LabVIEW fixes the issue of a class always loading all it’s VIs it’s the only solution. — James

Fix for this in version 1.2.1. Can you give it a quick test?

It’s sister function “Get LV Class Path” is similarly glacial for no obvious reason. As is “GetLVClassInfo” from the VariantType library. I’ve wonders if the problem is just that they call functions running in the UI thread for some reason. But it could also be root loop. The only workaround I see is caching; store a set of default-value objects in a lookup table and check against this before calling “Get LV Class Default Value”. I wish NI would put some effort into improving semi-crippled functions like these.

You could look at some of the packages in the Code Repository that use the OpenG Data tools (Variant Probe for example). I’d say there are two main uses: 1) Make reusable tools to handle an arbitrary cluster. The OpenG Variant Configuration File package is an example. Here the User of the tool at some point needs to convert the variant back to a known type. 2) Make a display that converts an arbitrary type into a string. The VariantProbe above is an example. — James