Experimental Physics and
Industrial Control System

Hi Jignesh,

 

-          In my case for write, I was trying dummy write with 0 length and it was not detecting the broken channel

(I assumed that it will be supported as per the Release Notes :  Release 4-5 “Serial, TCP/UDP/IP :---Handle 0-length write requests” ) I think write with 0 packet is valid situation in case of socket send method..?

 

I believe the Release Notes meant that a 0-length write does not return an error.  However, in the current implementation it does not actually send a message:

 

static asynStatus writeIt(void *drvPvt, asynUser *pasynUser,

    const char *data, size_t numchars,size_t *nbytesTransfered)

{

    ttyController_t *tty = (ttyController_t *)drvPvt;

    int thisWrite;

    asynStatus status = asynSuccess;

    int writePollmsec;

    int epicsTimeStatus;

    epicsTimeStamp startTime;

    epicsTimeStamp endTime;

    int haveStartTime;

 

    assert(tty);

    asynPrint(pasynUser, ASYN_TRACE_FLOW,

              "%s write.\n", tty->IPDeviceName);

    asynPrintIO(pasynUser, ASYN_TRACEIO_DRIVER, data, numchars,

                "%s write %lu\n", tty->IPDeviceName, (unsigned long)numchars);

    *nbytesTransfered = 0;

    if (tty->fd == INVALID_SOCKET) {

        if (tty->flags & FLAG_CONNECT_PER_TRANSACTION) {

            if ((status = connectIt(drvPvt, pasynUser)) != asynSuccess)

                return status;

        }

        else {

            epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize,

                          "%s disconnected:", tty->IPDeviceName);

            return asynError;

        }

    }

    if (numchars == 0)

        return asynSuccess;

…

 

So if numchars==0 it just returns asynSuccess without doing anything as long as it thinks the socket is connected (ttype->fd != INVALID_SOCKET.  And tty->fd will only be set to INVALID_SOCKET if it tries to send a message and fails.

 

I don’t know what the rules are about sending a 0-length message with send().  Is it allowed, and is the behavior well-defined for all platforms?  What you are trying to do is to send a 0-length message to determine if the socket is still connected.  I will defer to Eric or others on this.

 

> So I hope I am able to explain the scenario,

> one more thing this read and write with some dummy packet length are able to detect the broken connection if we keep PLC in STOP mode manually,

> but this method doesn’t detect the broken connection if I disconnect the network cable from PLC after successful connection.

 

How long did you wait after disconnecting the network cable to see if asyn would report isConnected()=false?  The timeout can take a long time (5 minutes?) on Linux.

 

> Though in all cases, reconnection is established automatically by asyn.

 

That’s good.

 

Mark

 

 

 

Hi Mark,

 

Thanks for you reply and suggestions.

 

What version of asyn are you using?

---I have tested the scenario on asyn version 4.21 and 4.23.

 

Please turn on all asynTrace debugging on that port in your startup script:

I think that failed write operations should trigger the channel to disconnect, but if not then we need to fix that.

 

--- I have enabled asynTrace debugging and below are the observations…

-          The channel connection status is properly identified by either dummy read or write when we keep any length higher than 0.

-          In my case for write, I was trying dummy write with 0 length and it was not detecting the broken channel

(I assumed that it will be supported as per the Release Notes :  Release 4-5 “Serial, TCP/UDP/IP :---Handle 0-length write requests” ) I think write with 0 packet is valid situation in case of socket send method..?

--- asynTrace debugging messages in each scenario :

1.       Write with length 0 in case of PLC RUN/STOP mode (always return status : asynsuccess)

2014/10/08 08:57:29.025 10.130.1.168:2001 write.

2014/10/08 08:57:29.025 10.130.1.168:2001 write 0

2014/10/08 08:57:29.025 asynOctetSyncIO wrote:

2014/10/08 08:57:29.025 PLC_SAMPLE_CPU_2001 queueUnlockPort

2014/10/08 08:57:29.025 PLC_SAMPLE_CPU_2001 asynManager::queueUnlockPort waiting for event

2014/10/08 08:57:29.025 PLC_SAMPLE_CPU_2001 queueUnlockPort unlock mutex 0x7f3328000a40 complete.

 

2.        Write with length 1 in case of PLC RUN (in case of PLC STOP mode, I get asynerror and isConnected also detect the broken channel)

2014/10/08 09:14:30.231 10.130.1.168:2001 write.

2014/10/08 09:14:30.231 10.130.1.168:2001 write 1

\000

2014/10/08 09:14:30.231 wrote 1 to 10.130.1.168:2001, return asynSuccess.

2014/10/08 09:14:30.231 asynOctetSyncIO wrote:

\000

2014/10/08 09:14:30.231 PLC_SAMPLE_CPU_2001 queueUnlockPort

2014/10/08 09:14:30.231 PLC_SAMPLE_CPU_2001 asynManager::queueUnlockPort waiting for event

2014/10/08 09:14:30.231 PLC_SAMPLE_CPU_2001 queueUnlockPort unlock mutex 0x7fbcf40009d0 complete.

t2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort locking port

2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort taking mutex 0x7fbcf40009d0

2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort queueing request

2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 addr -1 queueRequest priority 0 not lockHolder

2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort waiting for event

2014/10/08 09:14:30.331 asynManager::portThread port=PLC_SAMPLE_CPU_2001 callback

2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPortCallback signaling begin event

2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2014/10/08 09:14:30.331 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort got event from callback

2014/10/08 09:14:30.331 10.130.1.168:2001 write.

2014/10/08 09:14:30.331 10.130.1.168:2001 write 1

 

       But as this only unidirectional write channel so this dummy write will disturb the PLC performance as it will be considered as a valid data in case of write with higher than zero length not recommended as per the current implimenation.

 

       So below are the observations with READ

1.         Read with length 0 in case of PLC RUN/STOP mode (always return status : asynerror)

     2014/10/08 09:38:14.406 10.130.1.168:2001 read.

2014/10/08 09:38:14.406 PLC_SAMPLE_CPU_2001 queueUnlockPort

2014/10/08 09:38:14.406 PLC_SAMPLE_CPU_2001 asynManager::queueUnlockPort waiting for event

2014/10/08 09:38:14.406 PLC_SAMPLE_CPU_2001 queueUnlockPort unlock mutex 0x7f100c000a00 complete.

                  2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort locking port

2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort taking mutex 0x7f100c000a00

2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort queueing request

2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 addr -1 queueRequest priority 0 not lockHolder

2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort waiting for event

2014/10/08 09:38:14.505 asynManager::portThread port=PLC_SAMPLE_CPU_2001 callback

2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 asynManager::queueLockPortCallback signaling begin event

2014/10/08 09:38:14.505 PLC_SAMPLE_CPU_2001 asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2014/10/08 09:38:14.506 PLC_SAMPLE_CPU_2001 asynManager::queueLockPort got event from callback

2014/10/08 09:38:14.506 10.130.1.168:2001 read.

 

2.       Read with length 1 in case of PLC RUN mode (normally return status : asyntimeout as PLC will not respond but in PLC STOP mode this return asynerror and isConnected also detect the broken channel )

Same as above Read with length 0

 

 

So I hope I am able to explain the scenario, one more thing this read and write with some dummy packet length are able to detect the broken connection if we keep PLC in STOP mode manually, but this method doesn’t detect the broken connection if I disconnect the network cable from PLC after successful connection. Though in all cases, reconnection is established automatically by asyn.

 

So do you recommend to use other low level socket options or please suggest the better method  to detect the channel health.

 

Thanks for your support.

 

Best regards,

Jignesh

 

 

 

 
Jignesh PATEL
Control Systems Integration Technician
CODAC Section
 
ITER Organization, Building 72/286, CHD, Control System Division
Route de Vinon-sur-Verdon - CS 90 046 - 13067 St Paul Lez Durance Cedex – France
Phone: +33 4 42 17 84 72
Get the latest ITER news on http://www.iter.org/whatsnew

 

Hi Jignesh,

 

What version of asyn are you using?

 

> So I have tried some active method to detect the connection status, like dummy write(as this is write channel) and after checking the connection status with icConnected() but that also don’t report the broken connection

 

Please turn on all asynTrace debugging on that port in your startup script:

 

asynSetTraceIOMask(“myPort”,0,2)

asynSetTraceMask(“myPort”,0,255)

 

I think that failed write operations should trigger the channel to disconnect, but if not then we need to fix that.

 

If you don’t attempt any write or read operations then isConnected() won’t detect a disconnect, because the driver only detects a disconnect when it tries to do a write or read.

 

Mark

 

 

 

 

Hi,

 

I am working on Siemens S7 PLC driver development based on Asyn. Currently I have two channels of communication between IOC application and PLC, one of which just sends data to PLC on specific port when there is change like simple commands from user. So most of the time the channel remains ideal without any traffic. The other channel is bidirectional and have periodic data traffic on read direction.

Now I want to monitor this channel connection status in case of disconnection or failure from PLC side. I tried with isConnected() function, which doesn’t not work with this channel. But this method is working for other channel where I have bidirectional and periodic data traffic.

So I have tried some active method to detect the connection status, like dummy write(as this is write channel) and after checking the connection status with icConnected() but that also don’t report the broken connection so finally I tried with dummy read and checking the connection status with isConnected() which successfully detect the broken connection..

 

So please give comments for the above scenario and also suggest, is there any other method to check the connection status using drvAsynIPPort for such type of situation ?

 

Thanks for your support,

 

BR,

Jignesh

 

 

 

 
Jignesh PATEL
Control Systems Integration Technician
CODAC Section
 
ITER Organization, Building 72/286, CHD, Control System Division
Route de Vinon-sur-Verdon - CS 90 046 - 13067 St Paul Lez Durance Cedex – France
Phone: +33 4 42 17 84 72
Get the latest ITER news on http://www.iter.org/whatsnew