WEINTEK MT8102E и функция 02h (ModBUS)

[Jackson]

но это предполагает упаковку на стороне ПЛК, что по условиям - нежелательно

Технически не реализуемо, если быть точным.

[Madwolf]

Прочитайте выше. Есть обращение к биту. Есть обращение к группе битов.
Так же есть обращение к слову, но это предполагает упаковку на стороне ПЛК, что по условиям - нежелательно.

По логике не должно быть упаковки: запрашиваем слово (в моем случае это 16 бит), получаем в ответ слово - 16 бит.

Иван Николаевич выше правильно написал. Функция чисто для удобства. И о 115200 мы порой только мечтаем, колбасимся на 9600 или 19200))))

[Jackson]

И о 115200 мы порой только мечтаем, колбасимся на 9600 или 19200))))

коллеги, ну я-то на Ethernet’е шикую, 100 мегабит на ModBUS-TCP.

Кстати, мы принудительно убрали RS-485 ModBus из складской конфигурации контроллеров, заменив его на Ethernet с ModBus-TCP и Web-сервером. Объемы данных растут, задачи усложняются, клиентам 19200 уже нехватает (но если очень надо - это доп.опция теперь). Иначе так все и будем мучиться на низких скоростях, когда давно уже есть высокие.

[Никита]

Прочитайте выше. Есть обращение к биту. Есть обращение к группе битов.

Нету. Фактически это обращение к слову. И Евгений обращает внимание специально, что биты не упакованы. Т.е. с точки зрения физики каждый бит (coil, contact) - все равно 16 разрядов. Из которых, чаще всего, интересен младший. И адресация меряется именно в них.
И в памяти устройства они, скорее всего, расположены так же. Прямая работа с отдельными битами в регистрах была, вроде как, только в наборе инструкций знаменитого Z80. Потом про нее почти все забыли, пользуются масками.
Так вот, речь о том, что по запросу группы битов в ответ должна прилететь опять же группа 16-разрядных слов, каждое отвечает за свой бит. Одной посылкой, с общими адресом, функцией и контрольной суммой.

Отправлено спустя 3 минуты 9 секунд:

Кстати, мы принудительно убрали RS-485 ModBus из складской конфигурации контроллеров, заменив его на Ethernet с ModBus-TCP и Web-сервером. Объемы данных растут, задачи усложняются, клиентам 19200 уже нехватает (но если очень надо - это доп.опция теперь). Иначе так все и будем мучиться на низких скоростях, когда давно уже есть высокие.

Следующим шагом будете медиаконвертер на оптику делать против Ethernet. Масса недостатков у 485, но допустимая длина линка все же на порядок больше. Ибо единожды попробовав, клиент на 485 уже не вернется, а дальность потребует.

[keysansa]

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

В х86 остались, bt, btr, bts. 64 битный асм не изучал, не было необходимости.

Нету. Фактически это обращение к слову.

Я имел ввиду, что теоретически, при возможности упаковки внутри контроллера можно было бы использовать не 0х2, а 0х3 или 0х4

[Никита]

В х86 остались, bt, btr, bts. 64 битный асм не изучал, не было необходимости.

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

Я имел ввиду, что теоретически, при возможности упаковки внутри контроллера можно было бы использовать не 0х2, а 0х3 или 0х4

Теоретически можно. Но увы, практически невозможно, (практически нереализуемо) потому топик и появился.

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

[petr2off]

Выбросить то может быть и быстрее, но у меня был трабл, при работе с частотником Л-Старт. Читал одним запросом несколько регистров, а в средине оказалась дырка старая документация была), и полезли дикие задержки. Пришлось разбивать на 2 пакета, до дырки и после нее. Не факт, что это всегда будет. От среды наверно тоже зависит. Но я теперь 3 раза подумаю, прежде чем скопом читать последовательность регистров.

[Jackson]

Нету. Фактически это обращение к слову. И Евгений обращает внимание специально, что биты не упакованы. Т.е. с точки зрения физики каждый бит (coil, contact) - все равно 16 разрядов. Из которых, чаще всего, интересен младший. И адресация меряется именно в них.

Не совсем так. Это внутри памяти панели она оперирует со словами, а запрашивает-то биты (иначе была бы функция 03х или 04х). Панель внутри себя оперирует словами и достаёт из них биты по необходимости. Сделано, вероятно, для экономии процессорных ресурсов. И есть возможность запросить реально один бит: при использовании функции 1x_bit улетит запрос на один бит, а что с ним будет делать панель - наверное опять в слово засунет. В общем, это недокументированная "фича" создателей панели (я - художник, я так вижу). Это и отличает серьёзную технику от не очень серьёзной - в серьёзной технике на такое не нарвёшься, в ней что написано - так и работает.

Следующим шагом будете медиаконвертер на оптику делать против Ethernet.

Зачем? Есть готовые свичи с оптикой на борту.
И кстати для CAN мы оптику уже применяли, когда надо было на 4 км пробросить - без конвертации в Ethernet, есть прямые оптоконверторы.

Прогресс не стоит на месте.

Масса недостатков у 485, но допустимая длина линка все же на порядок больше.

Ну, не на порядок всё-таки, а в 2 раза при приемлемой скорости. И то скорость не очень приемлема для ряда задач. Для моего случая 485й совершенно не справится с таким объёмом данных. Справится, но при его скорости это не годится - период обновления будет большой. Это не СКАДА, а рабочий инструмент местного поста.

В х86 остались, bt, btr, bts. 64 битный асм не изучал, не было необходимости.

В панели, насколько я знаю, Андроид. Едва ли он умеет работать с битами напрямую.

Я имел ввиду, что теоретически, при возможности упаковки внутри контроллера можно было бы использовать не 0х2, а 0х3 или 0х4

Нет такой возможности, практически.

Для примера - у Инсата в OPC-сервере есть возможность настроить максимальную длину цепочки регистров для вычитывания одной командой.

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

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

Да, очевидно, но неоднозначно. Зависит от интерфейса и возможностей слейва (насколько быстро он отвечает на запросы).

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

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

Кстати вот, закончил проект одной из установок, смотрите скриншоты всех экранов. Это простая установка, опрашивается только три устройства. Здесь всё более-менее. А веселье началось на другой аналогичной установке, где устройств не три а семь. Можете оценить загрузку панели. Битовые индикаторы - примерно на 70% связаны с битами, выдёргиваемыми из слов, и 30% из битов, читаемых непосредственно. Плюс целочисленные двух- и четырёхбайтные слова.

[Madwolf]

Почитал про BT, BTC, BTS и BTR, поддерживаются начиная с 80386. Т.е. в моем примере нет. Думаю, что нормальный компилятор будет пользоваться этой командой для отправки бита.

[Никита]

Не совсем так. Это внутри памяти панели она оперирует со словами, а запрашивает-то биты (иначе была бы функция 03х или 04х).

Предлагаю уточнить, что все-таки отправляет контроллер. если запросить два бита подряд - получим одно слово с двумя битами или два слова с одним битом?
Смутили гугл и http://www.simplymodbus.ca вот таким примером:

Код: Выделить всё

Request
This command is requesting the ON/OFF status of discrete inputs # 10197 to 10218
from the slave device with address 17.

11 02 00C4 0016 BAA9

11: The Slave Address (11 hex = address17 )
02: The Function Code 2 (read Input Status)
00C4: The Data Address of the first input to read.
             ( 00C4 hex = 196 , + 10001 offset = input #10197 )
0016: The total number of coils requested. (16 hex = 22,  inputs 197 to 218 )
BAA9: The CRC (cyclic redundancy check) for error checking.

Response

11 02 03 ACDB35 2018

11: The Slave Address (11 hex = address17 )
02: The Function Code 2 (read Input Status)
03: The number of data bytes to follow (22 Inputs / 8 bits per byte = 3 bytes)
AC: Discrete Inputs 10204 -10197 (1010 1100)
DB: Discrete Inputs 10212 - 10205 (1101 1011)
35: 2 space holders & Discrete Inputs 10218 - 10213 (0011 0101)
2018: The CRC (cyclic redundancy check).

Летит в любом случае слово - один бит в регистр микросхемы UART в принципе нельзя положить.
Что касается панели - это нормальное явление. В любом языке программирования под булевы переменные отводится не меньше байта. Как только бит превращается в переменную - занимает машинное слово. Исключение я упоминал - Z80, но во-первых это требует специального программирования, а во-вторых, про работе с языками высокого уровня в дело вступает компилятор, а то и Java-машина, которые этим не заморачиваются.

И кстати для CAN мы оптику уже применяли, когда надо было на 4 км пробросить - без конвертации в Ethernet, есть прямые оптоконверторы.

Как говорил один известный подпольный миллионер: "это гусарство". Очень удобно иметь пару тёмных волокон и задействовать их под свои нужды на уровне физики, не задумываясь о маршрутах и джиттере. Но практика показывает, что в условиях предприятия волокна кончаются очень быстро и начинается уплотнение. Сначала все заталкивается в TCP/IP (с соответствующими плясками с QoS, VLAN и маршрутами), потом начинается обработка самой оптики на уровне WDM/DWDM/CWDM... Этого пока хватает, дальше посмотрим.
И еще - при наличии IP-инфраструктуры и необходимости менять точки подключения IP предпочтительнее. Все прямое преобразование в физику не пролезает через активное сетевое оборудование и требует физической оптики от точки до точки.А с IP немного попроще.

Да, очевидно, но неоднозначно. Зависит от интерфейса и возможностей слейва (насколько быстро он отвечает на запросы).

В модбасе время ответа нормировано. Тут есть возможность прикинуть по худшему варианту.

В панели, насколько я знаю, Андроид. Едва ли он умеет работать с битами напрямую.

Почитал про BT, BTC, BTS и BTR, поддерживаются начиная с 80386. Т.е. в моем примере нет. Думаю, что нормальный компилятор будет пользоваться этой командой для отправки бита.

В панели либо линух либо кастрированная винда. От конкретной модели зависит. И вряд-ли EasyBuilder компилирует проекты до уровня машинного кода. Про андроид, который работает через Java - вообще молчу. И да, смысла нет особого - не те времена, чтобы память байтами мерять. А по скорости одинаково, если не быстрее проверить слово на равенство нулю, чем вытаскивать бит. И так, ради флуда - в 386 команды то есть, но в Pentium появились MMX и схема предсказания переходов, вряд ли при разработке MMX учитывали, что кому-то понадобится работать с битами....

[Jackson]

Не согласен только насчёт оптики.

[+] опять же, к вопросу это не относится

Разные системы есть на производствах. И в моем случае это система электроэнергетики, от которой зависит всё производство. Один сбой в ней - и всё производство в лучшем случае встало, в худшем - взорвалось к едрене фене (видеозаписей таких взрывов полно на Youtube). Поэтому, разговоры про уплотнение у нас очень быстро заканчиваются после нескольких фраз: "Наша система так работать не будет, мы не будем этого делать потому что мы не можем брать большие деньги за неработающие системы. Наша деятельность - это поставка работающих систем, а не разбирательства по поводу неработающих. Если Вы считаете что знаете об этом больше чем мы - зачем тогда мы Вам? Берите оборудование, делайте как считаете нужным и сами несите за это ответственность. Наша ответственность заканчивается на наших зажимах клеммников - это написано в нашей документации, Вы её читали. Нам дорого наше имя, репутация и жизни людей, напрямую зависящих от наших систем, и мы сделаем всё для того чтобы их сохранить, вплоть до отказа в поставках. Покупайте прямо у производителя или у конкурентов и туда же обращайтесь за поддержкой - мы желаем Вам найти действительно работающее решение." И как бы пафосно это ни звучало - это правда, уж какая есть. Добро пожаловать на мировой рынок.

[Madwolf]

Ну как бы то ни было, выгодней выполнить один запрос на 16 бит, чем 16 по одному биту каждый?

[Никита]

Не согласен только насчёт оптики.

Увы, такова действительность. Есть проблема отсутствия темной оптики. И есть объекты которые ее требуют. Все от объекта зависит. В большой энергетике все еще интереснее. Так телемеханика спокойно работает по арендованным IP-каналам. А есть еще устройства передачи аварийных команд и сигналов (начиная от различных разгрузок и заканчивая УРОВ). Там время критично. Но и десятки-сотни километров оптики по двум разнесенным трассам проложить не всегда возможно. Резервирование обязательно. Так что и решения бывают самые разные, в зависимости от местных возможностей. Основной канал чаще всего ВЧ, а вот с резервом на линиях до 220кВ, на которых оптика не предусмотрена в объеме строительства, приходится изобретать.

[Jackson]

В большой энергетике все еще интереснее.

Понятно. Но мы туда не выходим, маленькая у нас энергетика. :) Все наши цепи - внутри одного объекта, как правило.