Логика: Распознать отдельно короткое и отдельно длинное нажатия (CodeSys v3)

[Cs-Cs]

Teemon Двумя вещами:
а) SysCom
б) Нормально написанным конечным автоматом для диммера.
Ща портировал на CDS v3.5, и при опросе 9 модулей IO всё пашет. Пока ещё тестирую.
Про планировщик, про прочее - позже будут посты. Сильно позже.
Да, запросы составляю вручную. Код примерно такой злой:

IF (bPortR1Open = TRUE) THEN
	CASE iMBReqStateR1 OF
		iReqR1W2Msk:	//ОПРОС МОДУЛЯ W1 - Маска Входов
			fbMbReqW2Msk(
				bEnable:= TRUE, 
				hPort:= hPortR1, 
				pCmdBuffer:= ADR(pBuffReqReadDIMaskW2), 
				pCmdBufferLen:= SIZEOF(pBuffReqReadDIMaskW2), 
				pRcvBuffer:= ADR(bfRecieveBuffer), 
				pRcvBytesNeed:= wBuffAnswReadDIMaskW2, 
				bCheckCRC:= TRUE, 
			);
			IF (fbMbReqW2Msk.bComplete = TRUE) THEN	//Парсим данные в DWORD маски входов, если запрос завершился успешно
				iMBReqStateR1 := iReqR1W2Cnt;	//Идём на следующий шаг
				iomW2DIMask := BYTE_TO_DWORD(bfRecieveBuffer[6])				//Входы 1-8
							OR SHL(BYTE_TO_DWORD(bfRecieveBuffer[5]), 8*1)		//Входы 9-16
							OR SHL(BYTE_TO_DWORD(bfRecieveBuffer[4]), 8*2)		//Входы 17-24
							OR SHL(BYTE_TO_DWORD(bfRecieveBuffer[3]), 8*3);		//Входы 25-32
			END_IF

... ... ... ... ...

IF (bPortR2Open = TRUE) THEN
	CASE iMBReqStateR2 OF
		iReqR2W5Out:	//ОПРОС МОДУЛЯ W5 - Маска выходов !!
			bfSendBuffer[0]	:= 20;		//Адрес 
			bfSendBuffer[1]	:= 16#10; 	//Команда
			bfSendBuffer[2]	:= 16#00; 	//Старший (начальный адрес регистра)
			bfSendBuffer[3]	:= 16#61; 	//Младший (начальный адрес регистра)
			bfSendBuffer[4]	:= 16#00; 	//Старший (число регистров)
			bfSendBuffer[5]	:= 16#02; 	//Младший (число регистров)
			bfSendBuffer[6]	:= 4; 		//Число байт данных (далее)
			bfSendBuffer[7]	:= DWORD_TO_BYTE(SHR(wBitMask32W5, 8*3)); //16#FF; 	//Выходы 25-32
			bfSendBuffer[8]	:= DWORD_TO_BYTE(SHR(wBitMask32W5, 8*2)); //16#FF; 	//Выходы 17-24
			bfSendBuffer[9]	:= DWORD_TO_BYTE(SHR(wBitMask32W5, 8*1));// 16#FF; 	//Выходы 9-16
			bfSendBuffer[10]:= DWORD_TO_BYTE(SHR(wBitMask32W5, 8*0));// 16#FF;	//Выходы 1-8 

			CSMBAddBuffCRC(ADR(bfSendBuffer), SIZEOF(bfSendBuffer), 11);

			fbMbReqW5(
				bEnable:= TRUE, 
				hPort:= hPortR2, 
				pCmdBuffer:= ADR(bfSendBuffer), 
				pCmdBufferLen:= 13, 
				pRcvBuffer:= ADR(bfRecieveBuffer), 
				pRcvBytesNeed:= wBuffAnswWriteDOMaskW5, 
				bCheckCRC:= TRUE, 
			);

			IF (fbMbReqW5.bComplete = TRUE) THEN
				iMBReqStateR2 := iReqR2W6Out;
			END_IF

[Teemon]

Teemon Двумя вещами:

О, ну по коду ничего страшного не вижу, на S7-1200 тоже так писал, всё "ручками". Зато работало как часы.
ЦРЦ драйвер сам считает или нужно тоже руками считать?
Кстати, в модбасе неизбжено (но тут уже что уж поделать) - если у меня будет ошибка опроса\таймаут - и в этот момент я жму кнопку - я потеряю её нажатие... Но по идее в шкафу ошибок должно быть очень, очень мало. Что говорит статистика?

Как в итоге автомат работает, одиночное, длительное, двойное нажатие как разделяешь?
Какой диммер?

[Cs-Cs]

Teemon Не, драйвер только гоняет байты. Причём все равно какие и сколько. Тупо выплёвывает буфер в порт, и всё. Или читает из полрта в буфер столько, сколько скажешь. Поэтому всё ручками. Там у меня вон функция даже есть - "CSMBAddBuffCRC" =))
Статистику ещё не причесал со старого формата опроса. Визуально - летает всё, ошибок нет.
Сливаю идею: одинарные/двойные нажатия кнопок у ОВЕНа круто ловить по счётчикам импульсов модулей IO. Поэтому даже если ошибка будет - то при следующем опросе, который быстро происходит, нажатие отловится. Если же ошибка длится дольше XX времени - то логика обработки кнопок перезапускается, и тогда нажатие потеряется. Чтобы не было такого, что через полчаса модуль подключили - и пошли нажатия, которые уже не нужны.

Автомат работает как обычный конечный, как подсказывал Krollcbas в начале темы: считаю условные тики (tick) и по их числу перехожу или в состояние "Single" или в состояние "Long", блокируя остальную логику.
Что значит - "какой диммер"? Ну, диммер. Как обычно он и должен работать.

[Teemon]

Teemon Не, драйвер только гоняет байты. Причём все равно какие и сколько. Тупо выплёвывает буфер в порт, и всё. Или читает из полрта в буфер столько, сколько скажешь. Поэтому всё ручками. Там у меня вон функция даже есть - "CSMBAddBuffCRC" =))
Статистику ещё не причесал со старого формата опроса. Визуально - летает всё, ошибок нет.
Сливаю идею: одинарные/двойные нажатия кнопок у ОВЕНа круто ловить по счётчикам импульсов модулей IO. Поэтому даже если ошибка будет - то при следующем опросе, который быстро происходит, нажатие отловится. Если же ошибка длится дольше XX времени - то логика обработки кнопок перезапускается, и тогда нажатие потеряется. Чтобы не было такого, что через полчаса модуль подключили - и пошли нажатия, которые уже не нужны.

Автомат работает как обычный конечный, как подсказывал Krollcbas в начале темы: считаю условные тики (tick) и по их числу перехожу или в состояние "Single" или в состояние "Long", блокируя остальную логику.
Что значит - "какой диммер"? Ну, диммер. Как обычно он и должен работать.

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

[Teemon]

Интересно...
https://ftp.owen.ru/CoDeSys3/98_Book...kManagment.pdf

Таким образом, если в проекте есть задача с адекватным временем цикла (например, для
протокола Modbus – 10…20 мс) – то описанные выше настройки задач всех Modbus-компонентов
можно оставить в значениях по умолчанию, и при этом никаких проблем с обменом не возникнет.
С другой стороны, если пользователь, например, увеличит время задачи MainTask до 100
мс (и при этом в проекте не будет задач с меньшим временем цикла) – то обмен будет работать
некорректно (с точки зрения пользователя опрос будет медленным, часть ответов slave-устройств
будет пропущена).

" (с точки зрения пользователя опрос будет медленным, часть ответов slave-устройств
будет пропущена)." - как это " часть ответов будет пропущена"??? Я так понимаю, увеличение времени цикла определяет просто частоту посылок запросов\обработки ответов? Что происходит на последовательном порту при приеме данных? Если это аппаратный модуль, там обычно буфер, куда всё и складывается... В кодесис по идее тоже при приёме данных они "сами" должны ложиться в какой-то буфер, не?.. У Сименса модули последовательной связи вроде этим и занимаются. А тут как? Типа если вызвал задачу раз в 100мсек, а где-то посередине был приём, который твоя программа пропустила и не сложила в буфер приема??.. Кто может разжевать.

[Teemon]

Страница 24:
У внимательных пользователей может возникнуть вопрос – а как именно компоненты
Modbus обрабатываются в контексте вызывающей их задачи? Точное описание работы
коммуникационных драйверов отсутствует, но в целом можно считать, что операции, связанные с
обменом (например, чтение/запись из COM-порта) выполняются асинхронно по отношению к
задаче цикла шины. В задаче CODESYS происходит только синхронизация буферов драйверов с
каналами компонентов. В справке CODESYS приводится следующий рисунок, который поясняет
принцип работы драйверов:

По идее, задача обмена данными имеет приоритет над остальными, а то я думал, что может быть, HMI и другие задачи грузили контроллер в твоем случае и "прерывали" задачу обмена?..

[Teemon]

CS, не пробовал применять тип задачи - Тип задач «Событие» для "отлова" изменения входного сигнала на модуле DI? Или это неприменимо для данного случая?..
CS, а чем конкретно этот пример
https://ftp.owen.ru/CoDeSys3/11_Docu...odbus_v2.0.pdf
плохо работает? И почему "самописное" складывание данных в порт\из порта работате лучше\быстрее? Это норма?)

[Cs-Cs]

Мне НЕ нравятся такие подробные беспардонные расспросы. Как владелец своего блога я умею отличать вежливые и подробные вопросы от тех, кто хочет сразу, всё и на блюдечке. К таким ситуациям у меня идиосинкразия. Острая.
Будет пост - вот там и будет всё показано и рассказано.

[Teemon]

Да как по твою душу угодно будет. Вопрос то был простой по своей сути - разобраться удалось где и что не работает или нет

[Cs-Cs]

Почему-то эта суть растянулась на кучу сообщений...
Вот я ДОДЕЛАЮ - и выложу сюда видоса кусок. Ты же на тему подписан? Не просто так забежал?
Вот выложу - ты увидишь. Скорость опроса меня втащила: на 9 модулях летает так, как на штатном планировщике на пяти модулях не летало.