ModBus и другие сетевые протоколы

[Danial]

Уважаемые разработчики, поправьте меня, дилетанта, если я где-то не прав. Но…
На сколько я знаю, помимо ModBus’a существуют и другие сетевые протоколы. Например, «BacNet», с которым мне приходилось работать на  Siemens’овых контроллерах. Ещё я слышал об Grundfos’овском протоколе «GENIbus» и широко распространенном в Европе протоколе «Profibus» (но сам я с ними толком не работал).
Связь со сторонним устройством, для каждого из этих протоколов, осуществляется через какой-то физический (аппаратный) интерфейс.
И если есть устройство, которое обрабатывает внешние запросы по протоколу ModBus и имеет выход на интерфейс RS-485,  то это устройство может «общаться» с контроллерами Zentec.
Я понимаю, что у контроллера Zentec нет физических выходов на другие интерфейсы, такие, как например RS-232, LonTalk, Ethernet, а потому, стороннее устройство, общающееся по протоколу «ModBus RS-232», например, контроллер Zentec опросить не сможет просто физически.

Но «Сетевой Протокол», на сколько я понимаю, это штука программная.
И если есть устройство, которое общается по протоколу Profibus с выходом на интерфейс RS-485, то контроллер Zentec в теории мог бы его опрашивать, при условии, что запрос будет составлен в соответствии с протоколом Profibus, а не ModBus.
С «GENIbus» аналогичная история. Этот протокол использует интерфейс RS-485, но контроллер Zentec его всё равно ‘не поймёт’ (потому как GENIbus ≠ ModBus).

Словом, может вы могли бы разработать программные блоки, которые перенастраивали бы порт СОМ1 на общение по другому (отличному от ModBus) протоколу ?
P.S. Идея позаимствована у свободно-программируемых тач-пультов Weintek и Samkoon (см. скриншот в приложении). Правда у этих пультов много выходов на самые разные интерфейсы (и работают они, по всей видимости, с самыми разными протоколами), но даже для одного интерфейса (RS-485) существует множество протоколов.

[mike]

Программная реализация того или иного протокола штука кропотливая и не всегда нужная. Мало того, не каждый протокол может быть реализован на "малом" микропроцессоре. Например, тот же Бакнет.

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

С другой стороны, некоторые модификации панелей Z036, серверов Z450 имеют встроенные протоколы Modbus RTU и TCP

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

[serge197a]

А вообще, у вас достаточно сильно в голове все перемешалось с этими протоколами, а Mike слишком корректно Вам это объяснил.
1. есть преобразователи интерфейсов и для разовой задачи это достаточно или купите совместимое оборудование.
дешево- и мультифункционально не бывает(ни у кого. за все нужно платить)
2. как правильно сказано Mike, эти протоколы реализованы на своем железе,
в частности с профибас, еще лицензию платить сименсу нужно. Этот протокол закрыт.
ну и т.д.

[serov]

Добавлю от себя. Мало того что фирменные протоколы закрыты и требуют лицензии, так они могут потребовать соответствующей аппаратной реализации. А, например LonWorks, если не ошибаюсь, вообще можно реализовать только через специализированные микросхемы, в стоимость которых заложена лицензия. Очень интересная штука ProfiBus, там есть вариации когда используется физический уровень Ethernet, но вот в локалку не заведешь, програмно это совсем другой протокол, нежели TCP.

[serov]

А ещё добавлю, что тестировать связь по ModBus гораздо проще, сегодня огромное количество отладочных средств - программ и пр... А вот отлаживать тот же ProfiBus несколько геморойно.

[Danial]

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

А ведь знаете, если бы транслятор позволяли бы писать макросы на языках типа ST (или хоть assembler), и была бы возможность формировать пакет сообщения для порта СОМ1, то я уверен, что нашлись бы народные умельцы, которые организовали бы макросы для общения на других протоколах (по интерфейсу RS-485) и выложили бы эти решения на форуме.
С одной стороны - и вам не пришлось бы это разрабатывать, с другой - не пришлось бы за это отвечать, потому как сторонние решения используются на свой страх и риск (как и в случае со сторонними программами).
И интерес к такому железу, я думаю, был бы больше 

[mike]

с ST экспериментируем. Не уверен, что из него можно будет напрямую обращаться в порт.