Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Микроконтроллеры (MCU) и микропроцессоры (MPU) > Прибор, RS-485, Modbus-ASCII

Автор: Cergiy 15.4.2008, 11:23

Приветствую всех! Из названия темы понятно что имеется: прибор, интерфейс RS-485, протокол Modbus-ASCII. Нужно например записать данные в регистр. (на самом деле много чего нужно) Но видите ли, я туповат и не догоняю. Допустим пользователь вводит число которое нужно записать (допустим это число будет 100). Я сначала должен в своей программе сформировать строчку в шестнадцатеричной системе 3A010601730064—0D0A, где 3A – начало посылки, 01 – сетевой адрес устройства, 0173 – нужный мне регистр, 0064(100d) - записываемые данные, потом должна быть контрольная сумма из 2-х символов(xxxx) о которой http://forum.vingrad.ru/forum/topic-206446.html и потом два символа конца посылки 0D и 0A (если я правильно понимаю это не 3338d, а именно 13d10d, записанные вместе). И вот, эту строчку мне надо переслать через COM-порт по RS-485, если я все правильно понимаю. И я не догоняю как это сделать. То есть как мне послать эту строчку так, чтобы прибор правильно ее обработал, ну что вот сначала пришел символ(3А) начала посылки, потом пошло «тело», а потом и 2 символа означающие конец посылки. Заранее благодарю за помощь! Я весь во внимании  (я правда не знал в каком разделе лучше это спросить)

Автор: xvr 15.4.2008, 14:03

Знатная каша    Код FILE* f=fopen("COM1","wb"); fprintf(f,":0106%04X%04X0000\r\n",0x173,100);

Автор: Cergiy 15.4.2008, 18:47

Ой, я так и думал, что написал как попало, но уж как-то лучше не получилось. Вот за код благодарю, но вот как бы етот код представить на делфи?  ИТ некоторые моменты не понятны - я с С никогда не работал. ну :0106 все понятно, а вот что дальше началось? К тому же, раз у меня этот 485 то нужно то включить RTS, потом время подождать и отключить RTS, да?! Кстате, может вы подскажите что непонятно, я по-понятнее объясню, ну чтобы и другие поняли. )

Автор: xvr 15.4.2008, 19:08

Цитата(Cergiy @ 15.4.2008,  18:47) Ой, я так и думал, что написал как попало, но уж как-то лучше не получилось. Вот за код благодарю, но вот как бы етот код представить на делфи?  Почти также - там тоже есть форматная печать, подробностей не знаю - с Делбфи не работал Цитата ИТ некоторые моменты не понятны - я с С никогда не работал. ну :0106 все понятно, а вот что дальше началось? Дальше спецификаторы формата: %04X - вывести параметр (0x173) в шестнадцатеричном виде большими буквами, использовать ровно 4 цифры, то же самое еще раз (но для следующего параметра - 100), затем вывести 4 нуля (место для CRC) Цитата К тому же, раз у меня этот 485 то нужно то включить RTS, потом время подождать и отключить RTS, да?! У PC нет RS485, есть только RS232, т.е. 485 делается через переходник, так что за подробностями что и куда включать надо обращаться к описанию этого переходника.

Автор: Cergiy 15.4.2008, 19:16

Благодарю! Хорошо, я попробую написать то что вы предложили на делфи. Там же ведь чтоб работать с ком портами пришлось искать компоненты (некогда самому писать), а там все своеобразно реализовано... Ну да ладно, если у кого есть еще какие идеи слушаю внимательно.

Автор: Felan 16.4.2008, 07:43

Цитата(xvr @  15.4.2008,  21:08 ) У PC нет RS485, есть только RS232, т.е. 485 делается через переходник, так что за подробностями что и куда включать надо обращаться к описанию этого переходника. +1 Переходники тоже разные бывают. Бывают умные, которые сами переключают RTS, а бывают, которые возвращают эхо, а ты сам уже, после прочтения эха, должен переключить RTS. Я когда-то работал с модбасом, но мы использовали бинарный протокол. И, если честно, то я считаю текстовые протоколы для работы с жезом извращением в высшей степени. Выставлять фиксированное время для установки/сброса RTS крайне не рекомендую. Даже если это и запустится, нет никаких гарантий что это будет работать через пять минут на другой машине. Следовательно, возможно, будет очень много проблем потенциально неотлавливаемых, кроме как осциллографом. Вот http://forum.sources.ru/index.php?showtopic=173025&view=findpost&p=1462984 для работы с ком-портом, котрый я когда писал, как раз для того, что бы работать модбасом. Реализация самого протокола есть, но тебе она без надобности, у тебя ASCII у нас был бинарный. По поводу контрольной суммы, не знаю, что ты имеешь ввиду под LRC, но у нас была CRC, и считалась она как CRC16. В приложении класс, которым считал я.

Автор: Felan 16.4.2008, 07:44

Кстати, если у тебя переходник с Эхом, то вот класс для отправки сообщений, который использует указанный выше класс для работы с портом.

Автор: xvr 16.4.2008, 07:56

Цитата(Felan @ 16.4.2008,  07:43) Я когда-то работал с модбасом, но мы использовали бинарный протокол. И, если честно, то я считаю текстовые протоколы для работы с жезом извращением в высшей степени. У Modbus-RTU очень жесткие времянки, на Windows бес плясок с бубном выдержать практически невозможно, так что ASCII его разновидности тоже имеют право на жизнь   Еще один плюс текстовых протоколов то, что к железке можно подключиться терминалом и пощупать ее работоспособность без специальных программ (особенно когда есть сомнения в работоспособности таких программ    ) Но в общем и целом бинарные протоколы для работы с железом выглядят предпочтительней.

Автор: Cergiy 16.4.2008, 08:08

Люди  Вот я прикрепляю файл который мне выслал производитель. Полюбуйтесь. "Не виноватая я". Добавлено @ 08:15 Но тогда я что-то не могу понять что мне делать с РС-485?!  У нас вообще виртуальный COM порт потому как подключение через USB, "переходник" АС4 фирмы "Овен".  Добавлено @ 08:18 Да и еще, есть рабочая прога от производителя которая свободно распространяется. Просто она не реализует некоторые моменты которые мне и поручили сделать, это типа, мой диплом и будет  Она вообще работает нормально, просто выбираешь COM порт и все, все опрашивается регулируется. Ну это я так, мало ли, может это что-то прояснит.

Автор: xvr 16.4.2008, 11:26

Цитата(Cergiy @ 16.4.2008,  08:08) Люди  Вот я прикрепляю файл который мне выслал производитель. Полюбуйтесь. "Не виноватая я". Нормальное описание Цитата Но тогда я что-то не могу понять что мне делать с РС-485?!  У нас вообще виртуальный COM порт потому как подключение через USB, "переходник" АС4 фирмы "Овен".  Вот на него и надо искать описание (на "переходник" АС4 фирмы "Овен")

Автор: Cergiy 16.4.2008, 12:30

Цитата(xvr @  16.4.2008,  11:26 ) Нормальное описание Не спорю, это я к тому, что, вобщем-то, ASCII не моя идея. Хотя и написано, что поддерживается и RTU.  АС4: Назначение Предназначен для взаимного преобразования сигналов интерфейсов USB и RS-485. Позволяет подключать к промышленной информационной сети RS-485 персональный компьютер, имеющий USB-порт. Основные функции     * Взаимное преобразование сигналов интерфейсов RS-485 и USB     * Автоматическое определение направления передачи данных     * Гальваническая изоляция входов     * Создание виртуального СОМ-порта при подключении прибора к ПК, что позволяет без дополнительной адаптации использовать информационные системы (SCADA, конфигураторы), работающие с аппаратным СОМ-портом     * Питание от шины USB     * Встроенные согласующие резисторы То есть я так понимаю мне о RS даже и думать не надо, а писать "как обычно"?!

Автор: xvr 16.4.2008, 13:52

Цитата АС4: Основные функции     * Взаимное преобразование сигналов интерфейсов RS-485 и USB     * Автоматическое определение направления передачи данных То есть я так понимаю мне о RS даже и думать не надо, а писать "как обычно"?! Судя по тому, что написано - да.

Автор: Felan 16.4.2008, 14:27

Цитата(xvr @  16.4.2008,  09:56 ) У Modbus-RTU очень жесткие времянки, на Windows бес плясок с бубном выдержать практически невозможно Почему нельзя? Какие именно времянки ты имеешь ввиду? Если время, когда надо дергать RTS, то это драйвер и сам может делать. А если преходник тупой, с эхом, то там вообще все четко, только надо эхо ловить. У меня все замечательно работало. Цитата(xvr @  16.4.2008,  09:56 ) так что ASCII его разновидности тоже имеют право на жизнь  По мне, так сомнительно это все  Цитата(xvr @  16.4.2008,  09:56 ) Еще один плюс текстовых протоколов то, что к железке можно подключиться терминалом и пощупать ее работоспособность без специальных программ (особенно когда есть сомнения в работоспособности таких программ   smile ) Тоже сомнительно. Когда пишешь программу, все равно делаешь отладочные логи, так что смысла в том, что бы тр№;"ся с текстом не вижу... Но это дело вкуса конечно  Цитата(xvr @  16.4.2008,  15:52 ) Судя по тому, что написано - да. +1

Автор: xvr 16.4.2008, 16:36

Цитата(Felan @ 16.4.2008,  14:27) Цитата(xvr @  16.4.2008,  09:56 ) У Modbus-RTU очень жесткие времянки, на Windows бес плясок с бубном выдержать практически невозможно Почему нельзя? Какие именно времянки ты имеешь ввиду?  Я имею в виду что в Modbus RTU используются интервалы между передачей символов в RS для разделения фреймов и прочего, причем эти интервалы относительно короткие - менее 4 символов. При приеме все еще хуже - эти интервалы придется измерять, на Windows это вообще швах    Цитата Если время, когда надо дергать RTS, то это драйвер и сам может делать.  Это кстати тоже, и драйвер (стандартный) этого не делает, более того, в железке (COM порт на PC) есть fifo на передачу и нет прерывания по освобождению собственно передатчика, так что никакой драйвер не сможет эффективно переключить RTS   (Только висеть на порту в постоянном цикле опроса) Цитата Цитата(xvr @  16.4.2008,  09:56 ) Еще один плюс текстовых протоколов то, что к железке можно подключиться терминалом и пощупать ее работоспособность без специальных программ (особенно когда есть сомнения в работоспособности таких программ   smile ) Тоже сомнительно. Когда пишешь программу, все равно делаешь отладочные логи, так что смысла в том, что бы тр№;"ся с текстом не вижу... Но это дело вкуса конечно  Логи куда? В RS порт? Или морзянкой на светодиод?

Автор: Felan 17.4.2008, 07:13

Цитата(xvr @  16.4.2008,  18:36 ) Я имею в виду что в Modbus RTU используются интервалы между передачей символов в RS для разделения фреймов и прочего, причем эти интервалы относительно короткие - менее 4 символов. При приеме все еще хуже - эти интервалы придется измерять, на Windows это вообще швах  smile  Не знаю, как там у вас, но вот у нас интервалы между символами выставлялись в настройках драйвера. И были они стабильные и четкие. Т.к. после того, как в буфер драйвера данные положены, драйвер сам их отправляет. И следит за этими интервалами. И все  хорошо и замечательно работает. При приеме тоже самое. Цитата(xvr @  16.4.2008,  18:36 ) Это кстати тоже, и драйвер (стандартный) этого не делает, более того, в железке (COM порт на PC) есть fifo на передачу и нет прерывания по освобождению собственно передатчика, так что никакой драйвер не сможет эффективно переключить RTS  smile (Только висеть на порту в постоянном цикле опроса) Это, он, драйвер, кстати делает. Просто его надо настроить. А если это делалось на делфи, так там ошибка в константах. Их надо ручками из MSDN взять. Покрайней мере у нас сам драйвер очень даже правильно дергал сигнал. Сам, после того, как все уйдет именно из буфера... Я вот только точно не помню, какой именно мы делали, то ли RTS, толи DTR. Я к тому времени уже увольнялся. Цитата(xvr @  16.4.2008,  18:36 ) Логи куда? В RS порт? Или морзянкой на светодиод?  Хм... пять раз прочитал эту фразу... Сначала думал - шутка юмора... Потом подумал, что издеваешься... Потом вспомнил, что в эту тему попал через другую... Посмотрел раздел, где она находится.... Блин.  Все, что я здесь писал, я писал с точки зрения программиста на делфи, который пишет программу для компьютера, которая работает с контроллером.    Из первого поста мне показалось, что надо именно это. Тут всегда есть куда лог писать  Так что извиняюсь, если мимо тазика

Автор: xvr 17.4.2008, 07:59

Цитата(Felan @ 17.4.2008,  07:13) Цитата(xvr @  16.4.2008,  18:36 ) Я имею в виду что в Modbus RTU используются интервалы между передачей символов в RS для разделения фреймов и прочего, причем эти интервалы относительно короткие - менее 4 символов. При приеме все еще хуже - эти интервалы придется измерять, на Windows это вообще швах  smile  Не знаю, как там у вас, но вот у нас интервалы между символами выставлялись в настройках драйвера.  Да ну? И где же они выставляются? Особено интересует как сделать паузу в 3 символа при передаче. Цитата И были они стабильные и четкие. Т.к. после того, как в буфер драйвера данные положены, драйвер сам их отправляет. И следит за этими интервалами. И все  хорошо и замечательно работает. Ни за чем он не следит. Цитата При приеме тоже самое. Код в студию   На эту тему было сломанно МАССА копий, сошлись на мнении, что это НЕВОЗМОЖНО. SetCommTimeouts НЕ ГАРАНТИРУЕТ ТОЧНОГО отслеживания интервалов при приеме, так что отловить интервал в 3 символа при приеме НЕВОЗМОЖНО. То, что у вас оно работало это еще ничего не значит, вам просто сильно повезло - фреймы шли отдельно друг от друга, поток фреймов ваша реализация не отловила бы.  Цитата Цитата(xvr @  16.4.2008,  18:36 ) Это кстати тоже, и драйвер (стандартный) этого не делает, более того, в железке (COM порт на PC) есть fifo на передачу и нет прерывания по освобождению собственно передатчика, так что никакой драйвер не сможет эффективно переключить RTS  smile (Только висеть на порту в постоянном цикле опроса) Это, он, драйвер, кстати делает. Просто его надо настроить.  Он (дравер) лезет с паяльником в компьютер и меняет чип RS232 передатчика? Или он обладает искуственным интелектом и умеет угадывать что происходит в железе, которое само этого сказать не умеет? Цитата А если это делалось на делфи, так там ошибка в константах. Их надо ручками из MSDN взять.  Это делалось на всем, чем только можно, вплоть до ассемблера в Windows драйвере. Цитата Покрайней мере у нас сам драйвер очень даже правильно дергал сигнал. Сам, после того, как все уйдет именно из буфера...  Угу, еще раз повторю - вам повезло. Есть масса народу, у которого этот самый драйвер переключал направление передачи ДО того, как последний символ уходил в линию. Цитата Я вот только точно не помню, какой именно мы делали, то ли RTS, толи DTR. Я к тому времени уже увольнялся. Замечательно - 'оно работало и делало все, что надо, вот только не помню что '   PS. По поводу Modbus RTU был очень длинный топик на electronix.ru (не могу дать ссылку - он сейчас лежит)

Автор: Felan 17.4.2008, 11:16

Цитата(xvr @  17.4.2008,  09:59 ) Ни за чем он не следит. В MSDN написано, что эти таймауты выставить можно. Оснований недоверять MSDN у меня нет. Я ставил. Это работало. Цитата(xvr @  17.4.2008,  09:59 ) Код в студию  smile На эту тему было сломанно МАССА копий, сошлись на мнении, что это НЕВОЗМОЖНО. SetCommTimeouts НЕ ГАРАНТИРУЕТ ТОЧНОГО отслеживания интервалов при приеме, так что отловить интервал в 3 символа при приеме НЕВОЗМОЖНО. То, что у вас оно работало это еще ничего не значит, вам просто сильно повезло - фреймы шли отдельно друг от друга, поток фреймов ваша реализация не отловила бы.  Какой код? Функция SetCommTimeouts. Вот и весь код. Я незнаю, что она там гарантирует (кстати, Windows не является системой реального времени, так что требовать от нее гарантий соблюдения каких-либо временных интервалов вообще, мягко говоря, некорректно), но то, что ReadFile возвращала управление если они не соблюдались, это было. А по поводу мониторинга среды, что бы выделить из нее пакет, это я не знаю как сделать... возможно на событиях можно.... которые драйвер САМ возбуждает. Но я не знаю. У нас работа была только с одним устройством одновременно. Фреймы действительно шли отдельно. Но это не умаляет того, что таймауты выдерживались. Код я уже давал. Работало все с тем классом, ссылку на который я давал. Цитата(xvr @  17.4.2008,  09:59 ) Он (дравер) лезет с паяльником в компьютер и меняет чип RS232 передатчика? Или он обладает искуственным интелектом и умеет угадывать что происходит в железе, которое само этого сказать не умеет? Незнаю, причем тут паяльник, ничего не понимаю в чипах и паяльниках. Но в MSDN написано, что драйвер может автоматически устанавливать(или сбрасывать я точно не понмю, помню, что проблемы были в том, что драйвер мог только одно делать, а у нас переходники были на другое настроены. Пришлось электронщикам переходник перепаять, что бы там наоборот было). Цитата(xvr @  17.4.2008,  09:59 ) Это делалось на всем, чем только можно, вплоть до ассемблера в Windows драйвере. А что именно вы пытались сделать? Как я понял, хотели отлавливать кадры по таймингам? Этого сделать скорее всего не получится. Только если использовать, как я уже гвоорил, события. И то, я не знаю, будет ли это работать. А в общем случае, компорт не предназначен для того, что бы анализировать среду. Если я прав, и вы хотели сделать именно это, все понятно. Молтком сложно вскапать огород. Цитата(xvr @  17.4.2008,  09:59 ) Угу, еще раз повторю - вам повезло. Есть масса народу, у которого этот самый драйвер переключал направление передачи ДО того, как последний символ уходил в линию. Сложно тут что-то ответить. Есть вообще масса разного народа. Я говорю за себя. В нашем частном случае, когда пакеты шли поочереди и на шине было только одно устройство все работало прекрасно. Цитата(xvr @  17.4.2008,  09:59 ) Замечательно - 'оно работало и делало все, что надо, вот только не помню что ' smile  PS. По поводу Modbus RTU был очень длинный топик на electronix.ru (не могу дать ссылку - он сейчас лежит) Потому что давно было, потому и плохо помню. Еще раз. Было организовано взаимодействие одного устройства на базе МК и компьютера через RS485, с использованием переходника RS232<>RS485, который возвращал эхо. После этого, было обнаружено, что в делфи неправильно объявлены константы для настройки драйвера порта. Константы управлением DTR/RTS были исправлены и драйвер настроен так, что бы сигнал (DTR или RTS я сейчас не помню, который именно использовали наши электронщики) изменял свое состояние в зависимости от наличия/отсутсвия байт в буфере порта. Смотрели на осциллографе. Все работало. Ссылку не надо, т.к. давно этим не занимаюсь. Просто хотел поделиться тем, что когда-то делал. И у меня, допускаю что по странному везению , это работало.

Автор: xvr 17.4.2008, 11:40

Цитата(Felan @ 17.4.2008,  11:16) Цитата(xvr @  17.4.2008,  09:59 ) Ни за чем он не следит. В MSDN написано, что эти таймауты выставить можно. Оснований недоверять MSDN у меня нет. Я ставил. Это работало. То, что написано в MSDN не может поменять АППАРАТУРУ в компьютере. Эта АППАРАТУРА не позволяет отлавливать timeout'ы на уровне отдельных символов в входном и выходном потоке. Любой timeout, поставленный через SetCommTimeouts будет округлен в большую сторону до величины тика системного таймера. MSDN по этому поводу молчит. Цитата Цитата(xvr @  17.4.2008,  09:59 ) Код в студию  smile На эту тему было сломанно МАССА копий, сошлись на мнении, что это НЕВОЗМОЖНО. SetCommTimeouts НЕ ГАРАНТИРУЕТ ТОЧНОГО отслеживания интервалов при приеме, так что отловить интервал в 3 символа при приеме НЕВОЗМОЖНО. То, что у вас оно работало это еще ничего не значит, вам просто сильно повезло - фреймы шли отдельно друг от друга, поток фреймов ваша реализация не отловила бы.  Какой код? Функция SetCommTimeouts. Вот и весь код. Этого недостаточно. Цитата Я незнаю, что она там гарантирует (кстати, Windows не является системой реального времени, так что требовать от нее гарантий соблюдения каких-либо временных интервалов вообще, мягко говоря, некорректно),  Угу, а полная реализация Modbus RTU этого требует, увы. Так что Windows здесь не подходит вообще, что и требовалось доказать. Цитата но то, что ReadFile возвращала управление если они не соблюдались, это было. Вы это проверяли? И именно на интервалах в 2-3 символа? 'Не верю!' (Станиславский) Цитата Фреймы действительно шли отдельно. Но это не умаляет того, что таймауты выдерживались. Код я уже давал. Работало все с тем классом, ссылку на который я давал. Вот! Т.е. это не было полноценным Modbus RTU, а было его обрезком с отдельными фреймами и без контроля за межсимвольными интервалами (по стандарту они не могут быть более 1.5 символа). Цитата Цитата(xvr @  17.4.2008,  09:59 ) Он (дравер) лезет с паяльником в компьютер и меняет чип RS232 передатчика? Или он обладает искуственным интелектом и умеет угадывать что происходит в железе, которое само этого сказать не умеет? Незнаю, причем тут паяльник, ничего не понимаю в чипах и паяльниках.  Вот с этого и надо было начинать. Цитата Но в MSDN написано, что драйвер может автоматически устанавливать(или сбрасывать я точно не понмю, помню, что проблемы были в том, что драйвер мог только одно делать, а у нас переходники были на другое настроены. Пришлось электронщикам переходник перепаять, что бы там наоборот было). На заборе тоже было написано ... Драйвер может устанавливать RTS по факту передачи, однако частенько он его сбрасывает не дожидаясь отправки последнего символа в линию, это факт и по этим граблям уже ходило немалое количество народа. Это не значит, что ВСЕ драйвера на ВСЕХ компьютерах ведут себя так, но такие тоже есть. Цитата Цитата(xvr @  17.4.2008,  09:59 ) Это делалось на всем, чем только можно, вплоть до ассемблера в Windows драйвере. А что именно вы пытались сделать? Как я понял, хотели отлавливать кадры по таймингам?  Да Цитата Этого сделать скорее всего не получится.  Именно, а стандарт Modbus RTU этого требует Цитата Сложно тут что-то ответить. Есть вообще масса разного народа. Я говорю за себя. В нашем частном случае, когда пакеты шли поочереди и на шине было только одно устройство все работало прекрасно. Именно - 'в нашем частном случае' Собственно зачем я весь этот разговор завел. Это касалось вашего заявления, что Modbus ASCII нафиг не нужен, а везде вместо него имеет смысл применять Modbus RTU. Я заявляю, что ПОЛНОЦЕННЫЙ (полностью соотвествующий стандарту) Modbus RTU на ЛЮБОЙ PC без специальной дополнительной аппаратурой реализовать НЕВОЗМОЖНО. В отличии от Modbus ASCII, который реализовать МОЖНО.

Автор: Felan 17.4.2008, 12:36

Цитата(xvr @  17.4.2008,  13:40 ) Собственно зачем я весь этот разговор завел. Это касалось вашего заявления, что Modbus ASCII нафиг не нужен, а везде вместо него имеет смысл применять Modbus RTU. Я не говорил такого. Я сказал: Цитата(xvr @  16.4.2008,  09:56 ) И, если честно, то я считаю текстовые протоколы для работы с жезом извращением в высшей степени. И вы меня в этом не разубедили. То, что текстовые протоколы в частных случаях бывают полезны, я не отрицаю. Здесь же все исключительно ИМХО. Цитата(xvr @  17.4.2008,  13:40 ) Именно, а стандарт Modbus RTU этого требует Требует. Но он писан для взаимодействия MK<>MK. А для PC надо использовать другие методы. Наш метод, в нашем частном случае работал и не знал проблем. Цитата(xvr @  17.4.2008,  13:40 ) Вы это проверяли? И именно на интервалах в 2-3 символа? 'Не верю!' (Станиславский) Нет, настолько досконально я не проверял. Не было нужды, т.к. все работало. Цитата(xvr @  17.4.2008,  13:40 ) Вот! Т.е. это не было полноценным Modbus RTU, а было его обрезком с отдельными фреймами и без контроля за межсимвольными интервалами (по стандарту они не могут быть более 1.5 символа). Я нигде не говорил, что реализовал полноценный MUDBU RTU, да еще и дословно по спецификации. Я сказал, что было сделано так-то и так-то и это работало. Цитата(xvr @  17.4.2008,  13:40 ) На заборе тоже было написано ... Драйвер может устанавливать RTS по факту передачи, однако частенько он его сбрасывает не дожидаясь отправки последнего символа в линию, это факт и по этим граблям уже ходило немалое количество народа. Это не значит, что ВСЕ драйвера на ВСЕХ компьютерах ведут себя так, но такие тоже есть. Справедливо. Особенно для разных осей... У нас все это работало только под XP. У XP наверно везде один драйвер порта... во всяком случае я не слышал, что кому-то пришло в голову его поменять. Но может быть и разный. Цитата(xvr @  17.4.2008,  13:40 ) Вот с этого и надо было начинать. С чего? С того, что я не электронщик? Я нигде этого не говорил. Цитата(xvr @  17.4.2008,  13:40 ) Я заявляю, что ПОЛНОЦЕННЫЙ (полностью соотвествующий стандарту) Modbus RTU на ЛЮБОЙ PC без специальной дополнительной аппаратурой реализовать НЕВОЗМОЖНО Полностью согласен. Еще раз. Спецификация MODBUS писана для MK<>MK. Для PC нужно использовать ДРУГИЕ МЕХАНИЗМЫ. Тем более, что в данном конкретном случае кадры как два пальца определяются по размеру. По крайней мере я лично их определял именно так. И все было хорошо.

Автор: xvr 17.4.2008, 13:14

Цитата(Felan @ 17.4.2008,  12:36) Цитата(xvr @  17.4.2008,  13:40 ) Собственно зачем я весь этот разговор завел. Это касалось вашего заявления, что Modbus ASCII нафиг не нужен, а везде вместо него имеет смысл применять Modbus RTU. Я не говорил такого. Я сказал: Цитата(xvr @  16.4.2008,  09:56 ) И, если честно, то я считаю текстовые протоколы для работы с жезом извращением в высшей степени. И вы меня в этом не разубедили. То, что текстовые протоколы в частных случаях бывают полезны, я не отрицаю. Здесь же все исключительно ИМХО. Ок. Если под железом понимается связь 2х и более спец. устройств, то полностью согласен. Если же это железо собирается подключаться к PC, то текстовый формат обмена может быть полезен (правда при условии, что его можно использовать с обычного терминала, без ручного подсчета всяких контрольных сумм и пр). И довольно много железок используют такой формат (например вся продукция фирмы Extron). Некоторые железки используют оба формата, например видеокоммутатор от системы видеонаблюдения фирмы Philips использует текстовые команды для управления (они документированны) и отдельный бинарный протокол (недокументированный) для обмена со своим софтом на PC. С другой стороны текстовые протоколы более трудоемки для реализации в железе и обычно на это идут неохотно    Текстовый протокол позволяет посылать железке ПРОИЗВОЛЬНЫЕ команды из обычного терминала не имея специального софта, тем более что обычно в таком специальном софте не предусматривается возможность отослать железке ПРОИЗВОЛЬНУЮ команду. Цитата Цитата(xvr @  17.4.2008,  13:40 ) Именно, а стандарт Modbus RTU этого требует Требует. Но он писан для взаимодействия MK<>MK. Он описан безотносительно к тому, кто с кем будет взаимодействовать. И МК тоже не знает с кем ему придется взаимодействовать по Modbus'у - с другим МК или с PC. Так что производители аппаратуры обычно поддерживают оба стандарта - и RTU (так как его поддержка требуется по спецификации Modbus'а) и ASCII (для связи с PC и другими не realtime железками). Это кстати пример места, где чисто текстовый протокол имеет преимущество перед бинарным при использовании в железе. Цитата Цитата(xvr @  17.4.2008,  13:40 ) На заборе тоже было написано ... Драйвер может устанавливать RTS по факту передачи, однако частенько он его сбрасывает не дожидаясь отправки последнего символа в линию, это факт и по этим граблям уже ходило немалое количество народа. Это не значит, что ВСЕ драйвера на ВСЕХ компьютерах ведут себя так, но такие тоже есть. Справедливо. Особенно для разных осей... У нас все это работало только под XP. У XP наверно везде один драйвер порта... во всяком случае я не слышал, что кому-то пришло в голову его поменять. Но может быть и разный. Могут быть разные порты, например отдельная многоканальная PCI плата с портами Цитата Цитата(xvr @  17.4.2008,  13:40 ) Я заявляю, что ПОЛНОЦЕННЫЙ (полностью соотвествующий стандарту) Modbus RTU на ЛЮБОЙ PC без специальной дополнительной аппаратурой реализовать НЕВОЗМОЖНО Полностью согласен.  Консенсус    Цитата Спецификация MODBUS писана для MK<>MK. Для PC нужно использовать ДРУГИЕ МЕХАНИЗМЫ. Было бы здорово, но не всегда возможно    Цитата Тем более, что в данном конкретном случае кадры как два пальца определяются по размеру. Могут быть проблемы с кадровой синхронизацией, если пакеты идут часто и символы в линии иногда теряются. Кстати, по поводу текстовых и бинарных форматов и специального софта: У меня был один проект, где PC взаимодействовал с внешней железкой. Взаимодействие происходило по RS232 или по сети (TCP), использовался бинарный формат. В процессе отладки всей системы мне ПРИШЛОСЬ в софте со стороны PC реализовать отправку в железку введенных (в виде hex дампа) пользователем пакетов, иначе было очень трудно ее (железку) отлаживать.

Автор: Felan 17.4.2008, 14:29

Цитата(xvr @  17.4.2008,  15:14 ) Ок. Если под железом понимается связь 2х и более спец. устройств, то полностью согласен. Если же это железо собирается подключаться к PC, то текстовый формат обмена может быть полезен (правда при условии, что его можно использовать с обычного терминала, без ручного подсчета всяких контрольных сумм и пр). И довольно много железок используют такой формат (например вся продукция фирмы Extron). Некоторые железки используют оба формата, например видеокоммутатор от системы видеонаблюдения фирмы Philips использует текстовые команды для управления (они документированны) и отдельный бинарный протокол (недокументированный) для обмена со своим софтом на PC. С другой стороны текстовые протоколы более трудоемки для реализации в железе и обычно на это идут неохотно  smile  Текстовый протокол позволяет посылать железке ПРОИЗВОЛЬНЫЕ команды из обычного терминала не имея специального софта, тем более что обычно в таком специальном софте не предусматривается возможность отослать железке ПРОИЗВОЛЬНУЮ команду. Эх  Еще раз. Я не призываю, полностью отказаться от текстовых протоколов и расстрелять всех, кто их реализовывал. В частных случаях они удобны. ЛИЧНО Я С ТАКИМИ ЧАСТНЫМИ СЛУЧАЯМИ НЕ ВСТРЕЧАЛСЯ . Ну не могу я себе представить, когда бы лучше было делать текстовый протокол. Я всегда находился со стороны PC и мне проще, удобнее, идеологически правильней было сделать нормальные логи, чем мучатся с реализацией текстового протокола.  То, что текстовые протоколы используются, и то, что даже HTTP - текстовый, не в ком разе не значит, что мне нравится работать с текстовыми протоколами, и что я не мог найти варианта, что бы можно было делать все-то же с бинарным. Просто уверен, что я повидал далеко не все, но фак остается фактом . Я искренне не понимаю, что такое "ПРОИЗВОЛЬНАЯ КОМАНДА". И зачем ее посылать устройству, если оно ее все равно не поймет?  Цитата(xvr @  17.4.2008,  15:14 ) Он описан безотносительно к тому, кто с кем будет взаимодействовать. И МК тоже не знает с кем ему придется взаимодействовать по Modbus'у - с другим МК или с PC. Так что производители аппаратуры обычно поддерживают оба стандарта - и RTU (так как его поддержка требуется по спецификации Modbus'а) и ASCII (для связи с PC и другими не realtime железками). Это кстати пример места, где чисто текстовый протокол имеет преимущество перед бинарным при использовании в железе. Я имел ввиду, что спецификация модбаса создавалась для промышленных сетей, и для промышленной автоматики. И там ни разу не учитывалось, что надо будет обеспечить взаимодействие с компьютером да еще и именно из под Windows. Ибо Windows не есть реал-тайм система, и она не может использоваться в серьезных автоматических системах без специальных надстроек, которые обеспечивают псевдо-реал-тайм среду. Даже среда и протокол для модбаса называются RS485, а не RS232. Следовательно не подразумевалось никаких СТАНДАРТНЫХ РЕШЕНИЙ ДЛЯ ИХ СОПРЯЖЕНИЯ. А все что делает через переходники и пр. это есть шаманство. То, что текстовый имеет свои особенности, и, в данном случае, может быть действительно удобнее, я не спорю.  Но, мы делали бинарный и у нас все работало. Это все что я декларирую  Цитата(xvr @  17.4.2008,  15:14 ) Могут быть разные порты, например отдельная многоканальная PCI плата с портами Могут. Но они все равно должны обеспечивать работу драйвера и его спецификацию. Наверняка, что есть случаи, когда это не так, и ты прав. Я с ними не встречался  Цитата(xvr @  17.4.2008,  15:14 ) Консенсус  smile  Не иначе, как сегодня небо упадет на землю!        Цитата(xvr @  17.4.2008,  15:14 ) Было бы здорово, но не всегда возможно Понятное дело. Просто мне кажется что это надо понимать, и учитывать при проектировании системы изначально. Цитата(xvr @  17.4.2008,  15:14 ) Могут быть проблемы с кадровой синхронизацией, если пакеты идут часто и символы в линии иногда теряются. Могут. И даже скорее всего будут. Но у нас такого не было. У нас по проще условия были. Но, уверен, что это то же решаемо. Хотя я не представляю себе как символ может потерятся... Ну исказиться еще ладно, а потеряться... Кусок кабеля разве что с ним украдут    Даже если пакет придет не полностью, это будет обнаружено на уровне CRC, и можно проанализировать буфер, для того, чтобы найти начало следующего. Это конечно то же шаманство, ну а как по другому?  Цитата(xvr @  17.4.2008,  15:14 ) У меня был один проект, где PC взаимодействовал с внешней железкой. Взаимодействие происходило по RS232 или по сети (TCP), использовался бинарный формат. В процессе отладки всей системы мне ПРИШЛОСЬ в софте со стороны PC реализовать отправку в железку введенных (в виде hex дампа) пользователем пакетов, иначе было очень трудно ее (железку) отлаживать. И что это дало? Как были цифры так и остались, только в другом представлении

Автор: Cergiy 17.4.2008, 15:26

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

Автор: xvr 17.4.2008, 16:27

Цитата(Felan @ 17.4.2008,  14:29) Эх  Еще раз. Я не призываю, полностью отказаться от текстовых протоколов и расстрелять всех, кто их реализовывал. В частных случаях они удобны. ЛИЧНО Я С ТАКИМИ ЧАСТНЫМИ СЛУЧАЯМИ НЕ ВСТРЕЧАЛСЯ . Ну не могу я себе представить, когда бы лучше было делать текстовый протокол. Я всегда находился со стороны PC и мне проще, удобнее, идеологически правильней было сделать нормальные логи, чем мучатся с реализацией текстового протокола.   Текстовый лучше тогда, когда невозможна отладка со стороны PC. Например - твой девайс стоит на объекте, там нет ни Delphi ни вообще какого либо компилятора. Текстов твоей программы для связи с железкой тоже нет (хотя они и нафиг не нужны без компилятора). Есть только PC с последней версией управляющей программы и терминалом. Выясняется, что все вместе не работает и логов, встроенных в программу, оказалось недостаточно, что бы понять причину. Что делать? Или хотя бы для начала разобраться кто виновать - железка или программа? Цитата Я искренне не понимаю, что такое "ПРОИЗВОЛЬНАЯ КОМАНДА". И зачем ее посылать устройству, если оно ее все равно не поймет?  Оно поймет, а вот управляющая программа на PC ее отправить не может - или она ее вообще не использует (например это команда какой нибудь диагностики), или она ее отправляет не тогда, когда хотелось бы, или до ее отправки дело не доходит (по каким либо причинам) Цитата Я имел ввиду, что спецификация модбаса создавалась для промышленных сетей, и для промышленной автоматики. И там ни разу не учитывалось, что надо будет обеспечить взаимодействие с компьютером да еще и именно из под Windows.  Это понятно, но тем не менее такая необходимость есть. Цитата Ибо Windows не есть реал-тайм система, и она не может использоваться в серьезных автоматических системах без специальных надстроек, которые обеспечивают псевдо-реал-тайм среду.  В серьезных системах Windows (равно как и не пром PC) используются исключительно как 'показометры' - они не влияют на собственно процесс. Тем не менее даже показометрам надо получать данные, и если они (данные) передаются по Modbus'у, значит надо их уметь принять. Цитата Даже среда и протокол для модбаса называются RS485, а не RS232. Следовательно не подразумевалось никаких СТАНДАРТНЫХ РЕШЕНИЙ ДЛЯ ИХ СОПРЯЖЕНИЯ. А все что делает через переходники и пр. это есть шаманство. Среда для 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, и можно проанализировать буфер, для того, чтобы найти начало следующего. Как? Считать CRC всего подряд со сдвигом на 1 байт пока не совпадет? С realtime'овостью (или с тем, что от нее осталось под Windows) при таком подходе можно попрощаться    Цитата Цитата(xvr @  17.4.2008,  15:14 ) У меня был один проект, где PC взаимодействовал с внешней железкой. Взаимодействие происходило по RS232 или по сети (TCP), использовался бинарный формат. В процессе отладки всей системы мне ПРИШЛОСЬ в софте со стороны PC реализовать отправку в железку введенных (в виде hex дампа) пользователем пакетов, иначе было очень трудно ее (железку) отлаживать. И что это дало? Как были цифры так и остались, только в другом представлении  Их мог задать ОПЕРАТОР с консоли, это собственно и есть единственное (IMHO) преимущество, которым обладает текстовый протокол. В данном случае это преимущество было реализованно на основе бинарного протокола и специальных возможностей в управляющем софте.

Автор: Felan 18.4.2008, 07:59

Cergiy, Ты бы хоть код привел. Сказал, что пользуешь, мои классы или нет. А так - ошибка в 17-ой строке  Цитата(xvr @  17.4.2008,  18:27 ) Текстовый лучше тогда, когда невозможна отладка со стороны PC. Например - твой девайс стоит на объекте, там нет ни Delphi ни вообще какого либо компилятора. Текстов твоей программы для связи с железкой тоже нет (хотя они и нафиг не нужны без компилятора). Есть только PC с последней версией управляющей программы и терминалом. Выясняется, что все вместе не работает и логов, встроенных в программу, оказалось недостаточно, что бы понять причину. Что делать? Или хотя бы для начала разобраться кто виновать - железка или программа? Я не понял, почему невозможна отладка на PC? Отладка программы контроллера очень даже возможна. А отладкой управляющей программы надо было раньше заниматься  Понятно, что ошибки могут потом всплыть, но опять же перекомпилировать ее ты же не будешь на объекте? Следовательно перекомпилят ее там где писали. Если логов встроенных в программу недостаточно то это проблема программы, надо делать достаточные логи  Но если программа хороманогая по своей задумке, сути и реализации... то лучше ее вообще не использовать, лучше сразу терминалом  Цитата(xvr @  17.4.2008,  18:27 ) Оно поймет, а вот управляющая программа на PC ее отправить не может - или она ее вообще не использует (например это команда какой нибудь диагностики), или она ее отправляет не тогда, когда хотелось бы, или до ее отправки дело не доходит (по каким либо причинам) Я не понял, что это за управляющая программа, которая реализует не все команды? Ну допустим в этом есть высокий смысл, непонятный мне. Но тогда эта программа уж точно не предназначена для отладки. Еще раз, отладку чего ты хочешь делать т.о.? Найти ошибки в УП? Это да. Но овчинка выделки не стоит. Найти ошибки в МК? Для этого не нужен текстовый протокол. Достаточно нормального лога. Цитата(xvr @  17.4.2008,  18:27 ) В серьезных системах Windows (равно как и не пром PC) используются исключительно как 'показометры' - они не влияют на собственно процесс. Тем не менее даже показометрам надо получать данные, и если они (данные) передаются по Modbus'у, значит надо их уметь принять. Ну в серьезных системах показометры тоже должны быть серьезными. А серьезному показометру не зазорно сделать маленький контроллер, который будет работать адаптером. Я думаю что это будет правильно во всех смыслах. Во например: Канал передачи - лес. Показометр - глаз. Днем все видно хорошо. Вечером хуже, но приемлемо. Ночью - нифига не видно. При полной луне что-то можно увидеть. Что бы видеть ночью используют спец. технику предназначенную специально для этого. Почему бы не использовать спец. заточенный конвертер на базе еще одного МК который будет переводить сплошной поток кадров, которые вообще передаются на конкурирующей основе, в четко разделенные последовательности с которыми можно без проблем работать PC? Это идеологически правильное решение. А текстовый протокол это шаманство. Просто его добавили, наверно (я незнаю историю модбаса) после того, как столкнулись проблемами о которых ты говоришь. Цитата(xvr @  17.4.2008,  18:27 ) Среда для Modbus'а может быть любая (есть даже вариант TCP/IP), и RS485 можно воткнуть в PC не как переходник из RS232, Advantech этим в частности занимается. Так что прием Modbus'а (ASCII) в Windows вполне стандартная задача и никакое не шаманство. Вот прием Modbus RTU - шаманство  smile Кстати есть ЖЕЛЕЗНЫЕ конверторы Modbus RTU в Modbus ASCII (ящик с 2мя портами RS232/RS485) - это стандартное решение для подключения Modbus RTU к Windows  smile  Да понятно, что среда любая. Но мы говорим про конкретную. Вот видишь, есть железные конверторы  И это СТАНДАРТНОЕ РЕШЕНИЕ, сам сказал. Все остальное - ШАМАНСТВО. Наверняка ты даже знаешь как это происходит.... У нас было так: Начальство придумало, что мы должны разработать. Начальство поменьше подумало и решило, что надо RS485 (ну, надо сказать, что это было оправдано), електроньщики почесали рему и сказали, что надо переходники, каждый стоит... незнаю $10 например. Начальство поменьше сказало, дороговато, поищите еще что-нибудь, а то начальство завернет. Начальство посмотрело... переобуть свой новый лексус не получится, если столько денег отвалить... Давайте ищите  варианты дешевле. Ну и вкрячили дешевый, с эхом, по $1 за переходник. А разработчики должны тр№;ся, но сделать что б работало, причем не через полгода, а вчера. Не знаю как там "у вас", но у нас, в частной лавочке было именно так  Я к чему это все завел... К тому, что надо делать правильно. А правильно дорого. Вот и появляются всякие разные "дешевые" решения  Хотя, иногда, они бывают действительно удачными  Цитата(xvr @  17.4.2008,  18:27 ) Как? Считать CRC всего подряд со сдвигом на 1 байт пока не совпадет? С realtime'овостью (или с тем, что от нее осталось под Windows) при таком подходе можно попрощаться  smile  Наверно да.... С ходу ничего в голову не приходит. А то, что попрощаться, это безусловно  Но, подобную фигню, мне кажется, можно реализовать на эвентах. Можно пробовать... Если кто-нибудь нормально профинансировал бы, я бы может попробовал, в свободное от работы время поковыряться  Цитата(xvr @  17.4.2008,  18:27 ) Их мог задать ОПЕРАТОР с консоли, это собственно и есть единственное (IMHO) преимущество, которым обладает текстовый протокол. В данном случае это преимущество было реализованно на основе бинарного протокола и специальных возможностей в управляющем софте.  Ну убей меня об стенку, зачем для этого ТЕКСТОВЫЙ ПРОТОКОЛ? Ну сделал  в программе отправку любой последовательности, и все  ЗЫЖ Вобщем, единственное, в чем я теперь стобой соглашусь полностью, это то, что текстовый протокол, который имее маркер конца кадра, позволяет избежать проблем связанных с выделение этих кадров из потока.  Если бы подобный маркер был предусмотрен в бинарном, было бы вообще счастье

Автор: xvr 18.4.2008, 10:54

Цитата(Felan @ 18.4.2008,  07:59) Я не понял, почему невозможна отладка на PC? Потому что ты сидишь на объекте и на PC, который там есть ничего нет   Ни Delphi, ни сорцов, ни тулзов для програмирования МК. А оно не работает   А там, где все это есть нет самой управляемой системы и повторить эффект, который проявился на объекте не получается. Цитата Отладка программы контроллера очень даже возможна.  Возможна где? Ошибка проявляется там, где ее отлаживать невозможно, ну нет на объекте средств програмирования. Цитата А отладкой управляющей программы надо было раньше заниматься  Поведай нам неразумным, как можно заниматься отладкой управляющей программы без объекта управления? Цитата Понятно, что ошибки могут потом всплыть, но опять же перекомпилировать ее ты же не будешь на объекте?  Именно Цитата Следовательно перекомпилят ее там где писали.  Именно Цитата Если логов встроенных в программу недостаточно то это проблема программы, надо делать достаточные логи  Достаточные - это сколько? Ты же не будешь логировать исполнение каждой строчки исходников своей программы? Цитата Я не понял, что это за управляющая программа, которая реализует не все команды? Запросто. Возьмем например девайс с которого все началось. У него несколько десятков Modbus регистров, автору этой темы надо прочесть температуру - это 1 регистр. Т.е. управляющая программа будет уметь читать 1 регистр и не будет уметь читать остальные 99. Даже родная управляющая программа, идущая с прибором, не обладает всей, нужной автору функциональностью (он сам сказал), и скорее всего она тоже читает не все регистры. С другой стороны, даже если управляющая программа и читает все регистры, она это делает по своей собственной инициативе и скорее всего невозможно заставить ее читать их так (и в том порядке) как хочет пользователь/разработчик. (Вариант с правкой сорцов и перекомпиляцией мы не рассматриваем - на объекте нет ни сорцов ни компилятора) Цитата Ну допустим в этом есть высокий смысл, непонятный мне. Но тогда эта программа уж точно не предназначена для отладки. ТОЧНО, не предназначенна. НО ОТЛАЖИВАТЬСЯ НАДО - ибо оно не работает, вопрос - как?    Цитата Еще раз, отладку чего ты хочешь делать т.о.? Так, еще раз, медленно и по пунктам:  На объекте стоит СИСТЕМА, состоящая из какой то железки и управляющей программы на PC  СИСТЕМА не работает, средств разработки с собой нет  Логов, встроенных в программу на PC не достаточно (например, если судить по логам, то все Ок)  Надо выяснить, кто виноват и что делать. Например, все общения МК с PC заносятся в лог, анализ лога показал, что вроде все правильно, но МК не работает. Вдумчивое прочтение документации (или сеанс медитирования) принес предположение, что для того, что бы заработало надо добавить в определенном месте в процессе обмена с МК дополнительную команду. Варианты действий:  Собираем манатки, едем домой  вносим в сорцы УП соотвествующую правку, собираем  везем на объект, запускаем, убеждаемся, что не работает  приходим к выводу, что надо добавить еше одну команду, goto п1 или  Подключаемся к МК терминалом, скармливаем ему новую последовательность команд  убеждаемся, что не работает  приходим к выводу, что надо добавить еше одну команду, goto п1 Как думаешь, сколько займет времени 10 итераций по варианту 1 и по варианту 2? Цитата Ну в серьезных системах показометры тоже должны быть серьезными. А серьезному показометру не зазорно сделать маленький контроллер, который будет работать адаптером. Зачем, не вижу смысла в добавлении отдельной коробки, когда можно сделать без нее с теми же характеристиками. Даже лучше - отдельная коробка, это устройство, которое может сломаться, увеличение числа таких устройст уменьшает надежность всей системы. Цитата А текстовый протокол это шаманство. Просто его добавили, наверно (я незнаю историю модбаса) после того, как столкнулись проблемами о которых ты говоришь. Есть подозрение, что он появился после того, как Modbus попытались подключить к какому нибудь PLC, у которого работа с бинарными данными (не говоря уже про realtime) была сильна затруднена    (Языки програмирования PLC находятся на уровне Basic'а или даже еще ниже) Цитата Я к чему это все завел... К тому, что надо делать правильно. А правильно дорого. Вот и появляются всякие разные "дешевые" решения  'Правильно' еще не значит 'дорого'. Решение должно удовлетворять поставленному ТЗ, если их несколько, то выбирается наиболее дешевое. В цену решения входит не только стоимость переходника, но и стоимость оплаченного рабочего времени тех, кто это все собирал в кучу (и аппаратчиков и программистов). Если на фирме рабочее время ничего не стоит, то надо искать не лучшее железо, а другое место работы    Цитата Цитата(xvr @  17.4.2008,  18:27 ) Их мог задать ОПЕРАТОР с консоли, это собственно и есть единственное (IMHO) преимущество, которым обладает текстовый протокол. В данном случае это преимущество было реализованно на основе бинарного протокола и специальных возможностей в управляющем софте.  Ну убей меня об стенку, зачем для этого ТЕКСТОВЫЙ ПРОТОКОЛ? Ну сделал  в программе отправку любой последовательности, и все  Текстовый протокол - не самоцель. Первоначальная цель была обеспечить возможность общаться с МК ВРУЧНУЮ, не имея каких то специальных средств. Текстовый протокол это одно из возможных решений, специальные средства в управляющей программе - это альтернативное решение. Увы я видел только 2 таких программы - одну я уже упоминал, а вторая была среда програмирования контролеров фирмы AMX (контроллеры для 'Умных домов'), она позволяла отправить любую команду любому устройству, включенному в ее сеть. Цитата ЗЫЖ Вобщем, единственное, в чем я теперь стобой соглашусь полностью, это то, что текстовый протокол, который имее маркер конца кадра, позволяет избежать проблем связанных с выделение этих кадров из потока.  Если бы подобный маркер был предусмотрен в бинарном, было бы вообще счастье    Есть такие бинарные протоколы (но не Modubs)

Автор: Felan 18.4.2008, 12:25

Цитата(xvr @  18.4.2008,  12:54 ) Потому что ты сидишь на объекте и на PC, который там есть ничего нет  smile Ни Delphi, ни сорцов, ни тулзов для програмирования МК. А оно не работает  smile А там, где все это есть нет самой управляемой системы и повторить эффект, который проявился на объекте не получается. Я прекрасно понимаю, что это очень реальный расклад. Но в таких случаях у нас ВСЕГДА предусматривался спец. режим для отладки. Цитата(xvr @  18.4.2008,  12:54 ) Поведай нам неразумным, как можно заниматься отладкой управляющей программы без объекта управления? Легко! Для этого обычно пишут заглушку, т.е. эмулятор, который реализует интерфейс системы. Мне кажется, что это настолько очевидно, что тех, кто так не делаешь, я пожалуй не назвал бы профессионалами. Цитата(xvr @  18.4.2008,  12:54 ) Достаточные - это сколько? Ты же не будешь логировать исполнение каждой строчки исходников своей программы? Зачем каждую строчку то логировать? Достаточно писать в лог только то, что нужно. Нет в этом ничего такого страшного, а есть такой паттерн проектирования "Команда", очень он способствует всяким удобствам в разработке подобного ПО. Цитата(xvr @  18.4.2008,  12:54 ) Запросто. Возьмем например девайс с которого все началось. У него несколько десятков Modbus регистров, автору этой темы надо прочесть температуру - это 1 регистр. Т.е. управляющая программа будет уметь читать 1 регистр и не будет уметь читать остальные 99. Даже родная управляющая программа, идущая с прибором, не обладает всей, нужной автору функциональностью (он сам сказал), и скорее всего она тоже читает не все регистры. С другой стороны, даже если управляющая программа и читает все регистры, она это делает по своей собственной инициативе и скорее всего невозможно заставить ее читать их так (и в том порядке) как хочет пользователь/разработчик. (Вариант с правкой сорцов и перекомпиляцией мы не рассматриваем - на объекте нет ни сорцов ни компилятора) Блин, уел. Ладно. Просто мне, как человеку разрабатывавшему подобный софт не пришла голову простая до безобразия мысль, что у команды чтения регистра не может быть параметра, который указывает какой именно регистр надо прочитать. А так же не пришло в голову, что в целях отладки этот параметр нельзя изменить... Отсутствие отладочного режима тоже... Цитата(xvr @  18.4.2008,  12:54 ) ТОЧНО, не предназначенна. НО ОТЛАЖИВАТЬСЯ НАДО Ты сам не находишь сдесь противоречия? Сделать что-то,  чем-то, что для делания этого не предназначено? Цитата(xvr @  18.4.2008,  12:54 ) Как думаешь, сколько займет времени 10 итераций по варианту 1 и по варианту 2? Вариант 2. Еще раз, то, что по не позволят элементарно проверить свою работу, т.е. работу команд, которые оно должно выполнять, но не выполняет, это значит, что плохое ПО. Протокол здесь НИ ПРИЧЕМ! Причем здесь посторонние команды, я тоже не понимаю. Ну увидит он, что у него не читается еще и остальные 99, что это кардинально изменит? Цитата(xvr @  18.4.2008,  12:54 ) Зачем, не вижу смысла в добавлении отдельной коробки, когда можно сделать без нее с теми же характеристиками Как не видишь смысла!? Ты же сам сказал, что сделать штатными средствами НЕВОЗМОЖНО! Да, тут выкрутились, оказалось, что есть текстовый протокол, а если бы его не было? Как можно сделать, когда ты сам вчера говорил, что ЧИП ПОРТА И ЕГО УПРАВЛЯЮЩЕЕ ПО НЕ ПОЗВОЛЯЕТ ДЕЛАТЬ "ЭТО" В ПРИНЦИПЕ???    Я отказываюсь понимать твою логику  Цитата(xvr @  18.4.2008,  12:54 ) Есть подозрение, что он появился после того, как Modbus попытались подключить к какому нибудь PLC, Ну вот видишь, по твоим же словам, была спецификация, налетели не грабли, под шаманили  Пусть даже и хорошо получилось, но суть остается той же. Цитата(xvr @  18.4.2008,  12:54 ) Если на фирме рабочее время ничего не стоит, то надо искать не лучшее железо, а другое место работы  smile  Я так и сделал, полтора года назад.  Цитата(xvr @  18.4.2008,  12:54 ) Текстовый протокол - не самоцель. Первоначальная цель была обеспечить возможность общаться с МК ВРУЧНУЮ, не имея каких то специальных средств. Текстовый протокол это одно из возможных решений, специальные средства в управляющей программе - это альтернативное решение. Увы я видел только 2 таких программы - одну я уже упоминал, а вторая была среда програмирования контролеров фирмы AMX (контроллеры для 'Умных домов'), она позволяла отправить любую команду любому устройству, включенному в ее сеть. Вот и я про то, что не самоцель. И что реализовывать его обосновывая тем, что "читать удобнее", считаю глупостью. Если в этом есть РЕАЛЬНАЯ НЕОБХОДИМОСТЬ - да пожалуйста, сам первый и реализую . Ладно. Я сдаюсь

Автор: xvr 18.4.2008, 13:35

Цитата(Felan @ 18.4.2008,  12:25) Цитата(xvr @  18.4.2008,  12:54 ) Потому что ты сидишь на объекте и на PC, который там есть ничего нет  smile Ни Delphi, ни сорцов, ни тулзов для програмирования МК. А оно не работает  smile А там, где все это есть нет самой управляемой системы и повторить эффект, который проявился на объекте не получается. Я прекрасно понимаю, что это очень реальный расклад. Но в таких случаях у нас ВСЕГДА предусматривался спец. режим для отладки. Значит ваше ПО уникальное - практически ни в одном ПО, распространяемым с железками, такого режима нет (по крайней мере мне не попадалось, за редким исключением) Цитата Цитата(xvr @  18.4.2008,  12:54 ) Поведай нам неразумным, как можно заниматься отладкой управляющей программы без объекта управления? Легко! Для этого обычно пишут заглушку, т.е. эмулятор, который реализует интерфейс системы. Мне кажется, что это настолько очевидно, что тех, кто так не делаешь, я пожалуй не назвал бы профессионалами. Не все можно сэмулировать, соотвественно не все можно проверить    Цитата Цитата(xvr @  18.4.2008,  12:54 ) ТОЧНО, не предназначенна. НО ОТЛАЖИВАТЬСЯ НАДО Ты сам не находишь сдесь противоречия? Сделать что-то,  чем-то, что для делания этого не предназначено? Противоречия не нахожу. Все предусмотреть невозможно, иногда приходится обходится тем, что есть. Это не есть основной режим отладки, это отлов каких то багов в экстренных и очень редких ситуациях. Цитата Цитата(xvr @  18.4.2008,  12:54 ) Как думаешь, сколько займет времени 10 итераций по варианту 1 и по варианту 2? Вариант 2. Еще раз, то, что по не позволят элементарно проверить свою работу, т.е. работу команд, которые оно должно выполнять, но не выполняет, это значит, что плохое ПО.  Оно выполняет и проверяет, и говорит, что произошла ошибка. Нужны не проверки в ПО а отдельный тестовый/технологический режим, позволяющий получить полный и произвольный доступ к железке. Цитата Протокол здесь НИ ПРИЧЕМ! Причем здесь посторонние команды, я тоже не понимаю. Ну увидит он, что у него не читается еще и остальные 99, что это кардинально изменит? ПО наплевать на остальные 99 - они ему не нужны. Проблема в СТЫКОВКЕ МК и ПО, разночтения в описании протоколов обмена с МК может привести к полной или частичной (что гораздо хуже) неработоспособности ПО Цитата Цитата(xvr @  18.4.2008,  12:54 ) Зачем, не вижу смысла в добавлении отдельной коробки, когда можно сделать без нее с теми же характеристиками Как не видишь смысла!? Ты же сам сказал, что сделать штатными средствами НЕВОЗМОЖНО!  Можно, Modbus ASCII Цитата Да, тут выкрутились, оказалось, что есть текстовый протокол, а если бы его не было? Тогда и нужно было бы ставить коробку. Цитата Цитата(xvr @  18.4.2008,  12:54 ) Текстовый протокол - не самоцель. Первоначальная цель была обеспечить возможность общаться с МК ВРУЧНУЮ, не имея каких то специальных средств. Текстовый протокол это одно из возможных решений, специальные средства в управляющей программе - это альтернативное решение. Увы я видел только 2 таких программы - одну я уже упоминал, а вторая была среда програмирования контролеров фирмы AMX (контроллеры для 'Умных домов'), она позволяла отправить любую команду любому устройству, включенному в ее сеть. Вот и я про то, что не самоцель.   Консенсус    Цитата И что реализовывать его обосновывая тем, что "читать удобнее", считаю глупостью. А кто то говорил про удобство чтения?   В таком ракурсе я его не рассматривал и не собираюсь    Цитата Если в этом есть РЕАЛЬНАЯ НЕОБХОДИМОСТЬ - да пожалуйста, сам первый и реализую . Иногда есть. Пример - устройство, расчитанное на полностью автономную работу, но имеющее порт для настроек и диагностики. С вероятностью 99% на объекте не окажется его управляющей программы, т.к. она там нафиг не нужна   Вероятность найти там PC с терминалом гораздо выше

Автор: Felan 18.4.2008, 14:32

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

Автор: Cergiy 18.4.2008, 18:16

Цитата(Felan @  18.4.2008,  07:59 ) Cergiy, Ты бы хоть код привел. Сказал, что пользуешь, мои классы или нет. А так - ошибка в 17-ой строке  У меня там солянка, но вообще мне порекомендовали 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, ну а про количество параметров там ничего не сказано. То есть я вообще не понимаю о чем речь. Может мне кто помочь?

Автор: xvr 18.4.2008, 20:17

Цитата(Cergiy @ 18.4.2008,  18:16) Но я не могу в логике 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), вероятно имелись в виду реле или что то подобное. В реалии обозначает выходной бит информации (действительно может быть реализованн как реле)

Автор: Cergiy 18.4.2008, 20:46

Цитата(xvr @  18.4.2008,  20:17 ) Количество параметров - 1 (количество подряд идущих регистров) Ну а вы сможите написать команду? то есть: :01030170(0001) или как-то по другому, то есть я вообще не понимаю, что должно быть написано и как. Поэтому в принципе написал на официальный сайт, но это у них долго: в прошлый раз дней 5 высылали мануал. Но мне в принципе интересн и какой например может прийти ответ.  В том смысле что тоже не понятно, что должно прийти ))))

Автор: xvr 19.4.2008, 17:26

Цитата(Cergiy @ 18.4.2008,  20:46) Цитата(xvr @  18.4.2008,  20:17 ) Количество параметров - 1 (количество подряд идущих регистров) Ну а вы сможите написать команду? то есть: :01030170(0001) или как-то по другому, то есть я вообще не понимаю, что должно быть написано и как. Поэтому в принципе написал на официальный сайт, но это у них долго: в прошлый раз дней 5 высылали мануал. Но мне в принципе интересн и какой например может прийти ответ.  В том смысле что тоже не понятно, что должно прийти )))) Команда - чтение регистра 0170 (температура): :0103017000018A Ответ (20 С, содержимое регистра 200 или 00C8) :0103000200C832

Автор: Cergiy 18.5.2008, 20:36

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

Автор: smalcom 23.5.2008, 09:25

используй таймера

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)