MODBUS COM отслеживание записи в канал

[RomeoVar]

я делал и так, и асинхронно. Это остался последний вариант, в котором я считал кол-во циклов, через которое данные запишутся в переменную из канала.
Происходит так - подымаешь флаг execute , xbusy поднимается в true. Данные записываются в переменную （примерно 30мс）, a xbusy висит, xdone не поднимается. Пока опять не запишешь в xexecute TRUE. Могу видео записать


Вот как-то так выходит

Я грешу на конфликт каналов с разными параметрами обмена. Или слишком высокая скорость обмена. У Вас в видео 9600, для моих задач этого мало

Пол дня вчера на исследование этой темы ухлопал, и остался на месте.
Сначала я сделал по рекомендации, Ваше видео посмотрел. Неа, ниче не работает

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

я делал и так, и асинхронно. Это остался последний вариант, в котором я считал кол-во циклов, через которое данные запишутся в переменную из канала.
Происходит так - подымаешь флаг execute , xbusy поднимается в true. Данные записываются в переменную （примерно 30мс）, a xbusy висит, xdone не поднимается. Пока опять не запишешь в xexecute TRUE. Могу видео записать


Вот как-то так выходит

Я грешу на конфликт каналов с разными параметрами обмена. Или слишком высокая скорость обмена. У Вас в видео 9600, для моих задач этого мало

Пол дня вчера на исследование этой темы ухлопал, и остался на месте.
Сначала я сделал по рекомендации, Ваше видео посмотрел. Неа, ниче не работает

Вы точно посмотрели видео из моего предыдущего поста?
В нём ваш проект со скоростью 38400 и исправленным кодом - и ловится каждый импульс xDone.

[RomeoVar]

Проблема, похоже была в этом куске кода (с 8 по 11 строки).
Было так:

IF fbModbusRol.xExecute THEN
	fbModbusRol(slave := ROL_DORNA, xExecute := FALSE, iChannelIndex := iCurrentCh);
END_IF

Сейчас я изменил на такой

IF fbModbusRol.xExecute THEN
	fbModbusRol.xExecute := FALSE;
END_IF

Спасибо.
Буду проверять на рабочем проекте

[RomeoVar]

Да, я увидел свой прокол
Но очень странно. В документации четко написано (по переднему фронту xExecute). Передний фронт был. Т.е. нужно было дождаться сигнала xDone и только потом прекращать вызов функционального блока. Т.е. операции чтения/записи и формирования сигналов выполняются ...
Все, понял. Спасибо.

[RomeoVar]

Нужно было делать так:

RTRIG_fbMbRolDone(CLK := fbModbusRol.xDone);

IF RTRIG_fbMbRolDone.Q THEN
	xSuccess := TRUE;
	fbModbusRol.xExecute := FALSE;
	xRdPosReg := FALSE;
END_IF

IF xRdPosReg THEN
	//xSuccess := FALSE;
	wIntPosPOld := GVL.stServo[1].stRdServo.wP700_IntPosP;
	GVL.stServo[1].stWrServo.wP700_IntPosP := 4610;
	GVL.stServo[1].stWrServo.wP765_IntPosDZT := 1000;
	fbModbusRol(slave := ROL_DORNA, xExecute := xExecModbus, iChannelIndex := iCurrentCh);
	ltTimeOfStart := TargetVars.stRtc.ltSystemTick;
	//xRdPosReg := FALSE;
	xCount := TRUE;
	iCntr := iCntr + 1;
END_IF

[DenisV]

Screenshot_3.png
Вырезка из той же статьи. А что значит потеря части ответов? Значения будут переданы не верно или просто не переданы?

Как я заметил, интервал выполнения задач очень сильно влияет на производительность и загрузку процессора.
А если происходит управление не критичной системой, то есть, где допустИм большой интервал ответа устройства. Можно ли как-то изменив интервал задач создаваемых Codesys как-то оптимизировать процесс и отдать предпочтение например более быстрой работе визуализации или в целом меньшей загрузке процессора?

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

Screenshot_3.png
Вырезка из той же статьи. А что значит потеря части ответов? Значения будут переданы не верно или просто не переданы?

Как я заметил, интервал выполнения задач очень сильно влияет на производительность и загрузку процессора.
А если происходит управление не критичной системой, то есть, где допустИм большой интервал ответа устройства. Можно ли как-то изменив интервал задач создаваемых Codesys как-то оптимизировать процесс и отдать предпочтение например более быстрой работе визуализации или в целом меньшей загрузке процессора?

Если у вас период опроса = 100 мс, таймаут = 1000 мс и период вызова задачи = 1000 мс - то, вероятно, ни одного ответа от slave-устройства вы в программе не увидите.
Это как пример.

Можно ли как-то изменив интервал задач создаваемых Codesys как-то оптимизировать процесс и отдать предпочтение например более быстрой работе визуализации или в целом меньшей загрузке процессора?

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

[DenisV]

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

В то же время согласно статье этого не рекомендуется делать, без четкого понимания своих действий. Пока к сожалению не могу сказать этого о себе, также сложно понять допустимые пределы настроек для нормальной работы. Может вы можете дать несколько советов по настройкам и оптимизации конкретного проекта? Может тогда мне удастся осознать всю концепцию.
Master-TCP Master Таймаут ответа 1000мс
AO_D1(МУ210-501) - мин.период опроса 200 мс
AI_D2 (МВ210-101) - мин.период опроса 600 мс
AI_D3 (МВ210-101) - мин.период опроса 600 мс
AI_D4 (МВ210-101) - мин.период опроса 600 мс

Интервалы MainTask=20мс, AlarmManagerTask=50мс, OwenCloudTask=100, Visu_task=100
Приоритеты по умолчанию.
Screenshot_1.pngScreenshot_2.png

Как можно в данном случае снизить нагрузку на процессор и немного увеличить скорость работы визуализации, пожертвовав скоростью опроса.

P.S И должна ли частота обновления экрана соответствовать интервалу выполнения задачи VISU_TASK для лучшего быстродействия ?

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

также сложно понять допустимые пределы настроек для нормальной работы.

Это и правда сложно - потому что для этого нужно сформулировать критерии "нормальной работы".

Как можно в данном случае снизить нагрузку на процессор и немного увеличить скорость работы визуализации, пожертвовав скоростью опроса.

Можете попробовать для AlarmManagerTask поставить 200 мс, для MainTask = 50 мс, для VISU_TASK приоритет = 30.

P.S И должна ли скорость выполнения задачи VISU_TASK соответствовать частоте обновления экрана ?

Желательно, чтобы сооответствовала или хотя бы была кратна.

[RomeoVar]

Пока я отлаживал моменты взаимодействия с Modbus у меня возник такой вопрос.
Специфика моей работы такова, что я с реальным контроллером взаимодействую 2*2 (2 дня работаю, 2 выходной). Мне в голову пришла мысль Взять SoftPLC ( Например CODESYS Control Win V3 ) , MasterOPC Universal Modbus, 2 USB адаптера RS485 (CH340g).
У меня получилось так:
CODESYS Control Win V3 - Добавил Com-порт, привязал к первому адаптеру 485 (порт № 5). Настроил модбас, добавил устройство.
MasterOPC Universal Modbus - настроил ка Slave, привязал ко второму адаптеру (порт №8)
Запускаю - все вроде работает, пакетами обмениваются, только при попытке записать или считать записанные значения в/из тэга MasterOPC Universal Modbus приходят нули.
Я опять где-то косячу? Или это все-таки ограничение CODESYS. Т.к. если такая фича прокатит можно к любому компу "прикрутить" модуль ввода вывода, работающего по modbus и фактически получить SoftPLC?
Заранее признателен
Если нужно позже могу записать видео, как чего я делал