09-04-2008 01:45 PM
Hello Luis,
Thanks again for all your help. I made several changes in my code based on another similar project and it now works correctly, EXCEPT I can only get it running correctly in release mode. If I select Run->Execute DSCDriverTester.exe from the menu, all is well. If I select Run->Debug DSCDriverTester.exe or use the green arrow button in the top tool bar to start the debugger, it fails at various places - the latest being a critical section entry in the DLL [EnterCriticalSection (&IFDataLock); where IFDataLock is a global of type CRITICAL_SECTION that is initialized within the DLL on startup]. This happened with another, similar setup we have for another product - which also had no issues in CVI 6.0. So, I believe there is some issue with the CVI 8.5.1 debugger here. I would send you code, but you would need one of our proprietary instruments to run it and I doubt the powers that be would agree to that here. A rough diagram of the setup follows:
Driver Tester Layer - Unit tester for API written in CVI with UIR files, etc. Calls all functions and tests for failure and success
____________________________
Comms DLL Layer - contains Async timer (interval is 0.008 sec) to handle incoming serial comms, uses ComRd and ComWrt functions to send and receive a 16 byte buffer to and from the instrument.
____________________________
^
|
____________________________
Instrument - receives commands from the DLL, parses, acts, and responds at a 60 Hz clock rate over the serial port.
Hope I'm being fairly clear. Let me know if I can answer any questions.
Thanks again,
Judy
09-05-2008 12:00 PM
Hi Judy,
Without being able to debug it on my end, it's going to be hard to learn much. But I can make a couple of suggestions:
1. When you say that the program "fails" when entering a critical section, I'm assuming that you mean that the program hangs. If that's not what you meant, please let me know what kind of failure it is (crash? an error is returned?).
If it consistently hangs in the same critical section call, have you attempted to reproduce the problem with a different program altogether? If you're able to write a simple program from scratch that uses critical sections and the problem doesn't exist, then we know that it's a combination of factors that is causing this hang, and then it's a matter of isolating what those factors are. You could that, for example, by gradually adding some of the characteristics of your real program to this new program (turning it into a dll that is invoked from your tester layer, adding an async timer, adding some fake serial communication, etc...). If at some point, you start being able to reproduce the problem, then we at least know which additional factor causes the problem, and you might even be able to send us this program, if it doesn't have a dependency on the proprietary instrument.
If, on the other hand, you never are able to reproduce the problem in the test program, then I'd recommend going back to your real program and moving the critical section call to as early as possible in the code, in order to eliminate possible interactions from other parts of the code. Eventually, you might have to move the critical section to be the very first thing that your program does. It would be interesting to know if it still hangs at that point.
2. You mentioned that you're using async timers. Because async timer events are fired in a separate thread (which I guess is the reason why you're using critical sections in the first place) there's always the possibility to run into deadlock-type hangs, if one is not careful. Generally speaking, the tendency for this to happen goes up the more locks (and/or critical sections) there are in the code. The classic scenario is that thread A is waiting on a lock that is being held by thread B, while at the same time thread B is waiting for thread A to respond to some command, or to release a different lock. In theory, there's no real reason why this should happen in debug mode but not in release mode, but running in debug mode could be changing the timing of the program's execution just enough for this to happen.
3. Have you tried running the debug build outside of the debugger? It would be nice to know if what makes the difference is the fact that you're running in the debugger itself, or if it's the fact that the program has debug info compiled into it.
Finally, I assume that you're no longer having the problem of SetCtrlVal hanging. If so, do you know exactly what it was that causing the hang in SetCtrlVal in the first place? Could that give us some insight into this new problem.
Luis