Why does the LoggerNet still send out the clock command every 20 sec even when the Pause Clock Update is checked ? Also, is it possible to set this transmission interval ? Thanks!
"2009-11-11 5:34:02 PM","PakBusPort_2","S","sending message","src: 4094","dest: 20","proto: BMP5","type: 0x17","tran: 153"
"2009-11-11 5:34:02 PM","PakBusPort_2","S","received message","src: 20","dest: 4094","proto: BMP5","type: 0x97","tran: 153"
"2009-11-11 5:34:02 PM","Met CR1000","S","BMP5 message received","type: 0x97","manage comm resource"
"2009-11-11 5:34:22 PM","PakBusPort_2","S","sending message","src: 4094","dest: 20","proto: BMP5","type: 0x17","tran: 157"
"2009-11-11 5:34:22 PM","PakBusPort_2","S","received message","src: 20","dest: 4094","proto: BMP5","type: 0x97","tran: 157"
"2009-11-11 5:34:22 PM","Met CR1000","S","BMP5 message received","type: 0x97","manage comm resource"
Most PakBus devices, particularly the dataloggers, have a forty second time out for PakBus low level sessions. If that time out hits and no message from that session end point has been received to extend the time out, then the datalogger will close the session. What this means really depends upon the link but, for phone modem connections, this can imply that the logger will lower its modem enable line which, in turn, will cause the remote modem to hang up its connection.
The twenty second interval clock check commands that LoggerNet sends are an effort to maintain the session in the light of this forty second time out. I would further point out that these messages should only be sent if LoggerNet is not sending any other message (such as data collection commands and etc.) that will have a similar effect.
Thanks, jtrauntvein ! Can the transmission interval of this keep alive message and the datalogger timeout be changed ?
The problem I am actually experiencing is the long delay to establish communication with the 2nd CR1000. (The two CR1000s are connected via the RS232 port using 115200 baud.) As you can see from the below log, it takes about 35 secs. Any method to shorten it ?
Specifics I don't understand include:
1. Why didn't the CR1000 respond to the first Clock Check command transaction 153 ?
2. How come the Loggernet resent the Clock Check command transaction 153 at 34:37 ? Also, why is the time gap just 15 sec this time ?
Thanks !
"2009-11-11 5:34:02 PM","ComPort","S","opening comm port","COM17","115200"
"2009-11-11 5:34:02 PM","ComPort","S","Provider opened","115200"
"2009-11-11 5:34:02 PM","ComPort","S","Device dialed"
"2009-11-11 5:34:02 PM","PakBusPort_2","S","sending message","src: 4094","dest: 10","proto: PakCtrl","type: 0x09","tran: 154"
"2009-11-11 5:34:02 PM","PakBusPort_2","S","received message","src: 10","dest: 4094","proto: PakCtrl","type: 0x89","tran: 154"
"2009-11-11 5:34:02 PM","PakBusPort_2","S","sending message","src: 4094","dest: 10","proto: PakCtrl","type: 0x0a","tran: 155"
"2009-11-11 5:34:02 PM","PakBusPort_2","S","received message","src: 10","dest: 4094","proto: PakCtrl","type: 0x8a","tran: 155"
"2009-11-11 5:34:02 PM","PakBusPort_2","S","sending message","src: 4094","dest: 10","proto: PakCtrl","type: 0x0b","tran: 156"
"2009-11-11 5:34:02 PM","PakBusPort_2","S","received message","src: 10","dest: 4094","proto: PakCtrl","type: 0x8b","tran: 156"
"2009-11-11 5:34:02 PM","PakBusPort_2","S","sending message","src: 4094","dest: 20","proto: BMP5","type: 0x17","tran: 153"
"2009-11-11 5:34:22 PM","PakBusPort_2","S","sending message","src: 4094","dest: 20","proto: BMP5","type: 0x17","tran: 157"
"2009-11-11 5:34:22 PM","PakBusPort_2","S","received message","src: 20","dest: 4094","proto: BMP5","type: 0x97","tran: 157"
"2009-11-11 5:34:22 PM","Met CR1000","S","BMP5 message received","type: 0x97","manage comm resource"
"2009-11-11 5:34:37 PM","PakBusPort_2","S","sending message","src: 4094","dest: 20","proto: BMP5","type: 0x17","tran: 153"
"2009-11-11 5:34:37 PM","Met CR1000","W","transaction failure","timed out or resource error","check/set clock"
"2009-11-11 5:34:37 PM","PakBusPort_2","S","received message","src: 20","dest: 4094","proto: BMP5","type: 0x97","tran: 153"
"2009-11-11 5:34:37 PM","Met CR1000","S","BMP5 message received","type: 0x97","check/set clock"
"2009-11-11 5:34:37 PM","PakBusPort_2","S","sending message","src: 4094","dest: 10","proto: PakCtrl","empty"
The clock transaction to which you refer (153) is actually being sponsored by the connect screen and is sent by it in order to establish and "verify" the link. The retransmission of the message at 5:34:37 is a result of a time out which, apparently, was around 15 seconds. Normally, on a direct connection, the time out will be less than this (around 5 seconds) but, because address 10 is being used as a router, LoggerNet uses a longer time out.
Given the fact that the first communication attempt fails but the second appears to work quickly, I would assume that the second logger (address 20) is not auto-baud synching quickly enough to detect the input. Note that, since the log only shows what is going on from LoggerNet's perspective, it does not reveal what is going on between the two loggers. You may get better results by changing the baud rate settings for the RS232 port on both loggers from "115200 Auto" to "115200 Fixed".
Thanks again ! But the baud rate settings for the RS232 port on both loggers are already "115200 Fixed" :(
Also, is the timeout here 35 sec (the time gap between the two clock transaction 153) or 15 sec ? This is indeed the reason for my creating this thread. If the timeout is so long and is not changeable, a single miss of the command by the logger will create a delay of 35 sec ! Another thing worths mentioning is the phenomenon is repeatable. It takes the same time to connect every time.
I spoke with one of the engineers responsible for the CR1000 OS yesterday and he told me that they have recently discovered a problem with the RS232 port that can result in the first bytes of transmission being ignored because the CPU is in a sleep state when the transmission first arrives. I believe that this could explain what you are seeing. In order to avoid this, you would need to keep the RS232 port active all of the time (this can be done through settings) but, currently, this will not work until a new OS can solve the CPU issue.
In the meantime, you can work around the problem by using a different interface such as COM1 (the control ports) or using an SC932A or SC105 to communicate using the control ports.
So far as the delays that you were inquiring about with LoggerNet: LoggerNet will factor any extra response time that has been assigned for links as well as the hop metric delays reported by PakBus nodes to calculate the timeout for PakBus transactions. The timeout of thirty five seconds does seem to be longer than what would exist by default (On my own test setup, I access a CR1000 over an Internet based router and get no longer than 13.5 seconds for a timeout). Is there a chance that you have assigned extra response time to the PakBus port or any of its parents?
Has this been fixed with OS18?
I cant spot it in the changelog.
No, the issue with a loss of characters during the sleep state was discovered post release of OS18. This issue is pretty obscure and may not be the core of you problem, as normally the logger shutsdown the serial port altogether and goes to sleep after a timeout of about 40 sec. In that state characters are always expected to be lost on the first communication, which is why the Pakbus protocol sends a special dial packet to wake the logger and sync the baud rate.
The recent discovered issue normally only affects other protocols (DNP3 and Modbus) where the user has turned on the serial port permanently and does not expect to loose the initial characters. Even with the serial port on the logger still went to sleep after 40 s, corrupting the first packet of data received. These protocols normally overcome this by retrying, so this problem was hidden up till now.
This may or may not affect you. The logger acting as a router (if it is - see below) should send a dial packet to wake it up if the connection was not previously active. As Jon says you would not see this in these logs.
You do not say what the routing configuration or hardware is between the two loggers which are connected via a single serial port?? Also describe the way the two loggers are "connected" in your network map in Loggernet.