Leaderboard

My plans to get the recertification by points were thwarted mostly by covid, so after my certification was suspended in March this year, I was left with the decision to take either the CLA-R or the CLA, in a PSI exam center. Luckily I did not read this thread and was fully expecting to nail it due to my 20+ years of actively participating in numerous diverse projects in different companies in different industries. My preparations were IMHO quite okay, took the example exam and a little surprisingly got only 20/30 answers right so would have narrowly failed. 70% means you got to get 21 of them right. Next, I did some very specific reading of the failed topics and designed my first ever XControl as this was gray area for me. Very soon after this, I took my first real test and promptly failed it with the same score of 20/30. More reading and researching, two weeks grace period, and today I passed my CLA-R with 22/30 correct answers ✨. I have to say, most of the comments on this thread about the CLA-R scope are still 100% valid. This test is funny. After finishing answering the questions, I had plenty of time and was able to go through all of the questions the second time. Up until the point I got the results I was confident that I would get a decent score as every question seemed pretty clear. And only 73%, go figure! Safe to say, I'll put more effort on recertification by points after this experience. There's one other thing I'd like to comment, on as it relates to asking outdated questions. The "Merge errors.vi" that was presented in one of the questions has been deprecated in LabVIEW 2010. You shouldn't have to memorize the exact functionality, and it shouldn't appear in the list of questions anymore. I know the functions that have got upgrades, as the earliest LabVIEW version I have been exposed to was 5.1 but that will not be true for everyone taking this test.

I've done something similar before but don't have all the answers. As you described I wrapped the LabVIEW code in a basic C function. The LabVIEW code was compiled to a DLL with the "Use embedded version of run-time engine" option selected. This removes the need for a UI. For shutdown I don't think I did anything special. I was perhaps less concerned as it was an embedded application - I do have a panel close? handler in the code but I can't remember if that fired when it was embedded. Error out is actually pretty simple. You can use the pipes API and write to id 1 for stdout or id 2 for stderr. Below is a screenshot from my error message handler.

From my very limited experiments with a common app (not a service), the OS kills it no matter what, leaving no chance to do even some basic cleanup. You may browse through this idea and comments: Notification in Event Structure When Linux is Shuting down Sadly all the attachments there are long gone and I didn't succeed in finding their copies. But even if you would implement that workaround in your application, I highly doubt it would allow to interrupt the shutdown process to do some work in the application as it's provided by modern Windows or Mac OS.

hey... wait a minute, does this mean that when a class is loaded on host and on RT target, it will be locked, and we'll be stuck with this limitation untill the end of LabVIEW?

Skimming thru this thread... try this: From C, call `PostLVUserEvent()`. Then, in LabVIEW, rather than registering that event reference into a `Register for Events` node, register the event reference with a `Register Event Callback` node. Here's the game-changer -- `PostLVUserEvent()` in C will behave differently depending on how the associated event reference is registered in LabVIEW. When a listener is bound to the event using `Register for Events`, `PostLVUserEvent()` is asynchronous and non-blocking, and does not wait for the consumption of the event. It "blocks" only long enough to copy data reliably into the queue shared by its message-reference-counting registrants, then moves along. On the other hand, `PostLVUserEvent()` will synchronously block until the Callback VI handler has finished executing. This means, your library can `Post` some pointers/handles into LabVIEW, LabVIEW can fill them in the Callback VI, and downstream logic from the `PostLVUserEvent()` needs no further gymnastics to synchronize/mutex.