cvi /labwindows - Cascon Goepel parallel thread (problem to get global sessionhandle variable)

[coca]

Hello,  I have a problem with an initialization from a boundary scan controller (cascon goepel) in a parallel thread.  

First of all I am new in programming with threads i have read many but I don’t solve my problem yet.

So, in my Main thread I have many initializations before my line DisplayPanel (gl_Ha.panelHandle); comes and displayed the panel.

The boundary Scan controller needs 10 - 15 sec to be ready before display my main panel. 

I can type the DisplayPanel (gl_Ha.panelHandle); before the Boundary Scan initialization but I want to do this in a other way.

I can also use a thread (I thought) and so I have decided. It works as far as I have created a thread function and in there I start the initialization function to get a sessionHandle Var for the controller.

So far so good but if I use the sessionHandle Var outside the thread function my programm break. 

My code:

In my Main I have these lines:  

int functionId; 

[...] 

CmtScheduleThreadPoolFunction (DEFAULT_THREAD_POOL_HANDLE, CasconInitThread, NULL, &functionId);

[...]

CmtWaitForThreadPoolFunctionCompletion (DEFAULT_THREAD_POOL_HANDLE, functionId, 0);        

In a other *.c file is my thread function:  

int iCasconHandle;  

int CVICALLBACK CasconInitThread (void *functionData)

{ 

if (!InitCasRunF (&iCasconHandle, NULL, NULL, NULL, NULL, NULL, cErrMsg))   // this function is from the boundary scan controller DLL  

[...]

 }  

In the *.h file of the *.c file:  

extern int iCasconHandle; 

int CasconInitThread (void *functionData);   

If I now use the iCasconHandle in an other  *.c file and use functions of the controller DLL the programm break.   

I have tryed many things to solve the problem but now I need help. I know the MultithreadingOverview.pdf for your Information.   

Hopefully someone can help

thx  coca 

Message Edited by coca on 12-03-2008 04:31 AM

[dummy_decoy]

when you say the program breaks, can you tell us exactly what happens ? (error, messages, ...)

everything seems fine in your code. but are you sure that "CasconInitThread()" has terminated before you try to access "iCasconHandle" ? if it has not yet terminated, then the error is normal.

another possible problem that i can see is that the cascon handle created by the DLL is thread specific and cannot be accessed from another thread. in this case, the handle would not be usable outside "CasconInitThread()". this happens sometimes when a software library tries to outsmart the library user and provides too much thread safety. check in your documentation if the handle can be shared between multiple threads.

[coca]

Hi ,

The exact failure is "FATAL RUN-TIME ERROR:   Unknown source position, thread id 0x0000094C:   The program has caused a 'General Protection' fault at 001B:73DD11C7"

 If I use the Handle Var outside the threadfunction with a DLL Controller funtion.

What you mean exatly with terminated before accessing the Handle Var, I thought this line in the main

CmtWaitForThreadPoolFunctionCompletion (DEFAULT_THREAD_POOL_HANDLE, functionId, 0); 

do it (maybe that is my error in reasoning)

And I check the Handbook too

By the way thx for your help  

[dummy_decoy]

with such an error, we can assume that the software is crashing into the DLL (or the source position would be known if you used a debug build).

the "CmtWaitForThreadPoolFunctionCompletion()" call does indeed wait for the handle initialisation to complete, but your code snippet does not specify if you access the handle after its completion. if this is the case, then the problem lies elsewhere...

[coca]

I access the Handle Var principal if the threadFunction is done. The thread set a led on and so the code can poll the status of the init.

... 

[LuisG]

Hi coca,

The first step you should do to narrow down the problem is to find out which dll the crash is happening in. Just put a breakpoint in your code in CVI and then bring up the modules window (Window>>Modules in CVI 9.0, Run>>Loaded Modules in older versions). You should find the address ranges of each dll that your program loads in that window, and you can see which dll that address (0x73DD11C7) belongs to.

It might be a system DLL, in which case it won't help you much. If that's the case, I recommend that you follow the steps below to generate a Dr. Watson log, which you can attach to this thread, and which might help us learn more about the crash. Try following these steps:

Windows XP

1. Run c:\windows\system32\drwtsn32.exe -i

(this will register Dr. Watson as your "just in time" debugger)

2. Run your application outside of the CVI environment. Whenever you get a crash and you see the "Please tell Microsoft about this problem..." dialog, click "Don't Send".

3. Browse to the C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson folder. The dump and log files are there. Keep in mind that if you have a second crash, it should overwrite the previous dump.

Windows Vista

Dr. Watson is not available in Vista, and its replacement (Windows Error Reporting) is very flaky, when it comes to generating crash dumps. So your best bet is to use windbg.

1. Install the Windows debugging tools.

2. Run C:\Program Files\Debugging Tools for Windows\windbg.exe -I

(this will register windbg as your "just in time" debugger)

3. Run your application outside of the CVI environment. When you get a crash, windbg should start up automatically. At that point, in its command window type .dump /ma c:\temp\mydump.dmp to generate the dump file.

If you have any trouble with any of these steps, then your best bet is to see if you can reproduce the problem reliably, and then send us the application (or some watered down version of it).

Hope this helps,

Luis

National Instruments

Message Edited by LuisG on 12-04-2008 11:29 AM

Message Edited by LuisG on 12-04-2008 11:30 AM

[coca]

thx for the tipp I check this on monday at work. Now is weekend for me ... 🙂

[coca]

Hi all,

thx for the Help.

I have talk today to the Goepel Electronic support Team.  

They cofirmed me what someone before said the DLL can only be used in one Thread.

And they have told me also that in the Handbook this issue untouched is.

😞

...