Можно уточнить что Вам необходимо в компоненте Modbus ?

запись и чтение регистров внешних слейв устройств на базе авр атмел с программой составленной в Flprog по протоколу modbus rtu через сериал порт он-же ком.
архитектуру компонента надо обсуждать в двух стороннем порядке, поскольку не имею представления какие ограничения накладываются языком и средой hiasm

Почитываю протокол модбас рту но пока в голове плохо укладывается, в программирование я полный нуб, моя тема чпу и механика, а с программированием только начинаю знакомится С++ и ардуиновский извращенный С.
Нахожу интересным и полезным взаимодействие пк с мк и другими устройствами поддерживающими modbus rtu и tcp

Привет кабанчик
Время нет хронически
Пока переделал элемент на обычный ком
и отладил 4 функции чтения.
Отлаживал на китайском контроллере Кинко к508.запись пока не делал, уперся как вывести данные наверх? Слева неудобно как-то. На мой взгляд запрос чтения был бы удобным через нижнюю точку но,не могу представить как затолкать снизу вводные данные?. Нужно будет адрес слейва,адрес внутри слейва,тип параметра,тип данных
короче нужно как-то сделать продвижение
некоторых данных снизу вверх в точку var

--- Добавлено в 2018-11-19 22:34:09

Где-то такое уже делали не найду где.

--- Добавлено в 2018-11-19 22:59:32

Перепутал, отписывался кренделееву.
А у тебя кабанчик есть готовый компонент?
Сейчас у меня в компоненте только настройки порта, топология и параметры сети в целом подаются на верхнюю точку списком параметров strlist.
Сейчас цикл опроса сети крутится бесконечным циклом. Используется предсказательный расчет времени ожидания ответа. При скорости 9600 время фазы запрос-ответ=31 мс при 8 переменных, а время запрос-неответ всего 37.

Редактировалось 2 раз(а), последний 2018-11-19 22:59:32

Вот я уже полгода наблюдаю за этой темой
Чисто из спортивного интереса: когда же до народа дойдет, что RTU невозможно реализовать на наших десктопах.

Народ, вы стандарт-то читали, или как
Между байтами пакета не должно быть паузы более 1.5 символа. И должна быть больше 3.5 - между пакетами.
У вас нет таких гарантий даже при передаче.
А на приеме, стандарт жестко нормирует поведение алгоритма при превышении вышеуказанной паузы.
Это как жы вы намерены измерять эти доли миллисекунд (на десктопе-то).
О каком RTU вы, вообще -- беседу-то ведете

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

---

Не знаю... За полгода можно было БЫ и овладеть вопросом

Редактировалось 1 раз(а), последний 2018-11-19 23:31:42

Не такой уж этот страх большой, товарищ Galkov. Это детский протокол по сравнению со взрослыми собратьями,главное отсутствие джиттера и разрывов пачки-это относится еще в большей степени к другим протоколам.
Если нельзя но хочется то можно - с 11 года исправно работает profibus-dp на 7 обьектах. А вы говорите за пол-года.
Я полтора года только вылизывал начиная с перевода литературы с немецкого и заканчиванием осмыслением всех временных характеристик.А ваши оба параметра легко реализуются при условии отсутствия иных процессов.

Все таки не удержался, надо как-то реагировать на сарказм.
Время я считал по отчетам сниффера от agg, а он построен на основе фильтр-драйвера который крутится в 0-м кольце, и в его отчеты можно верить. Могу выслать файл логирования или видео с цифрового осциллографа,так что я могу судить о миллисекундах. Гравное обеспечить несколько критериев:
1а -идеал написание драйвера режима ядра
1б отдельный поток с повышенным приоритетом
2 в системе не должно быть привилегированных процессов.
3 перед вызовом функции передачи сброс времени потока передачей остатка времени
4 вздрючивание приоритета до мышиного 31го
5 вызов передачи (в буфер fifo)
6 цикличный опрос буфера передачи на предмет опустошения
7 сброс приоритета потока.
Это все для того что бы передачу не рвало,в принципе передачу порвать и не может, может произойти опустошение буфера.
8 на callback функции вашего ммтаймера
делаете ваши 4 мс задержки тишины, а можете и больше все равно все на него наплевали.
Именно так сделан мой драйвер спокойно тянущий 0.5мбит.
9 после установки программы в автозагрузку выдергивается клава и мыш,все порты опечатываются стикерами

В начале 90-х из под DOS программно запрещал все прерывания контроллера (этих самых прерываний), а после выполнения критических операций ввода-вывода, снова разрешал. И да, тоже использовал кэширование данных в статической памяти платы интерфейса ввода-вывода.

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

Никакие осциллограммы не докажут, что на десктопе можно выполнять Real-Time-задачи с deadline-ами в милисекунду.
((и не надо мне приписывать 4мс - требования стандарта не я придумывал))
Поэтому, присылать не надо.
Факт некой работоспособности НЕ ДОКАЗЫВАЕТ отсутствия отказов. И никогда не доказывал.
Да, вы более-менее правильно изложили требования, для решения RT-задачи.
Которые, если их добивать до конца, означают написание собственной RT-оси.
Ни много ни мало.

---

Хотя задачу можно было бы решать по другому...
Если с самого начала начать думать в правильном направлении. А не пытаться дурака (десктопа) обучить разуму.
Промежуточный камень с двумя COM-портами, конвертором USB/COM (типа FT232), и драйвером RS485 (например ADM2587).
Какая-нибудь АVR-ка (скажем Atmega164P-20AU) на частотах типа 14.7456 МГц - прекрасно справится с задачей конвертации Modbus rtu в Modbus ascii в обе стороны.
Причем, от кода в AVR-ке уже можно будет требовать гарантий, а не крутить пальцы веером, типа: спокойно тянет.
А на этом форуме уже реально обсуждать Заказ на блок\блоки Modbus ascii

НО, я ни на чем не настаиваю.
Можете и дальше парить мозги друг-другу.........
Да, вот еще: нет тут никакого сарказма. Просто рассказал, как устроена жизнь.

Редактировалось 4 раз(а), последний 2018-11-20 11:39:35

Добрый день, сегодня оттестил чтение дискретных входов и выходов через функ 1,2 и запись coil （do） через функ 5.
Чтение и записи переменных гонять буду завтра. Когда переменные пойдут-выложу альфа версию. Пока заложены функции 1,2,3,4,5,6,15,16 -вроде все охватывать должны по данным, ну кроме функций диагностики ведомого. Из-за противоречивого расположения данных в области register, то есть переменных-придется ввести свойство типа ордер наверное.
Тест проводится на контроллере kinco-k508 (а-ля симменс из поднебесной).

Galkov, а я не знал этого... Тогда почему моя программа читает по Modbus RTU на стандартных компонентах Modbus уже лет 5?

А кто не давал узнать-то.
Просто читаем стандарт (я то его уже давненько читал, и говорю по памяти)


Читает, это не значит, что она удовлетворяет спецификациям Modbus-rtu.
И откуда вы знаете, что за пять лет не было ни одного сбоя.

Скорее всего, вы работаете в режиме мастера. И не на очень большой скорости.
Выплюнули в COM пакет целиком. Гарантированно один пакет.
Вероятность того, что винда не прервет передачу на этой паре сотен байт -- невелика, весь пакет влезет в FIFO порта.
Но - ненулевая. И еще зависит от того, что еще в это время крутится на десктопе.
Далее, относительно долго (100 мсек - это очень долго, в сравнении со скоростями порта) ждем приема.
Все, что принято - это как бы должен быть один пакет ответа слэйва. Один, и только один.
Если при приеме будут недопустимые (дольше 1.5 символов) дыры, то спецификация Modbus-rtu требует забраковать весь пакет.
Вы (на десктопе) этого не сделаете.

Работать как бы и будет. Но это не Modbus-rtu. Сколько бы кто-то не гнул пальцы.
А уж про слэйв-режим на десктопе - и говорить особо не приходится.

---

А есть еще вопросы помехозащищенности линии. Они не определяются стандартом. Но из-за этого они никуда не пропадают.
Стандарт на Modbus фактически требует физическую реализацию как RS-485.
Это полудуплекс. Значит надо переключаться с приема на передачу, и наоборот.
Когда линия висит типа в 3-м состоянии (все устройства на приеме) - помехозащищенность весьма хилая.
Особенно опасны помехи сразу перед передачей пакета, и сразу после. Один импульс помехи - и весь пакет ушел в брак.
В смысле - должен уйти. Потому-что стандарт нормирует алгоритмы приема/передачи.
Чтобы этого не происходило, необходимо держать "жесткую единицу" в течении хотя бы одного символа (а лучше - 3-х) до, и после пакета.
Этого стандарт не требует, но это жизненно необходимо.
Если, конечно, вас интересует результат. А не возможность покрутить пальцы веером.

---

Вообще-то, главное, что я хотел сказать - это то, что если ты хочешь сделать дело, то вопросом надо владеть...
Как бы "а я не знал этого" -- совсем не катит.
Стандарт на Modbus не является какой-то секретной информацией.

Редактировалось 6 раз(а), последний 2018-11-29 16:37:13

Galkov, вы писали
Я не где не сказал ни про слэйв, ни про иное. Я читаю модбас, раз в секунду по одному регистру, не более 5 шт. Надо по работе, наладке. Работает. Для меня идеально. Не программист я. Может и другим хватит этого.

Вы нигде и про мастер не сказали.
И что вообще значит: "Я читаю модбас". Если вы даже не удосужились узнать, что такое модбас.
Вот что такое модбас - я знаю. И при этом, что такое читать модбас - не понимаю в упор.

Ну, как говорится, и флаг Вам в руки.
Вы меня спросили, типа: а почему тогда работает. И я Вам ответил: потому что это не модбас.

Открыть Вам некоторые подробности про модбас, в теме Заказ на блок\блоки Modbus rtu - я, как и любой другой, имел право.
Если уж вы все сами читать документацию не обучены (или не понимаете зачем это).

От меня что еще надо-то
Ведь сказал же: просто наблюдаю. С любопытством.
До какого идиотизма мир уже опустился. И, кажется, что это еще не дно...

---

DIXI

Редактировалось 1 раз(а), последний 2018-11-30 17:29:18

Инструкция для юзера:

1). Galkov всегда прав.
2). Если Galkov не прав смотри пункт №1.

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

Сейчас проще использовать MQTT клиент с брокером - http://en.trialcommand.com/blog/gateway-esp8266-modbus-rtu-mqtt-hmi-industrial-panasonic/
Можно отправлять через консоль с Hiasma (mosquitto_pub/mosquitto_sub) я уже наподобие делал. Но если кто-то сделает элемент MQTT то это будет вообще надежно работать

Редактировалось 4 раз(а), последний 2018-12-02 18:38:40