COM Port Callback In a DLL Not Working

[d.]

Hi,

I've been working on this for a few days and haven't yet found a solution.  I've created a DLL for a serial interface (USB CDC) and everything works except the COM callback.  I'm using InstallComCallback() to install a callback function in my DLL, but this callback is never called from within the DLL when data is sent to the serial port.

If I do exactly the same thing inside an application without a DLL, it works perfectly.  So I know the process works fine.  I suspect that the COM callback is not executing properly only because it's within a DLL, but I don't see any way to determine that.  I'm talking to custom external hardware.  If I use a stand-alone application, I see that my hardware is returning data.  If I debug my DLL, I see that Windows is opening the DLL, my application call into the DLL to initialize the COM port is working, and another call to send data to my hardware over the COM port are working just fine.  It's only the receive side that isn't working.

Does anybody have any ideas?

Thanks,

Dave

[tstanley]

My guess is that events are not getting processed when you are using the DLL.  Are you calling ProcessSystemEvents(), RunUserInterface(), or GetUserEvent() in either the DLL or the application (assuming an application created in CVI) that loads the DLL?  Note that you'll have to do this in the same thread that installed the COM port callback.

[d.]

Thanks for the feedback.

ProcessSystemEvents() does not appear to handle interrupts, only user interface and other system events that don't apply.  Regardless, adding this call has no affect.

RunUserInterface() cannot be called because there is no UI and it does not return.  GetUserEvent() doesn't apply because there are no user events.

If you use InstallComCallback() inside of a standard UI, the callback works.  So maybe inside of the RunUserInterface() function there is some other hidden system level function call that processes the interrupts.

I'll keep looking.

Thanks for the help.

Dave

[d.]

After thinking about this some more, I think CVI is not able to handle this, and it's really a Windows issue.  It doesn't matter that the DLL is created by CVI or that I'm using a CVI UI to call the DLL.  My guess is CVI cannot handle the interrupts in the DLL and that InstallComCallback() will not work.

I hope somebody can prove me wrong though, since dealing with Windows is a lot harder for me.

Dave

[d.]

OK, yet another thought.  Maybe it's better to eliminate the serial communications from the DLL completely and let the parent application deal with the serial port.  Then the parent application can do whatever it needs regarding UI, passing the raw data to the DLL, and let the DLL do what it needs to do to process data.  This sounds a little clumsy to me, but then I don't have to deal with the internals of Windows serial port interrupt processing.

Dave

[tstanley]

Without seeing your code I'm not sure what you've tried, but my guess is that you are going to need to be doing something like:

while(stop == 0)

{

  ProcessSystemEvents();

}

Anytime you want the system to be able to fire the callback if you don't have a call to RunUserInterface() in the code.  If you are calling the DLL from a non-CVI application you may need to put it in another thread to keep the loop from blocking the main application.

[d.]

Thanks tstanley.  You are probably right.  My attempt to call ProcessSystemEvents() was in the wrong thread.

I don't see any way of creating a thread within the CVIRTE environment.  Is there one?

Thanks again.

Dave

[tstanley]

Hi Dave,

You'll have to look at the "Cmt" functions, i.e. CmtScheduleThreadPoolFunction (, , , ) will run a specified function in another thread.  I would guess is that this function would install the Com callback, then sit in a loop calling ProcessSystemEvents() until you're done getting data from the Com port.  You\ll may also have to be careful that only one thread at a time accesses the Com port as I don't know how thread-safe the CVI Com libraries are.  Hope this helps.

[d.]

Hi tstanley,

I really thought this was going to work...

With your help, I now have a separate thread running.  It runs fine.  I have a call to ProcessSystemEvents() and delay in the while(1) loop.  I can set a breakpoint and consistently hit it, so I know the new thread is running.

In the same thread but above the while(1), I'm initializing my COM port and installing the callback.  Unfortunately, I get the same results.  That is, I can send data to the serial port  I know my external hardware is getting the data because it beeps when it does.  And I know my hardware is responding to data because if I use my other applications I see it.

But the DLL is not getting a callback to the receive routine.  😞

I even tried initializing the RTE inside the new thread, before initializing the COM port and installing the callback.  Still no good.

I'll keep scratching my head...

Dave

[d.]

OK, I think I have it.  Might take me a few days to finalize since it's the holidays.  I'll post again.

d.