[Halcon 10 License Keygen
Christel Malden
ive been googling the net for hours now and still didnt came up with a solution to my problem, so i hope that you guys can help me.Im trying to add external libraries to my Qt Project (4.7.4 32-bit). I'm working with the CV-Software Halcon (x86-win32) and want to link the example test project (matching.pro) to the halconcpp.lib and halcon.lib inside the lib folder of Halcon. So i added the following lines to the .pro file.
So im thinking that it has something to do with the settings of qmake, especially the way in which it links to the halconcpp.lib.And because im quite a noob when it comes to compiler settings, my only hope is your knowledge.
Then the library is not really multithreading safe. It probably assumes that it is always called from the same thread and uses possibly things like Thread Local Storage or similar for its internal operation. Nice idea but that works very badly with LabVIEW. You don't really have a way to tell in LabVIEW to call a specific code in a specific thread other than the UI thread.
If it is indeed TLS which causes this problem (there are several other possible causes) then you would have to restore the TLS environment every time on entering your functions before calling any Halcon functions, and save it back into a buffer that you maintain with your API before returning to LabVIEW. A somewhat work intensive thing to do, but it's at least possible.
That should not happen if everything is done correctly. I mean, you do some work with Halcon in LabVIEW and then your very last operator is FinalizeHALCONLibrary() and then you don't touch any Halcon-related things at all or exit LabVIEW completely. I tried this by myself and this works without any messages or something.
Why do you attach these large screenshots instead of copy-pasting the code as a text? Well, not knowing which operators you use I advise you to check every operator with its description from Halcon Help. There you could find the information whether your operator is really reentrant or not. For instance, here's the info about GetContourXld:
For the clarity I need to add... You should understand what happens when you run the same VI after you executed it one time and didn't closed it. Your DLL and Halcon related libraries are still in memory. But FinalizeHALCONLibrary() has been called. The documentation states:
So now you have to unload your DLL from memory with closing your VI (or closing LabVIEW or calling FreeLibrary explicitly). If you don't do that and call Halcon functions again, the threads stay alive and FinalizeHALCONLibrary() doesn't work anymore! Now if you close the VI or LabVIEW, you get that annoying 9700 message. A fairly obvious solution in this situation would be calling FP.Close at the very end of your program in IDE mode or calling "Quit LabVIEW" in RTE mode. Of course, you could play with LoadLibrary / FreeLibrary if you feel that it's uncomfortably to see the program closing after every run. There might be another ways around that (say, manually calling shutdown CLFN when you finished your work).
But now the problem is there when I am using same halcon DLL function multiple times parallel in labview and terminate them when I closed labview , at that time again the issue of error 9700 occurred.
After all, you could try to switch to .NET nodes instead of DLLs. There's no such problem with the threads, as all the cleanup is done automatically. You have to close each reference when it's no longer needed. That's all.
I'm a little surprised that this message box still appears when 'do_low_error' parameter is set to 'false' or 'disabled'. It might be a bug or something specific, but I'm not going to puzzle it out.
795a8134c1