Паразитный выходной импульс - как устранить?

[Владимир Ситников]

И так мы разобрались почему ПР воспринимает потенциал на входе как фронт при вкл. питания ПР и почему при уставке ноль формируется импульс длиной с цикл ПР.... Кстати и счетчик посчитает это за фронт при включении питания ,если до этого на входе была 1 (напряжение)

Есть такая штука, "спецификация" называется.
Например, в стандарте 61131 явно записано как должны действовать R_TRIG и F_TRIG:

Снимок экрана 2018-02-18 в 16.29.46.png
Снимок экрана 2018-02-18 в 16.30.11.png

Тут и текстом, и кодом (даже код реализации R_TRIG/F_TRIG оказался в стандарте!) сказано, что R_TRIG и F_TRIG должны считать за фронт, если при их первом включении на входе будет TRUE/FALSE


Конечно, МЭК 61131 имеет весьма опосредованное значение для ОЛ, ведь, ОЛ для электронщиков предназначено, но хотелось бы верить, что разработчики ОЛ хотя бы изредка оглядываются на МЭК.


Но, к слову, стандарт 61131 ничего не говорит о работе TP при PT=0, т.е. тут дело остаётся на совести ОВЕН: хотят они или нет документировать то, как "в теории" должно работать ОЛ.

[rovki]

Есть такая штука, "спецификация" называется.
Например, в стандарте 61131 явно записано как должны действовать R_TRIG и F_TRIG:

Снимок экрана 2018-02-18 в 16.29.46.png
Снимок экрана 2018-02-18 в 16.30.11.png

Тут и текстом, и кодом (даже код реализации R_TRIG/F_TRIG оказался в стандарте!) сказано, что R_TRIG и F_TRIG должны считать за фронт, если при их первом включении на входе будет TRUE/FALSE


Конечно, МЭК 61131 имеет весьма опосредованное значение для ОЛ, ведь, ОЛ для электронщиков предназначено, но хотелось бы верить, что разработчики ОЛ хотя бы изредка оглядываются на МЭК.


Но, к слову, стандарт 61131 ничего не говорит о работе TP при PT=0, т.е. тут дело остаётся на совести ОВЕН: хотят они или нет документировать то, как "в теории" должно работать ОЛ.

речь не о том как должен обрабатываться первый фронт (и так понятно) ,а о том что должно быть при включении питания (первом старте) ПР ,если на входе 1 .Если на входе (физическом или переменной) стоит единица ,то R триггер сформирует импульс ,это свойство неоднократно используется в схемах для выявления события -включение питания .Тем более ,я уже сказал - что и в "железных"(реальных) таймерах будет запуск таймера в такой ситуации (переходной процесс) .Вопрос был как устранить этот эффект и был дан ответ (два варианта) ...

[SideMoon]

Но, к слову, стандарт 61131 ничего не говорит о работе TP при PT=0, т.е. тут дело остаётся на совести ОВЕН: хотят они или нет документировать то, как "в теории" должно работать ОЛ.

Давайте дождемся мнения представителя Овена.
Может быть Овен в следующей версии Owen Logic исправит мелкую ошибку в макросе TP и дело с концами.

[Владимир Ситников]

Давайте дождемся мнения представителя Овена.
Может быть Овен в следующей версии Owen Logic исправит мелкую ошибку в макросе TP и дело с концами.

Да вы что.
Во-первых, в ОЛ всё хорошо.
Во-вторых, если исправить даже мелкую ошибку в макросе TP, то все имеющиеся проекты станут работать по-другому, а значит, могут сломаться. И кому это нужно?

[Karkade]

если исправить даже мелкую ошибку в макросе TP, то все имеющиеся проекты станут работать по-другому, а значит, могут сломаться. И кому это нужно?

Как раз в мою тему. Я из опасений таких "модернизаций" хочу иметь резервную копию софта и чтобы она могла установить в ПР ту же версию прошивки, которая использовалась на момент разработки и отладки проекта.
Иначе в случае претензий , заказчику ничего не докажешь.
http://www.owen.ru/forum/showthread.php?t=28230

А исправить ошибку можно созданием макроса TP_NEW

[Владимир Ситников]

исправить ошибку можно созданием макроса TP_NEW

Сразу уж TP_20180219, через какое-то время TP_20180923 и так далее.
Представляете как будет выглядеть перечень ФБ? Вообще ни одну схему составить не получится, только и будешь, что список ФБ прокручивать.
Вывод -- не нужно никаких TP_NEW.

[melky]

/* ------------------- TP ------------------- */
TP::TP()
{
	IN = false;
	PT = 0;
	_M = false;
	_StartTime = 0;
	Q = false;
	ET = 0;
}
TP::TP(unsigned long PT)
{
	IN = false;
	TP::PT = PT;
	_M = false;
	_StartTime = 0;
	Q = false;
	ET = 0;
}
boolean TP::Run(boolean IN)
{
	TP::IN = IN;
	if (!_M) {
		if (TP::IN) {
			_M = true; // взводим флаг М
			_StartTime = millis();
			if (ET < PT)
				Q = true;
		}
	} else {
		if (Q) {
			ET = millis() - _StartTime; // вычисляем время
			if (ET >= PT)
				Q = false;
		} else {
			if (!TP::IN) {
				_M = false;
				ET = 0;
			}
		}
	}
	return Q;
}

Код реализации ТР на ПК - паразитных импульсов при PT=0 НЕТ. что не так с программированием ?

[melky]

Владимир Ситников если в программе кому-то необходим импульс, то человек просто будет использовать R_Trig без всяких TP с нулевой уставкой. Нет?, я ошибаюсь и применять будут именно ТР ?

[capzap]

Владимир Ситников если в программе кому-то необходим импульс, то человек просто будет использовать R_Trig без всяких TP с нулевой уставкой. Нет?, я ошибаюсь и применять будут именно ТР ?

а как Вам эта фраза из 55 поста

Режимы использования таймера каждый выбирает сам

может и будут, Вам откуда знать

[Владимир Ситников]

маленькая поправка, если заметили МЕМ расположен в области ретайн,

Да, тут меня правильно поправили. Реально R_TRIG не "включение" а "1-е выполнение" отрабатывает так, как будто до этого сигнал был FALSE (и код и текст на это указывают).

при очередном включении могут происходить "нежданчики", например если вход тоже TRUE то будет потеря импульса фронта у R_TRIG

Если устройство выключается при CLK=TRUE, то, конечно, оно никак в выключенном состоянии не поймёт были ли изменения CLK. И, если после включения CLK будет равно TRUE, то R_TRIG ничего не сгенерирует.

Честно говоря, не возьмусь рассуждать нужен ли эффект "RETAIN по умолчанию", но оно хотя бы описано, и можно рассуждать "подходит ли для конкретной задачи или нет".