Menu

RTS and DTR separation

Help
Anonymous
2010-05-18
2013-05-20
  • Anonymous

    Anonymous - 2010-05-18

    I have two applications using serial port to switch external devices over simple electronics connected to physical serial port RTS and DTR pins (when at least one of these is high the external device will turn ON). Application1 can only drive RTS and DTR together and Application2 can be configured to use one of these two pins. If I make two virtual port pairs with com0com and connect these with physical serial port with hub4com I can get both applications to drive external devices at the same time but then one application turns off then external devices will be off even if second application is not commanded to turn off external device. All I want is that external device is ON until both applications are turned off these pins.
    I tried to disconnect unnecessary pins in virtual port pairs and now I can see (LEDs are connected to RTS and DTR pins for testing) that Application1 will drive RTS LED and Application2 will drive DTR LED.
    But when one applications already turned ON one output (corresponding LED is ON) and then second application will switch on second output (another LED will turn ON), somehow first LED will turn OFF. I cannot find out how and why is another pin turned OFF. So schematics will function as "first on - first off" but I need "first on - last off". Is this possible using com0com and hub4com and without two physical serial ports?
    My com0com:
           CNCA0 PortName=COM4,cts=!lrts,dsr=!ldtr,dcd=!ldtr,ri=!ldtr
           CNCB0 PortName=-,dsr=!ldtr,dcd=!ldtr,ri=!ldtr
           CNCA1 PortName=COM6,cts=!lrts,dsr=!ldtr,dcd=!ldtr,ri=!lrts
           CNCB1 PortName=-,cts=!lrts,ri=!lrts
           CNCA2 PortName=-
           CNCB2 PortName=-
    My hub4com:
    hub4com -baud=38400 -route=all:0 -create-filter=pinmap:"-rts=cts -dtr=dsr" -add-filters=0:pinmap -octs=off \\.\COM1 \\.\CNCB0 \\.\CNCB1

    Log:
    0 10:06:19 hub4com.exe IOCTL_SERIAL_GET_COMMSTATUS Serial0 SUCCESS
    1 10:06:19 hub4com.exe IOCTL_SERIAL_GET_COMMSTATUS com0com20 SUCCESS
    2 10:06:19 hub4com.exe IOCTL_SERIAL_GET_COMMSTATUS com0com21 SUCCESS
    3 10:06:25 Application2 IOCTL_SERIAL_SET_DTR com0com11 SUCCESS
    4 10:06:25 hub4com.exe IOCTL_SERIAL_GET_MODEMSTATUS com0com21 SUCCESS
    5 10:06:25 Application2 IOCTL_SERIAL_GET_MODEMSTATUS com0com11 SUCCESS
    6 10:06:25 hub4com.exe IOCTL_SERIAL_SET_DTR Serial0 SUCCESS
    7 10:06:25 hub4com.exe IOCTL_SERIAL_WAIT_ON_MASK com0com21 SUCCESS
    8 10:06:25 Application2 IOCTL_SERIAL_GET_MODEMSTATUS com0com11 SUCCESS
    9 10:06:25 Application2 IOCTL_SERIAL_WAIT_ON_MASK com0com11 SUCCESS
    10 10:06:29 hub4com.exe IOCTL_SERIAL_GET_COMMSTATUS Serial0 SUCCESS
    11 10:06:29 hub4com.exe IOCTL_SERIAL_GET_COMMSTATUS com0com20 SUCCESS
    12 10:06:29 hub4com.exe IOCTL_SERIAL_GET_COMMSTATUS com0com21 SUCCESS
    13 10:06:32 Application1 IOCTL_SERIAL_SET_DTR com0com10 SUCCESS
    14 10:06:32 Application1 IOCTL_SERIAL_SET_RTS com0com10 SUCCESS
    15 10:06:32 hub4com.exe IOCTL_SERIAL_GET_MODEMSTATUS com0com20 SUCCESS
    16 10:06:32 hub4com.exe IOCTL_SERIAL_SET_RTS Serial0 SUCCESS
    17 10:06:32 hub4com.exe IOCTL_SERIAL_CLR_DTR Serial0 SUCCESS
    18 10:06:32 hub4com.exe IOCTL_SERIAL_WAIT_ON_MASK com0com20 SUCCESS
    19 10:06:32 Application1 IOCTL_SERIAL_CLR_DTR com0com10 SUCCESS
    20 10:06:33 Application1 IOCTL_SERIAL_CLR_RTS com0com10 SUCCESS
    21 10:06:33 hub4com.exe IOCTL_SERIAL_GET_MODEMSTATUS com0com20 SUCCESS
    22 10:06:33 hub4com.exe IOCTL_SERIAL_CLR_RTS Serial0 SUCCESS
    23 10:06:33 hub4com.exe IOCTL_SERIAL_WAIT_ON_MASK com0com20
    24 10:06:36 Application2 IOCTL_SERIAL_CLR_DTR com0com11 SUCCESS
    25 10:06:36 hub4com.exe IOCTL_SERIAL_GET_MODEMSTATUS com0com21 SUCCESS
    26 10:06:36 Application2 IOCTL_SERIAL_GET_MODEMSTATUS com0com11 SUCCESS
    27 10:06:36 hub4com.exe IOCTL_SERIAL_WAIT_ON_MASK com0com21
    28 10:06:36 Application2 IOCTL_SERIAL_GET_MODEMSTATUS com0com11 SUCCESS
    29 10:06:36 Application2 IOCTL_SERIAL_WAIT_ON_MASK com0com11
    30 10:06:39 hub4com.exe IOCTL_SERIAL_GET_COMMSTATUS Serial0 SUCCESS
    31 10:06:39 hub4com.exe IOCTL_SERIAL_GET_COMMSTATUS com0com20 SUCCESS
    32 10:06:39 hub4com.exe IOCTL_SERIAL_GET_COMMSTATUS com0com21 SUCCESS

     
  • Vyacheslav Frolov

    With latest hub4com from CVS you can do the following:

    hub4com.exe -load=,,_END_
        -route=all:0
        -create-filter=pinmap:-rts=connect -dtr=connect
        -add-filters=0:pinmap
        -create-filter=pin2con:-connect=dsr
        -add-filters=1:pin2con
        -octs=off
        COM1
        \\.\CNCB0
        \\.\CNCB1
        _END_

      - transfer data from CNCB0 and CNCB1 to COM1.
        If DSR is in raised state on CNCB0 or CNCB1
        then RTS and DTR are in raised state on COM1
        else RTS and DTR are in cleared state on COM1.

    See
      hub4com.exe -help=pinmap
    and
      hub4com.exe -help=pin2con
    for more info.

     
  • Anonymous

    Anonymous - 2010-05-18

    So with windows (hub4com.exe) this is possible only some time in the future when this cvs code will be compiled into new release version? I got this code in my linux server from cvs but there is no .exe files.

     
  • Karel

    Karel - 2010-05-21

    Alright, now I think I got a working .exe compiled from cvs source. In linux I will compile something every few weeks or so, but in windows was this new work. Now I have new hub4com.exe working exactly as before with release 2.0.0.0-386, with my last configuration.
    But with your example I got two LEDs always shining as soon as hub4com is starting (_END_) and not possible to turn off with any software.
    If I will not specify pinmap:"-rts=cts -dtr=dsr" I always got two shining and not controllable LEDs. If I specify only pinmap:-rts=cts I got shining and not controllable LED connected to DTR pin, RTS is not shining and is controllable with software. And If I specify only pinmap:-dtr=dsr I got shining and not controllable LED connected to RTS pin, DTR is not shining and is controllable with software.
    But I would want to control these pins independently.

     
  • Vyacheslav Frolov

    Change

      -add-filters=1:pin2con

    to

      -add-filters=1,2:pin2con

    Note: both applications should be configured to use DTR

     
  • Anonymous

    Anonymous - 2010-05-21

    Wow, impressive. Not as I imagined it can work but just as I need it. Both applications can now drive both pins simultaneously but these are staying ON until last application turns it off. So I got "first on - last off" and also got one windows application development experience. Thank you.
    And just a little note: I changed in my working system "-create-filter=pin2con:-connect=dsr" to "-create-filter=pin2con:-connect=cts" and set my Application2 to use RTS, I don't know why (and don't care anymore) it will not work with dsr in real system. It worked well in my test system.

     

Log in to post a comment.