Просмотр полной версии : Опрос тепловычислителя СПТ940
Товарищи форумчане, всем доброго времени суток.
Подскажите, пожалуйста, кто-нибудь пробовал опросить тепловычислитель СПТ940 по протоколу Modbus RTU или эта затея - утопия и пора начинать "копать" в сторону протокола М4?
А у него есть Modbus?
з.ы. чем опрашивать собираетесь? я просто для Логики писал драйвер, но он пока без поддержки протокола М4. Если он у вас на столе, то могу доработать.
Сделать для него шлюз в Modbus или в OPC UA вполне возможно...
Согласно одно из мануалов, протокол Modbus RTU есть, но опросить им тепловычислитель не получается (родной OPC работает без проблем), особенно по порту RS232 (отвечу наперёд, один из кругов ... пройден, интерфейс "побежден", путем доработки преобразователя AC3-M).
Пока пытаюсь опросить СПТ940 Owen OPC Server'ом, но всё тщетно.
Сергей0308
15.03.2022, 13:59
Согласно одно из мануалов, протокол Modbus RTU есть. Опросить тепловычислитель по протоколу Modbus RTU не получается (родной OPC работает без проблем), особенно по порту RS232 (отвечу наперёд, один из кругов ... пройден, интерфейс "побежден", путем доработки преобразователя AC3-M).
Пока пытаюсь опросить СПТ940 Owen OPC Server'ом.
Какое-то нарушение здравого смысла: пишите, что поддерживает протокол Модбас, а опрашиваете(пытаетесь опросить) по протоколу Овен, мне так кажется!
Сергей, где я написал, что пытаюсь опросить прибор протоколом ОВЕН?:)
Сергей0308
15.03.2022, 14:04
Сергей, где я написал, что пытаюсь опросить прибор протоколом ОВЕН?:)
В названии ОРС-сервера!
В названии ОРС-сервера!
Дык он (Owen OPC Server) и с Modbus "дружит"...
Вот же: https://owen.ru/product/new_opc_server
Сергей0308
15.03.2022, 14:09
Дык он (Owen OPC Server) и с Modbus "дружит"...
Тогда непонятно зачем у Овена два ОПС-сервера, Овен и Модбас?
Ну, если, сервер, что у вас используется поддерживает модбас - нет проблем!
Подозреваю, что нет там никакого Modbus. Либо должна быть определенная модификация, либо возможно (с трудом верится) надо включить Modbus. Но не помню, чтобы у них такое было. Остается М4, раз родной OPC работает.
Написать опрос в ПЛК63 думаю будет крайне сложно, учитывая протокол. Хотя бы потому, что прибор немного конфигурируемый.
Ссылку на документацию именно вашей версии покажите, откуда вы взяли, что там Modbus есть ?
ну я не увидел по нему наличия Modbus, где вам это приснилось?
ну я не увидел по нему наличия Modbus, где вам это приснилось?
Вполне явная информация в документе "РАЖГ.421412.035 Д7", и в ответе тех. поддержки годичной давности (собственно, на основании их ответа и был приобретён данный тепловычислитель).
Написать опрос в ПЛК63 думаю будет крайне сложно, учитывая протокол. Хотя бы потому, что прибор немного конфигурируемый.
Если я правильно понял, то Приборист (по информации из ветки ПЛК1хх) справился с этой задачей...
Spawn не путайте ПЛК100 и 63, а то может оказаться памяти не хватит.
Если будете корячить все таки в ПЛК 63, то помогу чем смогу. По крайней мере расчет CRC без проблем. Ну и некоторое понимание определения местоположения данных, они там поддаются расчету.
Вы задали адрес NT ? и я нашел по Modbus таблицу, но сам документ имеет имя СПТ941 хотя по самому тексту везде 940
Вы задали адрес NT ? и я нашел по Modbus таблицу, но сам документ имеет имя СПТ941 хотя по самому тексту везде 940
Задал адрес (NT), задал скорость и "идентификатор оборудования" (КИ).
Spawn не путайте ПЛК100 и 63, а то может оказаться памяти не хватит.
Если будете корячить все таки в ПЛК 63, то помогу чем смогу. По крайней мере расчет CRC без проблем. Ну и некоторое понимание определения местоположения данных, они там поддаются расчету.
С CRC, вроде, разобрался, по крайней мере с алгоритмом ее расчета. Расчеты CRC из документации совпадают с моими.
Все-таки пишите на ST для ПЛК63?
из того, что помню. Если переменная не влазит в страницу памяти, то она разрывается на две страницы. Начало переменной в конце одной страницы, конец переменной в начале следующей.
Страницы памяти имеют заголовок и контрольную сумму. Если вы считаете две страницы памяти, то будет так
заголовок1 - данные_страницы1 - CRC_стр1 - заголовок2 - данные_страницы2 - CRC_стр2
В общем чутка попляшите с бубном :)
В общем, получилось достучаться до прибора по протоколу Modbus RTU, но осталась незавершенная работа с протоколом М4. Никак не могу установить сеанс связи с прибором.
При попытке записать в порт абракадабру вида "16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#10, 16#02, 16#3F, 16#00, 16#00, 16#00, 16#00, 16#BE, 16#16", прибор в ответ шлет всего четыре байта: "16#32, 16#09, 16#04, 16#16", а должен присылать восемь байт: "16#10, 16#02, 16#3F, 16#92, 16#28, 16#00, 16#04, 16#16". Если значения 16#04 и 16#16 еще можно хоть как-то отнести к "хвосту" ответа, то от куда берутся 16#32 и 16#09 и почему ответ всего из четырех байт, не понятно...
Если в этом же (моем) коде переписать значения буфера на запрос Modbus RTU, то ответы от СПТ940 приходят "адекватные".
Не пойму в чем затык...
Вот лог опроса тепловычислителя OPC-сервером ЛОГИКА:
59813
Пробовал и с паузой, и без, и вообще без 16-ти FF - результат одинаковый: "16#32, 16#09, 16#04, 16#16"...:)
Причем, если, например, в запросе изменить адрес прибора (NT) с 02 на 03 (в приборе адрес оставить без изменений - 02), с пересчетом КС8, соответственно, то прибор молчит, значит, можно сделать вывод, что данные до прибора доходят, но в ответ он шлет какую-то несуразицу. Если КС8 "похе..ть", прибор тоже молчит...
Попробую заслать абракадабру с ПК.
Попробую заслать абракадабру с ПК.
В терминале на запрос "16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#10, 16#02, 16#3F, 16#00, 16#00, 16#00, 16#00, 16#BE, 16#16" нормальный ответ приходит: "16#10, 16#02, 16#3F, 16#92, 16#28, 16#00, 16#04, 16#16".
melky, помогайте. :)
Куда копать?
Spawn начните с изучения протокола в первую очередь, есть документация на него.
Ориентироваться на лог обмена между OPC сервером и прибором надо осторожно, так как он посылает много служебной информации.
И да, он посылает первый раз 16-ть байт FF для инициализации линии или что-то вроде этого. Причем насколько помню, при обмене с ПК через интерфейс может работать и без этого. + пауза скорее всего должна быть.
// отправка стартовой последовательности
Connection.Write(ProtoRS.StartSequence, 0, ProtoRS.StartSequence.Length);
Thread.Sleep(Math.Min(ReqParams.Timeout, 1050)); // TODO !!!
Пауза нужна. глянул в свой код...
Spawn начните с изучения протокола в первую очередь, есть документация на него.
Что его изучать-то? Запрос сеанса связи "как на ладони". :)
Затолкал в порт "16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#10, 16#02, 16#3F, 16#00, 16#00, 16#00, 16#00, 16#BE, 16#16", получил (должен получить) "16#10, 16#02, 16#3F, 16#92, 16#28, 16#00, 16#04, 16#16".
С терминала в порт отправлял запрос без всяких задержек (25 байт подряд одной "строкой"), ответ от СПТ приходит нормальный. Не пойму, в чем принципиальная разница использования задержки при отправке в порт данных с ПК и с ПЛК?
так как он посылает много служебной информации.
О какой служебной информации идет речь? В логе обмена (пост #16) ничего об этом не "сказано". :cool:
Что его изучать-то? Запрос сеанса связи "как на ладони". поверьте, вам это только кажется.
Когда вы согласно документации составите один запрос, то увидите разницу. OPC отправляет часто повторяющиеся запросы. Например на каждую переменную в странице отправляет по одному одинаковому запросу, хотя в странице памяти сразу несколько переменных, которые прочитав страницу можно разобрать. Экономится время на запросах.\
пЕсатели протокола Логика и в том числе OPC сервера те еще извращенцы оказались :)
С терминала в порт отправлял запрос без всяких задержек
Вы сами задержкой являетесь, достаточной для прибора, если вы кодом отправляете, то задержки уже программные, которых может не быть.
16#10, 16#02, 16#3F, 16#00, 16#00, 16#00, 16#00, 16#BE, 16#16
Вот здесь у вас почему-то в блоке данных запроса нули. а по своим логам глянул у меня тоже нули... Это всего лишь запрос версии ПО и идентификатора прибора
Это всего лишь запрос версии ПО и идентификатора прибора
Вот же ш:
1.
59853
2.
59854
3.
59855
Получается, что запрос "составлен" корректно (сокращенный формат сообщений):
59856
Я специально "слушал" порт при работе OPC-сервера, чтобы посмотреть то, что шлет он, а он шлет тоже самое, что написано в мануале и тоже самое, что шлю и я с ПЛК и с ПК (терминала). Только ответ на ПК (что в OPC, что в терминале) приходит корректный, а на ПЛК, такое ощущение, что какой-то битый, причем, судя по двум последним байтам ответа, приходит только конец, начало где-то теряется...
Ну это вопрос к ПЛК, почему он херит ответ
Ну это вопрос к ПЛК, почему он херит ответ
Ну осталось самое простое - понять что и где не так...:D
Я где-то вначале писал, что пробовал в своем коде менять только "наполнение" буфера на отправку, писал (руками побайтно, для М4 тоже буфер заполнен побайтно) значения запроса протокола Modbus RTU - ответ приходит тот, который и должен быть.
Жаль, что нет под рукой другого ПЛК, чтобы проверить работу протокола М4 на нем...
Если стать на прослушку между ПЛК и СПТ940 вы увидите полный ответ или так же битый ?
Если стать на прослушку между ПЛК и СПТ940 вы увидите полный ответ или так же битый ?
Подключился к шине RS-485 (ПЛК-СПТ):
59873
:confused:
"Худой конец": либо код "кривой" :D (вопрос - как тогда Modbus RTU работает?), либо ПЛК63...
Постепенно приходим необходимости изучения кода
Да, я уже и сам к этому "пришел"...:D
В коде "небольшой" рабочий беспорядок, прошу громко не материться...
Spawn честно не представляю, как такие вещи писать на ПЛК. Вызывать соответствующие методы на обработку и так далее.
Это вы еще до float не добрались, который в СПТ совсем не IEEE754
С шага 1 (если был до того был неоткрыт) уход на 4 (мимо 16xFFh)
?
Валенок, эта "редакция" проекта на проверку работы Modbus RTU, там и в 4-м шаге массив заполнен байтами для этого протокола.
Во вложении вариант с паузой для М4. Для запроса без паузы, нужно править шаг 2.
Я же говорю - рабочий беспорядок...:)
Который появился в результате проверки всевозможных вариантов.
Это вы еще до float не добрались, который в СПТ совсем не IEEE754
melky, проблемы нужно решать в порядке их поступления, тут бы, для начала, с сеансом связи разобраться...:)
Вроде речь о 16-ти
А зачем в запросе OPC-сервера ЛОГИКА их 20 (а не 16)? Что 16, что 20, что 30 FF ничего не меняют, это я уже в самом конце их 30 сделал, с целью посмотреть что изменится в ответе СПТ...
Зачем 3 буфера ?
Чтобы смотреть, что там в них происходит.
2 таймера, 3 буфера и нули никак на результат не влияют, он всегда один и тот же, а весь этот обоз - результат безуспешных экспериментов, в самом начале был фен-шуй...:)
У меня складывается впечатление, что проблема в ПЛК (толи порт не успевает "развернуться", толи проблема из разряда Modbus ASCII на ПЛК63/73), потому как, даже этот бардак в коде, протоколу Modbus RTU не мешает корректно работать.
Думаю еще на UNM попробовать, или смысла нет?
Достал СПК110[М01]...
Тупо скопировал код (со всем имеющимся в нем бардаком) в проект CDS 3.5:
60265
Spawn судя по скрину порт успевает развернуться ? :)
Spawn судя по скрину порт успевает развернуться ? :)
Да... и судя по нему же, на 63-м не успевает...:)
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot