drjdpowell

One can also just "Browse" the directory structure (which is what I've learned to do as then you know you can see everything): But the easiest with VIPM packages is to use the "Show Examples" button in VIPM:

So far I've noticed that it takes a lot of time to figure out why a VIM is broken. Any input being wrong makes everything wrong, with only an unhelpful error message. It's the biggest problem with VIMs that have input's that must have matching datatypes. I'd like to be able to specify somehow that the "Buffer" input's should always be accepted, even if the added data is unspecified, but I'm not sure how to do that (though I've just had an idea I'll try later).

Last thing I did was move the examples into the standard example location. You should be able to find them either from the show examples button in VIPM, or in the Example Finder. I had hoped the menu would update to the new location but I guess not.

As an experiment in seeing what VIMs can do, here is an all-VIM implementation of a "circular buffer", based on code from a 2D DBL array circular buffer I had previously used. In LabVIEW 2018. Features: Works on any scalar type, giving a 1D array buffer, or any 1D array, giving a 2D array buffer (could be extended to a 3D buffer of 2D arrays) Has VIMs that accept either a by-Value Buffer, or a DVR of a Buffer Package contains simple examples. Comments welcome. jdp_science_lib_malleable_buffer-0.1.0.5.vip

Here is the latest version of the package. To run the examples you will need a Postgres server/database and must modify the connection string to point to it (and have the right user and password, of course). I just tried it with a fresh install of Postgres 10 and it reasonably painless. This is LabVIEW 2015 (but if I developed this library further I would probably go the 2018-9 to access the power of malleable VIs). jdp_science_postgresql-0.1.1.9.vip

A while back I posted a beta version of a client library to access Postgresql. The project driving that work was put on hold, and I have not done significant work since. But at least some people have used or have considered using it, so I wanted to see how many people that is. There has also been a desire expressed to me about using it on RT, so I wanted to know if anyone has developed it to do that.

You should post a topic on LAVA sometime explaining how you use Teststand and Messenger Library. I have not had the pleasure (or is it torment?) of seriously using Teststand.

Note: there is nothing stopping you putting all your code in an actor in one single subvi (which Actor.vi or ActorNR.vi then calls). So you can try this easily.

By default, subVI are set to "Same as Caller" execution system, but they can be a specific system instead. I suspect it might be just the subVI that does the TestStand call that needs to be in a different Execution System, not the calling Actor.vi itself. So try just changing the subVI.

Here is something that I often have problems with and have no good solution: Often I have floating or modal windows, and another modal window opens (either from the VI that is the first window or another async-running component) and the active modal window ends up behind the first window. Often this second window is the file dialog. The User ends up unable to click on the active modal window, and unable to move any other LabVIEW window. They think the application has hung, which effectively it has. Really, of course, I want the active modal window (that is blocking the User from all other windows) to always be on top. How do other people get around this problem?

Those are VIM, VI macros, I think, not your clones. To get clones you need to use Open VI ref with the form <VI name>:nn, with nn as a possible clone number. See the development of the Task Manager.

Thanks Rolf, your definition of "pretty easy" is slightly wider ranging than mine.

i'm afraid I only ever had the documentation from the netCDF website, sorry.

I've done a 3D-points-cloud type application in the past. I used SQLite to store and analyse the data, using the RTree feature to store points (the RTree is designed for fast lookup of multi dimensional mapping data). One can do max/min, mean, std dev, etc user various filter conditions in SQLite much easier than in LabVIEW arrays. For display I used the 3D Picture Control. Both these techs involve a steep learning curve but are very useful for your type of application.

The special math functions like "Create Special Matrix" can do it; they return an error code -20001 ("Analysis: (Hex 0xFFFFB1DF) There is not enough memory to perform the specified routine.") if you try and create a too-large matrix. They do their work in a dll, and this might be the way I would have to go.

I have application where the User provides files from another program, which are typically 10 Mb, but with no real limit on their size. One User managed to generate a 900+ Mb file and caused an out-of-memory condition which caused my app to fail. Rather than the annoying "Out of memory" dialog that pops up, I would much rather get a standard error that I can handle (by telling the User that file is too big to load and then returning to normal operation). So I have been trying to think of a way to attempt to allocate a very large string with a graceful way to fail if there is not enough memory. Has anyone else found a way to do this?

I've had a google and you're right, there are uses of "priority queue" for structures that are not analogous to common meaning of "queue". Wikipedia even labels a stack with priority as being a "priority queue". Personally I think this counterproductive when used with frameworks as only a subset of users will know the secret language. Surely we can use English words with their standard meanings.

That's my point. You explaining that a theorectical elderly person might get priority means this is a priority queue and thus there was no other expectation of ordering, and that's why you cutting in front is ok...that ain't gonna go down well.

That is a weird, though undeniably literal, interpretation of the words priority queue. You must get into a lot of arguements at the supermarket checkout.

I'd expect there to be a very strong expectation that anything called a queue enforces ordering, as that is what the word queue means.

Thought I'd show an example of "complexity" of a framework, according to my way of thinking, by comparing the priority messages of the NI Actor Framework and the DQMH: Looks the same from an API level (they even use similar icons). Let's look inside; here is the relevant code section for priority messages for the AF: Yikes! And here is the same for DQMH: Ah, much simpler. Now we can see which framework involves more complexity: the DQMH. Wait, what, you say? Isn't the obvious complexity of the AF implementation mean the AF involves more complexity? Well, no, because I, as User of a framework, care nothing about the implementation, I care about application I am building with these APIs. So let's consider the task of sending three high-priority messages, A then B then C. In what order will the three messages be received and acted on? With the Actor Framework the order will be A, then B, then C, ABC, always. With the DQMH we have: 1) if the receiver can execute them faster than they are sent, the order will be ABC 2) if the receiver is handling another message the order will be CBA (as we place on the front of the queue) 3) if the receiver is idle, but executing A takes time (allowing C to get before B), the order will be ACB 4) if busy but finishes after B is sent but before C is sent, the order is BCA 5) as (4) but B is finished executing before C sent, ther order is BAC Thus with the DQMH there are 5 possible orderings of execution, with the probability of the various orderings highly dependant on timing of not-directly-related bits of code (other messages being sent). At best, this is counter-intuitive and potentially confusing during debugging. At worst, one combination is a rare race condition that doesn't show up during testing and causes near-impossible-to-debug errors in deployed code. So that is an example of complexity, and it is certainly accidental, as the DQMH designers did not intend unpredictability of message-handling order when they used enque-in-front as message "priority".

Exactly, but according to your definition it would be "accidental complexity". No, my original claim (that Daklu reacted against) was that a good framework reduces complexity. Working without a tried and tested...something (could just be a standard way of working that you are very expert in, but a "Framework" adds a library that supports that standard) leads to code that has extra complexity in it. Often that extra complexity is not obvious, but that's the worst kind of complexity. A particular bugbear of mine is NI templates like "QMH" and "Continuous Measurement and Logging" template/example that come with LabVIEW, which you might think are simple. I consider them very over-complicated. I've given more than one talk pointing out weaknesses in CM&L.

What is a "framework" but a tried and tested template for design combined with a support library and hopefully some productivity tools and documentation?

I don't think Functional and OO are contradictory, per se. Rather, it's by-reference objects contained in other objects that is very non Functional. By-value objects and LabVIEW dataflow seems quite Functional to me.

I think Daklu meant when your program is more complex than the problem it is solving. My problem with calling this "accidental" is that it sounds easy to avoid if you're careful, when really it is very hard to avoid lots of extra complexity. An example that comes to mind is shutdown/cleanup code. A good framework will handle cleanup simply and easily (this is an area I think Messenger Library is strong).