|
Название: ТСРВ 043+СП4+терминал IRZ21AB=Неверное время Отправлено: shurban4ik от 16.11.2024, 03:55:31 Есть много объектов не менее 50 где стоят приборы ТСРВ 043 024М 034 026М, но лишь на нескольких объектах с ТСРВ043 выскакивает ошибка неверное время или дата в приборе, затем через какое время пропадает, а иногда не пропападает, иногда реально показывает что там типо дата и время реально сбито. Иногда помогает переопросить прибор с перезаписью и дата нормализуется и иногда и это не помогает. Все модемы одинаково настроены понимаю что проблема либо с модемами либо с СП4, смущает что на других скажем 46 приборах все нормально работает и лишь на 4х ТСРВ 043 такая фигня
Название: Re:ТСРВ 043+СП4+терминал IRZ21AB=Неверное время Отправлено: KIA от 18.11.2024, 08:05:51 Попробуйте через наборы запустить опрос текущего времени с проблемных приборов. Например минут на 5.
Проверьте корректно ли оно считывается. Название: Re:ТСРВ 043+СП4+терминал IRZ21AB=Неверное время Отправлено: shurban4ik от 26.11.2024, 05:17:30 Проверил запустил набор с интервалом 30сек текущие время возвращает нормально
Название: Re:ТСРВ 043+СП4+терминал IRZ21AB=Неверное время Отправлено: Иван Кривокора от 24.12.2024, 12:19:45 Есть много объектов не менее 50 где стоят приборы ТСРВ 043 024М 034 026М, но лишь на нескольких объектах с ТСРВ043 выскакивает ошибка неверное время или дата в приборе, затем через какое время пропадает, а иногда не пропападает, иногда реально показывает что там типо дата и время реально сбито. Иногда помогает переопросить прибор с перезаписью и дата нормализуется и иногда и это не помогает. Все модемы одинаково настроены понимаю что проблема либо с модемами либо с СП4, смущает что на других скажем 46 приборах все нормально работает и лишь на 4х ТСРВ 043 такая фигня Здравствуйте.Прошу прощения за задержку с ответом. были заняты текущими задачами в соответствии с планом разработки. Проанализировали последние логи, ища моменты с чтением даты и времени приборов по временам возникновения события «Неверная дата или время в приборе» в журнале. Вот пара примеров: [DEBUG] 00:01:27.136 Session 17070. Посылаем запрос: 010380040002AC0A [DEBUG] 00:01:27.136 Session 17070. Отправляем в адаптер: C8CACBCCCD010008010380040002AC0A0D0A [DEBUG] 00:01:30.641 Session 17070. Network: Пришел ответ. Размер: 39, данные: C8CACBCCCD01001D0103183F851EB83F851EB83F851EB84040000040400000404000004DD80D0A [DEBUG] 00:01:30.641 Session 17070. Обработка данных: 0103183F851EB83F851EB83F851EB84040000040400000404000004DD8 01 03 18 3F851EB83F851EB83F851EB8404000004040000040400000 4DD8 [DEBUG] 02:01:38.773 Session 17070. Посылаем запрос: 010380040002AC0A [DEBUG] 02:01:38.773 Session 17070. Отправляем в адаптер: C8CACBCCCD010008010380040002AC0A0D0A [DEBUG] 02:01:40.584 Session 17070. Network: Пришел ответ. Размер: 75, данные: C8CACBCCCD01004101033C3B4AE3DC3B5BEC813B5E6E983B57C8B13B50E8513B92BBC23B8AE3B93B91AC1D3B8E51053B87EEED3BD246B43BCA66AB3BAC4F293BB984F63BC30D43D98E0D0A [DEBUG] 02:01:40.584 Session 17070. Обработка данных: 01033C3B4AE3DC3B5BEC813B5E6E983B57C8B13B50E8513B92BBC23B8AE3B93B91AC1D3B8E51053B87EEED3BD246B43BCA66AB3BAC4F293BB984F63BC30D43D98E 01 03 3C 3B4AE3DC3B5BEC813B5E6E983B57C8B13B50E8513B92BBC23B8AE3B93B91AC1D3B8E51053B87EEED3BD246B43BCA66AB3BAC4F293BB984F63BC30D43 D98E Вместо запрошенных 4 байтов (2 регистров) в канал связи попадают ответы с большим количеством байтов, причем первые 4 байта в этих ответах точно не являются unixtime. Но ответы корректные, код функции совпадает, контрольная сумма бьётся. Соответственно, драйвер пытается разобрать первые 4 байта как unixtime, и в результате возвращает 0x3F851EB8 1065688760 Thu Oct 09 2003 08:39:20 GMT+0000 или 0x3B4AE3DC 994763740 Tue Jul 10 2001 11:15:40 GMT+0000, как в примерах выше. Вот так выглядят связки запрос-ответ для этого же прибора с ответом с временем unixtime: [DEBUG] 00:01:32.212 Session 17070. Посылаем запрос: 010380040002AC0A [DEBUG] 00:01:32.212 Session 17070. Отправляем в адаптер: C8CACBCCCD010008010380040002AC0A0D0A [DEBUG] 00:01:33.359 Session 17070. Network: Пришел ответ. Размер: 19, данные: C8CACBCCCD010009010304676210C448CA0D0A [DEBUG] 00:01:33.359 Session 17070. Обработка данных: 010304676210C448CA 01 03 04 676210C4 48CA [DEBUG] 02:01:48.982 Session 17070. Посылаем запрос: 010380040002AC0A [DEBUG] 02:01:48.982 Session 17070. Отправляем в адаптер: C8CACBCCCD010008010380040002AC0A0D0A [DEBUG] 02:01:50.482 Session 17070. Network: Пришел ответ. Размер: 19, данные: C8CACBCCCD01000901030467622CF5981E0D0A [DEBUG] 02:01:50.482 Session 17070. Обработка данных: 01030467622CF5981E 01 03 04 67622CF5 981E 4 байта 0x676210C4 1734480068 Wed Dec 18 2024 00:01:08 GMT+0000 или 0x67622CF5 1734487285 Wed Dec 18 2024 02:01:25 GMT+0000 представляют корректное время. С чем это может быть связано? Возможны две причины: • либо к прибору подключен один модем, и модем настроен на подключение к нескольким TCP-серверам, и в результате конкурентного чтения приходят ответы на чужие запросы; • либо к прибору подключены два модема: к интерфейсам RS-232 и RS-485 по одному модему, соответственно; но для этих двух интерфейсов у прибора один UART; соответственно, при конкурентном чтении через разные интерфейсы обмена наш запрос мог просто не дойти, его «обогнал» чужой запрос. Так как это ваши приборы на ваших узлах учета, расскажите нам, пожалуйста, какой у вас случай из этих двух. С уважением, Кривокора Иван Название: Re:ТСРВ 043+СП4+терминал IRZ21AB=Неверное время Отправлено: Иван Кривокора от 24.12.2024, 12:46:20 Есть много объектов не менее 50 где стоят приборы ТСРВ 043 024М 034 026М, но лишь на нескольких объектах с ТСРВ043 выскакивает ошибка неверное время или дата в приборе, затем через какое время пропадает, а иногда не пропападает, иногда реально показывает что там типо дата и время реально сбито. Иногда помогает переопросить прибор с перезаписью и дата нормализуется и иногда и это не помогает. Все модемы одинаково настроены понимаю что проблема либо с модемами либо с СП4, смущает что на других скажем 46 приборах все нормально работает и лишь на 4х ТСРВ 043 такая фигня Здравствуйте.Прошу прощения за задержку с ответом. были заняты текущими задачами в соответствии с планом разработки. Проанализировали последние логи, ища моменты с чтением даты и времени приборов по временам возникновения события «Неверная дата или время в приборе» в журнале. Вот пара примеров: [DEBUG] 00:01:27.136 Session 17070. Посылаем запрос: 010380040002AC0A [DEBUG] 00:01:27.136 Session 17070. Отправляем в адаптер: C8CACBCCCD010008010380040002AC0A0D0A [DEBUG] 00:01:30.641 Session 17070. Network: Пришел ответ. Размер: 39, данные: C8CACBCCCD01001D0103183F851EB83F851EB83F851EB84040000040400000404000004DD80D0A [DEBUG] 00:01:30.641 Session 17070. Обработка данных: 0103183F851EB83F851EB83F851EB84040000040400000404000004DD8 01 03 18 3F851EB83F851EB83F851EB8404000004040000040400000 4DD8 [DEBUG] 02:01:38.773 Session 17070. Посылаем запрос: 010380040002AC0A [DEBUG] 02:01:38.773 Session 17070. Отправляем в адаптер: C8CACBCCCD010008010380040002AC0A0D0A [DEBUG] 02:01:40.584 Session 17070. Network: Пришел ответ. Размер: 75, данные: C8CACBCCCD01004101033C3B4AE3DC3B5BEC813B5E6E983B57C8B13B50E8513B92BBC23B8AE3B93B91AC1D3B8E51053B87EEED3BD246B43BCA66AB3BAC4F293BB984F63BC30D43D98E0D0A [DEBUG] 02:01:40.584 Session 17070. Обработка данных: 01033C3B4AE3DC3B5BEC813B5E6E983B57C8B13B50E8513B92BBC23B8AE3B93B91AC1D3B8E51053B87EEED3BD246B43BCA66AB3BAC4F293BB984F63BC30D43D98E 01 03 3C 3B4AE3DC3B5BEC813B5E6E983B57C8B13B50E8513B92BBC23B8AE3B93B91AC1D3B8E51053B87EEED3BD246B43BCA66AB3BAC4F293BB984F63BC30D43 D98E Вместо запрошенных 4 байтов (2 регистров) в канал связи попадают ответы с большим количеством байтов, причем первые 4 байта в этих ответах точно не являются unixtime. Но ответы корректные, код функции совпадает, контрольная сумма бьётся. Соответственно, драйвер пытается разобрать первые 4 байта как unixtime, и в результате возвращает 0x3F851EB8 1065688760 Thu Oct 09 2003 08:39:20 GMT+0000 или 0x3B4AE3DC 994763740 Tue Jul 10 2001 11:15:40 GMT+0000, как в примерах выше. Вот так выглядят связки запрос-ответ для этого же прибора с ответом с временем unixtime: [DEBUG] 00:01:32.212 Session 17070. Посылаем запрос: 010380040002AC0A [DEBUG] 00:01:32.212 Session 17070. Отправляем в адаптер: C8CACBCCCD010008010380040002AC0A0D0A [DEBUG] 00:01:33.359 Session 17070. Network: Пришел ответ. Размер: 19, данные: C8CACBCCCD010009010304676210C448CA0D0A [DEBUG] 00:01:33.359 Session 17070. Обработка данных: 010304676210C448CA 01 03 04 676210C4 48CA [DEBUG] 02:01:48.982 Session 17070. Посылаем запрос: 010380040002AC0A [DEBUG] 02:01:48.982 Session 17070. Отправляем в адаптер: C8CACBCCCD010008010380040002AC0A0D0A [DEBUG] 02:01:50.482 Session 17070. Network: Пришел ответ. Размер: 19, данные: C8CACBCCCD01000901030467622CF5981E0D0A [DEBUG] 02:01:50.482 Session 17070. Обработка данных: 01030467622CF5981E 01 03 04 67622CF5 981E 4 байта 0x676210C4 1734480068 Wed Dec 18 2024 00:01:08 GMT+0000 или 0x67622CF5 1734487285 Wed Dec 18 2024 02:01:25 GMT+0000 представляют корректное время. С чем это может быть связано? Возможны две причины: • либо к прибору подключен один модем, и модем настроен на подключение к нескольким TCP-серверам, и в результате конкурентного чтения приходят ответы на чужие запросы; • либо к прибору подключены два модема: к интерфейсам RS-232 и RS-485 по одному модему, соответственно; но для этих двух интерфейсов у прибора один UART; соответственно, при конкурентном чтении через разные интерфейсы обмена наш запрос мог просто не дойти, его «обогнал» чужой запрос. Так как это ваши приборы на ваших узлах учета, расскажите нам, пожалуйста, какой у вас случай из этих двух. С уважением, Кривокора Иван А вот у ТСРВ-023/027/024/025 и ТСРВ-042 интерфейсы RS-232 и RS-485 на одном UART’е и не должны использоваться параллельно. |