LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Can a call to a DLL be aborted?

Hi all,

I've got a rather huge project stat starts to cause bad problems now communicating with an USB device. There's a home-made DLL that calls some chip-specific DLL functions. From time to time a call that finally should simply close the handle to that device takes far too long, from seconds to hours. It will finally return and everything is done, but I cant affort to wait more than some few seconds.

Now my Q is, is there any way to abort a call to that DLL whenever it takes more than a specified period? I thought of dynamically call a VI that calls the DLL, but I am not sure if this would really help, as LV is really lazy when it hangs in the DLL call _now_! The system monitor shows no CPU usage (~1%) and does not show LV hanging, but LV does react to any clicks with long delayes, if at all. Would not like to set that up just to find out that it could not have worked.

Any C programme here that has an idea to change the home-made dll?

Greetings from Germany!
--
Uwe

0 Kudos
Message 1 of 5
(3,018 Views)
I think the best way would be to let the DLL function to abort itself, if possible. Just call GetTickCount (Win32, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/gettickcount.asp) at function start, then repeatedly during processing.
I don't think you can abort a call from outside.

Paolo
Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 2 of 5
(3,014 Views)
After re-thinking the whole thing, I conclude this is impossibel, at least in the way I asked for.

To abort a process, it must be a separate process. As LabVIEW itself is a single process, I would have to bring this DLL-stuff into another process, which could just be another LV runtime engine. This might work in the devellopment system, but no way when compiling the main app into an exe itself. OR I had to use an older runtime engine.

AND, I would need to create a LabVIEW daemon that accepts the jobs with the DLL as it needs to stay in memory when being active.
AND I'd need a whole bunch of communication between both processes, exchanging different data like handles, errors, commands and communication packets.

Conclusion: I will not try going this way unless someone proofs me wrong.
Greetings from Germany!
--
Uwe



0 Kudos
Message 3 of 5
(3,012 Views)
Paolo,

thx for your reply. You're right in saying that you cannot abort such a call directly, as this would damage the caller itself. That's why the idea with a dynamic call. But this has to be a separate process to be abortable.

This is the reason why even our C 'softy' (software develloper 😉 ) can not do it in his home-made DLL. You just can abort a separate process. This implies the daemon and comm problem as described in my opther posting.

No such easy solution, unfortunately ;-((
Greetings from Germany!
--
Uwe

0 Kudos
Message 4 of 5
(3,010 Views)


@LuI wrote:

LV is really lazy when it hangs in the DLL call _now_! The system monitor shows no CPU usage (~1%) and does not show LV hanging, but LV does react to any clicks with long delayes, if at all.

I think that Non-threadsafe DLL calls are performed in the UI thread, which should explain the hang.

Correction - might be the calling VI's thread and not the UI thread.

Message Edited by tst on 05-05-2006 03:52 PM


___________________
Try to take over the world!
0 Kudos
Message 5 of 5
(3,008 Views)