PDA

Просмотр полной версии : СПК107 не работает ФБ UNM_SerialRequest OwenCommunication



eigor_vl
21.07.2020, 14:45
Добрый день.
Ситуация такая:
Программа на ST.
Порт открывается OCL.COM_Control.
передача данных происходит OCL.UNM_SerialRequest, устройство отвечает!
А дальше OCL.UNM_SerialRequest данные в буфер не принимает выдает ошибку TIME_OUT!
То есть вообще. Ни при каких
tTimeout, szExpectedSize, wStopChar.
Пишет uiResponseSize = 0.

Хотя на другом порту OCL.MB_SerialRequest работает!

Вот код.

// VAR COM3 Master
abIGM_Req: ARRAY [0..9] OF BYTE;
abIGM_Res: ARRAY [0..13] OF BYTE;

iIGM_T: INT;
iIGM_CO2: INT;

iDeleyReq: INT:= 0;

fbComControl3: OCL.COM_Control; // ФБ упр-я COM3
fb_module_IGM_1: OCL.UNM_SerialRequest; // ФБ опроса уст-ва IGM_1

iStateCom3: INT; // шаг опроса по порту COM3

// END_VAR COM3 Master




////
CASE iStateCom3 OF
0: // открытие порта COM3

fbComControl3
(
xEnable:= TRUE,
udiComPort:= 3, // RS485-3
udiBaudrate:=9600,
udiByteSize:=8,
eParity:= OCL.COM_PARITY.NONE,
eStopBit:=OCL.COM_STOPBIT.ONE

);

// ИГМ-0171
// 0x23 0x30 0x31 0x44 0x41 0x54 0x41 0x3f 0x0d 0x0a
// #01DATA?
// 30 30 32 36 34 20 30 33 30 35 38 0d
// 00264 03058
abIGM_Req[0]:= 16#23;
abIGM_Req[1]:= 16#30;
abIGM_Req[2]:= 16#31;
abIGM_Req[3]:= 16#44;
abIGM_Req[4]:= 16#41;
abIGM_Req[5]:= 16#54;
abIGM_Req[6]:= 16#41;
abIGM_Req[7]:= 16#3F;
abIGM_Req[8]:= 16#0D;
abIGM_Req[9]:= 16#0A;



IF fbComControl3.xDone THEN
iStateCom3:=1;
END_IF

1: // опрос IGM_1

fb_module_IGM_1
(
xExecute:= TRUE,
tTimeout:= T#1000MS,
szExpectedSize:= 0, // разные врианты :=12 , 0
wStopChar:= 16#000D, // разные врианты :=16#0000, 0
usiRetry:= 1, // кол-во повторов
hCom:= fbComControl3.hCom,
pRequest:= ADR(abIGM_Req),
szRequest:= SIZEOF(abIGM_Req),
pResponse:= ADR(abIGM_Res),
szResponse:= SIZEOF(abIGM_Res)

);


iIGM_T:= fb_module_IGM_1.uiResponseSize;

IF fb_module_IGM_1.xDone OR fb_module_IGM_1.xError THEN
// после выполнения блока его нужно сбросить
fb_module_IGM_1(xExecute:= FALSE);
iIGM_T:= abIGM_Res[0];
iIGM_CO2:= abIGM_Res[1];

iStateCom3:= 2;
END_IF

2: // опрос EF170_2


iStateCom3:= 1;



END_CASE

////

Подскажите что не так.

Евгений Кислов
21.07.2020, 16:27
Добрый день.


передача данных происходит OCL.UNM_SerialRequest, устройство отвечает!

Как вы это определяете?

eigor_vl
21.07.2020, 23:22
Подключился параллельно терминалкой и смотрю порт.
50269

eigor_vl
21.07.2020, 23:38
А в какой момент UNM_SerialRequest переключается на прием? После отправки 10 -го байта?
И почему если считает что таймаут вышел не отправляет повторных запросов если usiRetry:= 3 например?

Евгений Кислов
22.07.2020, 04:45
А в какой момент UNM_SerialRequest переключается на прием?

На следующем цикле после отправки.
У вас эта программа выполняется в задаче с каким временем цикла?

eigor_vl
22.07.2020, 08:35
Код опроса датчика выполнялся в действии, которое вызывалось из основной программы (СОМ3()).
Перенес код опроса в основную программу все заработало!
Я не очень понимаю как выполняются задачи.

Спасибо!
Буду разбираться.

vkykypy3o
09.06.2026, 16:50
Добрый день!

Столкнулся с такой же проблемой:
ПЛК210, RS-485_2 (9600, 8-N-1)
Блок UNM_SerialRequest вызывается в основном таске (пробовал и свободное выполнение и цикл 1 мс)
tTimeout := t#1000ms
szExpectedSize := 0
wStopChar := 16#0

Ответ блока всегда один и тот же: eError = TIME_OUT

Параллельно терминалом считываю всё, что летит по шине: запрос есть, ответ тоже есть

Счётчик циклов основного таска и в свободном выполнении и в цикле 1 мс (длительность выполнения до 20 мкс) растёт с одинаковой скоростью, а значит переключение порта с записи на чтение не может быть быстрее чем оно уже есть.

Подскажите, пожалуйста, что можно сделать в данном случае?

Евгений Кислов
09.06.2026, 17:01
Добрый день.
Для начала установите для задачи интервал вызова 20 мс.

vkykypy3o
09.06.2026, 17:15
Все так же TIME_OUT

vkykypy3o
09.06.2026, 17:49
При помощи терминала выяснил, что первый символ ответа приходит спустя 8 мкс после последнего символа запроса. Если переключить порт с записи на чтение можно только в цикле ПЛК, то тут уж никак не поймать ответ :(

Евгений Кислов
09.06.2026, 17:54
первый символ ответа приходит спустя 8 мкс после последнего символа запроса

И на стороне slave-устройства нет никакой настраиваемой задержки перед ответом?


Если переключить порт с записи на чтение можно только в цикле ПЛК

Можете попробовать организовать работу с портом через библиотеку SysCom.
Она работает синхронно, так что позволяет реализовать отправку запроса и получение ответа в пределах одного цикла.
Возможно, в вашем случае этого окажется достаточно (но уверенности нет).

vkykypy3o
15.06.2026, 15:55
И на стороне slave-устройства нет никакой настраиваемой задержки перед ответом?
К сожалению нет, это электронная нагрузка АКИП (он же ITECH) с ПО от NI


Можете попробовать организовать работу с портом через библиотеку SysCom.
Она работает синхронно, так что позволяет реализовать отправку запроса и получение ответа в пределах одного цикла.
Возможно, в вашем случае этого окажется достаточно (но уверенности нет).
А вот это получилось с библиотекой CAA SerialCom! Сделал в пределах одного цикла ПЛК вызовы блока Write по циклу WHILE, пока не будет ошибки или выполнено, после чего вызывается блок Read

Проблема теперь другая: блок Read выдаёт затроение ответа. То есть терминалом я вижу определённую последовательность символов ответа (она правильная), а блок Read помещает в буфер три такие же последовательности подряд (никаких дополнительных символов в промежутках и по краям нет). Блок Read вызываю без цикла WHILE по одному вызову в цикле ПЛК

vkykypy3o
15.06.2026, 17:11
Проблема теперь другая: блок Read выдаёт затроение ответа. То есть терминалом я вижу определённую последовательность символов ответа (она правильная), а блок Read помещает в буфер три такие же последовательности подряд (никаких дополнительных символов в промежутках и по краям нет). Блок Read вызываю без цикла WHILE по одному вызову в цикле ПЛК
Оказалось всё банально просто: я забыл оконечный нулевой байт при формировании строки из массива байтов, поэтому просто читал не только свою новую строку, но и старые данные, в которых оказались такие же ответы.

В итоге опрос быстроотвечающего устройства получился такой: при помощи библиотеки CAA SerialCom в одном цикле ПЛК вызывается блок Write в цикле WHILE, пока не выполнится, после чего один раз вызывается блок Read, а уже следующим циклом ПЛК повторный вызов блока Read даёт ответ от устройства

Спасибо!