Icp Con. Dcon. Потеря начала ответа. Опции

[zaural]

Здравствуйте. Кто-нибудь сталкивался с проблемой следующего рода. Опрашиваю несколько (пока 2 прибора) приборов ICP DAS по протоколу Dcon. Один отвечает нормально (I7053 дискретные в/вв), а вот I7015 пропадает начало ответа (нет начальных байт). Временами ответ приходит полностью, но где-то раз в 30 мин. В остальное время первые 1-3 байта не приходят. С чем может быть связано, кто-нибудь натыкался на подобное?

[zaural]

Здравствуйте. Кто-нибудь сталкивался с проблемой следующего рода. Опрашиваю несколько (пока 2 прибора) приборов ICP DAS по протоколу Dcon. Один отвечает нормально (I7053 дискретные в/вв), а вот I7015 пропадает начало ответа (нет начальных байт). Временами ответ приходит полностью, но где-то раз в 30 мин. В остальное время первые 1-3 байта не приходят. С чем может быть связано, кто-нибудь натыкался на подобное?

[Alexander_I]

За почти 20 лет работы с подобными модулями ни единого раза не встречал с протоколом DCON подобных фортелей. Однако, изобразить вероятно можно, если вы не дожидаясь конца обработки одного модуля посылаете запрос на следующий. Может получиться нечто подобное, ибо конверторы интерфейса автоматически переключают направление передачи.

[zaural]

При длинном ответе (26 байт должно быть) стабильно идут 23-25, лишь "по праздникам" 26. При коротком ответе (6 байт) в основном приходит 6, но временами (циклически каждый где-то 6-10 раз) не отвечает.

Однако, изобразить вероятно можно, если вы не дожидаясь конца обработки одного модуля посылаете запрос на следующий.

Я уже пробовал не циклический быстрый подряд опрос: 1) циклически , но с большими интервалами (до 5 секунд); 2) генерировал запрос сам время от времени, циклически не опрашивал. Результаты пока теже. Будем смотреть.

[Alexander_I]

А что у вас значит циклически, с большими интервалами? Т.е. вы опросили один модуль, выждали секунду-другую, опросили следующий, и т.д.?

[zaural]

Т.е. вы опросили один модуль, выждали секунду-другую, опросили следующий, и т.д.?

Вообще логика пока следующая:
1) посылаю запрос
2) получаю уведомление, что он ушел
3) жду ответ определенного размера. Если ответ есть - считываю. Если нет или не тот размер, то жду определенное время.
4) получил ответ или истек период ожидания -> шлю следующий запрос.
Вот эту логику я считал идеальной, и пытался ее реализовать. При различных экспериментах понятно, что вроде ответы путаются. Несмотря на то, что вроде если нет ответа жду сколько то секунд. Получается жду ответа, буффер пуст, ошибка, идет время. Делаю запрос следующий, буфер наполнел и там может быть информация по предыдущему запросу. Но это вроде как я понимаю.
Понятно, что я где-то что-то не учитываю (но что)? Оба модуля сидят напрямую на ПЛК, расстояние малое. Но есть задержка, которую надо добавить.

Сообщение отредактировал zaural - 12.2.2013, 13:23

[Alexander_I]

Да никаких задержек добавлять не надо. Все абслютно четко, запро - ответ, с анализом, нормальный или ошибочный, и тут-же можно давать следующий запрос. Здается мне, что вы как-то перехитрили сами себя с обработкой. В жизни не видел ничего подобного.

[zaural]

Все абслютно четко, запро - ответ, с анализом, нормальный или ошибочный, и тут-же можно давать следующий запрос

Оно так и есть. Послдений эксперимент: отправляю ровно один запрос #02. Должн овернуться >05657FFF7FFF7FFF7FFF7FFF0D. Возвращается 5657FFF7FFF7FFF7FFF7FFF0D. А иногда вместь начальных "нормальных" ASCII возвращаются 130 и больше. И это вот ровно отправлен один запрос, считан ответ и все, больше запросов нет.

[Alexander_I]

Ну тогда однозначно у вас кривой модуль, коль вы так уверены, что нет ошибок обработки, и вы однозначно уверены, что именно это ответ от модуля. Правда от этого не становятся понятными ошибки от второго модуля, дискретного. У нас связь работает в цеховых условиях параллельно кран-балкам и кабельным трассам на расстоянии свыше 100 м и при скорости 57600 - ни разу не видел ничего подобного.

П.С. Естественно - с терминаторами. Кабель КММС.

Сообщение отредактировал Alexander_I - 13.2.2013, 9:54

[ktulu]

"Здравствуйте. Кто-нибудь сталкивался с проблемой следующего рода. Опрашиваю несколько (пока 2 прибора) приборов ICP DAS по протоколу Dcon. Один отвечает нормально (I7053 дискретные в/вв), а вот I7015 пропадает начало ответа (нет начальных байт). Временами ответ приходит полностью,"

...эффект для меня давно известный у ICPCON, причем независимо от протокола DCON или ModBus RTU, причина поведения кроется где-то в реализации RS-485 драйвера на модулях, решается химией с задержками после отправления запроса от master, и выставлением задержки перед ответом на slave, там кто-то из них занимает линию на какие-то 10ки мс больше чем положено для отправления посылки...

[zaural]

.эффект для меня давно известный у ICPCON, причем независимо от протокола DCON или ModBus RTU, причина поведения кроется где-то в реализации RS-485 драйвера на модулях, решается химией с задержками после отправления запроса от master, и выставлением задержки перед ответом на slave, там кто-то из них занимает линию на какие-то 10ки мс больше чем положено для отправления посылки

Значит все-таки что-то там есть. Я не одинок в проблеме.
Вот логи линии связи:
1)

$016\x0D\x00!EFFF00\x0D#012\x0D\x00!0100000\x0D#02\x0D\x00\x0005687FFF7FFF7FFF7FFF7FFF\x0D
$016\x0D\x00!EFFF00\x0D
#012\x0D\x00!0100000\x0D#02\x0D\x00\x0005687FFF7FFF7FFF7FFF7FFF\x0D
$016\x0D\x00!EFFF00\x0D
#012\x0D\x00!0100000\x0D#02\x0D\x00\x0005687FFF7FFF7FFF7FFF7FFF\x0D

Вроде правильно. Хотя по описаниям должна вернуться строка формата >05687FFF7FFF7FFF7FFF7FFF. А здесь разделителя не видно.
2)

$016\x0D\x00!EFFF00\x0D#012\x0D\x00!0100000\x0D
#02\x0D\x00\x00
$016\x0D\x00!EFFF00\x0D#012\x0D\x00!0100000\x0D

И вот такое временами происходит. То есть на #02 не ответа.
И все проблемы пока от аналогового #02.
Дискретный $016 и #012 вроде отвечает стабильно.

Сообщение отредактировал zaural - 14.2.2013, 12:59

[zaural]

Скорость всего 9600. Принимаю на beckhoff через интерфейсный модуль.

[SIM]

За почти 20 лет работы с подобными модулями ни единого раза не встречал с протоколом DCON подобных фортелей.

Я тоже не сталкивался, могу статистику посмотреть, I7188EXD опрашивает I7060 годами без перерыва на 115к, сколько будет пропущенных запросов, какие-то единицы из миллионов. При помехах от насосов под 100 КВт.

Еще, потеоретезирую, может какая-то проблема в терминалке на ПК, винда как-раз имеет квант времени 10-20 мс, и при криво настроенном драйвере FIFO без буфера, винда не успеет переключиться в режим приема. Сам когда писал терминалки для работы с СОМ портом читал по одному байту, так проще было программировать, и хватало вполне быстродействия на 9600.

Может мастер сам не успевает переключаться в режим чтения, ждет таймаут после передачи (иногда для этого используются дополнительные линии COM пора типа DTR, RTS и т.п.)

Попробуйте запросы слать на другом оборудовании вообще. Или подключите паралельно RS485 ноутбук в режиме чтения, и простой переходник, у меня для таких целей есть RS485-USB, очень удобно. Или вообще осцилографом разобрать что творися на шине денных.

Сообщение отредактировал SIM - 14.2.2013, 15:18

[zaural]

Спасибо всем за советы. Проблема разрешилась.