Возможно ли создать конфигурацию в которой сеть из PLC под qnx связывается с верхним уровнем через открытые протоколы: Modbus RTU/TCP и т.д ?

Добрый день !

Т.е. вы хотите, что бы сетка PLC "притворилась" Modbus устройством ?

Нет, такого нет.

Для связи сетки PLC по стандартному протоколу с верхним уровнем служит автоконфигурирующийся OPC сервер. Он сам обнаруживает PLC в сети и импортирует из них теги.

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

Было бы не плохо, если бы qnx_PLC, по мимо того, что он может общаться с верхом по OPC, отдавал бы данные как slave-устройство по различным открытым протоколам: Modbus, DNP3 и т.д.

Идея понятна. Но давайте ее рассмотрим на примере Modbus. Когда у нас есть какой-то девайс, например ОВЕН, с фиксированным набором регистров, и есть к этому девайсу драйвер на верхнем уровне - все понятно.

Но когда внизу много девайсов (контроллеров), каждый - с произвольной структурой, то и драйвер вверху должен быть супер конфигурируемый.

Иными словами, из-за этого особенного драйвера , преимущества открытого протокола потеряются. ИМНО.

Дык этот вопрос, я имею ввиду куча контроллеров в низу с разношерстными протоколами, решается организационно. Мух в одну сетку, котлеты в другую и будет счастье. Конечно можно засунуть ОВНы и Modbus RTU в одну сетку, только стоит ли?
Так собственно сабж. Есть в планах нафаршировать qnx_plc различными протоколами в слейвовом и мастерном вариантах ?

Добрый день !

В качестве мастера - безусловно планируется. Это сейчас и делается.

Что касается слейвов, то , опять таки, не до конца ясна выгода от такого решения. Чем это будет лучше OPC ?

Мне более актуальным представляется взаимодействие QNX PLC по полевым протоколам не с верхним уровнем, а с сетками "железных" ПЛК других производителей, что бы можно интегрировать дешевое и надежное железо, которое сейчас в избытке с существующими системами.

Т.е. в качестве горизонтальных связей.