ModBus Чтение всех каналов за одну команду

TRACE MODE 5 и 6. Встроенная прямая поддержка Modbus/RTU и /TCP с формированием групповых запросов.

Переводите на CAN, тогда запросы вообще не нужны, приборы сами будут пересылать результаты (если смогут)

Насчёт дружного игнорирования не соглашусь.

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

Это широко распространённая практика. Поддержка прибором любого протокола обмена (в т.ч. модбаса) как раз и реализуется для того, чтобы в тч и на "верхнем уровне" (Ваш случай) можно было организовать обмен данными. Для возможности общения с прибором на верхнем уровне как раз и требуется драйвер, который возмёт на себя реализацию обмена как на физическом уровне (например, обмен через ком-порт), так и публикацию данных с контроллера (например, в виде OPC-тегов).

Для прибора, поддерживающего широко распространённый протокол обмена (тот же модбас) можно брать драйвера  сторонних разработчиков. Но нередко производители выпускают оригинальные драйвера для своих приборов. И это вполне рационально.

На конкретном примере.

Работал на предприятии, выпускающем контроллерное оборудование.  В контроллер закладывалась поддержка модбаса. И до появления специализированного драйвера инжринговые фирмы без проблем подключали приборы к своим скада с помощью модбас ОРС-серверов сторонних производителей. Но были некоторые неудобства. Например, прибор измеряет виброскорость 0-25 мм/мек или виброускорение +-2.5 мм/сек. Эти величина... не дискретная. Но в контроллере достаточно трудно было реализовать операции для чисел с плавающей запятой. Поэтому сделали так: в регистры с текущими значениями писались целые числа, а в другой регистр - тип измеряемой величины.

Алгоритм опроса контроллера (по модбасу) в этом случае был такой:

1) считывался регистр, хранящий тип измеряемой величины (типа 0 - вибросокрость, 1- виброперемещение). В зависимости от этого выставлялся коэффициет пересчёта значений с регистров текущих значений параметров. Например, для вибросокрости коэфиициент был 0.1, для виброускорения - 0.01.

2) считываются значения из регистров текущих значений параметров. Реальное значение с канала получается путём умножения этих значений на коэффициент.

Естественно, что эти действия без проблем можно выполнить в скада (что и делалось на протяжении 10-ти лет). Но написал драйвер (ОРС-сервер), в котором одна из групп как раз отвечает за текущие значения с каналов. Теперь для получения реального значения с канала из ОРС-клиента достаточно считать значение из сооветствующего тега (например, ArgusM1.ChannelValues.Channel1 - значение с первого канала). И всё. При этом программист скада может и не знать, что данные в орс-сервер идут по модбас протоколу.

Сейчас работаю со шнайдёровскими контроллерми. Ситуация абсолютно такая же. Контролеры поддерживают модбас. Но для каждого контроллера назначение регистров несколько различаются (Sepam 20, 40 и 80). Я считываю драйвером модбасовским большой пакет данных. А потом в зависимости от типа контроллера разбираю этот блок данных (по-сути, разбор реализован в виде отдельных драйверов для каждого типа контроллера).

Таким образом, нередко работа с контроллерами, поддерживающих широко распространённые протоколы обмена сводится к

1) получению данных по этому самому протоколу

2) разбор данных, пересчёт.

Пункт воторой можно реализовать и в скада (что вы и пытаетсь сделать).

Или совместить получение данных и их некоторую их обработку в одной программе (драйвере). Что многи е производители и делают.

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

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

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