razrab83

Так ведь и речь о том, что на ПК сделать честный RTU нельзя. ну наконец то... всё! Расходимся ;)

ну вы и описываете что-то доморощенное. Это холивар двух подходов к модбас. Очень часто новички не анализируют паузы. кадру выделяют на "лету", т.е. сначало что-то там анализируют, потом сверяют CRC. Встречал даже так... Принял первый байт - это адрес. Адрес не мой - значит это не мне. Далее делает разбор пакета и даже не считает CRC. Зачем его считать, если пакет не мне? А то, что в адресе может быть ошибка и адрес нельзя анализировать до приема всего пакета и проверки CRC - об это не думают. я приверженец того, что выделить пакет паузами, потом проверить CRC, и только потом проверять адрес и функцию и данные.

вы не сможете указать в хар-ках девайса: поддерживается протокол Modbus. Вы должны будете описать физику шины (RS232/485/ttl3.3), битрейт, старт/стоп. описать как менять битрейт, если есть ограничение на 19200 - то и их указать... а теперь самое вкусное))) - вы должны описать все регистры и поддерживаемые функции из протокола, а также если есть пользовательские функции (а модбас это допускает) - будьте любезны и их. например у девайса состояние системы из 50 параметров. я в своем самописном протоколе опишу структуру и пакет с фиксированым заголовком в 3 байта и далее структура. вы в готовом модбасе укажите, что использовать модбас, а потом всё состояние из 50 параметров раскидаете на регистры. надо передать флоат в 4-х байтах, у вас это будет два регистра, мл часть флоата в регистре 0х1000, старшая в 0х1001. и так про каждый параметр. а если нужно текст передать переменной длинны, то это тот ещё гемор в модбас. в моём протоколе придуманным за 5 минут состояние передать или текст... - не вопрос. Сделать описание передачи текста - бумажной работы меньше, чем в вашем готовом модбас. сколько раз уже покупались устройства с модбасом, но в опсании или отсутствовала карта регистров, либо криво описана.

ну анализировать первый попавшийся байт - это тоже не торт. приняли вы первый байт - тут должен быть адрес. Если пакет без ошибки - то это адрес. Приняли второй. Если пакет без ошибки - то это функция... но вот только есть там ошибка или нет, вы поймете только после расчета CRC (не берём во внимание паузы в 1.5). Как так? вы уже анализируете пакет не проверив его целостность. Вам отправили 200 байт одним пакетом. вы приняли второй байт с ошибкой и ошибочно определили длину пакета допустим в 7 байт. у вас crc не совпало. игнорим. приняли 8-ой и 9-ый байт - для вас это новый адрес и функция. Но это ещё первый пакет. вы запускате новый вычисление нового пакета - упс, там тоже crc не совпал. В счетчике пакетов девайс отметит "Получил 10 пакетов, из них 10 с ошибкой". А на самом деле был один пакет и он с ошибкой. как можно анализировать пакет, если ты не знаешь про его целостность? нет, не ошибаюсь. в даyном случае в тендере на оборудование не было ни каких требований к стандарту протокола. Да и этого протокола как такого не было... он родился спонтанно... просто решили сделать межплатный обмен на Modbus. Было требование, допустим, измерять влажность и включать насос. Было бы это один МК или Два... шкаф или ящик... внутри CAN или RS485. сколько плат и как они сопрягаются - вообще таких требований не стояло. Делай хоть на ПЛИС, хоть на МК, хоть на MOXA, хоть на паровом двигателе... Главное чтобы обеспечить внешние измерения, внешние воздействие и индикацию. А как ты там обеспечил межплатный обмен - это ни кого не интересует.

.... делали систему... одной комнадой... сосед по парте пошел на встречу... т.е. внутри команды договорились убрать 1.5. Вышли на рынок с этим устройством. В мануале "Провод А подключить в проводу В" внутри шкафа. Ни каких modbus, ни каких rs485, ни каких сторонних девайсов и боже упаси ни каких ОРС в помине нет (даже на горизонте). Юзеру не нужно и он не должен знать, какой внутри протокол. Конкурент пусть хоть затестирует наш протокол. Замкнутрая система - работает, заявленые требования выполняет. А что там в кишках - ни кого не волнует. Но вот если внутри системы воткнуть санкционку устройство, которое разработала не наша кантора, и даже не в рф, а в германии/сша... и там честный модбас... и его воткнуть внутри в наш шкаф (на этапе разработки системы) - то работать система не будет. Наша система продавалась на рынке как единое целое. не допускает подклчения внешних девайсов. Естественно, если выпускать систему с расчетом расширения внешними чужими девайсами, то о ни каких договорах с колегой речи быть не может, должен быть честный модбас.

ни когда не понимал, зачем писать MS Word, когда есть OpenOffice? Зачем писать дельта-дизайн, когда есть альтиум и eagle? Зачем писать ВК, когда есть фэйсбук? Зачем писать воцап, когда есть вайбер? На такую фигню жизни жалко. )) Делали своё железо, по него делали свою скаду, со своим блекджетом и девушками. Продовалось и железо и скада. Что в этом плохово?

оно не то что стоит на последнем месте, оно не стоит не на каком месте, от слова совсем. Сколько за карьеру было сделано мной систем... в скольких учавствовал... и скаду свою писали, и кучу АСКУЭ всяких делали... свои эл.счетчики, водосчетчики... И Modbus был, и МЭК-104, и куча Проприетарных протоколов. И даже был сторонний датчик ветра, на который не было описание протокола - сами его реинженерили. Сколько автоматики для себя наделал.... ОРС даже на горизонте не было. на мои протоколы документация более внятная, чем на Modbus. Протокол пишется с описания. Через 1-2 мес я уже сам его забуду. Даже так - вышел из офиса и забыл свой же протокол. Зачем помнить константы. Единственное что помню - описание лежит там и называется так. После хорошего описания и сам ошибок не наделаешь и тот, кто будет сопрягаться мне ни одного вопроса не задаст, не будет отвлекать. ps был случай.... купили датчик ветра. по RS232 его можно читать. Описания протокола нет. Звоним на завод изготовитель: -А можно описание протокола? -А его нет. -А как ваша программа на ПК с ним работает? -А её написал один инженер и уволился. исходников нет. описания протокола нет.

не бывает разного реалтайма. 3.5 и 1.5 символов определены в стандарте. их надо выдержать. чтоб их выдеражать, нужно точно знать сколько времени у вас буде реакция на воздействие. мк может обеспечить точное поведение, т.к. обеспечить реалтайм. МК может обеспечить 3,5 и 1,5. ОС, допустим винда не может. что касается ожидание ответа, то модбас его не рагламентирует. При создании системы пишутся требования: "битрейт 115200, старт, 8бит, ДВА стопа. адреса то такие. Ожидание ответа не более 1000 мс.". Винда должна обеспечить выдачу пакета без пауз, а ожидать ответ будет 1 сек. ожидать она 1 сек сможет, а выдать команды без пауз не всегда. Опять же.... я же писал.... т.е. пусть это будет поливалка теплицы. Винда отпрашивает датчик влажности грунта. Винда сама опрашивает по модбас через usb/rs485. Отправила запрос... ушел запрос с дыркой в 4 байта. Датчик грунта не ответил. Система нереалтаймовая не работает. а теперь, в этой нереалтаймовой системе выносим преобразование usb в rs-485 во внешний преобразователь на контроллере stm32. Нереалтаймовая Винда по usb отправила булк, МК принял. Мк формирует запрос датчику. Нереалтаймовая винда ждет ответа. Мк выдает через DMA в rs запрос. байты идут строго друг за другом. без пауз. Датчик грунта принял пакет и запустил измерение. Там сложный датчик, состоящий из кучи устройств и медленный.... в течении 800 мс делается изсерение и отправляется ответ. Ответ без пауз. Преобразователь на МК получает ответ, при этом контролируя 1.5 и 3.5. Получив пересылает его по USB в ПК. Через 805 мс после запроса ПК получил ответ. В зависимости от состояния грунта измерение проводиться от 500 до 900 мс. Поэтому требование в 1000 мс - обоснованное. Далее... надо включить полив.... всё тоже самое... нереалтаймовый ПК передает в преобразователь команду на включение поливалки. и преобразователь в модбус команду на насос - пошел полив. Допустим, нереалтаймовый ПК дал команду в USB на полив, и ушел на свопинг.... или на индексацию FS. Команда застряла на 1-2 с недрах ОС и в конце концов попала в преобразователь. И что? Вся система рухнет? Помидоры завянут? Нет! Преобразователь с задержкой в 1-2 сек получит команду на полив, выдаст "правильно" эту команду в модбас и насос начнет полив. Но если в вашей нереалтаймовой системе преобразователь модбас не реалтайм, и ваш usb свисток не сможет обеспечить выдачу непрерывно без пауз пакета, то насос получит команду с паузой и не выполнит её. Помидоры завянут.

не нужна. если у вас вся система "ПК+железо" есть не раелтайм, но есть модбас - то ОС с реалтаймом не нужен. Допустим вы сделаете свой преобразователь rs485/usb. или rs485/tcp на stm32f107. с одной стороны 485/modbus. мк обеспечивает 3.5 и 1.5 паузы. получил 20 байт - пауза в 3.5 - отправил по тср в ПК пакет добавив 6 байт заголовка. хоть на ОРС отправляй. Нужно ПК дать запрос - отправил по ТСП/USB в преобразователь запрос, МК сам его выдаст в rs485 со всеми тайменгами. Задаем требование системы "Ответ от слейва не более 1 сек". На любом битрейте ваш преобразователь будет работать, вне зависимости от ОС и реалтайма на ОС.

"известна заранее" != "есть длинна пакета". Вопрос не в том, как определить длинну пакета, вопрос в том, что в модбас нет длинны пакета. Длинну пакета конечно же определить можно. Она в каждом пакете своя и нужно уже на уровне парсинга данных вычислять данных. С длинной гораздо проще парсить. Длинна пакета известна до парсингаданных. получил пакет взял первые 3 байта из потока/массива - сразу понятна длинна пакета. ещё не заглядывая в данные - уже понимаешь сколько байт данных. из этих заголовок + данные можно сразу сделать класс/структуру и засунуть его в очередь, БД, мессадж, контейнр. Не разбирая и не сами данные уже можно разбить входной поток/массив на поток пакетов аля std::list<MyPack> list; А потом перебирай этот лист и обрабатывай каждый пакет. ps посмотрите Modbus TCP - обязательный заголовок 6 байт в котором есть длинна пакета. Длинна каждого пакета, в том числе которые фиксированные и не меняются. при чем здесь OPC? А ваш распрекрасный стандарт можно будет подключить к танку Армата? Можно будет купить готовый боинг, чтобы включить "железку" с этим протоколом с Modbus в работающую систему самолёт? Понимаете - нет задачи включиться в ОРС. Нет задачи, стыковаться с др системами, о чем ТС говорил.

где оно в запросе? где оно в пакетах с кодом ошибок? то, что там длинна какая-то в частных пакетах внутри данных - это не длинна пакета. Эта ваша длинна - это данные. У вас когда уарт примет 100 пакетов. Потом парсер начнет распарсивать - парсер должен должен прежде всего выделить целый пакет абстрагируясь от данных, потом, в зависимости от функции передать данные в парсер конкретного пакета. Если я в свой протокол добавлю длину пакета (или пусть длину данных) - модбаса не получиться. запос: 04 - адреc МК (получателя) 01 - адрес отправителя (ПК) 03 - функция, чтение смещения 0 - длина данных 12 34 - CRC ответ 01 - адрес ПК 04 - адрес отправителя 03 - функция, чтение смещения 4 - длинна поля данных 0x12345678 - тут в float смещение инструмента в метрах 12 34 - crc если можно ещё и адрес отправителя, это если много девайсов, но и без него не хуже. Зелёным - обязательный заголовок пакета. из 3-х(4-х) байт. Далее... поле данных - не регистры, а данные. Нужно смещение - получи смещение. Надо температуру - получи температуру. Надо в одном пакете 50 данных в разных форматах (float/int/float/MyStruct) - упакуй и передай. Вплоть до того что можно запросить у слейва текст. в пакете вернёт массив char. Если есть потребность в пакетах больших 256 байт, поле длинны данных 2 байта - передавай одним пакетом до 65 кб.

нет

в Modbus нет поля длинны блока данных.

есть шкаф, в котором с десяток устройств объедены шиной RS-485. Для обмена используется протокол Modbus. Девайсы Промышленные девайсы в шкафу с "честным" Modbus. Контролируется 3.5 и 1.5. Все девайсы - это слейвы. Подрубили промышленную ЭВМ к этой шине как мастера. битрейт 921600. по этой шине идет непрерывный контроль со стороны мастера. Пакеты не очень длинные, но и не короткие. Обмен непрерывный. Периодически рвется связь. мастер теряет ответы от слейва и принимает решение, что слейв рипнулся и делает соответствующие действия. Если снизить битрейт до 9600 - то обмен стабильный, но время опроса всей системы сильно увеличивалось и не удовлетворяло требованиям. Стали разбираться..... мастер при запросе, в пакете часто делал дырки более 1.5 символов. А иногда и более 3.5 символов. Прогеров мастера носом ткнули в осциллограммы шины 485. Прогеры стали кумекать.... на эвм был linux. они что то там намудрили... что-то в область realtime... стало лучше... дырок в 3.5 нет, а вот в 2 символа появлялись. редко, но появлялись. Долго они с этим боролись - и сдались. Нешмагла я, нешмагла. В итоге разрабов слейвов заставили убрать контроль 1.5. Перешли на нечестный Modbus. Далее.... пожелали написать анализатор/снифер. Подрубился ноутом через usb-rs485 к шине - и в окошках весь обмен... кто, кому, когда, какие данные шлёт и по возможности визуализировать данные. Т.е. ПК выступал как слейв, который просто подслушивает. Так вот ПК не смог разделить пакеты. Делалось это через VCP. На ПК прога спрашивает "есть в порту непрочитанные данные?", далее "прочитать все данные". Вычитывает много байт... допустим 1500. Что это? где там пакеты? как их поделить? В массиве байт искались пакеты программно. В лог падали пакеты... несколько штук подряд у которых время приема было одинакового, т.е. время вызова функции read(); ps переходник usb-rs485 использовался MOXA, о котором недавно тут упоминали. Я это всё к тому, что тащить Modbus в ПК - это геморрой. Если Modbus тащится для того, чтобы "быть как все", т.е. что-бы в будущем было сопряжение с другими, то нужно его делать честным. Если он не честный, то могут быть проблемы с сопряжение др. устройств. Если др. устройства разрабатывает сосед по офису, то он может "вам пойти на встречу". А если это какая нить санкционочка - то ..... Modbus хорош для обмена между МК, но тащить его в ПК, даже в промышленный - это геммор. Даже на апаратном rs485 - это тоже гемор. Вполне вероятно. С большей вероятностью для наладки все будет работать. с маленьким битрейтом ваш ПК отправит запрос - минуту 10 мс будет ждать ответ, а не дождется то повторит запрос. Даже если в запросе/ответе были дырки и слейв не ответил. Ваш пк раз 50 повторит запрос, пользователь даже не заметит, что там что-то пошло не так. Прочитать и записать несколько регистров - почему бы нет. Я бы объединил две платы через UART. И объединил бы у uarta Rxd и TxD и соеденил бы одной линией (аля 1-Wire). Пк через USB. программный проброс команд с USB в 1-Wire. Протокол и на usb и на 1-Wire свой. Даже если подключаться к ПК через uart, то тоже все 3 девайса соединить одной 1-Wire. Какие проблемы? Ни каких колец не нужно Если всё же RS, то ни как не 422, а 485. Чем плох 485? Протокол - свой. Даже если за основу Modbus, то нечестный. Да и зачем вам модбас? Зачем вам какой-то готовый freeПротокол? Свой протокол пишется быстрее, чем я этот пост. 0-ой байт - адрес, 1-ый байт команда, 3....n байт данные, CRC, ВСЁ!!! Ну можно докинуть ещё один байт длинны. И чтоб было совсем приятно парсить массив с 10-ю пакетами, добавьте в начало пакета 2 байта синхрослова.

ТС же пишет, что в eps32 нет usb, а есть USB Serial. Т.е. это урезанный usb, до usb-device cdc. ни каких хостов там нет. и писать там usb стек не придется. да даже если взять стм32ф103 CPU - на котором есть "полноценный" usb. Как этим одним усб подключиться одновременно к пк и к другому cpu?

зрачком чиркнул даташит - Full-speed USB Serial/JTAG controller. везде USB/JTAG. Я правильно понимаю, что усб используется в eps как встроенный отладчик и ему не требуется внешних st-link/j-link/прочий-link отладчиков? Как он поддерживается в IAR-e?

На честном RTU с 3.5-символьными интервалами это г*вно любой USB/UART не работает, даже запаянный на плате. в смысле не как работает усб-485, а как у них получается сделать преобразователь, оформленный в корпус, и доставить в эту страну донести до почтового ящика за 51 рубль?

ps ПЯТЬДЕСЯТ РУБЛЕЙ!!! ПЯТЬДЕСЯТ!!! Доставка бесплатно. Не понимаю, как это работает?

более того.... большинство, лепящие modbus в ПК на COM (без усб) или /dev/tty - так же не включают голову. 1,5 и 3,5 символа между байтами не анализируют. вопрос филоссофический..... допустим cpu шлет в пк через усб свисток USB FS. скорость в modbus 9600. всего 5 байт. байт-пауза в 0,5 байт - байт - пауза в 0,5 байт - байт - пауза в 0,5 байт - байт - пауза в 0,5 байт - байт - пауза в 3,5 как UART/USB выдаст в ПК эти байты? Будет пять булков отправлено в ПК и приложение получит через VCP пять байт с паузой между ними 0,5±t? Или преобразователь эти байты оформит в один булк? А если в modbus будет два пакета по 5 байт с паузой между ними в 4 символа. То в пк отправятся 10 булков по 1 байту? или UART/USB соберёт эти два пакета отправит один булк в 10 байт? Как ваше приложение на ПК в одном булке разделит на пакеты эти 10 байт? Это хороший вариант, лучше чем у вас на первой картинке. Если не 422, то тогда так ПК <-> USB/UART <-> CPU1 + CPU1 <-> UART/485 <-> 485/UART <-> CPU2 А вообще... вы пишете, что вам нужно ТРИ устройство посадить на шину? Зачем? Соедините два устройства любой самой дешевой/доступной шиной: CAN/UART/485/422/1-Wire/I2C/Ethernet.... и сделайте порт USB для подключения к ПК. Зачем ПК лезьть в шину между CPU? CPU может ретранслировать команды от пк другому CPU. Ну хорошо.... ну всё таки вам нужен modbus (т.к. это стандарт, сторонние устройства, сторонние программы, бла бла бла.... ) выкиньте с платы всю ветку usb-uart-485, оставьте на плате только 485 и втыкайтесь в эту шину компьютером напрямую через всё тот же злощасный usb/uart, ой, т.е. через usb/rs485. Например через такой. Возможно они дороговаты... но алиэкспресс ещё не забанили. Там эти переходники 72р (по мойму на сегодня меньше $1).

выбор 485 в отрыве от всего - наверно оправдан.... выбор ESP32.... наверно тоже оправдан.... но... если глянуть на всю систему... см 1-ую картинку USB <-> usb/uart <-> uart/485 <-> 485/uart <-> cpu ..... ??? можно ещё 10 штук 485/uart добавить ))... почему нельзя USB<->cpu ? аааа.... ну да, в eps нет usb. Но лучше может тогда USB <-> usb/uart <-> cpu и объединить внутри cpu два "485"? Или может лучше взять stm32 с usb на борту? А ещё лучше в топку 485 и оставить esp, но соединить всё на ethernet? в esp eth на борту... более того у esp на борту wifi.

сам не пробовал, посмотри тут

и? это имеет прямое отношение к запросом на прерывания: стоит вачдог - нет запросов на прерывание. У ТС может именно по WD идет прерывание.

в иаре точно такое есть. если в паузе сработает таймер или вачдог, то при шаге - велкомТуОбработчик. НО, если у вас STM32, то посмотрите регистр DBG. В нем можно отключить прерывания в "паузе". Например если выставить флаг DBG_WWDG_STOP, то Window Watchdog Stopped when Core is halted

я такого поведения не наблюдал. ps из сказанного вами я понимаю так: 1) запускаем программу в отладке 2) останавливаемся где-то в коде на брейке (программа находиться в паузе) 3) смотрим код, пъем кофе, ни чего не нажимаем, программа продолжает пребывать в паузе.... 4)пока пили кофе, и вдруг налетел ветер вас перекинуло в прерывание, т.е. IDE открыла файл с обработчиком прерывания и подсветило первую строку. файл, на котором был брейк и на котором стояли стал неактивным (или перекрылся обработчиком). вы ни чего не нажимали, ни чего не выполняли, находились в паузе - и вас перекинуло!? Вот именно такого поведения, о котором вы говорите, я ни когда не наблюдал. если же вас, находясь в паузе, ни куда не перекидывает, потом вы делаете шаг - и перекидывает в обработчик - так это не "перебрасывает в паузе", а "перебрасывает при пошаговой отладке". Это не пауза, а выполнение. Вы шагнули через функцию printf() без захода - там коду 100500 строк асма, конечно там может все что угодно случиться. Если в паузе у вас встал флаг прерывания, то после того, как допьете кофе и сделаете шаг (даже если шаг по asm("nop");) - вас перебросит. По мойму это нормальное поведение любой иде (в том числе и IAR). Чтоб этого не было, в паузе запретите прерывания (можно прямо в IDE руками нужный флаг снять, можно в коде до брейка запретить прерывания, после разрешить).

да почти в любом описании основ ОС/РТОС где идет объяснение мьютексов - приводится аналогия с домом/закрытой дверью/ключами....