Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: RE: ASYN Communication through windows serial port (via USB)
From: Mark Rivers <rivers@cars.uchicago.edu>
To: Josh Stein <stein@aps.anl.gov>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Thu, 8 Mar 2012 16:48:00 +0000
Josh,

This suggestion goes against your request to "eliminate the ambiguity in choices when building on the windows platform".  But there is a third option for compiling on Windows, which is to use Cygwin.

Cygwin might be a good choice for your particular application, because it lets you use "unix-like" source code, and it does work properly with Windows serial ports.  They appear as they do on Linux, i.e. /dev/tty0, etc.  I had been using Cygwin for local serial ports for many years before I finally wrote the support for native Windows.

It might also be worth tracking down why MinGW is not working.  It could be something as simple as a structure not being packed properly and could be fixed with a simple #ifdef and compiler switch in my drvAsynWin32SerialPort.c.

I actually think that the 3 choices in compilers for Windows (VC++, MingGW, and Cygwin) are good tools to have in the arsenal.  Some vendor libraries really want to be built with VC++, some with unix-like code.  VC++ and MinGW support 64-bits, Cygwin does not, etc.

Mark


________________________________________
From: Josh Stein [stein@aps.anl.gov]
Sent: Thursday, March 08, 2012 10:37 AM
To: Mark Rivers
Cc: tech-talk@aps.anl.gov
Subject: Re: ASYN Communication through windows serial port (via USB)

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:stein@aps.anl.gov]
> Sent: Monday, March 05, 2012 3:36 PM
> To: Mark Rivers
> Cc: tech-talk@aps.anl.gov
> 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 [stein@aps.anl.gov]
>> Sent: Sunday, March 04, 2012 3:35 PM
>> To: Mark Rivers
>> Cc: tech-talk@aps.anl.gov
>> 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"<rivers@cars.uchicago.edu>
>> To: "Josh Stein"<stein@aps.anl.gov>, tech-talk@aps.anl.gov
>> 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: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Josh Stein [stein@aps.anl.gov]
>> Sent: Friday, March 02, 2012 4:03 PM
>> To: tech-talk@aps.anl.gov
>> 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?
>>
>>
>>
>>
>>

References:
RE: ASYN Communication through windows serial port (via USB) Mark Rivers
Re: ASYN Communication through windows serial port (via USB) S. Stein
RE: ASYN Communication through windows serial port (via USB) Mark Rivers
Re: ASYN Communication through windows serial port (via USB) Josh Stein
RE: ASYN Communication through windows serial port (via USB) Mark Rivers
Re: ASYN Communication through windows serial port (via USB) Josh Stein

Navigate by Date:
Prev: Re: ASYN Communication through windows serial port (via USB) Josh Stein
Next: RE: How do you close a CSS BOY window? Chen, Xihui
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: ASYN Communication through windows serial port (via USB) Josh Stein
Next: RE: asyn driver on Windows XP Pavel Masloff
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·