Просмотр полной версии : ModBus
Василий_S
08.02.2014, 00:47
Здравствуйте! Кто может подсказать, на какой скорости лучше вести обмен данными с ПЛК-100 по модбасу и какова максимальная длина запрашиваемых данных?
Простите за такое начало, не могу представить как объяснять коротко ситуацию.
В кратце так: делается запрос (периодически постоянно) на чтение данных из ПЛК по интерфейсу ModBus, длина ответа из ПЛК - 75 ASCII символов (64 с нужной информацией). Всё бы ничего, только ПЛК, временами, "правильно" не отвечает. Временами, (значит за 4800 запросов за сутки раз 10 - 20 - 30, иногда больше) ответ из ПЛК не корректен. Вроде немного - но портит всю картину мироздания. Инфа бежит по витой паре, длина измеряется сотнями метров и более. Скорость поставлена в 3 раза выше предлагаемой овеном по умолчанию.
- зашёл в тупик. Если кто-нибудь откликнется на такой крик о помощи - приведу подробности.
Буду очень благодарен за отзыв.
30/4800 = 0,6 % Очень даже хорошо.
Я бы пересмотрел обработку ошибочного ответа в мастере. Ошибки же не 30 раз подряд, верно?
Ну или скорость занизить.
Да какой тут отзыв, устали уже все отвечать, недели две назад только закончили обсуждать этот вопрос
Василий_S
10.02.2014, 22:38
Да какой тут отзыв, устали уже все отвечать, недели две назад только закончили обсуждать этот вопрос
Уж простите за беспокойство.
Дело не в протоколе Модбас, а в спецификациях на RS485.
Всё что надо сделать в первую очередь, так это тупо выполнить требования к медиа.
"Витая пара" - это ни о чём. Спецификации RS485 гораздо более конкретны.
И промышленность выпускает туеву хучу кабелей именно для этого интерфейса.
И каждый из производителей норовит указать на рекомендации по прокладке промышленных сетей на основе RS485.
Правила одни и те же.
По-гуглите рекомендации для Profibus, DH+, DH-RIO, DeviceNET - все эти сети основаны на RS485.
Интерфейс один, протоколы разные.
Василий_S
10.02.2014, 23:13
30/4800 = 0,6 % Очень даже хорошо.
Я бы пересмотрел обработку ошибочного ответа в мастере. Ошибки же не 30 раз подряд, верно?
Ну или скорость занизить.
Да, 0,6 % немного, но всю картину портит.
Ошибочные ответы отфильтровываются. Ставлю три проверки: длина сообщения, контрольная сумма и совпадение адреса устройства в запросе и в ответе. Если что-то "не бьёт", отправляю повторный запрос, и так до 20 раз. Точнее - организован цикл опроса устройства до 20 попыток (задрал специально). Если попытка удачная, то прога выходит из цикла и в организованную переменную записываются данные из буфера,в противном случае переменная обнуляется. При количестве проходов больше 1-го организовал запись строки в текстовый файл с информацией об адресе устройства, времени повторной попытки, количество повторных попыток и содержании ответа.
Результаты следующие: с одного устройства данные корректно считываются со 2-й,3-й попытки. Несколько раз количество повторных попыток было равно 20 и данные были обнулены. (Обнулялась переменная, в которую считывались данные буфера). С другого устройства ситуация с количеством повторных попыток равным 20 и нулевым содержанием переменной с данными ПЛК намного хуже.
Но что интересно, сбои начинаются в рабочее время. Где-то с 8-20, когда ситуация на предприятии проходит под девизом "началось в колхозе утро", потом как-то ошибочность спадает, в околообеденное время вялый всплеск и "успокаивается" после 17-00. В выходные ошибки - редкость.
Где искать? или это зависимость ПЛК от качества э/энергии, хреновая плата с ком-портами (даже если она - мокса), прошивка ПЛК, дурное влияние запада? Вот вопрос.
Василий_S
10.02.2014, 23:18
Дело не в протоколе Модбас, а в спецификациях на RS485.
Всё что надо сделать в первую очередь, так это тупо выполнить требования к медиа.
"Витая пара" - это ни о чём. Спецификации RS485 гораздо более конкретны.
И промышленность выпускает туеву хучу кабелей именно для этого интерфейса.
И каждый из производителей норовит указать на рекомендации по прокладке промышленных сетей на основе RS485.
Правила одни и те же.
По-гуглите рекомендации для Profibus, DH+, DH-RIO, DeviceNET - все эти сети основаны на RS485.
Интерфейс один, протоколы разные.
Да модбас и не виню. В основном - обмен проходит нормально.
Хорошо - поищу в этом направлении. Хотя сеть давно раскинута из кабеля с 4-мя витыми парами.
Здравствуйте! Кто может подсказать, на какой скорости лучше вести обмен данными с ПЛК-100 по модбасу и какова максимальная длина запрашиваемых данных?
Простите за такое начало, не могу представить как объяснять коротко ситуацию.
В кратце так: делается запрос (периодически постоянно) на чтение данных из ПЛК по интерфейсу ModBus, длина ответа из ПЛК - 75 ASCII символов (64 с нужной информацией). Всё бы ничего, только ПЛК, временами, "правильно" не отвечает. Временами, (значит за 4800 запросов за сутки раз 10 - 20 - 30, иногда больше) ответ из ПЛК не корректен. Вроде немного - но портит всю картину мироздания. Инфа бежит по витой паре, длина измеряется сотнями метров и более. Скорость поставлена в 3 раза выше предлагаемой овеном по умолчанию.
- зашёл в тупик. Если кто-нибудь откликнется на такой крик о помощи - приведу подробности.
Буду очень благодарен за отзыв.
У тебя, вероятно, линии связи (лс) проложены рядом с силовыми кабелями. Поставь на концах лс резисторы 120 Ом. Скорость обмена сделай 9600.
Ва-аще-то RS485 не только нагрузочных резисторов требует, но и резисторов смещения.
И кабеля с определённым волновым сопротивлением.
И всё это опять-таки в целях помехозащищённости.
Для инженера "по стандарту" значит то же, что для иудея "кошерно", а для мусульманина "халяль".
Для инженера "по стандарту" значит то же, что для иудея "кошерно", а для мусульманина "халяль".
однозначно эти слова, что то новое в ответах по этой теме, остальные здесь звучали неоднократно, достаточно было воспользоваться поиском по форуму
Василий_S
11.02.2014, 15:18
У тебя, вероятно, линии связи (лс) проложены рядом с силовыми кабелями. Поставь на концах лс резисторы 120 Ом. Скорость обмена сделай 9600.
Резисторы установлены. А скорость, видать, придётся сбросить.
Василий_S
11.02.2014, 15:28
У тебя, вероятно, линии связи (лс) проложены рядом с силовыми кабелями. Поставь на концах лс резисторы 120 Ом. Скорость обмена сделай 9600.
Резисторы установлены. А скорость, видать, придётся сбросить.
С прокладкой кабелей - да, полное безобразие. Местами ЛС проложены с силовыми кабелями. Не моё сие творение. ЛС в своё время были проложены местными энтузиастами.
Василий_S
11.02.2014, 15:29
однозначно эти слова, что то новое в ответах по этой теме, остальные здесь звучали неоднократно, достаточно было воспользоваться поиском по форуму
Если не в натяг, попрошу ссылочку.
Василий_S
11.02.2014, 15:31
Ва-аще-то RS485 не только нагрузочных резисторов требует, но и резисторов смещения.
И кабеля с определённым волновым сопротивлением.
И всё это опять-таки в целях помехозащищённости.
[I.[/I]
Спасибо, вопрос проработаю.
Если не в натяг, попрошу ссылочку.
начиная с этого http://www.owen.ru/forum/showthread.php?t=9854&p=54184&viewfull=1#post54184
В поиске главное указать требуемый набор ключевых слов и на любой вопрос можно найти не менее десятка ответов
Спасибо, вопрос проработаю.
Смотри не переработай. Там какая-то чушь про резисторы смещения.
Там какая-то чушь про резисторы смещения.Коллега Вольд, если Вы не в ладах с английским, и не можете осилить официальную спецификацию RS485, то позвольте и Вам, и всем желающим, рекомендовать дивную книжку с замечательными картинками:
Парк Дж., Маккей С, Райт Э. "Передача данных в системах контроля и управления: практическое руководство"
там на 87 странице Вы сможете увидеть Рис. 3.16. Пример установки резисторов, снижающих уровень помех
Книгу эту в различных форматах можно легко найти в сети.
http://pc-lib.net/setevie-reshenia/41405-peredacha-dannikh-v-sistemakh-kontrolya-i-upravleniya-prakticheskoe-rukovodstvo.html
http://diska.net/setevie_technologi/1571-peredacha-dannyh-v-sistemah-kontrolja-i-upravlenija-prakticheskoe-rukovodstvo.html
Главное, прежде, чем писать обидное, вспомнить замечательный афоризм К.Пруткова:
"Многие вещи нам непонятны не потому, что наши понятия слабы;
но потому, что вещи сии не входят в круг наших понятий"
Тебе этот афоризм тоже полезно помнить. Если грамотно организовать обмен (в частности захват/перехват шины, таймауты), то резисторы смещения не нужны.
Василий_S
11.02.2014, 16:28
Смотри не переработай. Там какая-то чушь про резисторы смещения.
Поздно осторожничать - уже переработал.
Поздно осторожничать - уже переработал.
Что именно ?
Василий_S
11.02.2014, 17:22
Что именно ?
Да, блин, из-за принципа, ещё обозначенном А.С. Пушкиным "не гонялся бы ты поп за дешевизной", точнее - игнорируемом на одном замечательном предприятии, пришлось остановиться на выбранном уже ПЛК "Овен". Подкупило ещё то, что на каждый дискретный вход можно подцепить счётный модуль.
Задача состояла в том, чтобы сосчитать импульсы электросчётчиков чтобы в реальном времени просматривать текущую и результативную энергетику предприятия. Революционная идея (точнее - её воплощение в жизнь), естеССССтвенно, сначала проходила экспериментальную стадию. Все, на первый взгляд всё было зашибись. Поэкспериментировал со скоростями - остановился на 38400 км/ч. Циферки красиво бегали на экране монитора. Потом поставил первый собранный шкафчик на подстанцию. Сцапал вторую проблему - ПЛК в "поле" и условиях длительной работы, превышающей установленный ТК РФ 8-ми часовой номинал стал останавливаться. Ну, ладно, воткнул программную кнопку по совету форумчан - вроде полегчало, остановки выполнения программы исчезли. А первая проблема была с часами реального времени. С чувством безграничной благодарности к разработчикам ПЛК, решил и эту проблему - записью текущего значения времени из ПК в ПЛК.
Далее - стал систематизировать данные. Вообще - сбор текущих данных организовал 18-ти секундным циклом. С 0 по исключительно 10 секунду веду опрос устройств с целью сбора информации, с 10 включительно по исключительно 16 - записываю в ПЛК время, с 16 по 18 - снова ведётся опрос. В ПЛК организован подсчёт импульсов за 18 секунд, 1 час и 1 сутки. Данные опроса расихиваются по таблицам БД эСКуэЛя. Там же, в эСКуэЛе, импульсы пересчитываются в реальные единицы измерения. На 6-й секунде цикла из таблиц, где находятся данные о пересчёте импульсов за 18-ти сек. период (то бишь текущие мощности), измеренная величина со значением текущего времени записывается в архивные таблицы. Таких записей за сутки - 4800. Раз в час (на той же 6-й секунде но по прошествии астрономического часа) в архив пишется Э/энергия за час. Раз в сутки, таким же макаром - Э/энергия за прошедшие сутки.
Сравнивали результаты сбора данных официальной системы и тестируемой. Данные совпадали, но были и редкие сбои. Надо, блин, было сразу разбираться почему. Но на крыльях эйфории стал ветвить систему. Потом, позже, при просмотре архивных таблиц увидел некорректные данные. Очень редко 10 - 20 - 30, в зависимости от времени суток и "недельности" дня. В иные выходные ошибок вообще не наблюдалось. И эта фигня портит всю картину, особенно при просмотре трендов, создаваемых на базе архивных таблиц.
Вот такая исповедь с выдачей идеи, уважаемый Вольд, надеюсь - не утомил.
А работы сделано немало. 24 ПЛК в свежекупленых шкафчиках уже украшают интерьеры электроподстанций.
Вот как выкручиваться из ситуации?
еретический вопрос
а что за электросчетчики (ну из которых импульсы поступают)?
На ПК что за приложение установлено ?
Василий_S
11.02.2014, 17:39
а что за электросчетчики (ну из которых импульсы поступают)?
ЦЭ 2727. Считывются калибровочные импульсы по цене 40 000 за квт*Ч.
Василий_S
11.02.2014, 17:39
На ПК что за приложение работает ?
Старый добрый VB6.
Глупо как то все, если модбас только между плк и ПК, то чего бы не использовать modbusTCP. Про какой то 18-секундный цикл, это вообще что, ПК считывает данные из каждого плк за это время или тратит на каждый контроллер столько
Василий_S
11.02.2014, 17:48
Глупо как то все, если модбас только между плк и ПК, то чего бы не использовать modbusTCP. Про какой то 18-секундный цикл, это вообще что, ПК считывает данные из каждого плк за это время или тратит на каждый контроллер столько
За 18 сек прога обегает все ПЛК и не один раз. 18 сек было выбрано как наиболее удобный период. Обеспечивается точность по мощности 5 вт на импульс и удобно дифференцировать по времени - получать из кВт*ч-ов кВт-ы.
И кабель с 4-мя витыми парами БЫЛ уже РАСКИНУТ.
На ПК что за приложение работает ?
Старый добрый VB6.
Протокол Modbus RTU в приложении сам реализовал ?
Василий_S
11.02.2014, 18:05
Протокол Modbus RTU в приложении сам реализовал ?
ModBus ASCII. Конечно сам, героическими усилиями, так сказать.
ModBus ASCII. Конечно сам, героическими усилиями, так сказать.
А каким образом у тебя неверные данные в базу попадают, почему они не отбраковываются ? Что КС не помогает ?
И кабель с 4-мя витыми парами БЫЛ уже РАСКИНУТ.
кабель с четырьмя парами как раз таки ближе к ЛВС, чем RS485
в чем подвох?
Василий_S
11.02.2014, 19:08
А каким образом у тебя неверные данные в базу попадают, почему они не отбраковываются ? Что КС не помогает ?
Это уже проблема распределения полученных данных. Было бы что распределять. А базовая проблема в том, что данные в буфер после запроса иногда приходят некорректно. Я ставил "ловушки" по длине ответа и туда попадалось то, что длина ответа от устройств "иногда" меньше ожидаемой. Сейчас поставлен тройной фильтр - по длине данных, КС и совпадению адреса в ответе и запросе к устройству. В общем, всё указывает на некорректность ответов ПЛК. В дальнейшей обработке данных не сомневаюсь. В том числе и попадании некорректных данных в базу ибо это результат их обработки.
По "тройному" фильтру прога определяет: ещё раз запрашивать "этот" ПЛК или переходить к следующему устройству. Поставлена планка на 20 попыток. Если все они неудачны - то результат обработки (в организованной переменной)- 0. И эти нули видны в базе в объявленном выше количестве - за 4800 записей за сутки 10-20-30 пенок, равных нулю. А так - частенько просматривается 2 или 3 попытки, есть и другие значения, меньшие 20-ти. И это бы устроило (меньше 20-ти попыток), ибо корректный результат, после последней попытки запроса, есть.
Василий_S
11.02.2014, 19:08
кабель с четырьмя парами как раз таки ближе к ЛВС, чем RS485
в чем подвох?
И мне интересно.
А проблема в том, что данные в буфер после запроса иногда приходят некорректно. Я ставил "ловушки" по длине ответа и туда попадалось то, что длина ответа от устройств "иногда" меньше ожидаемой.
Есть такой сайт http://ru.wikipedia.org/wiki/Modbus, там в самом низу раздел Стандартные коды ошибок и под ним примеры, в котором явно наблюдается, что ответ может быть меньше ожидаемого, это один из вариантов
Василий_S
11.02.2014, 19:38
Есть такой сайт http://ru.wikipedia.org/wiki/Modbus, там в самом низу раздел Стандартные коды ошибок и под ним примеры, в котором явно наблюдается, что ответ может быть меньше ожидаемого, это один из вариантов
Спасибо, видимо мне стоит вернуться к анализу именно содержимого буфера, а не тольк,о как в прошлом делал, ограничиваться контролем длины ответа устройств.
Василий_S
13.02.2014, 15:41
В общем, обнаружилась интересная вещь!
Длина ответа ПЛК на запрос мастером по модасу аскии совпадает с ожидаемой, но в месте, где находится КС - стоят нули!
Предистория такая:
Поставил первую ловушку. Т.е. по проверке длины ответа ПЛК (MSComm1.InBufferCount = 75 должно быть), находящегося в буфере (перед считыванием данных из буфера) организовал запись в текстовый файл содержание ответа, если длина ответа меньше 75. И - НИ ОДНОЙ ЗАПИСИ за сутки!!!
Смотрю вторую ловушку. Там идёт проверка по длине ответа, КС и совпадению адреса в запросе и ответе. Сделан цикл из 20 попыток запроса, если проверка неудачная. Если проверка проходит, то прога выходит из этого цикла. В случае достижения количества попыток запроса равным 20 делается запись в текстовый файл с содержанием ответа и сопутствующими атрибутами (адрес, время и номер ловушки). И там, в текстовом файле второй ловушки, ОБНАРУЖИВАЮ ОТВЕТ ПЛК требуемой длины, с корректными, кажись, данными и с НУЛЯМИ в месте расположения КС!!!
Что за хрень, а, разработчики ПЛК "Овен"?!
И таких ответов дофига и все с нулями в КС.
Как бы Вам вежливо объяснить, чтоб искали ошибки прежде всего в своей программе, есть ведь сторонние модбас тестеры с выводом отправленных и принятых байт, вот если покажете скрин что и они показывают об некорректной работе овеновского оборудования, тогда и взывайте к разработчикам
Василий_S
13.02.2014, 16:02
Как бы Вам вежливо объяснить, чтоб искали ошибки прежде всего в своей программе, есть ведь сторонние модбас тестеры с выводом отправленных и принятых байт, вот если покажете скрин что и они показывают об некорректной работе овеновского оборудования, тогда и взывайте к разработчикам
Хорошо, но попозже. Ещё понаблюдаю, сутки - маловато. Но ноли в КС впечатляют.
Да и мне уже не до вежливости - столько сил и времени вгрохал.
В общем, обнаружилась интересная вещь!
Длина ответа ПЛК на запрос мастером по модасу аскии совпадает с ожидаемой, но в месте, где находится КС - стоят нули!
Предистория такая:
Поставил первую ловушку. Т.е. по проверке длины ответа ПЛК (MSComm1.InBufferCount = 75 должно быть), находящегося в буфере (перед считыванием данных из буфера) организовал запись в текстовый файл содержание ответа, если длина ответа меньше 75. И - НИ ОДНОЙ ЗАПИСИ за сутки!!!
Смотрю вторую ловушку. Там идёт проверка по длине ответа, КС и совпадению адреса в запросе и ответе. Сделан цикл из 20 попыток запроса, если проверка неудачная. Если проверка проходит, то прога выходит из этого цикла. В случае достижения количества попыток запроса равным 20 делается запись в текстовый файл с содержанием ответа и сопутствующими атрибутами (адрес, время и номер ловушки). И там, в текстовом файле второй ловушки, ОБНАРУЖИВАЮ ОТВЕТ ПЛК требуемой длины, с корректными, кажись, данными и с НУЛЯМИ в месте расположения КС!!!
Что за хрень, а, разработчики ПЛК "Овен"?!
И таких ответов дофига и все с нулями в КС.
на сколько мне известно есть такая фича, когда вместо передачи последних единиц линия "отпускается". разные устройства это действие воспринимают по-разному. Некоторые - счита.ют единицами и все ок. Некоторые - считают нулями и всё плохо.
Столкнулись с этим при работе с МВ110-8АС. Решение одно - отключать проверку КС. либо вручную заменять последние нули в посылке на единицы и проверять КС.
Василий_S
13.02.2014, 16:15
на сколько мне известно есть такая фича, когда вместо передачи последних единиц линия "отпускается". разные устройства это действие воспринимают по-разному. Некоторые - счита.ют единицами и все ок. Некоторые - считают нулями и всё плохо.
Столкнулись с этим при работе с МВ110-8АС. Решение одно - отключать проверку КС. либо вручную заменять последние нули в посылке на единицы и проверять КС.
А можно чуток поподробней? В плане того, что мне не понятно, что значит линия "отпускается".
Василий_S
13.02.2014, 16:19
Интересно ещё бы понять как связан всплеск нахождения нулей в КС, или что там ещё, с наступлением дневного рабочего времени.
А можно чуток поподробней? В плане того, что мне не понятно, что значит линия "отпускается".
в том плане, что они не передаются. а так как нормальный уровень сигнала - высокий, то некоторые приборы считают, что все оставшиеся биты в посылке - единицы.
но проблема возникает тогда, когда приборы вместо того, чтобы догадываться - ждут оставшихся единиц.
а вот наличие/отсутствие КС от времени суток это уже интересно
Ребята, пока вы не приведёте в допустимую норму отношение сигнал/шум, вы можете хоть из порток выпрыгнуть, используя различные методы контроля, перебирая протоколы и т.п. - результата не добьётесь.
Проверьте:
- источники помех;
- заземление, уравнивание потенциалов и экранирование;
- архитектуру подключения (звезда и дерево недопустимы, только шлейф);
- согласование линии и защитное смещение.
Василий_S
13.02.2014, 16:52
в том плане, что они не передаются. а так как нормальный уровень сигнала - высокий, то некоторые приборы считают, что все оставшиеся биты в посылке - единицы.
но проблема возникает тогда, когда приборы вместо того, чтобы догадываться - ждут оставшихся единиц.
а вот наличие/отсутствие КС от времени суток это уже интересно
То есть, если правильно понял, в ответной посылке символов КС попросту - нет, и принимающее устройство их "дописывает", так?
Василий_S
13.02.2014, 17:01
Ребята, пока вы не приведёте в допустимую норму отношение сигнал/шум, вы можете хоть из порток выпрыгнуть, используя различные методы контроля, перебирая протоколы и т.п. - результата не добьётесь.
Проверьте:
- источники помех;
- заземление, уравнивание потенциалов и экранирование;
- архитектуру подключения (звезда и дерево недопустимы, только шлейф);
- согласование линии и защитное смещение.
Источников помех - предостаточно. Это, всё-таки, предприятие.
Заземление мне самому не нравится, хотя бы в том плане, что пришлось цепляться к общему контуру.
Потенциалы - пепепроверю.
Экранирование, Ну, могу сказать, что используется витая пара в кабеле КССПВэП 4х2х0,52 и экран подцеплен к корпусу щкафа. Шкафы - к контурам зданий.
В общем, обнаружилась интересная вещь!
Длина ответа ПЛК на запрос мастером по модасу аскии совпадает с ожидаемой, но в месте, где находится КС - стоят нули!
Предистория такая:
Поставил первую ловушку. Т.е. по проверке длины ответа ПЛК (MSComm1.InBufferCount = 75 должно быть), находящегося в буфере (перед считыванием данных из буфера) организовал запись в текстовый файл содержание ответа, если длина ответа меньше 75. И - НИ ОДНОЙ ЗАПИСИ за сутки!!!
Смотрю вторую ловушку. Там идёт проверка по длине ответа, КС и совпадению адреса в запросе и ответе. Сделан цикл из 20 попыток запроса, если проверка неудачная. Если проверка проходит, то прога выходит из этого цикла. В случае достижения количества попыток запроса равным 20 делается запись в текстовый файл с содержанием ответа и сопутствующими атрибутами (адрес, время и номер ловушки). И там, в текстовом файле второй ловушки, ОБНАРУЖИВАЮ ОТВЕТ ПЛК требуемой длины, с корректными, кажись, данными и с НУЛЯМИ в месте расположения КС!!!
Что за хрень, а, разработчики ПЛК "Овен"?!
И таких ответов дофига и все с нулями в КС.
Я связывал ПЛК110 с ПК по Modbus-RTU, сам реализовывал протокол обмена. В корректном отклике от ПЛК получал все, что должно быть включая КС. Если ты в пакете-отклике получил неверную КС, то такой пакет сразу надо браковать и не надо его вообще дальше анализировать.
Экранирование, Ну, могу сказать, что используется витая пара в кабеле КССПВэП 4х2х0,52 и экран подцеплен к корпусу щкафа. Шкафы - к контурам зданий.
А экран кабеля с одной стороны заземлен или с обоих ?
Василий_S
13.02.2014, 20:42
Я связывал ПЛК110 с ПК по Modbus-RTU, сам реализовывал протокол обмена. В корректном отклике от ПЛК получал все, что должно быть включая КС. Если ты в пакете-отклике получил неверную КС, то такой пакет сразу надо браковать и не надо его вообще дальше анализировать.
В принципе, так и делается, только другими граблями с другого захода. И ещё, повторюсь, - бегло посмотрел ответы с нулями в КС - там корректные данные. Надо ли браковать такие данные?
Василий_S
13.02.2014, 20:45
А экран кабеля с одной стороны заземлен или с обоих ?
Где как. Сеть раскинута задолго до моего появления на объекте.
Где как. Сеть раскинута задолго до моего появления на объекте.Как говаривал один мой начальник "Чей бы бычок не прыгал, телёнок - наш", - теперь всё одно, именно Вам приводить это хозяйство к нормам.
Несмотря на "исторически сложившийся бардак".
Протокол Modbus RTU в приложении сам реализовал ?ModBus ASCII. Конечно сам, героическими усилиями, так сказать.
А каким образом у тебя неверные данные в базу попадают, почему они не отбраковываются ? Что КС не помогает ?Это уже проблема распределения полученных данных. Было бы что распределять. А базовая проблема в том, что данные в буфер после запроса иногда приходят некорректно. Я ставил "ловушки" по длине ответа и туда попадалось то, что длина ответа от устройств "иногда" меньше ожидаемой. Сейчас поставлен тройной фильтр - по длине данных, КС и совпадению адреса в ответе и запросе к устройству. В общем, всё указывает на некорректность ответов ПЛК. В дальнейшей обработке данных не сомневаюсь. В том числе и попадании некорректных данных в базу ибо это результат их обработки.
В общем, обнаружилась интересная вещь!Длина ответа ПЛК на запрос мастером по модасу аскии совпадает с ожидаемой, но в месте, где находится КС - стоят нули!
to Вольд, XopHeT и Ryzhij убедите меня, что дело в железе, а не в самописных прогах, даже несмотря на
Интересно ещё бы понять как связан всплеск нахождения нулей в КС, или что там ещё, с наступлением дневного рабочего времени.
Спорить с тем, что "самописные", как Вы изволили выразится, программы могут обладать меньшей "дуракоупорностью" в сравнении с тем, что проверено "ветром и временем" я не буду.
Это очевидно.
Так же как и то, что возможность сия гипотетическая.
Пока.
Но вот нарушение норм "по железу" уже явное.
И это тоже факт.
Спорить с тем, что "самописные", как Вы изволили выразится, программы могут обладать меньшей "дуракоупорностью" в сравнении с тем, что проверено "ветром и временем" я не буду.
Это очевидно.
Так же как и то, что возможность сия гипотетическая.
Пока.
Но вот нарушение норм "по железу" уже явное.
И это тоже факт.
Специально привел комменты, где несмотря на прохождение через проверку контрольной суммы, приходят нулевые значения, причем тут железные коммуникационные факторы если КС совпадает, через некоторое время чудесным образом стала приходить нулевая КС оказывается
А по поводу помех, так меня это больше всего расстраивает, смысл посыла: до меня всё проложено, устранять не буду, а оборудование Ваше г...о
Согласен.
Косяк на косяке, плюс лень в придачу.
И ещё, повторюсь, - бегло посмотрел ответы с нулями в КС - там корректные данные. Надо ли браковать такие данные?
Конечно надо, иначе какой может быть еще критерий отбора.
Где как. Сеть раскинута задолго до моего появления на объекте.
Экран кабеля должен быть заземлен только с одной стороны.
Василий_S
14.02.2014, 14:26
Согласен.
Косяк на косяке, плюс лень в придачу.
Нифига се, заценил. Видел бы объём проделанной работы. Причём почти в одиночку.
Василий_S
14.02.2014, 14:30
Конечно надо, иначе какой может быть еще критерий отбора.
А если в ответе содержатся корректные данные, а? Бывает, всё время в цикле, отведённое на запрос, идут нули в КС, а нужные данные там есть. Если отбраковывать по КС - это в проекте - потеря данных.
Вторые сутки наблюдаю ту же картину. проскакивают нужные 75 символов с нулями в КС.
Василий_S
14.02.2014, 14:38
Экран кабеля должен быть заземлен только с одной стороны.
Да, вы правы. Сейчас бы определиться что нужно делать во всех аспектах проблемы. А потом уже делать.
А что если проверка про заземлению не даст результата? Тем более, что предшественники отключение экранов с одной стороны делали. Везде ли, пока не знаю.
Плюс к тому - эти ошибки по объёму мизерны по сравнению с объёмом собираемой информации, но подпорчивают картину. Я бы мог на это плюнуть, но не хочу гнать фуфло. Поэтому предпочёл сначала разобраться, а потом уж что-то предпринимать.
Нифига се, заценил. Видел бы объём проделанной работы. Причём почти в одиночку.
Так от Вас и попытки небыло выложить здесь проект плк, который формирует неправильные данные, высчитывает к этим данным КС и Ваша прога на ПК "проглатывает" это, чтоб ктонибудь облегчил Ваши страдания и попытался устранить программные ошибки хотя бы в одном "узком" месте
Нифига се, заценил. Видел бы объём проделанной работы. Причём почти в одиночку.
Ясно дело. Болтать это одно, а дело делать совсем другое.
Василий_S
14.02.2014, 14:41
Специально привел комменты, где несмотря на прохождение через проверку контрольной суммы, приходят нулевые значения, причем тут железные коммуникационные факторы если КС совпадает, через некоторое время чудесным образом стала приходить нулевая КС оказывается
А по поводу помех, так меня это больше всего расстраивает, смысл посыла: до меня всё проложено, устранять не буду, а оборудование Ваше г...о
Мне часы реального времени сколько крови выпили. Рекордсмены они по неточности.
Да, вы правы. Сейчас бы определиться что нужно делать во всех аспектах проблемы. А потом уже делать.
А что если проверка про заземлению не даст результата? Тем более, что предшественники отключение экранов с одной стороны делали. Везде ли, пока не знаю.
Плюс к тому - эти ошибки по объёму мизерны по сравнению с объёмом собираемой информации, но подпорчивают картину. Я бы мог на это плюнуть, но не хочу гнать фуфло. Поэтому предпочёл сначала разобраться, а потом уж что-то предпринимать.
У тебя проблемы с передачей информации по линиям связи. С этим надо что-то делать, а потом ПО ворошить. Тебе предлагают разобраться с заземлением экрана кабеля. Это не сложно. Тебе предлагали уменьшить скорость обмена до 9600. Эти два мероприятия могут существенно улучшить ситуацию.
Мне часы реального времени сколько крови выпили. Рекордсмены они по неточности.
Бюджетная модель она и в Африке будет бюджетной, понимаю если идут длительные процессы и может пропадать питание, тогда нужен РТС, чтоб не спутать день с ночью, но если у Вас строгие периоды опросов, так используете разницу от функции TIME() - будет значительно точнее
Мне часы реального времени сколько крови выпили. Рекордсмены они по неточности.
На кой хрен тебе часы в ПЛК, если постаяно работает ПК. При записи в БД можно брать системное время ПК.
У тебя проблемы с передачей информации по линиям связи. С этим надо что-то делать, а потом ПО ворошить. Тебе предлагают разобраться с заземлением экрана кабеля. Это не сложно. Тебе предлагали уменьшить скорость обмена до 9600. Эти два мероприятия могут существенно улучшить ситуацию.
нет у него проблем, 30 ошибок за сутки не стоят того чтоб менять кабели связи
Василий_S
14.02.2014, 14:54
Так от Вас и попытки небыло выложить здесь проект плк, который формирует неправильные данные, высчитывает к этим данным КС и Ваша прога на ПК "проглатывает" это, чтоб ктонибудь облегчил Ваши страдания и попытался устранить программные ошибки хотя бы в одном "узком" месте
Если именно это вы имели в виду, а не результаты по контролю КС. Позже выложу. Хотя это обычное конфигурирование модбас слейв с 25 переменными в формате DWORD. Первая - для приёма значения времени из ПК, Остальные - три группы по 8 значений насчёта импульсов по каждому входу. Первая группа держит импульсы за 18 сек., вторая - за час, третья - за сутки. Переменные постоянно обновляются.
Василий_S
14.02.2014, 14:56
На кой хрен тебе часы в ПЛК, если постаяно работает ПК. При записи в БД можно брать системное время ПК.
Не на какой хрен, а чтобы дифференцировать кВт*ч в кВт. Речь идёт о точности измерения, если не понимаете.
Точно через 18 сек надо сбрасывать счётчик импульсов, как и другие - через час и сутки..
Василий_S
14.02.2014, 15:04
У тебя проблемы с передачей информации по линиям связи. С этим надо что-то делать, а потом ПО ворошить. Тебе предлагают разобраться с заземлением экрана кабеля. Это не сложно. Тебе предлагали уменьшить скорость обмена до 9600. Эти два мероприятия могут существенно улучшить ситуацию.
На ПО не грешу. А с экраном буду разбираться в первую очередь.
нет у него проблем, 30 ошибок за сутки не стоят того чтоб менять кабели связи
Менять кабеля никто не предлагает. А ошибок при передаче у него за сутки не 30, а море. 30 это то, что попадает в базу, а пакетов бракуется за сутки много больше.
Не на какой хрен, а чтобы дифференцировать кВт*ч в кВт. Речь идёт о точности измерения, если не понимаете.
Точно через 18 сек надо сбрасывать счётчик импульсов, как и другие - через час и сутки..
Попробуйте конструкцию
VAR tik:TON; END_VAR
IF tik.Q THEN
(* здесь можно обработать что то раз в 18 секунд *)
END_IF;
tik(IN:=NOT tik.Q,PT:=T#18s);
насколько она будет точнее, чем слабенькие часы реального времени
Василий_S
14.02.2014, 15:10
Попробуйте конструкцию
VAR tik:TON; END_VAR
IF tik.Q THEN
(* здесь можно обработать что то раз в 18 секунд *)
END_IF;
tik(IN:=NOT tik.Q,PT:=T#18s);
насколько она будет точнее, чем слабенькие часы реального времени
Не-е от использования таймеров для этих целей я в самом начале отказался. Дифференцировать надо только по реальному времени.
Не на какой хрен, а чтобы дифференцировать кВт*ч в кВт. Речь идёт о точности измерения, если не понимаете.
Точно через 18 сек надо сбрасывать счётчик импульсов, как и другие - через час и сутки..
А не проще ли постоянно читать из ПЛК состояние счетчиков, не сбрасывая их, а затем в ПК делать разбивку по временным группам. Так и потери данных не будет.
Василий_S
14.02.2014, 15:13
Менять кабеля никто не предлагает. А ошибок при передаче у него за сутки не 30, а море. 30 это то, что попадает в базу, а пакетов бракуется за сутки много больше.
Да - это именно так. где-то 30 некорректных данных - это просматривается в БД. Видны в трендах и в цифровых таблицах.
Василий_S
14.02.2014, 15:14
А не проще ли постоянно читать из ПЛК состояние счетчиков, не сбрасывая их, а затем в ПК делать разбивку по временным группам. Так и потери данных не будет.
Да? при том что переменные в вычислительной технике имеют свои пределы.
Да? при том что переменные в вычислительной технике имеют свои пределы.
Этот момент можно учесть слегка усложнив программу.
Василий_S
14.02.2014, 15:16
Всё таки кто может поведать о нулях в КС. Что за природное явление, а то уже уходим от вопроса.
Василий_S
14.02.2014, 15:18
Этот момент можно учесть слегка усложнив программу.
Я понимаю, Но решил - выгоднее сделать именно так как сделано.
Выгоднее получать "снизу" уже готовые цифры. Притом ушёл от того, чтобы передавать на верх вычисленные реальные единицы в формате "REAL"
Всё таки кто может поведать о нулях в КС. Что за природное явление, а то уже уходим от вопроса.
А ты с COM-портом в своем приложении для ПК как работаешь ?
Я понимаю, Но решил - выгоднее сделать именно так как сделано.
А ты подумай над этим.
Я понимаю, Но решил - выгоднее сделать именно так как сделано.
Выгоднее получать "снизу" уже готовые цифры. Притом ушёл от того, чтобы передавать на верх вычисленные реальные единицы в формате "REAL"
Какой может быть "REAL" при подсчете импульсов ?
Василий_S
14.02.2014, 15:27
А ты с COM-портом в своем приложении для ПК как работаешь ?
Четырёх ком-портовая мокса воткнута как плата расширения в ПК. Появилась возможность разделить ПЛК на 4 группы. Номера ком-портов хорошо просматриваются в диспетчере устройств. К ним обращаются 4 программы, каждая к своему порту.
Запрос, ожидание по таймауту или пока длина буфера будет равна 75, затем - считывание данных из буфера. 0.09 сек, поставленные на таймаут вполне достаточны.
Василий_S
14.02.2014, 15:30
Какой может быть "REAL" при подсчете импульсов ?
Элементарно: импульсы (содержатся в формате DINT) надо пересчитывать в реальные единицы с учётом цены этих импульсов, к-та трансформации, а при получении значений текущей мощи ещё и делить на 200. Получаются, иногда, числа с запятыми.
Поэтому решил, чтобы не таскать по проводам знаки, порядки и мантиссы, лучше буду брать данные целым числом. И выиграл на этом в том, что за 1 запрос снимаю данные по 8 входам сразу, больше в буфер не лезет.
Четырёх ком-портовая мокса воткнута как плата расширения в ПК. Появилась возможность разделить ПЛК на 4 группы. Номера ком-портов хорошо просматриваются в диспетчере устройств. К ним обращаются 4 программы, каждая к своему порту.
Запрос, ожидание по таймауту или пока длина буфера будет равна 75, затем - считывание данных из буфера. 0.09 сек, поставленные на таймаут вполне достаточны.
ОС Windows не является системой реального времени. По этой причине может возникнуть путаница с пакетами, принимаемыми из ПЛК.
Элементарно: импульсы (содержатся в формате DINT) надо пересчитывать в реальные единицы с учётом цены этих импульсов, к-та трансформации, а при получении значений текущей мощи ещё и делить на 200. Получаются, иногда, числа с запятыми.
Ты не правильно поставил задачу. Правильно писал IVM. Еще раз повторяюсь. Надо было чтобы ПЛК тупо считали импульсы от счетчиков и передавали накопленную сумму в ПК. А в программе ПК делай все расчеты и прочее и не было бы никаких проблем.
Василий_S
14.02.2014, 15:37
Ты не правильно поставил задачу. Еще раз повторяюсь. Надо было чтобы ПЛК тупо считали импульсы от счетчиков и передавали накопленную сумму в ПК. А в программе ПК делай все расчеты и прочее и не было бы никаких проблем.
Не согласен.
Хотя примерно так и делается, только разница в сбросе счётчиков.
Потом, ПЛК в данной системе - что-то вроде БД. Комп может вырубиться и данные можно потерять.
Не согласен.
Обоснуй свои мысли.
Василий_S
14.02.2014, 15:49
Вы, по сути предлагаете то же самое, только счётчики всё равно надо обнулять в один прекрасный момент. И всё равно придётся синхронизировать это обнуление с выполнением программы "наверху" и придётся это делать опять-таки по времени. И там наверху, просто, будут другие проблемы. Так выгоднее - к этому решению пришёл.
Василий_S
14.02.2014, 15:56
Ладно, Вольд, это тема для другого разговора. Не эта бы фигня - всё было бы ништяк. В целом и в подавляющем большинстве система работает. И показатели бъют в рамках своёй точности и методике обработки данных.
В бы лучше что-нибудь про явление с "отпусканием линии" где в КС непонятно что. Я впервые услышал об этом.
С одним направлением поисков определился - проверим ситуацию с заземлением. А если история будет продолжаться в том же духе?
У тебя максимальное время в течение которого ты не можешь принять правильный пакеты от ПЛК какое ? Правильный пакет это тот, у которого правильная КС. С какой периодичностью ты шлешь запросы в ПЛК ?
Не согласен.
Хотя примерно так и делается, только разница в сбросе счётчиков.
Потом, ПЛК в данной системе - что-то вроде БД. Комп может вырубиться и данные можно потерять.
У тебя накопленные импульсы хранятся в ПЛК и никуда они не потеряются пока сам не сбросишь счетчики. Разрядность счетчиков можно сделать очень большой, тогда не понадобится их часто обнулять. Обработку результатов намного удобнее вести в приложении для ПК. Ты сделал стратегическую ошибку при постановке задачи. Ладно бы тебе кто-то навязал свою идеологию, но ты сам принимал решение.
Василий_S
15.02.2014, 15:38
...... Ты сделал стратегическую ошибку при постановке задачи. Ладно бы тебе кто-то навязал свою идеологию, но ты сам принимал решение.
Остапа несло-о! Какие слова, какой типаж.
Остапа несло-о! Какие слова, какой типаж.
Что не нравится ? Ничего, перетопчешься. Сам себе проблемы создал.
Василий_S
15.02.2014, 16:19
У тебя максимальное время в течение которого ты не можешь принять правильный пакеты от ПЛК какое ? Правильный пакет это тот, у которого правильная КС. С какой периодичностью ты шлешь запросы в ПЛК ?
Ситуация интересная. Вот, например, на одном ком-порте висят два контроллера. К каждому устройству даётся возможность сделать запрос до 20 раз, для чего на "верху"организован цикл. Если ответ на запрос проходит проверку по трём критериям, то программа выходит из цикла многоразового запроса к одному устройству и переходит к другому. В случае, если количество попыток достигло 20-ти, то в текстовый файл записывается строка с содержанием адреса устройства, времени запроса, отметки о наличии 20-ти попыток и содержание ответа устройства. В случае если данные были приняты не с первой попытки (кроме 20-й), - также делается запись в файл.
В текстовом файле видно, что при повторных, (далеко не частых) попытках данные принимаются, в основном, со 2-й и 3-й попытки. Устройства "шалят" не синхронно.
Но есть моменты, когда в течении 10 секунд данные, с одного устройства, не принимаются (не проходят проверку по трём фильтрам) в то время, когда с другого устройства данные принимаются "на ура".
Т.е. видно в течение 10-ти секунд одного из 18-ти секундных циклов делаются записи с адресом одного устройства, кол-во попыток = 20 и содержание ответа, где в КС стоят нули. Причём остальные данные - корректны. На следующем цикле ответы от этого устройства принимаются.
В случаях приёма данных не с первой попытки КС в записанной строчке есть.
А если в ответе содержатся корректные данные, а? Бывает, всё время в цикле, отведённое на запрос, идут нули в КС, а нужные данные там есть...
Пока хоть что-то в кучке мусора не соответствует критериям определяющим пакет, мусор остается мусором. Как бы чего не казалось и не хотелось. Много чего похоже на кабачковую икру.
Хотелось бы увидеть алгоритм проведения запроса и обработки полученного ответа. Неявно это уже звучало:
У тебя максимальное время в течение которого ты не можешь принять правильный пакеты от ПЛК какое ? Правильный пакет это тот, у которого правильная КС. С какой периодичностью ты шлешь запросы в ПЛК ?
Вот тут чел тоже подрывался про неработающую железку. Смотрим итог.
http://www.owen.ru/forum/showthread.php?t=16524
Все таки смущает зависимость КС от времени суток. Вроде чушь, но учитывая что
ОС Windows не является системой реального времени..
и то что 90% работы в офисах происходит в первый и последний час )))) как-то закрадываются сомнения, несмотря на отсутствие их у Вас.
Если ответ на запрос проходит проверку по трём критериям, то программа выходит из цикла многоразового запроса к одному устройству и переходит к другому.
А что это за три критерия ? Сколько линий связей у тебя подходят к ПК ?
посмотрел
7182 запросов, ошибок 0.
Правда не совсем корректно:
На столе, ПЛК100 слейв, ПЛК63 мастер, 38400, 8N1, ASCII, чтение 125 регистров
Жутко некорректное сравнение. Сравнил офис с промпроизводством. И еще ты связываешь два родных ПЛК на короткой ЛС, а Василий_S ПК и кучу ПЛК на длинющих ЛС. Это в корне разные ситуации.
Жутко некорректное сравнение.
Вообще ASCII не использую - RTU, а требования жёстче. На складе скоммутировал 600м ПВС без всяких резисторов. Сходил поел. Ошибок 0.
Есть живые объекты где 100..300м в непонятной куче кабелей (прокладывал не я) - ошибки стремятся к нулю. Опять же - нет резисторов, и часть - звезда.
А родные-неродные ПЛК - а какая разница ? Куча ПЛК ? А без разницы. Пока опробованный максимум - 12 слейвов. Из них 4xПЛК63, там пришлось ковырять по 20-30 параметров из каждого.
Соббсно мысль - проблема мастера. На ПК
Ты в программе для ПЛК можешь напрямую работать с COM-портом, а он в программе для ПК не может.
Почему? COM API - отменили?
ПК - как ПЛК с рандомным циклом где-то в 15-.. мс. Если данные в его буферах не теряются - то какая разница.
Почему? COM API - отменили?
У него программа для ПК на VB сделана.
Ты в программе для ПЛК можешь напрямую работать с COM-портом, а он в программе для ПК не может.
Я тут предлагал Василию проверить работу своей программы на эмуляторе слейва, а так же неплохо бы ОРС поставить, чтоб сравнить как читаются плк, но ему видимо нужно ОВЕН обосрать, других целей этой беседы я не вижу
Я тут предлагал Василию проверить работу своей программы на эмуляторе слейва, а так же неплохо бы ОРС поставить, чтоб сравнить как читаются плк, но ему видимо нужно ОВЕН обосрать, других целей этой беседы я не вижу
Капитан, не надо нагнетать.
Не надо нагнетать.
Я так понимаю Вы тоже против использования проверенных мастеров, по сбору данных. Самопальный мастер круче штатного слейва плк? Это из-за чего интересно, потому что парень авторитетно заявляет, что у него масса "ловушек"?
А что такое проверенный мастер в данном случае ? Я думаю, мужик только тем и занимается, что ищет ошибки в своей программе для ПК.
А что такое проверенный мастер в данном случае ? Я думаю, мужик только тем и занимается, что ищет ошибки в своей программе для ПК.
ОРС сервер например
ЗЫ мне процитировать надо, что Ваш мужик уверен в правоте своей программы, а моими советами займется позже?
ОРС сервер например
ЗЫ мне процитировать надо, что Ваш мужик уверен в правоте своей программы, а моими советами займется позже?
А куда ему этот ОРС сервер в своей программе присобачить ? Нет у него никакой уверенности, потому и мечется. У него легкая паника, поэтому и посты неадекватные. Я бы на его месте сидел и долбил свою программу до полной победы.
Василий пропал куда-то (но дело его живет)
Я думаю, мужик только тем и занимается, что ищет ошибки в своей программе для ПК
Ну всяко бывает. Например глаз замылился. Я вот предложил обрисовать алгоритм.
И какая разница - на каком языке написано. Сериал-порт - место где последовательно появляются байты и утверждается что появились нули в месте КС.
Если какие-то помехи, что возможно, то какие-то избирательные, гурманы так сказать. Едят исключительно КС. Это нормально ?
Вот скажите уважаемый Вольд, какая разница для слейва - кто его опрашивает ? Я могу на ПЛК поменять частоту опроса.
ОС Windows периодически вмешивается в работу прикладной программы (прерывает). Я думаю разберется мужик со своими проблемами, вроде он толковый. А то на форуме периодически такие дятлы появляются, просто страшно становится за Россию.
А причем здесь ПЛК-слейв ?
А причем здесь ПЛК-слейв ?
ПЛК, вероятно, все правильно делает, а вот у приложения для ПК с приемом пакетов-откликов проблемы возникают. А может и с программой ПЛК что-то у него не так. Короче, надо сидеть и разбираться и все у него для этого есть. А нам волноваться особо не стоит.
Ну так на это и capzap намекает достаточно толсто
А нам волноваться особо не стоит
За шайбу незасчитанную волнуемся
Ну так на это и capzap намекает достаточно толсто
За шайбу незасчитанную волнуемся
Да, это ужас какой-то, если гол действительно был, а его не засчитали ! А установить истину при нынешних технических средствах не проблема (все ходы записаны). Короче, скандал.
Василий_S
24.02.2014, 15:23
В общем, получается такая штука. В моменты, когда в ответе из ПЛК в КС стоят нули, сама КС равна 256 в децималах или 100 в хексах (должно ли быть такое вообще?). Т.е. получается, что в КС,в положенные два символа,, при значении равном 100 в хексах, записываются второй и третий символ (нули), а единица куда-то теряется.
Был проведён эксперимент: "ловить" содержимое ответа ПЛК при условии:
1. если в КС стоят два нуля, как хексовские символы;
2. если в КС стоит один ноль, как хексовский символ;
3. если в КС пусто
4. если превышен таймаут ожидания.
При этом в строку текстового файла записывалось:
1. Адрес ПЛК;
2. Время записи;
3. количество повторных запросов к ПЛК;
4. содержимое буфера;
5. отдельно вычисленная КС в децималах;
6. перевод вычисленной КС в хексы;
7. реальные символы из КС;
8. длина буфера;
9. флаг функции вычисления КС (1, если вычисленная КС совпадает с реальной, 0 - если не совпадает)
10. флаг таймаута ожидания (1 - если время превысило уставку, 0 - если нет.)
Результат такой: везде, где в месте КС стоят нули вычисленная КС = 256 в децималах.
Переведённая подсчитанная КС в хексы показывает 0, поскольку функция расчитана на перевод двух символов.
Вырезанная - показывает то, что есть - "00"
При этом длина буфера равна требуемой - 75, ну и флаг по КС равен логическому нулю, да, и флаг по таймауту тоже в нулях.
Пример:
содержимое буфера:
:23 03 20 (0058 0000) (007Е 0000) (00А3 0000) (0006 0000) (0000 0000) (0038 0000) (0003 0000) (0000 0000) 00 ||
, вроде перепечатал без ошибок. В скобках - подсчитанные импульсы на 8-ми входах ПЛК (Hex), жирным шрифтом - содержимое КС
Вычисленная КС = 256(Dec)
Количество повторных запросов - 20 (такая уставка)
длина буфера = 75 - видимо, приём ответа от ПЛК полный и нет записей содержимого буфера в другой файл по событию, если длина буфера меньше 75.
Что получается, ПЛК теряет "1" - первый символ из 100(Hex) и пишет в КС два нуля?
Вот пока в пути и не рядом с компом, появилось несколько вопросов
Модбас аскии чем определяется конец посылки?
Сколько байт занимает контрольная сумма и сколько это в количественном формате отображается в консоли
:) пока все, на телефоне не вижу текст поэтому мысль потерял
Василий_S
24.02.2014, 15:54
Посылка по модбасу в ASCII-режиме заканчивается последовательностью "возврат каретки-перевод строки".
Перед ней КС занимает 2 символа, насколько понимаю.
Приёмное устройство - MOXA CP-114IS/DB9M V1.3 на 4 порта. Может не стыкуется мокса с овеном в "отдельные моменты"?
Блин вроде всё правильно, а при расчете кс инверсия и прибавление единицы делается
И самое главное не вставляется ли высчитанная кс на клиенте в приемный буффер,а потом уже логинится в файл
Василий_S
24.02.2014, 19:05
Может так и задумано в ПЛК Овен, что 256(Dec) представляется двумя нулями и надо иметь ввиду, что это 100(Hex), следующая цифра после FF? Интересно, почему овеновцы молчат?
Вы не катите на овен, есть те же орс серверы модбас, ставим их и смотрим логи, появятся ли там подобные ошибки, поймите алгоритм lrc достаточно прлст, чтоб программист его не смог соблюсти. И чем мусолить эту тему, прлтестируйте свою программу на комп.эмуляторе слейва. Тем более когда у Вас известен весь пакет с нулевой кс, Вы знаете какое/кие числа там находятся и заполнить эмулятор проблем нет и в случае если в течении n-ного времени ошибок не будет,тогда предъявляйте документированную претензию
Василий_S
24.02.2014, 19:30
Что за манера?
На вопрос, просто, что ли не в состоянии ответить? Смысл эмулятор трясти. Алгоритм КС стандартен, овен написанные запросы понимает и на них реагирует, причём адекватно.
А что мне ещё делать остаётся делать? Если предположение верно, не просто ли просто сказать - да, подтвердить предположение. Мне дальше надо определяться, как ситуацию отигрывать. И вообще никто в теме дельного не посоветовал. Только Хорнет помог определиться в каком направлении искать.
Послушайте, у меня на ПК собственная программа читает четыре плк семеновских и четыре винтековские панели и по протоколу dcon на айспидас выдаю сигналы. Так вот у меня все работает,не на столе а на производстве, так что единственный кто что то путнее сказал, это Я, великий и ужасный
Василий_S
24.02.2014, 20:46
Молодец. Не забудь про бюст на родине.
Только мне бы убедиться, что 100(Hex) - это именно "00" в КС. Тогда проблема решается.
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot