| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1557.1 | Probably an INTERCHANGE problem. | BASEX::EISENBRAUN | John Eisenbraun | Thu Feb 06 1997 10:21 | 31 |
| >If you do a $ SET TIME to � 1 hour while a device is enabled, the connection
>to this device will be broken. You need to restart ILAN$DEVSRV to recover.
I tried this. It seemed to work fine if I set the time ahead, but I
started getting timeouts when setting the time back. Like you, I had
to restart DEVSRV (and kill the ILAN_DTLSRV process) in order to
recover.
>I'm not sure whether this is a TCP/IP-issue or due to the Interchange-protocol.
I strongly suspect that this is the INTERCHANGE software that is
causing this problem. There are timers and delays in the INTERCHANGE
software (DTL_WAIT), so it could very well be INTERCHANGE.
>My suspicion was that exceeding the UCX-DROPTIME when setting a new time
>could cause this. Is there any timing-information encoded in the data exchange
>between the DAS and the PLC, or is it really caused by UCX ?
I don't really think this is a UCX problem.
>They have a clock attached to the PLC. The clocks value is read by the DAS and
>is further used to set the system time on the axp. While testing this
>configuration, they discovered the above symptom. (Though I don't think they'll
>have to deal with time-drifts of more than a couple of seconds, they'd like to
>know what could be the cause.)
As I said above, I suspect it is the INTERCHANGE software. If the
customer really wants to know, I can pursue this with Allen-Bradley,
although I wouldn't expect drifts of a couple of seconds to be a
problem.
|
| 1557.2 | .. please, if possible | VNACO1::KARASEK | Thomas KARASEK @AUI | Fri Feb 07 1997 06:49 | 8 |
| John,
thanks once more for your investigation.
I wouldn't expect problems with a couple of seconds either, however, the
customer would like to know, what the limits are, and if they could be modified
at all.
If you had a chance to discuss this with AB, we would be happy.
- Thanks & regards, Tom.
|
| 1557.3 | Pursuing this with AB | BASEX::EISENBRAUN | John Eisenbraun | Thu Feb 13 1997 11:24 | 15 |
| > If you had a chance to discuss this with AB, we would be happy.
Remembering to do this slipped my mind, so I apologize for the delay in
responding. I finally called AB and they are looking into it.
I did determine that the problem is happening in DTL_WAIT. I also did
some experimenting and the "hang" continues until the clock time
passes the original clock time. So, if you set the time back an hour,
the DTL_SERVER process will hang until an hour later. If it's only a
few seconds, then the hang will only be a few seconds.
I didn't experiment with this, but I also suspect that if the DTL_WAIT
completes for another reason (such as another request completing), you
won't experience the hang, although there is no way you could guarantee
that you had a request complete for every DTL_WAIT call.
|
| 1557.4 | DTL_WAIT uses absolute time - no workaround. | BASEX::EISENBRAUN | John Eisenbraun | Fri Feb 14 1997 11:59 | 5 |
| AB called back and confirmed that the DTL_WAIT call uses the absolute
time when timing out the DTL_WAIT call, so if the time is set back
during DTL_WAIT, it will hang until the clock time has proceeded back
to the original time. AB said there is no workaround to this problem.
It's the way that INTERCHANGE is designed to work.
|