Я сделал и програмно тоже, но получалась такая шляпа. Обрезание пакета не происходило, я расчитывал задержку.
Но возникала проблема со слэйвом. А именно: надо было послать ответ тогда, когда мастер гарантировано переключал направление с передачи на приём. Поэтому картина вырисовывалась следующая. Мастер вставляет задержку чтобы не было "обрезания", а слэйв вставляет задержку относительно задержки чтобы гарантировано попасть на приём. Но если мастеру - всё по барабану, то слэйв, чтобы подтвердить приём - фактически простаивает. Но это только пол беды. У меня была задумка - автоматически подстраивать скорости. Когда-то я реализовывал полный автобод, но тут у меня у слэйва не было ресурсов. Слэйв работает всё время и отвлекается только по поступлению пакетов. Поэтому я решил упростить задачу (что оправдано в данном интерфейсе). Принцип такой. Мастер посылает пакет (каждый пакет - какая-то команда). Слэйв поступает таким образом: Отвечает Ok, Error или не отвечает. Ok - CRC Ok. Error - запрос на повтор. (то есть команда понята, но CRC - Error) А нет ответа если не понят пакет (Метка - команда). Это даёт возможность "сканировать" мастером с определением скорости захвата. Но тут и незадача. Работа осущ. на скоростях 1200-115200. Таким образом размер паузы увеличивается на размер 1.5 байта на младшей скорости (~12ms). Что приводит к доп. увеличению задержки на ответ.

Короче я по концовке поставил со стороны PC аппаратный одновибратор по обычной схеме (на 7400).

Задержки таковы: 5мс - слэйв. Мастер выжидает таймаут 50мс.

Но в принципе по мне это не бьёт, так как максимально эффективная скорость передачи (на больших данных) у меня 4800. Это значит, что при дальнейшем увеличении скорости коннекта, - скорость передачи не растёт. Включаются механизмы управления потоком.


Кстати у меня есть програмка тестирования MODBUS протокола из под PC. Когда реализовывал его - пользовался. Всё работало. (Правда давно было) Могу выложить если интересует.

2 singlskv

Зачем так щипетильно относится к стандарту MODBUS? Я принимаю, что серверу (то бишь периферийному контроллеру), естественно, надо отслеживать и межсимвольные и, обязательно, межкадровые, интервалы. Но клиенту (то бишь РС), межсимвольные интервалы ИМХО не нужны, и большинтсво ПО, по крайней мере с которым я более менее знаком, не проверяет их. Достаточно контрольной суммы в пакете, поля длины пакета и таймаута кадра (опять же ИМХО). Я достаточно плотно занимаюсь с горношахтным оборудованием. Линии связи - более 15 километров!!! Под землей и на поверхности, при этом кругом 6 киловольт и 660 вольт, потребители по 400 кВт!!! Вся электроника прекрасно дышит в ритм и у диспетчеров и под землей. И ни каких специальных кабелей - обычные телефонные 20-и парники...

1. В асинхронном режиме можно ввести метрику процессора (UART).
2. В синхронном - реализовать мультипроцессорный режим MPCM.
И все.

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


Однако это позволит запросто избавиться вот от этого:



опять-таки, эта часть стандарта объясняется только кривизной мастера, и надумана только для ASCII режима. В RTU посылки-то с нормальным кодом защиты, т.о. нам не страшны любые искажения и смещения потока.

Я думаю всё это обосновано следующим. Должно быть описано КАЖДОЕ состояние. И это, в принципе, правильно. Я начал передавать фрейм. Передал - заголовок. Слэйв принял. Но ждать он может ограниченное время - иначе клинч.

Давайте посчитаем какой должен быть разрыв м/у байтами. Фактически разрыв м/у байтами должен быть меньше, чем для слэйва принятие решения о завершении пакета. Так какой он должен быть? Ну возьмём фиксированный - к примеру 5мс. Нельзя. Для скорости 1200 бод (а нижняя по стандарту думаю вообще 300) байт - 8.3мс. Таким образом для данной скорости 5мс - мало. Поэтому таймаут привязан к скорости. Возьмём 10 байт. Учтём, что после завершения пакета (для слэйва) слэйв должен обработать команду и подтвердить её приём или ответить на команду. Таким образом к задержке для мастера надо прибавить ещё задержку на ответ. Таким образом чем больше задержка - тем ниже пропускная способность шины. Это понятно. Таким образом желательно ввести МИНИМАЛЬНУЮ задержку. Но она не может быть меньше одного символа. В этом случае мы просто не будем знать закончилась ли передача. Ну вот Вам и формула должна быть минимальная задержка более одного символа. Выбрано 1.5.


Как раз здесь у меня претензий нет. Претензии по самим командам. С некоторыми я ни соглашусь ни в жизнь.

Должен быть интерфейс. Слейв должен по запросу выдавать свою програмную модель что-ли. А мастер не вправе читать/писать всё подряд. Мастер и слэйв должны быть защищены друг от друга. А здесь протоколы этого не предусматривают.

Ну во первых назвать Windows нормальным мастером рука не поднимется
Во вторых, выдерживать эти межпакетные интервалы Вам все равно придется, иначе
другие устройства, которые придерживаются стандарта могут Вас не понять
А для Win это проблема, если Вы попытаетесь воспользоваться просто задержкой
Sleep(xx) для интервала xx менее такта операционной системмы (10-20 мс) то, можете
с удивлением обнаружить, что Sleep(10) например, чудесным образом превращается
в задержку 15мс, а иногда в задержку 300 МИКРОСЕКУНД
А нужно гарантированно выдерживать не менее 4 байтов

На самом деле конечно не все так печально.
В стандарте оговаривается рекомендация, выдерживать 3,5(4) байта промежутки
только для скоростей до 19200. При более высоких скоростях, рекомендуется выдерживать
межпакетный промежуток не менее 1750мкс.
Хотя это все равно не вписывается в возможности Win.
А если при каждой пересылке мы будем ждать 20мс, т.е. гарантированно больше такта
операционки, то максимальная производительность интерфейса будет 50 пакетов в
секунду (примерно).
При пакетах запрос/ответ например по 8 байт и скорости 115200 мы будем иметь
производительность канала: (8+4+8)*50=600 байт в секунду вместо 11520.

Еще пару слов в поддержку 4(3,5) межбайтового интервала.
Пусть у нас есть один мастер и 2 слейва.
Мастер шлет запрос первому слейву и ждет от него ответ.
В какой момент второй слейв должен решить что могла начаться передача ему ?
Вот сидит он и слушает общую линию, и как он может определить что начался новый пакет
который нужно попытаться разобрать ?
Есть еще парочка пременений этому межпакетному промежутку, но чего-то и так слишком много
буковок получилось ...

К сожалению, не всегда.
Здесь ИМХО, есть несколько моментов.
1.Кривизна serial драйверов Win.
2.Кривизна чипсетов на мамках.
3.Ну и опять же длина таймаутов
по пунктам 1. и 2. от нас конечно мало что зависит, ну можно конечно немного
погуглить и найти более коректный драйвер
по пункту 3. могу ответственно заявить что COMMTIMEOUTS для высоких скоростей
вещь довольно кривая, да и при скорости 115200 время одного байта 87мкс, а минимальный
таймаут 1мс

ЗЫ. У меня на нотебуке при пересылке длинных пакетов иногда пропадают байтики
внутри пакета


Ну вроде никто не мешает реализовать это в рамках стандарта

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

По поводу первой части.
По моему все мы, включая defunct говорим об одном и том же, но просто разными словами.
В обобщённом виде выглядит так: В принципе к стандарту претензий нет, но есть претензии к PC+Windows, которые не позволяют реализацию данного стандарта в полном соответствии. При этом приходится чем-то жертвовать слегка "подправляя" стандарт под себя. Жертвуем мы чем-то "несущественным". Правда неесущественным для себя. Иными словами мои жертвы, ваши и defunct могут отличаться. Хотя скорее всего будут работать м/у собой.

По поводу второй части. Всё правильно "никто не мешает реализовать это в рамках стандарта" и т.д. Я не спорю. Я просто говорю что он не полный в моём понимании. Так как то что я реализую в рамках стандарта и то что Вы реализуете в этих же рамках и в полном соответствии - не будет совместимо. Причём без всяких там "скорее всего". Даже если мы с вами будем делать одну и ту же вещь! Эти вещи должны быть прописаны самим стандартом. А этого нет!

Давно присматриваюсь к "Пирамиде".
http://upload.caxapa.ru/pyramid/

Изумительно выглядела бы связка WAKE(транспортный уровень) + Пирамида(логический уровень).

Подписываюсь под этим. Я это выстрадал.

При последней реализации меня пытались заставить разрешить прямой доступ к памяти! Причём основания такие - программа на PC тоже будет отлаживаться и ошибка невозможна. С другой стороны изменение логической модели МК приведёт лишь к изменению обслуживающей проги.

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

Я потерял исходное сообщение, кто это высказал:
"Целью проектирования является разработка простого метода доступа к внутренним
параметрам приборов. Базовое условие - терминал не обязан знать или предполагать что-
либо о приборе для решения этой задачи. "

Абсолютно с этим согласен. Ровно год назад перед разработкой нового прибора я решил, что должно быть именно так. И заложил в прибор новый протокол, эдакий очень упрощенный SNMP. Как и браузерe SNMP, браузеру этого протокола абсолютно все равно, какое устройство подключено - он автоматически сосчитает имена всех доступных объектов, создаст закладки в окне, прочитает текущие значения. Есть программа осуществляющая более сложный доступ (чтение и запись переменных, вывод на экран) по простому неветвящемуся скрипт-файлу. Логика работы прибора может быть легко проверена браузером протокола вручную. Если более сложная программа для PC нужна, она не будет единственным средством работы с прибором, можно не зависеть от другого программиста.
Пока доволен результатом, планирую выложить все на сайте фирмы, включая порты слэйва под AVR и MSP. Более того, есть порты мастера и для микроконтроллера, что обеспечивает "прозрачность" контроллера, который служит шлюзом.

К чему это я? Да просто читаю, как сложно реализовать стандартный низкоуровневый протокол под Windows, и предложения убрать часть спецификации. И в чем смысл частичного соблюдения каких-то спецификаций? Зачем нести полуразрушенный самими же прах старых протоколов? Совместимость все равно не гарантируется! Если хотя бы один обязательный пункт спецификации MODBUS не выполнен, это уже не MODBUS!

Я именно о том же.
В настоящий момент меня не очень интересует данная тема, но когда припрёт, то боюсь опять начнётся ваяние велосипеда. Если будет возможность с интересом прочту Вашу статью. Понятно, что конкретная реализация не обязательна, а вот идея порой стоит многого. Очень не хочется наступать на те же грабли на которые уже кто-то наступал.

Не совсем в тему, но иногда возникает стойкое ощущение, что мы регулярно проделываем одну и ту же работу, но паралельно. Конечно было бы заманчиво хотябы частью этой работы делится с другими. И наоборот.
Конечно это практически несбыточная фантазия, но помечтать же можно.
В этом смысле определённые протоколы - это самая близкая точка соприкосновения. Здесь не надо "лучше", - здесь надо "так же". Короче если бы образовалось группа поддержки перспективного интерфейса или идеологии, то возможно я бы её поддержал.

Моя вина . Это цитата из описания системы "Пирамида", ссылка на которую содержится в моем предыдущем сообщении.

Скажите пожалуйста, вот если соединять слейвы с мастером выполненные на микроконтроллерах в мультипроцессорном режиме, то мастер указывает в 9-ом бите, что это: адрес или данные. А вот СОМ-порт компа может слать этот девятый бит?
В программе "терминал" установить режим с 9-м битом невозможно, нет там такого флажка.

Так же читал о возможности передавать идентификатор (адрес/данные) в стоп-бите.
Может быть его можно устанавливать/сбрасывать в компе?

Если комп не поддерживает на ур-не железа такую возможность, то как программно эмулировать на компе мультипроцессорный режим?

Короче, как мне добраться из компьютерной программы к этим битам.

Спасибо.

ИМХО никак.
Но может быть есть драйверы RS-232 которые имеют режим 9-ти бит данных типа FTDI, но я что-то не помню.
Или можно забацать как Real сделал на FT2232 ногодёргательным методом....

Управляя битом четности, ибо он и есть тот самый девятый бит . Есть возможность в 8250 устанавливать его в конкретное состояние (смотрите mark/space).