Experimental Physics and
Industrial Control System

Josh Stein <[email protected]> · Thu, 08 Mar 2012 10:37:29 -0600

Mark and community,


 I built Epics and Asyn on a windows desktop machine with a built-in

serial port using my "standard' suite of tools which includes the MinGW

compiler. The same error occurred when trying to set communication

properties with the asynSetOption() function. This eliminates the USB to

Serial Port question.



 I then downloaded and installed Visual Studio 10 C++ and rebuilt

(base, asyn, ioc) and the problem no longer manifests itself.



 So it _appears_ to be a compiler issue. Let the head scratching

ensue. So my immediate 'solution' to the issue is to begin using Visual

Studio instead of MinGW. Unfortunately this means some hacking around in

source code for commercially supplied source code which assumes a

"unix-like" environment which MinGW supplied, but Visual Studio does not.



Question in general to the community - is it at all possible to reduce

or eliminate the ambiguity in choices when building on the windows

platform? I'm assuming doing so would benefit anyone just starting with

Epics on Windows.




On 3/5/12 4:13 PM, Mark Rivers wrote:

Hi Josh,

There is another pair of functions, GetCommState/SetCommState which look like they could be the simplest functions to use.  They directly take a "dcb" structure pointer, rather than being embedded in another structure, as in GetCommConfig /SetCommConfig.  It would be interesting to see if they work.

I think we need to figure out if your problems have to do with the compiler or the fact that it is a USB device emulating COM ports.  Can you run your application compiled with MinGW on a PC with a local serial port (COM1) and see if it works?

Mark


-----Original Message-----
From: Josh Stein [mailto:[email protected]]
Sent: Monday, March 05, 2012 3:36 PM
To: Mark Rivers
Cc: [email protected]
Subject: Re: ASYN Communication through windows serial port (via USB)

A little update for the community, as Mark and I took a bit off-line
while poking about.

It turns out the error is indeed in the "GetCommConfig" function call;
which is done even during a "SetCommConfig" to populate the data
structures of the port.

I added a different function call ("GetCommProperties") to determine if
any calls to these (Microsoft) functions would succeed - and sure
enough, that one works without error (see
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363259%28v=vs.85%29.aspx).
However the values returned seem to not correlate with the definition
for the COMMPROP structure (see
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363189%28v=vs.85%29.aspx)
so there may be a hint in that (I'm still investigating).

Finally I want to point out that I am compiling on MinGW whereas Mark
compiles with Microsoft VC++

Any ideas welcome.

--J

On 3/4/12 4:52 PM, Mark Rivers wrote:

Josh,

If you look at the code in drvAsynSerialPortWin32::setOption you'll see that it first does GetCommConfig() to read the existing settings, modifies one parameter, and then calls SetCommConfig.

We need to figure out if the error is actually being returned in GetCommConfig or in SetCommConfig. There was previously a typo in the error messages in setOption, so it was printing "GetCommConfig" in either case. Please get the latest version from the SVN repository (committed today):

https://svn.aps.anl.gov/epics/asyn/trunk/asyn/drvAsynSerial

Or apply this patch from release R4-18:

Index: drvAsynSerialPortWin32.c
===================================================================

--- drvAsynSerialPortWin32.c    (revision 1900)
+++ drvAsynSerialPortWin32.c    (working copy)
@@ -302,7 +302,7 @@
       if (ret == 0) {
           error = GetLastError();
           epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize,
-                            "%s error calling GetCommConfig %d", tty->serialDeviceName, error);
+                            "%s error calling SetCommConfig %d", tty->serialDeviceName, error);
           return asynError;
       }
       return asynSuccess;

Then we can know which function is actually returning the error.

Mark


________________________________________
From: S. Stein [[email protected]]
Sent: Sunday, March 04, 2012 3:35 PM
To: Mark Rivers
Cc: [email protected]
Subject: Re: ASYN Communication through windows serial port (via USB)

Any attempt to change a parameter does indeed result with the same error.

Is there some way to request a list of the parameters which the device understands?


----- Original Message -----
From: "Mark Rivers"<[email protected]>
To: "Josh Stein"<[email protected]>, [email protected]
Sent: Sunday, March 4, 2012 12:03:58 PM
Subject: RE: ASYN Communication through windows serial port (via USB)

Josh,

It is possible that the problem is not actually with the baud rate setting, but with some other parameter. The way that the Windows SetCommConfig function works is that a large structure that defines all of the serial port parameters is passed to SetCommConfig. It is possible that the default value of some other parameter is set incorrectly for this port, so when you change the baud rate it is actually the value of some other parameter that is causing the error.

What happens if you try to change the data bits, stop bits, parity, etc. first? Do you get the same error for them?

Mark

________________________________________
From: [email protected] [[email protected]] on behalf of Josh Stein [[email protected]]
Sent: Friday, March 02, 2012 4:03 PM
To: [email protected]
Subject: ASYN Communication through windows serial port (via USB)

Boy how I hate bringing this stuff up on a Friday...

I have a need to communicate to a serial based instrument off of a
windows laptop. I have the latest ASYN build, which supports COM port
mapping for windows. Like any 'modern' laptop, this machine does not
have any built in serial connections, so I have a USB adapter which maps
COM3 to a serial port. I can talk to the device via a terminal program
on machine.

I execute the following on a softIOC running on the windows box:

drvAsynSerialPortConfigure("L0","COM3",0,0,0,0)
asynSetOption("L0",0,"baud","115200")

setOption failed COM3 error calling GetCommConfig 87


Note the setOption failed error; this is (apparently) preventing me from
setting the baud rate to 115.2K (which, of course, is what the external
device needs). (As an aside, I contacted Mark Rivers and he pointed out
the typo in the error message - it should read: "...error calling
SetCommConfig...")

I know this adapter handles that baud rate, as I can set it via a
terminal program and communicate to my external device.

Any ideas?







Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System