Вот скрин сниффера при обмене с двумя сигмами. К сожалению, все равно не очень понятно, так как присутствуют непонятные символы. С SOH и ETH еще более менее ясно, а вот с другим...1.jpg
Вот скрин сниффера при обмене с двумя сигмами. К сожалению, все равно не очень понятно, так как присутствуют непонятные символы. С SOH и ETH еще более менее ясно, а вот с другим...1.jpg
Последний раз редактировалось intellis; 07.09.2016 в 21:11.
После дополнительного изучения сниффера разобрался вроде, надо отправлять команду типа '01GH' Для опроса сигнализатора с номером 1. тогда начинает что-то приходить. Возникла другая проблема. Приходят непонятные цифры - '0200002120200002120200002' , не соответствующие документации, но помимо этого вот еще что - после отключения сигнализатора данные продолжают поступать еще несколько минут. Откуда неясно. Сигнализатор сидит на RS485-2. На RS-485-1 другое устройство со своим протоколом. Поначалу подумал, что в результате глюка данные по сигнализатору начали идти с RS-485-1, но при полном отключении всех интерфейсов данные энное количество времени все равно идут. Потом перестают. Оба RS-485 работаеют с библиотекой UNM. В то же время обмен по RS-485-1 идет отлично. Похоже на глюк ПЛК, точнее его интерфейса. Никто не сталкивался?
а что родная программа отправляет при запросе и получает в ответ по сниферу?
интересует так же в HEX
Вот скрин в hex, полученный в режиме наблюдения, то есть при запущенной родной программе, верхний скрин, который в ASCII был получен тем же способом. 2.jpgКстати, порт RS-485-2, который опрашивает сигнализатор, у меня в режиме RTU. В приведенном скрине все сходится, полученные данные я не проверял, но в ответах есть и номер сигнализатора и код функции. А вот у меня ерунда какая-то. Ковырял настройки порта в Codesys - пока ничего не нашел.
Последний раз редактировалось intellis; 08.09.2016 в 23:01.
Контрольная сумма в ответе совпадает с документацией и она не Modbus, именно как описано в документации сложение всех байт, два байта, старшим вперед.
в запросе сонтрольная сумма одним байтом.
Попробуйте в терминале в HEX варианте отправить запрос.
Ну и копайте код Codesys
Да, видел, на скрине все совпадает с документацией. Но с ПЛК не выходит пока. Буду пробовать дальше.
intellis и melky, Вы читали эту строчку, я просто на скринах этого не вижу, может не внимательно смотрюНачало и конец кадра обозначаются специальными маркерами
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Да, читал, и да, на скринах нет этих маркеров. Так ведь эта строчка Алена в той части мануала, где описывается протокол Овен. Хотя мне говорили, что протокол сигмы идентичен, нот по видимому это не так.
так в любом аскишном протоколе есть оконечные маркеры, это в RTU по времени паузы определяется когда завершился пакет.
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Судя по ответу прибора от родной программы в HEX варианте там в помине нет никаких маркеров. Все четко по документации включая расчет контрольной суммы.
Прибор работает в RTU режиме а не в ASCII, зачем туда приплели протокол ОВЕН даже непонятно.
з.ы. посылка команды в HEX из терминала точно скажет о результате.