Leaderboard

Glad you found the source of the problem! Just to dive in and explore further to this statement above -- it's perfectly acceptable to register inside the loop prior to binding the registration to the Event Handler Structure -- though perhaps not typical. I'm guessing that the memory leak you found was due to the registration not being shifted in a Shift Register inside the loop code. This would cause a memory leak, since each iteration a new Event Registration Queue is formed. Though, if it's shifted, only one Event Registration is created, and then modified each subsequent iteration. Check out the snippet below, which simulates the difference between shifting and not shifting an event registration. The two Boolean controls -- Leak? and Handle Event? -- allow you to run the example in four modes: Handle Event == TRUE and Leak == FALSE - Though it remains atypical to re-register each iteration, this is the only of the four combinations that does not produce a memory leak. Handle Event == TRUE and Leak == TRUE - This is an interesting scenario that causes a leak of 100kb/iteration, even though the data is consumed (handled). This indicates that Event Registrations, like Queues, maintain a high-water mark as an optimization technique. (Thoric, I'm guessing this unintentional scenario was the bug in your code) Handle Event == FALSE and Leak == FALSE - This scenario might be used to pre-load a work queue, which would then later be bound to a single handler. This technique is useful if the computation-to-memory ratio is high, and time needed to calculate the work to be done is relative quick compared to the amount of time needed to do the work. (I wish that LabVIEW's Event Registration binding to an Event Handler had the same semantics as a Queue, with 1:N capabilities. Then, we could dynamically launch a pool of workers bound to the same work queue, and have the Piranha Brigade munch away at the work in concurrently and asynchronous from each other) Handle Event == FALSE and Leak == TRUE - This scenario is useless and almost certainly a bug, unless the Shift Register was replaced by an Auto-Indexing output, to which the array of registrations were later each bound to handlers. (Though even with the output array of registrations, this technique is not quite as desirable as the Piranha Brigade above, especially when the amount of time to perform each job is variable.)

Are above topics important for CLD? If a simple queued state machine does the job, do we still need to know the above labview topics? Best Regards K Waris

A simple queued state machine will work just fine on the CLD. Get it (mostly) functional, document well, and keep everything neat.

TestStand <1 Hr> - Hands On This 1 hour session introduces the concepts of NI TestStand. At the end of the session, you should be able to [/font]understand how to use NI TestStand test management software to: Create a TestStand sequence and add the frequency test step; Generate a report for your test sequence; Add tests using preconfigured step templates; Debug test sequence using the NI TestStand Sequence Editor https://decibel.ni.com/content/docs/DOC-32943?nisrc=RSS-devzone-new-en

Elijah Kerry leads the large app team at NI and he just published an update to his measurement utility: https://decibel.ni.com/content/docs/DOC-21441 that demonstrates how to use it with TestStand: https://decibel.ni.com/content/docs/DOC-33162

We went through pretty much the same process of discovery. Short answer: Yes, we put classes that work together to perform some specific tasks (e.g., configuration) in a library (.lvlib). We also put classes (or other files) in a library when a group of these form part of a template but in each instance we need a unique namespace. (The library provides a namespace and we don't have to rename all the individual contents. We can also copy the entire library on disk at once.) Finally, sometimes we have a group of child classes that obviously go together (for examples, we have Commands.lvlib and States.lvlib that contain children of CommandThisComponent.lvclass and State.lvclass, respectively.) In all cases we need all elements of the library in the project anyway, and it is actually quite handy to have everything grouped under a library in the project. (I think this is an especially important practice, by the way.) When these situations do not apply (i.e., we have a class that we may call all on its own) we usually do not put classes in libraries since we do not see an obvious benefit. (Putting disparate classes in a library adds unneeded items to the dependencies, as you say. We could make a library for an individual class, but especially since a class is already a library there doesn't seem to be anything to gain by doing that.) The other thing to keep in mind is that if you open a nested library it will open the parent library and any other libraries in the nest. Paul

See attached VI