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

[light_finder]

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

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

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

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

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

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

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

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