К сожалению, по условию задачи, этот вариант не подходит

[quote name='singlskv' date='Jan 8 2007, 17:35' post='194214']

1. Работа на скоростях до 115200
6. Контроль межбайтовых и межпакетных промежутков в пакетах Modbus (ну конечно
на столько, на сколько это вообще возможно под Win)
[/quote]
на скорости 115200 один байтик передается 87мкс
межбайтовый промежуток 4 байта = 347 мкс

а стандартные таймуты COM порта начинаются от 1мс
и Sleep тоже от 1 мс , и при этом еще и не отрабатывается
а такт операционки 10-20мс

а если вводить везьде большие задержки, то 115200 может чудесным образом
превратиться в 19200
да и контроль остается только по длинне пакета и по CRC

Вот собственно по этому и хочется найти исходники где реализован
хоть какой-то контроль.

Например можно для контроля промежутков использовать Performance Counters.
Просто очень не хочется наступать на все грабли на этом пути,
особенно если на них уже кто-нибудь наступил
[/quote]Для начала: межбайтовый промежуток можно сделать и 1 мс - таймаут в порту отрабатывается аппаратно, а вот уведомлениие об этом событии приложению ОСь выдаст конечно с задержкой, но это уже не столь важно будет - главное таймаут будет зафиксирован

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



А какие у Вас требуемые межкадровые интерывалы? И что за контроллеры?

Подумал и решил что избавиться от программного контроля за лишней линией (RTS) было бы очень удобно. Попробовал сделать так как предложил Сергей Борщ, прошу посмотреть правильно-ли я все соединил:

Если все верно, то прошу объяснить какие номиналы должны быть у R1, R2, R3, R4, R5 и C1. И будет-ли данная схема работать на скорости 115200 бит/c?

Вы опять попутали выводы V- и GND у ST232. На GND подается земля, на V- минус С4, плюс С4 на землю. На выводе V- получается напряжение около -10в. Если есть возможность - используйте ST202 - ей достаточно керамических конденсаторов на 0.1 мкФ. R1 не нужен - ST232 не умеет переводить выход в третье состояние.
У меня работает на 115200. R2 - подтяжка, 1К...4К7 для 115200, при меньших скоростях сопротивление можно увеличивать, при этом снижается потребеление. R3 10К, C1 1нФ, R4 и R5 согласно документу, который привел ув. prottoss должны быть 450...650 ом.

Все исправил, схемы приняли вид:
RS232 to RS485:


AVR to RS485:


Если все верно, то 1/3 дела сделано, теперь бы еще программу для МК под эту схему придумать.

Мне тоже не нравится. Кажется устаревшим, излишне перегруженным и в то же самое время не полным. То есть объявление - "у меня тоже MODBUS" - абсолютно ничего не даёт. На сто процентов модбас нефтяников не будет работать с модбасом форд. Да я и не уверен что форд-тайота услышат друг-друга. Если, да то это только в случае, что они договорились м/у собой "кроме протокола". Хотя надо признать, что сама структура первого уровня - пакеты - формат пакетов - таймауты - CRC - придраться особо не к чему. К сожелению с LIN не разбирался и до CAN тоже руки не дошли. Хотелось бы конечно. Но пока не было такой задачи.

Компонента MODBUS у меня нет, но есть компонент COM порт и RS485. Я его использовал, но немного корректировал. У меня есть сомнения что под виртуалом вообще полностью можно создать MODBUS. singlskv совершенно точно перечислил причины. Только что с этим боролся.
Пробовал вот такой вот вызов таймера
TimerID:=timeSetEvent(ASpeed[Speed],0,@TimeProc,0,TIME_PERIODIC);
10мс отрабатывает нормально, но можно и меньше. Но тоже есть проблемы. Мне обещали подогнать правильную работу ч/з OPENGL. Буду пробовать.

Когда я говорил про Фордов, нефтянников и иже сними, я как раз и имел ввиду программный протокол, а физическая часть на вкус и цвет - Форд и Ко использует K-Line , нефтянники используют диф. пары, кто-то предпочитает радио потому как расстояния разные (одна из главных причин) и стимулы.



ЗЫ: Как OpenGL может помочь, что то я не догоняю??? Это которая с Direct3D дружит?

Опять почти. В документе "имени prottossa" в разделе 3.4.6 сказано (даже выделено), что резисторы растяжки должны быть только в одном месте на всю шину. В вашем случае без переходника 232-485 система не работает, поэтому их имеет смысл оставить именно в этом переходнике, а в "AVR то 485" R1 и R2 исключить.
Повод прочитать раздел 2.4 Master / Slaves State Diagrams упомянутого документа

Щаз лопну от гордости

prottoss Не надо,нам вас будет недоставать.

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

Возможно и может, надо глянуть в эту сторону (мысля очень интересная)
дело в том что у OpenGL должны быть очень шустрые таймеры(не помню уже, давно это было, да и не на PC), ему ведь 3D графику в реалтайме выводить надо.
А стандартные виндусовые таймеры нормально начинают работать от 10мс.

Некоторые пытаются использовать MMTIME, там вроде такт получается 1-3мс

Я некоторое время занимался программированием 3D графики, и, как человек икушенный в этом не легком деле, скажу Вам что OpenGL базируется на DirectX, DirecX создан для Windows и он не использует точных таймеров. Для сдерживания, допустим FPS, используется обычный софтверный тамер системы Реалтайм для игрухи это 25 -50 ФПС.



ЗЫ: Представляю картину. Огромный зал с компьютерами, супер АСУ так сказать. Дядьки с умными лицами ставят Ваше ПО на систему удаленного управления объектами, бубны, торжественная музыка... Хлоп ... Аншлаг... Версия DirectX на Вашей системе устарела, требуется обновление ПО... ... Ну а че, прально, и оператору хорошо, вечером мона Кваку новую погонять, хехе

Дабы не заморачиваться с микросекундными задержками в windows я использую протокол WAKE. В нем определение границ пакетов происходит по служебным байтам. Есть исходники и на мк и на компьютер, за что огромное спасибо Леониду Ивановичу.
К сожалению ссылка на протокол не работает. Если интересно могу выложить исходники здесь.

ПС WAKE открытый и бесплатный протокол, в отличие от MODBUS.

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



А в каком месте MODBUS закрытый протокол?????????????

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

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

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

Ссылка на WAKE
http://www.spetspribor.com/support/software/wake/wake.html
к сожалению не работает , поэтому выложил сохраненную страницу со всеми файлами на ФТП
/upload/DOCs/WAKE.rar

байт-стаффинг конечно не очень хорошо, но жесткая времянка еще хуже(ИМХО).
А то что MODBUS закрытый может я и ошибся, но всякие там оговорки типа:
мне не нравятся.

ПС
2 prottoss На Вашем сайте исходников MODBUS нет, значит это закрытый протокол .

У меня к сожалению нет доступа к этому ФТП, может закинеш эти файлы мне на e-mail: labor@online.ua?

Мдя, после того, что я тут выложил, и Ваших слов некоторые точно подумают, что MODBUS придумал я , хм....я уже подумываю о новой версии - PROTTOSSBUS, а че? звучит ...

Зато на моем сайте есть достаточное количество информации, что бы разобраться в протоколе и начать продуктивно работать в этом направлении. Что касается исходников - я уже говорил выше - есть на http://modbus.org совершенно БЕЗВОЗМЕЗДНЫЕ готовые исходники (под PIC, но переделывается влет за неделю) и для клиента и для сервера. Все на Сях. Может быть выложу и свои - надо их причесать немного...

Положил сюда:
http://rapidshare.com/files/11035544/WAKE.rar.html (1.8 Мб)



Отличная идея

Это замечательно, может кому то понадобитсся именно полный MODBUS. Я, правда достаточно давно, реализовывал его на ASM51. В принципе с точки зрения микроконтроллера ничего сложного нет. Но для меня немного нафталином попахивает.

А вот с точки зрения PC, всё не так просто. Например задача - контроллировать задержку в 1.5 символа (пишу по памяти) на высоких скоростях (а RS485 поддерживает до 2Мбит) представляется сомнительной. Я столкнулся с тем что у меня PC самопроизвольно рвала пакеты. Иногда вставляя незначительные промежутки, но и скорость у меня не рекордная! А что будет на большой? Кроме того незнание момента окончания передачи для PC, а расчёт его, - тоже вызывает ощущение - не очень.

Всё идейно важное, - на мой взгляд из первого уровня (как я бы сказал) из MODBUS взял тот же WAKE. А для меня красивым протоколом на втором уровне является X-modem. Я исследовал для себя. Он даёт самую высокую скорость при ошибках в линии. Очень идея красивая. Правда я делал адаптивные размеры пакетов и анализировал статистику.

Интересно было бы повозится с LIN и с CAN. Чтобы самому составить своё собственное мнение.

А вообще интересно наблюдать, что все более-менее современные протоколы в конечном итоге приближаются к сетевым.

Разве идея MODBUS это не master-slave (запрос-ответ)?
Насколько помню там тупо до ужаса.
Посылаешь пакет, ставишь тайм-аут (отфонарный) ~100ms, если в ответ что-то пришло - хорошо, считаешь CRC, 0 - отлично, проверяешь код функции, совпал - значит ответ на наш запрос, ну а дальше парсишь сообщение.
Слейву еще проще. Получил команду - отправил незамедлительно ответ.

Где там задержки в 1.5 символа-то?

фунции modbus драйвера:

Не, незамедлительно нельзя!
по стандарту нужно выдержать интервал не менее 4 длительностей байта

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

По стандарту нужно чтобы каждый принимаемый байт попадал в фрейм
длительностью 1,5 байта на данной скорости.
Правда эту часть стандарта обычно никто не контролирует строго.
Главное это чтобы межбайтовые промежутки не превышали межпакетные.
Ну и контролировать можно только со стороны слейва.
Если слейв микроконтроллер то это сделать легко, а вот если PC под Win да и еще скорость
приличная, то тогда легче сразу повеситься

Когда мастер PC под Win то существует проблема обрезания длинных пакетов:

Кстати SasaVitebsk какая у Вас скорость ?
Удалось ли победить обрезание пакетов ?

Я сделал и програмно тоже, но получалась такая шляпа. Обрезание пакета не происходило, я расчитывал задержку.
Но возникала проблема со слэйвом. А именно: надо было послать ответ тогда, когда мастер гарантировано переключал направление с передачи на приём. Поэтому картина вырисовывалась следующая. Мастер вставляет задержку чтобы не было "обрезания", а слэйв вставляет задержку относительно задержки чтобы гарантировано попасть на приём. Но если мастеру - всё по барабану, то слэйв, чтобы подтвердить приём - фактически простаивает. Но это только пол беды. У меня была задумка - автоматически подстраивать скорости. Когда-то я реализовывал полный автобод, но тут у меня у слэйва не было ресурсов. Слэйв работает всё время и отвлекается только по поступлению пакетов. Поэтому я решил упростить задачу (что оправдано в данном интерфейсе). Принцип такой. Мастер посылает пакет (каждый пакет - какая-то команда). Слэйв поступает таким образом: Отвечает 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). 

Это в структуре DCB нужно установить поле Parity:
Parity - Определяет выбор схемы контроля четности. Данное поле должно содержать одно из следующих значений:

EVENPARITY-- Дополнение до четности
MARKPARITY-- Бит четности всегда 1
NOPARITY-- Бит четности отсутствует
ODDPARITY-- Дополнение до нечетности
SPACEPARITY-- Бит четности всегда 0??????????

Значит мне надо работать со значениями MARKPARITY/SPACEPARITY ?

Большое спасибо!

Да.