ПЛК 210-2 работа с 232

[Илья2]

Добрый день, нужно отправить по 232 запрос на инициализацию связи с СПТ-944 29 байт информации из которых (FF) 20 штук + 9 байт кода.
"FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 10 00 3F 00 00 00 00 C0 16"
использую блок fbComControl открываю ком порт и блоком fbComSend пробую отправить данные и не могу их уместить в одном сообщении.
при попытке отправить в формате STRING сообщение принимается кодировкой UNICODE и чтобы получить "FF"нужно отправить "я" а последние 9 байт не получается преобразовать.
при попытке отправки через переменную LWORD упираюсь в предел калькулятора. явно надо делить сообщение вот только нет понимания как прибор поймет разделенные сообщения как единое.
может сталкивался с такой задачей?

[Евгений Кислов]

Добрый день, нужно отправить по 232 запрос на инициализацию связи с СПТ-944 29 байт информации из которых (FF) 20 штук + 9 байт кода.
"FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 10 00 3F 00 00 00 00 C0 16"
использую блок fbComControl открываю ком порт и блоком fbComSend пробую отправить данные и не могу их уместить в одном сообщении.
при попытке отправить в формате STRING сообщение принимается кодировкой UNICODE и чтобы получить "FF"нужно отправить "я" а последние 9 байт не получается преобразовать.
при попытке отправки через переменную LWORD упираюсь в предел калькулятора. явно надо делить сообщение вот только нет понимания как прибор поймет разделенные сообщения как единое.
может сталкивался с такой задачей?

Добрый день.
Используйте ARRAY OF BYTE [0..28]

[melky]

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

[Илья2]

Уже есть готовые запросы прибору для каждого из параметра. главное теперь разобрать ответ)))

[Илья2]

Да, использовав ARRAY OF BYTE [0..28] получилось отправить корректный запрос, но когда начал пробовать читать ответ по такой же схеме (через ARRAY OF BYTE ) теряю половину ответа
прибор отправляет часть кода "10 00" получаю в плк от - "10", а 00 нет.
а когда отправляю в плк "10 00 00 00" получаю "10 00". это плк как то преобразует переменные по интересному переменные или я неверный формат выбрал?

T1_TB1_answer_1 := OSCAT_BASIC.BYTE_TO_STRH(abyResponseBuffer[0]);
T1_TB1_answer_2 := OSCAT_BASIC.BYTE_TO_STRH(abyResponseBuffer[1]);
T1_TB1_answer_3 := OSCAT_BASIC.BYTE_TO_STRH(abyResponseBuffer[2]);
T1_TB1_answer_4 := OSCAT_BASIC.BYTE_TO_STRH(abyResponseBuffer[3]);

STATE.READ_1:
fbComRead
(
xExecute := TRUE,
hCom := fbComControl.hCom,
pBuffer := ADR(abyResponseBuffer),
szBuffer := SIZEOF(abyResponseBuffer)
);

[melky]

таймауты на ответ, размеры буфера и т.д.
То есть контрольные суммы ответов проверять не надо, доверимся прибору как есть? :)
Ну и насколько помню, 944-й это М4 протокол, там можно одним запросом запросить кучу параметров, а не тыкать его носом в каждый.

[Cs-Cs]

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

pBuffer и szBuffer показывают не то, скоглько штук байт НАДО принять, а сколько штук байт мы можем принять за один раз.
В реальности fbComRead примет столько, сколько успело прийти в порт на текущий момент обработки программы.
То есть, мы ожидаем, что будет так: Вызвали - он принял szBuffer байт или меньше, и мы их сразу получили.
На самом деле скорее всего оставшиеся байты дойдут в следующем цикле программы ПЛК.
Поэтому надо так:
* Заводим какой-то буфер принятых данных и счётчик байт в нём
* Когда начинаем приём, обнуляем буфер и счётчик
* Каждый раз, когда fbComRead выполнился, смотрим, сколько байт он принял и добавляем их в наш буфер, собирая ответ по частям
* Когда приняли нужное число байт (длина ответа) или когда увидели нужный ответ (если он заканчивается известными нам байтами) - обрабатываем его.
* Должен быть ещё какой-то таймаут вида "Если прошло хх времени и приняли недостаточно байт - ошибка".

[Илья2]

Даже с буфером принимаю некорректные значения)))) буфер на 10 секунд. один фрагмент уже по 1 байту пробую разбирать и все равно не то отправляю "10 00 3f 54" получаю "10 3F F5" 75363

[МихаилГл]

Может это модуль сам нули "съедает"?
Я для стороннего протокола по RS485 использую вот это:
75367,
Потом ответ парсю... Вроде пропусков и окон в ответах не было...

[melky]

10 01 3f 54 2c 02 3d 16 - это пример ответа 944 на первый запрос с кучей FF + тело запроса.

у вас после 10 идет 3F в ответе ну и маловато у вас байтов в принципе, так как в ответе прибор должен свой идентификатор вернуть, а это 54 2c далее вроде версия прошивки и CRC или CS не помню уже.
Такое ощущение, что у вас порт проглатывает некоторые байты, ну или программа проглатывает.

[МихаилГл]

Проще ТС проверить как работает программа на геркулесе. Я помню тоже как то мучился со строками запроса. В процессе преобразований что-то съедалось. Кроме этого модули работы с портами тоже бывает съедают нулл символы и считают что дальше них запроса нет. Поэтому надо не 00 например посылать а в формат типа $XX преобразовывать. Но лучше сначала напрямую с ПК проверить и потом сравнивать с тем, что вы в кодесисе получаете.

[Илья2]

Спасибо всем за советы и варианты решения, перепробовал много способов, оказалось ошибка была в том что стартовый бит 1 для плк нужно указывать. Программе все равно сколько бит хоть 1 хоть 2,3.