LabVIEW
how to detect the abort excution button of labview
Hi Thesara,
@thesara wrote:
and if i dont make the vi i will not get the job that i need
So you want to get a (LabVIEW related) job with the combined help of the public forum, but without fundamental LabVIEW knowledge?
You already got help, but don't seem to take suggestions. You also don't provide any code of your own even though being asked for…
You are given solid advice from LabVIEW experts with decades of experience here. People who have helped hundreds of programmers. And they are really trying to help you. But to get help, you need to start answering their questions and listen to their advice. Don't take that as insults.
If you were an electrician and are given instructions to install an outlet in a bathtub, so the user can make toast and charge their phone while taking a bath, and all experts tells you that its an insane requirement and will cause nothing but harm and will serve no purpose. Would you still require the experts to tell you how to do it?
@thesara wrote:
this is the requirnment ive been told , im not doing this for fun im seeking help cus im stuck ive been told to do what im asking exactly
and if i dont make the vi i will not get the job that i need
so if u can help i appreciate it without the additional unecessary insults cus im stressed enough
Did it specifically say "the abort button in the toolbar" or "a way to abort the program" - reading the requirements (and writing them) are skills of their own, and if it's the former you should really question your teacher (and send them here).
Hi thesara,
@thesara wrote:
he basically want to make something that works similiar to matlab s function
You have been asked to explain the term "matlab s function" before, but still fail to answer our questions…
@cordm wrote:
Since we are dealing with call library nodes (in the other thread),
This would be extremely important information that the OP has failed to mention in any way so far. Everything said by him was vague, using words that mis the usual meaning of things in LabVIEW by some inches to miles, and any requests for more information are ignored or answered with the same or different unclear terminologies.
take a look at their "Callbacks" tab. You cannot act on the abort button click inside the VI that is aborted, but you can do so in a DLL that is called from that VI.
Configuring the Call Library Function Node - LabVIEW User Manual
Yes this is a thing and actually can exactly be used to detect the Abort button being pressed while the execution is inside a Call Library Function. But no, it is anything from trivial, and requires the C code that is called in the Call Library Node to be specifically programmed to detect that and that can only be done if the underlaying API that is called in the code provides an asynchronous call interface. This is Advanced C code programming of the higher sort and getting this to work well and reliably requires even an experienced C programmer a lot of time, sweat, torn out hairs and gallons of coffee.
With the expertise shown so far in the OPs communication and the lack of properly communicating what this actually is about, I would see the chances for them to get this working in a way that is solid and always working well pretty much as nihil.
I have no expericence with this, but it looks like it requires some effort to make it work.
Some effort is a big understatement here!
Abort callbacks are not executed for CLNs running in UI thread. That makes it extra hard for non-thread-safe libraries. You have to create a thread-safe wrapper that somehow manages to make calls to the underlying library thread-safe.
You need a wrapper library anyway to create the callback functios that will then call the terminate function.
IMHO, avoid it if at all possible.
In short, I would advice against it. This is unlikely to end well, even after spending 100ds of hours. This code will be difficult to write, even more difficult to debug and pretty much impossible to get 100% right, without a very solid C/C++ programming foundation. Because once the solution "seems" to run, the real work starts. This is not "look mom it runs" stuff and then keep your hands off. It requires extremely solid testing, and testing again and then testing even more to make sure that it won't crash under not ideal solutions, such as when a user manages to press the abort button while he at the same time unplugs the power cord or any of a few thousand other possible coincidences!
The "poor mans" solution here would be to make the actual C function that is called in the Call Library Node asynchronous. Then put it in a loop in the diagram and terminate the loop once the work in the DLL has finished. Still a lot of work, and likely requiring you to create some thread in the DLL that does the work and communicates with the function being called from the Call Library Node about its progress, but it keeps things separated and testable on their own. Unless you are able to implement this properly, trying to use the Callback feature in the Call Library Node configuration is only going to be an even bigger nightmare.
