Да ну? И где же они выставляются? Особено интересует как сделать паузу в 3 символа при передаче.
Ни за чем он не следит.
Код в студию   На эту тему было сломанно МАССА копий, сошлись на мнении, что это НЕВОЗМОЖНО. SetCommTimeouts НЕ ГАРАНТИРУЕТ ТОЧНОГО отслеживания интервалов при приеме, так что отловить интервал в 3 символа при приеме НЕВОЗМОЖНО.
То, что у вас оно работало это еще ничего не значит, вам просто сильно повезло - фреймы шли отдельно друг от друга, поток фреймов ваша реализация не отловила бы. 
Он (дравер) лезет с паяльником в компьютер и меняет чип RS232 передатчика? Или он обладает искуственным интелектом и умеет угадывать что происходит в железе, которое само этого сказать не умеет?
Это делалось на всем, чем только можно, вплоть до ассемблера в Windows драйвере.
Угу, еще раз повторю - вам повезло. Есть масса народу, у которого этот самый драйвер переключал направление передачи ДО того, как последний символ уходил в линию.
Замечательно - 'оно работало и делало все, что надо, вот только не помню что '  

PS. По поводу Modbus RTU был очень длинный топик на electronix.ru (не могу дать ссылку - он сейчас лежит)

В MSDN написано, что эти таймауты выставить можно. Оснований недоверять MSDN у меня нет. Я ставил. Это работало.


Какой код? Функция SetCommTimeouts. Вот и весь код.
Я незнаю, что она там гарантирует (кстати, Windows не является системой реального времени, так что требовать от нее гарантий соблюдения каких-либо временных интервалов вообще, мягко говоря, некорректно), но то, что ReadFile возвращала управление если они не соблюдались, это было.
А по поводу мониторинга среды, что бы выделить из нее пакет, это я не знаю как сделать... возможно на событиях можно.... которые драйвер САМ возбуждает. Но я не знаю. У нас работа была только с одним устройством одновременно.

Фреймы действительно шли отдельно. Но это не умаляет того, что таймауты выдерживались. Код я уже давал. Работало все с тем классом, ссылку на который я давал.


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


А что именно вы пытались сделать? Как я понял, хотели отлавливать кадры по таймингам? Этого сделать скорее всего не получится. Только если использовать, как я уже гвоорил, события. И то, я не знаю, будет ли это работать. А в общем случае, компорт не предназначен для того, что бы анализировать среду. Если я прав, и вы хотели сделать именно это, все понятно. Молтком сложно вскапать огород.



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




Потому что давно было, потому и плохо помню.
Еще раз. Было организовано взаимодействие одного устройства на базе МК и компьютера через RS485, с использованием переходника RS232<>RS485, который возвращал эхо.
После этого, было обнаружено, что в делфи неправильно объявлены константы для настройки драйвера порта. Константы управлением DTR/RTS были исправлены и драйвер настроен так, что бы сигнал (DTR или RTS я сейчас не помню, который именно использовали наши электронщики) изменял свое состояние в зависимости от наличия/отсутсвия байт в буфере порта. Смотрели на осциллографе. Все работало.

Ссылку не надо, т.к. давно этим не занимаюсь. Просто хотел поделиться тем, что когда-то делал. И у меня, допускаю что по странному везению , это работало.

То, что написано в MSDN не может поменять АППАРАТУРУ в компьютере. Эта АППАРАТУРА не позволяет отлавливать timeout'ы на уровне отдельных символов в входном и выходном потоке.
Любой timeout, поставленный через SetCommTimeouts будет округлен в большую сторону до величины тика системного таймера. MSDN по этому поводу молчит.
Этого недостаточно.
Угу, а полная реализация Modbus RTU этого требует, увы. Так что Windows здесь не подходит вообще, что и требовалось доказать.
Вы это проверяли? И именно на интервалах в 2-3 символа? 'Не верю!' (Станиславский)
Вот! Т.е. это не было полноценным Modbus RTU, а было его обрезком с отдельными фреймами и без контроля за межсимвольными интервалами (по стандарту они не могут быть более 1.5 символа).
Вот с этого и надо было начинать.
На заборе тоже было написано ... Драйвер может устанавливать RTS по факту передачи, однако частенько он его сбрасывает не дожидаясь отправки последнего символа в линию, это факт и по этим граблям уже ходило немалое количество народа. Это не значит, что ВСЕ драйвера на ВСЕХ компьютерах ведут себя так, но такие тоже есть.
Да
Именно, а стандарт Modbus RTU этого требует
Именно - 'в нашем частном случае'

Собственно зачем я весь этот разговор завел. Это касалось вашего заявления, что Modbus ASCII нафиг не нужен, а везде вместо него имеет смысл применять Modbus RTU.

Я заявляю, что ПОЛНОЦЕННЫЙ (полностью соотвествующий стандарту) Modbus RTU на ЛЮБОЙ PC без специальной дополнительной аппаратурой реализовать НЕВОЗМОЖНО. В отличии от Modbus ASCII, который реализовать МОЖНО.

Я не говорил такого. Я сказал:


И вы меня в этом не разубедили. То, что текстовые протоколы в частных случаях бывают полезны, я не отрицаю. Здесь же все исключительно ИМХО.


Требует. Но он писан для взаимодействия MK<>MK.
А для PC надо использовать другие методы. Наш метод, в нашем частном случае работал и не знал проблем.


Нет, настолько досконально я не проверял. Не было нужды, т.к. все работало.


Я нигде не говорил, что реализовал полноценный MUDBU RTU, да еще и дословно по спецификации. Я сказал, что было сделано так-то и так-то и это работало.


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


С чего? С того, что я не электронщик? Я нигде этого не говорил.


Полностью согласен. Еще раз. Спецификация MODBUS писана для MK<>MK. Для PC нужно использовать ДРУГИЕ МЕХАНИЗМЫ.
Тем более, что в данном конкретном случае кадры как два пальца определяются по размеру. По крайней мере я лично их определял именно так. И все было хорошо.

Ок. Если под железом понимается связь 2х и более спец. устройств, то полностью согласен. Если же это железо собирается подключаться к PC, то текстовый формат обмена может быть полезен (правда при условии, что его можно использовать с обычного терминала, без ручного подсчета всяких контрольных сумм и пр). И довольно много железок используют такой формат (например вся продукция фирмы Extron). Некоторые железки используют оба формата, например видеокоммутатор от системы видеонаблюдения фирмы Philips использует текстовые команды для управления (они документированны) и отдельный бинарный протокол (недокументированный) для обмена со своим софтом на PC.
С другой стороны текстовые протоколы более трудоемки для реализации в железе и обычно на это идут неохотно   
Текстовый протокол позволяет посылать железке ПРОИЗВОЛЬНЫЕ команды из обычного терминала не имея специального софта, тем более что обычно в таком специальном софте не предусматривается возможность отослать железке ПРОИЗВОЛЬНУЮ команду.

Он описан безотносительно к тому, кто с кем будет взаимодействовать. И МК тоже не знает с кем ему придется взаимодействовать по Modbus'у - с другим МК или с PC. Так что производители аппаратуры обычно поддерживают оба стандарта - и RTU (так как его поддержка требуется по спецификации Modbus'а) и ASCII (для связи с PC и другими не realtime железками). Это кстати пример места, где чисто текстовый протокол имеет преимущество перед бинарным при использовании в железе.

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

Кстати, по поводу текстовых и бинарных форматов и специального софта:
У меня был один проект, где PC взаимодействовал с внешней железкой. Взаимодействие происходило по RS232 или по сети (TCP), использовался бинарный формат. В процессе отладки всей системы мне ПРИШЛОСЬ в софте со стороны PC реализовать отправку в железку введенных (в виде hex дампа) пользователем пакетов, иначе было очень трудно ее (железку) отлаживать.

Эх  Еще раз. Я не призываю, полностью отказаться от текстовых протоколов и расстрелять всех, кто их реализовывал. В частных случаях они удобны. ЛИЧНО Я С ТАКИМИ ЧАСТНЫМИ СЛУЧАЯМИ НЕ ВСТРЕЧАЛСЯ . Ну не могу я себе представить, когда бы лучше было делать текстовый протокол. Я всегда находился со стороны PC и мне проще, удобнее, идеологически правильней было сделать нормальные логи, чем мучатся с реализацией текстового протокола.  То, что текстовые протоколы используются, и то, что даже HTTP - текстовый, не в ком разе не значит, что мне нравится работать с текстовыми протоколами, и что я не мог найти варианта, что бы можно было делать все-то же с бинарным. Просто уверен, что я повидал далеко не все, но фак остается фактом .

Я искренне не понимаю, что такое "ПРОИЗВОЛЬНАЯ КОМАНДА". И зачем ее посылать устройству, если оно ее все равно не поймет? 


Я имел ввиду, что спецификация модбаса создавалась для промышленных сетей, и для промышленной автоматики. И там ни разу не учитывалось, что надо будет обеспечить взаимодействие с компьютером да еще и именно из под Windows. Ибо Windows не есть реал-тайм система, и она не может использоваться в серьезных автоматических системах без специальных надстроек, которые обеспечивают псевдо-реал-тайм среду. Даже среда и протокол для модбаса называются RS485, а не RS232. Следовательно не подразумевалось никаких СТАНДАРТНЫХ РЕШЕНИЙ ДЛЯ ИХ СОПРЯЖЕНИЯ. А все что делает через переходники и пр. это есть шаманство.
То, что текстовый имеет свои особенности, и, в данном случае, может быть действительно удобнее, я не спорю. 
Но, мы делали бинарный и у нас все работало. Это все что я декларирую 


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


Не иначе, как сегодня небо упадет на землю!       


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


Могут. И даже скорее всего будут. Но у нас такого не было. У нас по проще условия были. Но, уверен, что это то же решаемо. Хотя я не представляю себе как символ может потерятся... Ну исказиться еще ладно, а потеряться... Кусок кабеля разве что с ним украдут   
Даже если пакет придет не полностью, это будет обнаружено на уровне CRC, и можно проанализировать буфер, для того, чтобы найти начало следующего. Это конечно то же шаманство, ну а как по другому? 


И что это дало? Как были цифры так и остались, только в другом представлении 


Это сообщение отредактировал(а) Felan - 17.4.2008, 14:32

Товарищи, а оно заработало!!! 
Точнее заработало пока только запись, а вот чтение не получается, он  мне постоянно показывает что буфер пустой. 
Но я вообще-то не могу даже разобраться с командой чтения 03h. В файле что я присоединил написано какой она имеет вид, и что там подразумевается под "количество запрашиваемых (передаваемых) параметров", когда я просто хочу считать текущую температуру, не понятно.

Текстовый лучше тогда, когда невозможна отладка со стороны PC. Например - твой девайс стоит на объекте, там нет ни Delphi ни вообще какого либо компилятора. Текстов твоей программы для связи с железкой тоже нет (хотя они и нафиг не нужны без компилятора). Есть только PC с последней версией управляющей программы и терминалом. Выясняется, что все вместе не работает и логов, встроенных в программу, оказалось недостаточно, что бы понять причину. Что делать? Или хотя бы для начала разобраться кто виновать - железка или программа?
Оно поймет, а вот управляющая программа на PC ее отправить не может - или она ее вообще не использует (например это команда какой нибудь диагностики), или она ее отправляет не тогда, когда хотелось бы, или до ее отправки дело не доходит (по каким либо причинам)
Это понятно, но тем не менее такая необходимость есть.
В серьезных системах Windows (равно как и не пром PC) используются исключительно как 'показометры' - они не влияют на собственно процесс. Тем не менее даже показометрам надо получать данные, и если они (данные) передаются по Modbus'у, значит надо их уметь принять.
Среда для Modbus'а может быть любая (есть даже вариант TCP/IP), и RS485 можно воткнуть в PC не как переходник из RS232, Advantech этим в частности занимается. Так что прием Modbus'а (ASCII) в Windows вполне стандартная задача и никакое не шаманство. Вот прием Modbus RTU - шаманство   Кстати есть ЖЕЛЕЗНЫЕ конверторы Modbus RTU в Modbus ASCII (ящик с 2мя портами RS232/RS485) - это стандартное решение для подключения Modbus RTU к Windows   
Из за помех в линии может не опознаться стартовый бит (остальные при этом могут быть 0), может переполнится приемное FIFO, может возникнуть ошибка при приеме символа (например Parity или Framing Error - не опознался стоповый бит, опять же из за помех) 
Как? Считать CRC всего подряд со сдвигом на 1 байт пока не совпадет? С realtime'овостью (или с тем, что от нее осталось под Windows) при таком подходе можно попрощаться   
Их мог задать ОПЕРАТОР с консоли, это собственно и есть единственное (IMHO) преимущество, которым обладает текстовый протокол. В данном случае это преимущество было реализованно на основе бинарного протокола и специальных возможностей в управляющем софте.

Cergiy, Ты бы хоть код привел. Сказал, что пользуешь, мои классы или нет. А так - ошибка в 17-ой строке 


Я не понял, почему невозможна отладка на PC? Отладка программы контроллера очень даже возможна. А отладкой управляющей программы надо было раньше заниматься 
Понятно, что ошибки могут потом всплыть, но опять же перекомпилировать ее ты же не будешь на объекте? Следовательно перекомпилят ее там где писали. Если логов встроенных в программу недостаточно то это проблема программы, надо делать достаточные логи 
Но если программа хороманогая по своей задумке, сути и реализации... то лучше ее вообще не использовать, лучше сразу терминалом 


Я не понял, что это за управляющая программа, которая реализует не все команды? Ну допустим в этом есть высокий смысл, непонятный мне. Но тогда эта программа уж точно не предназначена для отладки.
Еще раз, отладку чего ты хочешь делать т.о.? Найти ошибки в УП? Это да. Но овчинка выделки не стоит. Найти ошибки в МК? Для этого не нужен текстовый протокол. Достаточно нормального лога.


Ну в серьезных системах показометры тоже должны быть серьезными. А серьезному показометру не зазорно сделать маленький контроллер, который будет работать адаптером.
Я думаю что это будет правильно во всех смыслах.
Во например: Канал передачи - лес. Показометр - глаз. Днем все видно хорошо. Вечером хуже, но приемлемо. Ночью - нифига не видно. При полной луне что-то можно увидеть. Что бы видеть ночью используют спец. технику предназначенную специально для этого. Почему бы не использовать спец. заточенный конвертер на базе еще одного МК который будет переводить сплошной поток кадров, которые вообще передаются на конкурирующей основе, в четко разделенные последовательности с которыми можно без проблем работать PC? Это идеологически правильное решение.
А текстовый протокол это шаманство. Просто его добавили, наверно (я незнаю историю модбаса) после того, как столкнулись проблемами о которых ты говоришь.


Да понятно, что среда любая. Но мы говорим про конкретную. Вот видишь, есть железные конверторы  И это СТАНДАРТНОЕ РЕШЕНИЕ, сам сказал. Все остальное - ШАМАНСТВО. Наверняка ты даже знаешь как это происходит.... У нас было так:
Начальство придумало, что мы должны разработать. Начальство поменьше подумало и решило, что надо RS485 (ну, надо сказать, что это было оправдано), електроньщики почесали рему и сказали, что надо переходники, каждый стоит... незнаю $10 например. Начальство поменьше сказало, дороговато, поищите еще что-нибудь, а то начальство завернет. Начальство посмотрело... переобуть свой новый лексус не получится, если столько денег отвалить... Давайте ищите  варианты дешевле. Ну и вкрячили дешевый, с эхом, по $1 за переходник.
А разработчики должны тр№;ся, но сделать что б работало, причем не через полгода, а вчера.
Не знаю как там "у вас", но у нас, в частной лавочке было именно так 

Я к чему это все завел... К тому, что надо делать правильно. А правильно дорого. Вот и появляются всякие разные "дешевые" решения  Хотя, иногда, они бывают действительно удачными 


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


Ну убей меня об стенку, зачем для этого ТЕКСТОВЫЙ ПРОТОКОЛ? Ну сделал  в программе отправку любой последовательности, и все 

ЗЫЖ Вобщем, единственное, в чем я теперь стобой соглашусь полностью, это то, что текстовый протокол, который имее маркер конца кадра, позволяет избежать проблем связанных с выделение этих кадров из потока.  Если бы подобный маркер был предусмотрен в бинарном, было бы вообще счастье   

Потому что ты сидишь на объекте и на PC, который там есть ничего нет   Ни Delphi, ни сорцов, ни тулзов для програмирования МК. А оно не работает   А там, где все это есть нет самой управляемой системы и повторить эффект, который проявился на объекте не получается.
Возможна где? Ошибка проявляется там, где ее отлаживать невозможно, ну нет на объекте средств програмирования.
Поведай нам неразумным, как можно заниматься отладкой управляющей программы без объекта управления?
Именно
Именно
Достаточные - это сколько? Ты же не будешь логировать исполнение каждой строчки исходников своей программы?
Запросто. Возьмем например девайс с которого все началось. У него несколько десятков Modbus регистров, автору этой темы надо прочесть температуру - это 1 регистр. Т.е. управляющая программа будет уметь читать 1 регистр и не будет уметь читать остальные 99. Даже родная управляющая программа, идущая с прибором, не обладает всей, нужной автору функциональностью (он сам сказал), и скорее всего она тоже читает не все регистры.
С другой стороны, даже если управляющая программа и читает все регистры, она это делает по своей собственной инициативе и скорее всего невозможно заставить ее читать их так (и в том порядке) как хочет пользователь/разработчик. (Вариант с правкой сорцов и перекомпиляцией мы не рассматриваем - на объекте нет ни сорцов ни компилятора)
ТОЧНО, не предназначенна. НО ОТЛАЖИВАТЬСЯ НАДО - ибо оно не работает, вопрос - как?   
Так, еще раз, медленно и по пунктам:

•  На объекте стоит СИСТЕМА, состоящая из какой то железки и управляющей программы на PC
•  СИСТЕМА не работает, средств разработки с собой нет
•  Логов, встроенных в программу на PC не достаточно (например, если судить по логам, то все Ок)
•  Надо выяснить, кто виноват и что делать.

Например, все общения МК с PC заносятся в лог, анализ лога показал, что вроде все правильно, но МК не работает. Вдумчивое прочтение документации (или сеанс медитирования) принес предположение, что для того, что бы заработало надо добавить в определенном месте в процессе обмена с МК дополнительную команду. Варианты действий:

•  Собираем манатки, едем домой
•  вносим в сорцы УП соотвествующую правку, собираем
•  везем на объект, запускаем, убеждаемся, что не работает
•  приходим к выводу, что надо добавить еше одну команду, goto п1

или

•  Подключаемся к МК терминалом, скармливаем ему новую последовательность команд
•  убеждаемся, что не работает
•  приходим к выводу, что надо добавить еше одну команду, goto п1

Как думаешь, сколько займет времени 10 итераций по варианту 1 и по варианту 2?
Зачем, не вижу смысла в добавлении отдельной коробки, когда можно сделать без нее с теми же характеристиками. Даже лучше - отдельная коробка, это устройство, которое может сломаться, увеличение числа таких устройст уменьшает надежность всей системы.
Есть подозрение, что он появился после того, как Modbus попытались подключить к какому нибудь PLC, у которого работа с бинарными данными (не говоря уже про realtime) была сильна затруднена    (Языки програмирования PLC находятся на уровне Basic'а или даже еще ниже)
'Правильно' еще не значит 'дорого'. Решение должно удовлетворять поставленному ТЗ, если их несколько, то выбирается наиболее дешевое. В цену решения входит не только стоимость переходника, но и стоимость оплаченного рабочего времени тех, кто это все собирал в кучу (и аппаратчиков и программистов). Если на фирме рабочее время ничего не стоит, то надо искать не лучшее железо, а другое место работы   
Текстовый протокол - не самоцель. Первоначальная цель была обеспечить возможность общаться с МК ВРУЧНУЮ, не имея каких то специальных средств. Текстовый протокол это одно из возможных решений, специальные средства в управляющей программе - это альтернативное решение.
Увы я видел только 2 таких программы - одну я уже упоминал, а вторая была среда програмирования контролеров фирмы AMX (контроллеры для 'Умных домов'), она позволяла отправить любую команду любому устройству, включенному в ее сеть.
Есть такие бинарные протоколы (но не Modubs)   

Я прекрасно понимаю, что это очень реальный расклад. Но в таких случаях у нас ВСЕГДА предусматривался спец. режим для отладки.


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


Зачем каждую строчку то логировать? Достаточно писать в лог только то, что нужно. Нет в этом ничего такого страшного, а есть такой паттерн проектирования "Команда", очень он способствует всяким удобствам в разработке подобного ПО.


Блин, уел. Ладно. Просто мне, как человеку разрабатывавшему подобный софт не пришла голову простая до безобразия мысль, что у команды чтения регистра не может быть параметра, который указывает какой именно регистр надо прочитать. А так же не пришло в голову, что в целях отладки этот параметр нельзя изменить... Отсутствие отладочного режима тоже...


Ты сам не находишь сдесь противоречия? Сделать что-то,  чем-то, что для делания этого не предназначено?


Вариант 2. Еще раз, то, что по не позволят элементарно проверить свою работу, т.е. работу команд, которые оно должно выполнять, но не выполняет, это значит, что плохое ПО. Протокол здесь НИ ПРИЧЕМ! Причем здесь посторонние команды, я тоже не понимаю. Ну увидит он, что у него не читается еще и остальные 99, что это кардинально изменит?


Как не видишь смысла!? Ты же сам сказал, что сделать штатными средствами НЕВОЗМОЖНО! Да, тут выкрутились, оказалось, что есть текстовый протокол, а если бы его не было?
Как можно сделать, когда ты сам вчера говорил, что ЧИП ПОРТА И ЕГО УПРАВЛЯЮЩЕЕ ПО НЕ ПОЗВОЛЯЕТ ДЕЛАТЬ "ЭТО" В ПРИНЦИПЕ???   
Я отказываюсь понимать твою логику 


Ну вот видишь, по твоим же словам, была спецификация, налетели не грабли, под шаманили  Пусть даже и хорошо получилось, но суть остается той же.


Я так и сделал, полтора года назад. 


Вот и я про то, что не самоцель. И что реализовывать его обосновывая тем, что "читать удобнее", считаю глупостью. Если в этом есть РЕАЛЬНАЯ НЕОБХОДИМОСТЬ - да пожалуйста, сам первый и реализую .

Ладно. Я сдаюсь 

Значит ваше ПО уникальное - практически ни в одном ПО, распространяемым с железками, такого режима нет (по крайней мере мне не попадалось, за редким исключением)
Не все можно сэмулировать, соотвественно не все можно проверить   
Противоречия не нахожу. Все предусмотреть невозможно, иногда приходится обходится тем, что есть. Это не есть основной режим отладки, это отлов каких то багов в экстренных и очень редких ситуациях.
Оно выполняет и проверяет, и говорит, что произошла ошибка. Нужны не проверки в ПО а отдельный тестовый/технологический режим, позволяющий получить полный и произвольный доступ к железке.
ПО наплевать на остальные 99 - они ему не нужны. Проблема в СТЫКОВКЕ МК и ПО, разночтения в описании протоколов обмена с МК может привести к полной или частичной (что гораздо хуже) неработоспособности ПО
Можно, Modbus ASCII
Тогда и нужно было бы ставить коробку.
Консенсус   
А кто то говорил про удобство чтения?   В таком ракурсе я его не рассматривал и не собираюсь   
Иногда есть. Пример - устройство, расчитанное на полностью автономную работу, но имеющее порт для настроек и диагностики. С вероятностью 99% на объекте не окажется его управляющей программы, т.к. она там нафиг не нужна   Вероятность найти там PC с терминалом гораздо выше   


Это сообщение отредактировал(а) xvr - 18.4.2008, 13:36

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

 У меня там солянка, но вообще мне порекомендовали dll-ху и с ней все заработало очень быстро, пример кода что-то типа sio_write (3, @buf, 17), то есть пишем в COM-3 из массива buf типа char, 17 символов  На чтение из буфера примерно такая же конструкция, а значение этой функции разные, то есть, например, -1 если порт не активен, 0 если буфер пуст, если считалось не помню какое значение(сейчас нет ничего под рукой). Вобщем вот, да и дали мне код, как правильно надо LRC считать, все заработало.

Но я не могу в логике MODBUSA разобраться, сейчас процитирую. Для команд 03h либо 04h(кстати, чем они отличаются, в мануале написано что они обе для того чтобы читать несколько параметров) существует следущая форма запроса: :1 Adr 2 Fc 2 PAdr 4 PNum 4 LRC 2 CRLF 2(цифры обозначают количество байт), где 
1) Adr – сетевой адрес устройства, 2 знака
2) Fc – код функции, 2 знака
3) PAdr – адрес параметра, 4 знака
4) PNum – количество запрашиваемых (передаваемых) параметров от PAdr включительно, 4 знака
итд.

Так вот мне не понятно откуда я должен узнать PNum? Я раньше подцеплял мануал по своему прибору Термодат-17КЗ (можете посмотреть). Мне нужно считывать текущее значение температуры, то есть я адрес параметра там посмотрел - 0170h, ну а про количество параметров там ничего не сказано. То есть я вообще не понимаю о чем речь.

Может мне кто помочь?

Количество параметров - 1 (количество подряд идущих регистров)
Команды 03 и 04 отличаются набором регистров, которые они читают. 03 - Holding Registers, 04 - Input Registers. Что понимается под Holding и Input Registers определяет устройство. В вашем случае это одно и тоже. Вообще Modbus оперирует понятиями, которые давно не имеют физического соотвествия с какой либо реальной аппаратурой   Например команды 01 и 05 читают и пишут катушки (Coils), вероятно имелись в виду реле или что то подобное. В реалии обозначает выходной бит информации (действительно может быть реализованн как реле)