PDA

Просмотр полной версии : задержка ответа по сети Rs-485



light_finder
27.05.2010, 19:34
Господа, доброго времени суток.

Мой пост направлен, в первую очередь, к разработчикам и инженерам компании ОВЕН. Опишу вкратце свою проблему.

Я представляю компанию, относящуюся к МинОбороны, поэтому требования и спрос с нас велик. В данный момент наша компания занимается разработкой системы управления. Для реализации этой системы были выбраны модули фирмы ОВЕН. Так как время на разработку у нас ограничено, был выбран самый нетрудоемкий для изучения и понимания протокол обмена, а именно, DCON. Софт был разработан и протестирован с использованием преобразователя АС3-М. Далее была приобретена плата расширения, имеющая порт RS-485, и руководством была поставлена цель переписать софт для работы через порт этой платы.

Специфика порта такова, что он требует программного управления передатчиком. То есть для записи данных в порт требуется включить передатчик, для чтения - выключить. Данные, попадающие в порт при включенном передатчике, теряются. Так как выключение передатчика занимает определенное время, требуется внести задержку между моментом получения модулем управляющего пакета и моментом отправки модулем ответа с целью предотвращения потери ответа.

К нашей радости, модули ОВЕН имеют конфигурируемый параметр "задержка ответа по сети RS-485". Значение этого параметра было установлено в максимально допустимое значение, составляющее 45 мс. После этого был написан софт. Но как выяснилось при тестировании, написанный софт работает только с модулем МДВВ.

Об этой проблеме я сообщил техподдержке. Мне ответил Валюнин Кирилл. Он послал мне сниффер и предложил измерить реальные задержки ответов модулей. Как выяснилось, ни один из модулей (а я работаю с МДВВ, МВУ И МВА) не выдает заданной задержки в 45 мс. МДВВ выдает бОльшую задержку, МВУ И МВА мЕньшую. Поэтому ответ МДВВ считать удается, а ответы МВА и МВУ нет. Я послал скриншоты сниффера Кириллу. Он мне ответил, что "как выяснилось в Dcon не поддержан параметр задержки ответа". То есть видимо это стало неожиданностью для вашего сотрудника. Почему об этом нет ни слова в руководстве я так и не понял. На вопрос, что мне теперь делать (сдача системы намечена уже буквально на следующую неделю), Кирилл предложил мне перейти на другой протокол. Решение, конечно, профессиональное, но разбираться сейчас в логике работы modbus как-то нету времени. Я написал об этом Кириллу и попросил его выслать мне исходные коды для обмена с тремя имеющимися у меня модулями пор протоколу modbus. На эту просьбу Кирилл мне ответил, что у него нет исходных кодов, так как он не программист . Я ему предложил спросить программистов, через два дня он мне ответил, что спросил у программиста , и тот ему ответил, что у них нет ресурса для разработки примеров работы с модулями по протоколу modbus. На этом все закончилось. На вопросы, что же мне делать, Кирилл больше не отвечает.

Я пишу это не с целью описать непрофессиональность ваших сотрудников, а с целью выяснить, что же мне все-таки делать. Потому что сдача системы уже на носу, а примеры для modbus мне никто не дает и что делать никто не говорит. Прошу прощения, но при всем уважении к Кириллу я не верю в то, что ваши программисты не имеют готовых примеров для работы со всеми вашими модулями.

Прошу как можно скорее разобраться и помочь мне с решением сложившейся проблемы.

Филоненко Владислав
27.05.2010, 20:02
1. 45 мс переключать 485? это рекорд. Завтра спрошу наших программистов на PC о методах "скоростного" переключения.
Сообщите свой e_mail.
2. Протоколы ОВЕН и ModBus гораздо логичнее и проще в реализации, к тому же, учитывая специфику министерства обороны, обеспечивают в разы большую надежность контрольной суммы.

light_finder
27.05.2010, 21:09
При чем тут рекорд или нет. Передатчик выключается за меньшее время, просто поведение ваших приборов зачастую непредсказуемо, поэтому я проверял возможность обмена при различных значениях задержек, в том числе и при максимальной. Спрашивать ваших разработчиков о переключении порта не имеет смысла, так как порт куплен не у вашей организации и ваши программисты едва ли смогут чем-то помочь. Вы бы лучше спросили, почему про то, что DCON игнорирует параметр задержки, не сказано в ни в одном руководстве.

Про надежность я с вами спорить не буду, хотя про разы и речи быть не может. И механизм контроля протокола ОВЕН, ни механизм контроля DCON, и механизм контроля протокола modbus обнаруживают ошибки одинарной кратности, но не более того. Про простоту, кажется, тоже все очевидно, если найти и сравнить объемы описаний каждого из этих трех протоколов.

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

ps связаться со мной по е-мейлу можно нажав на мой ник и выбрав ссылку "отправить e-mail"

Николаев Андрей
27.05.2010, 23:56
1. К сожалению для технической поддержки стало неприятным сюрпризом как и для Вас отсутствие задержки ответа по протоколу DCon, по этому это не указано в документации. За что приносим извинения, и обязательно исправим.
2. Примеров действительно нет. Завтра постараемся как то решить данный вопрос. Что именно (какие данные) Вам нужны для поддержки протокола ОВЕН или ModBus? Если просто формат запроса и формат получаемого ответа - завтра мы Вам данную информацию вышлем.

light_finder
28.05.2010, 00:10
Если Вам не сложно, то вышлите форматы пакетов по обоим протоколам (как ОВЕН, так и ModBus) которые нужно послать в порт для выполнения следующих действий:

1. Установка выхода (одного и всех) модуля МДВВ в заданное состояние (без ШИМ, просто включить и выключить)
2. Чтение состояния входа (одного и всех) модуля МДВВ
3. Установка состояния входа (одного и всех) модулей МВУ8 и МР1 в заданное состояние (опять же, без ШИМ)
4. Чтение состояния входа (одного и всех) модуля МВА8

Мне нужны просто примеры посылок для выполнения вышеперечисленных действий, а также структуры ответов модулей. Ну и алгоритмы формирования контрольных сумм.

Ps если существует возможность считывания значений выходов МДВВ, МВУ и МР1, тоже пришлите, пожалуйста, формат и примеры посылок и ответов.

Дмитрий Егоренков
28.05.2010, 09:48
> что же мне все-таки делать

купить нормальную плату, которая не требует программного управления

Кирилл Валюнин
28.05.2010, 09:59
Прямо-таки рассказ про меня.
А теперь по делу:
1. Готовых примеров-нет.
2. Сейчас прошивки МВА8 и МВУ8 проверяются. Выясняется почему не отрабатывает задержка.
Молчу 2 дня- ибо пока нет положительных результатов.
Если внесение корректив в прошивку потребует много времени, будут созданы примеры работы по ModBus

light_finder
28.05.2010, 10:29
кирилл, так мы с вами уже две недели с этой проблемой разбираемся.

господа, вы можете понять, что мне через несколько дней надо проект сдавать? хотя бы форматы, которые мне обещал николаев андрей выслать, пришлите. а потом разбирайтесь в прошивках.

прошу прощения за то, что имена и фамилии с маленьких букв - опять из-за вашего движка

light_finder
28.05.2010, 10:45
> что же мне все-таки делать

купить нормальную плату, которая не требует программного управления

совет не уступает по профессиональности совету "перейдите на другой протокол, так как в этом мы что-то не реализовали". Но Вам это простительно, так как Вы не являетесь сотрудником компании ОВЕН, насколько я могу судить.

Понимаете, дело в том, что не я выбираю и покупаю средства для реализации поставленной задачи. А делают это люди, мало представляющие себе принципы работы тех средств, которые они покупают. Да и кто знал, что с модулями фирмы ОВЕН будут возникать какие-то проблемы..

Дмитрий Егоренков
28.05.2010, 10:59
вы или ваше начальство приняли неверное техническое решение, купив полуавтоматический преобразователь, и теперь героически боретесь с последствиями. с автоматическим преобразователем проблема бы даже не возникла.

за выходные у вас еще есть время заменить Dcon на овен. это несложно.

light_finder
28.05.2010, 11:12
я бы сказал, при осуществлении какого действия мы или наше начальство приняли неверное техническое решение, но промолчу.

какая информация мне нужна для для перехода на другой протокол я написал немного выше и мне обещали эту информацию прислать.

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

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

Малышев Олег
28.05.2010, 11:23
Здравствуйте,

Вы купили плату с поддержкой RS485 с не автоматическим управлением по интерфейсу.
Данная проблема решена под Windows через owen_io.dll и Owen OPC.
К сожалению Вы используете Linux дистрибутив Debian.

Если бы Вы дали труд поискать в интернете то нашли бы огромное количество бесплатного и распространяемого в исходных кодах софта для работы с Modbus
На вскидку http://pvbrowser.org/pvbrowser/sf/manual/booklet/node44.html

Однако ОСНОВНАЯ проблема не в rs.dl, а в использовании неправильных драйверов платы!
Должен быть patch под Linux RS485 для данной платы - ищите и найдете.

Кстати присоединяюсь к мнению о героической борьбе с последствиями.

Филоненко Владислав
28.05.2010, 11:25
А еще проще ModBus. В стандарте даже даны примеры С функций для расчета CRC.

light_finder
28.05.2010, 11:41
Здравствуйте,
Вы купили плату с поддержкой RS485 с не автоматическим управлением по интерфейсу.

Добрый день.
Спасибо, что объяснили



Если бы Вы дали труд поискать в интернете то нашли бы огромное количество бесплатного и распространяемого в исходных кодах софта для работы с Modbus
На вскидку http://pvbrowser.org/pvbrowser/sf/manual/booklet/node44.html

Кстати присоединяюсь к мнению о героической борьбе с последствиями.

Меня интересует лишь управление модулями ОВЕН, а именно, форматы посылок и ответов. Код, генерирующий и посылающий пакет в порт, я как-нибудь напишу сам.

По поводу мнения о героической борьбе. Если бы разработчики модулей ОВЕН реализовали НОРМАЛЬНО параметр задержки ответа или ХОТЯ БЫ знали о том, что они его не реализовали, никаких проблем бы не возникло.




Однако ОСНОВНАЯ проблема не в rs.dl, а в использовании неправильных драйверов платы!
Должен быть patch под Linux RS485 для данной платы - ищите и найдете.


А почему Вы не сказали, что основная проблема заключается в том, что я использую неправильную операционную систему или неправильный монитор? Причин можно найти сколь угодно много, но ОСНОВНАЯ проблема заключается в том, что разработчики компании ОВЕН халатно отнеслись к разработке.

Кирилл Валюнин
28.05.2010, 12:59
Спор непродуктивен.
Вот такого плана необходимы данные ?
МВА 16 адрес 115200 8,N,1 ModBus-RTU чтение первого канала регистр 0001 целочисленное значение
Request
00:07 [10][04][00][01][00][01][63][4B]

Response
00:07 [10][04][02][00][1B][05][38]
Такое?

Кирилл Валюнин
28.05.2010, 13:14
МВУ8
115200 96 адрес 8,N,1 ModBus-RTU на первый выход подаем 1000 регистр 0 (1000 dec-3e8 hex) функция Write multiple register 10h

Request
00:07 [60][10][00][00][00][01][02][03]
08:0F [E8][03][7C]
Response
00:07 [60][10][00][00][00][01][09][B8]

У МР1 соответственно регистры после 7го

light_finder
28.05.2010, 13:22
Спор непродуктивен.
Вот такого плана необходимы данные ?
МВА 16 адрес 115200 8,N,1 ModBus-RTU чтение первого канала регистр 0001 целочисленное значение
Request
00:07 [10][04][00][01][00][01][63][4B]

Response
00:07 [10][04][02][00][1B][05][38]
Такое?

нет.
Во-первых лучше ASCII версию данного протокола, так как она удобнее для отладки.

примеры нужны такого плана:

МДВВ: адрес 16, скорость 115200, 8 битный байт, без контроля четности, 1 стоп-бит

операция: установка выхода 0 в состояние 1
пакет: ":10..crlf"
ответ: "..crlf"

операция: установка всех выходов в состояние 255
пакет: ":10..FFcrlf"

ответ: "..crlf"

и т,д. для всех перечисленных мной операций.

Для протокола ОВЕН тоже можете прислать аналогичные структуры.

Кирилл Валюнин
28.05.2010, 13:27
мдвв
скорость 115200
адрес 32
команда записи битовой маски выходов (выход 1 замкнуть, остальные разомкнуть)
запрос
20 10 00 32 00 01 02 00 01 F7 D3
ответ
20 10 00 32 00 01 A6 B7

команда записи битовой маски выходов (все выходы разомкнуть)
запрос
20 10 00 32 00 01 02 00 00 36 13
ответ
20 10 00 32 00 01 A6 B7



опрос битовой маски входов:
запрос
20 03 00 33 00 01 72 B4
ответ (все входы разомкнуты)
20 03 02 00 00 04 43
ответ (вход 1 замкнут, остальные разомкнуты)
20 03 02 00 01 C5 83

Кирилл Валюнин
28.05.2010, 13:28
пакет: ":10..crlf"
ответ: "..crlf"
Это для AsCII, для ModBus-RTU все написал

Кирилл Валюнин
28.05.2010, 14:02
Ок. ModBus-ASCII
115200 8,N,1 ModBus-ASCII

МВА8
16 адрес
Регистр 1 читаем int (1 вход) читаем 3 функцией read holding register
Request
:100300010001EB

Response
:100302001BD0

МВУ8
96 адрес пишем функцией 10h (в 0 регистр знаечение 1000 (3Е8 hex))
Регистры МР с 8го идут (в РЭ указано)
Первый выход замкнуть
Request
:6010000000010203E8A2

Response
:6010000000018F

МДВВ
32 адрес
Пишем в 0 регситр (1 выход ) значение 1000 (3Е8 hex))
Request
:2010000000010203E8E2

Response
:201000000001CF

Соответсвенно размыкаем подаем 0
Request
:201000000001020000CD

Response
:201000000001CF

Чтение входов МДВВ
Битовая маска входов 51 регистр (033hex) читаем 3 функцией read holding register
1 вход
Контакт разомкнут
Request
:200300330001A9

Response
:2003020000DB

Контакт замкнут
Request
:200300330001A9

Response
:2003020001DA

Кирилл Валюнин
28.05.2010, 15:11
по Modbus Rtu и Ascii обмен выше.
структура обмена описана в документе (данный документ у Вас уже есть-был выслан в одном из писем)
2404

что касается ОВЕН
http://www.owen.ru/uploads/type_prot_owen.zip

пример обмена:
МВА8 16 адрес
Опрос первого входа
#HGHGONOKVKHN.
#HGGMONOKKHTOHULGIKSSRIIV.

Кирилл Валюнин
28.05.2010, 15:38
какая-нибудь из этой информации пригодилась?

light_finder
28.05.2010, 15:48
кирилл, выделите пожалуйста в предоставленных примерах поля

Кирилл Валюнин
28.05.2010, 16:13
Поля ModBus описаны в pdf-описании
Адрес/функция/стартовый адрес старший байт/стартовый адрес младший байт/ данные старший байт/данные младший байт/контрольная сумма

Request
:200300330001A9

20-адрес прибора
03-номер функции
00
33-33 регистр
00
01-значение 1
А9-контрольная сумма

light_finder
28.05.2010, 16:53
а где символы возврата каретки и переноса строки в конце пакета?

Davy Jones
28.05.2010, 19:48
А может стоит взять более или менее готовое:
http://mbserver.tripod.com/
Ну а так как у вас дебиан:
http://www.modbusdriver.com/doc/libmbusmaster/
http://www.modbustools.com/

Davy Jones
28.05.2010, 20:02
Для Nix на С
http://homepage.ntlworld.com/p.mcrae/paul/
LibModbus - Linux dynamic library:
http://copyleft.free.fr/wordpress/index.php/libmodbus/

light_finder
28.05.2010, 20:10
спасибо, ознакомлюсь на досуге

Davy Jones
28.05.2010, 20:11
возможно что-то пригодится

Foxer
31.05.2010, 15:18
подскажите какой конфликт может возникнуть между двумя мва8 с разными адресами. при подключении поочереди оба стабильно работают, при одновременном подключении и опросе через конфигуратор начинают проскакивать ошибки. увеличил скорость с 9600 до 11500 протокол Rtu, скорость увеличилась, но процент ошибок не изменился. Аналогично при опросе с ПЛК

Филоненко Владислав
31.05.2010, 16:08
увеличьте время ожидания ответа

ASo
31.05.2010, 16:10
проверьте терминирование шины.

Ельцов Андрей
01.06.2010, 07:59
подскажите какой конфликт может возникнуть между двумя мва8 с разными адресами. при подключении поочереди оба стабильно работают, при одновременном подключении и опросе через конфигуратор начинают проскакивать ошибки. увеличил скорость с 9600 до 11500 протокол Rtu, скорость увеличилась, но процент ошибок не изменился. Аналогично при опросе с ПЛК

Какие адреса у модулей?
Попробуйте сделать адреса кратные 8.

Foxer
01.06.2010, 10:24
менять время ожидания пробовал, результат не удовлетворил. терминирование думаю тоже ничего не даст длина шины 1,5 метра.
а с адресами попробую стояли адреса 11,12.

Ельцов Андрей
01.06.2010, 10:32
поставьте адеса 0, 8 и т.п.