задержка ответа по сети Rs-485

[light_finder]

Господа, доброго времени суток.

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

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

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

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

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

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

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

[Филоненко Владислав]

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

[light_finder]

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

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

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

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

[Николаев Андрей]

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

[light_finder]

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

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

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

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

[Дмитрий Егоренков]

> что же мне все-таки делать

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

[Кирилл Валюнин]

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

[light_finder]

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

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

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

[light_finder]

> что же мне все-таки делать

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

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

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

[Дмитрий Егоренков]

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

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