LabVIEW
Error msg: "top level VI was stopped at subVI "Enqueue.vi" - Stream Channel crashes LV?
Solved!
OK, it took some time, but now I removed all Stream Channels from all of the 8 modules called from the top level VI, I only left Channels maybe at a couple of places where they do not play major role.
So inside each module, a single Stream Channel connected the Event Loop with the State Machine loop. I replaced each of these with a Queue, since it gives me the same functionality I need (Enqueue, Dequeue, "Timeout (msec)" input, "Timeout?" bool output).
Voila! Memory leak is GONE! The memory consumption stays "beton solid" around 300MB!
@mcduff wrote:
Nice!
Maybe you or Bob Schor can explain the advantages of Channels over other methods. I have not tried them yet, and so far, have only seen some bugs in the implementation in these forums along with the problem of sharing projects, ie, rebuilding the channel vis etc. So far, I have not seen a compelling reason to use Channels, why did you pick them for this project over a queue, user event, etc?
Cheers,
mcduff
First of all, I massively use User Events in this very project!!! All the "inter-module" communication is done via Dynamic User Events. You just cannot live without this, so powerful.
However, I wanted to use Channels for "intra-module" communication, so to transmit data inside a Module, between two loops (or sometimes 3). If you use Channels, you need less wire, this is the very first advantage. Of course, you can dig deeper into more complex Channel types, and find even more useful things. Well, lets hope these teenager issues will be solved soon regarding to Channels, and they will be safe to use. I cannot recommend it now. I just got burned too much yesterday 😉
Ah, here is a visual explanation (non functional) why it is more "tidy" to use a Channel over a Queue:
As the Champion of Channels (and working furiously behind the scenes to better document the current set of recently-introduced problems), I want to extend Blokk's Example of Streaming with Queues vs Streaming with Channels. You usually stream between While Loops, and there's always the issue of (a) stopping both loops and (b) making sure the "communication path" is preserved until the need for it has finished. With Queues, this can be accomplished by having the Producer send an "All Done" signal (here the "illegal" Dbl value NaN) after the Producer loop has been told to stop and the Consumer recognizing this signal, stopping itself, and then (safely) Releasing the Queue. Here is the example:
Not too bad, but it would be "interesting" to explain this to someone new to LabVIEW. Here is the Channel version of the same code:
So much simpler -- the Stream Channel includes a "Last Element" input that the Producer sets and the Consumer Reads. The only weird thing in this example is the path of the Channel Wire, but that's an aesthetic choice -- the following is even simpler:
Bob "Channel" Schor
