При первом скане X0 "пропустит" импульс к М2. Без разницы, где будет X0 при этом.
ISP функциональный блок
Re: ISP функциональный блок
Re: ISP функциональный блок
Речь была не о первом скане а о первом использовании ФБ(когда идет нарастающий импульс М0). А при первом скане импульс к М2 по-любому блокируется через М10.
В аналогичном варианте без ФБ все корректно.
В аналогичном варианте без ФБ все корректно.
Re: ISP функциональный блок
Тут вся загвоздка в том, как происходит обработка вызова функционального блока. Есть подозрение, что при вызове функция ведёт себя по другому, относительно просто куска кода в основном цикле.не исключено что при вызове она передаёт состояние х0 в свою часть и это обрабатывается как передний фронт.
П.с. я вот только реально не знаю, зачем вам этот гемморой, поскольку вы сейчас пытаетесь пойти по пути, который китайцами не предусматривался, так сказать использовать баг как фичу. Это очень скользкая дорожка, ведь потом читаемость кода станет отвратительной, а отладка в онлайне невозможной вовсе, поскольку в фб можно залазить только для просмотра. Любая корректировка только через перепрошивку.
П.с. я вот только реально не знаю, зачем вам этот гемморой, поскольку вы сейчас пытаетесь пойти по пути, который китайцами не предусматривался, так сказать использовать баг как фичу. Это очень скользкая дорожка, ведь потом читаемость кода станет отвратительной, а отладка в онлайне невозможной вовсе, поскольку в фб можно залазить только для просмотра. Любая корректировка только через перепрошивку.
Re: ISP функциональный блок
В WPLSoft, если он еще у вас есть, нарисуйте)) этот примерчик. И в режиме Sep Run "погоняйте" его.
Важно! Состояние дискретных входов (Х0, Х1...) всегда обновляется/запоминается в начале скана.
- Вложения
-
- Скан_1.png (38.19 КБ) 2055 просмотров
-
- Скан_2.png (39.02 КБ) 2055 просмотров
Re: ISP функциональный блок
Запустил ваш примерчик на WLPSoft(хоть им и не пользуюсь) в дебагере, режим 'Step run'. И абсолютно тот же самый эффект. Ну разве вы его не замечаете? Повторю условия когда это проявляется: Х0 всегда "ON". Только при ПЕРВОМ вызове подпрограммы Р1 (нарастающим фронтом М0) включается маркер М2. При последующих "сбросах" М0, М10, М2 и вызове подпрограммы Р2, маркер М2 не включается.
Вот для того и нужен, чтоб знать как он проявляется и и успешно его обходить.
А то заподозрил, что в голове с алгоритмами и логикой что-то уже не то, и бросать пора это дело.
Re: ISP функциональный блок
Так же , как и без подпрограммы - М2 остается в OFF.)
Так и должно быть. В чем прикол?)
- Вложения
-
- Scan_3.png (35.09 КБ) 2052 просмотра
-
- Scan_4.png (35.32 КБ) 2052 просмотра
Re: ISP функциональный блок
Прикол в ПЕРВОМ вызове подпрограммы Р1, М2 включается в "ON". А он не должен включаться НИКОГДА, при условии что Х0 всегда "ON". Ну ведь на вашем же скрине с подпрограммой видно, что М2 "зеленый" (ON), чего быть не должно.
Re: ISP функциональный блок
Это вы так считаете. Дельта считает по другому!))
При первом скане LDP Х0 работает также, как LDP M11.
- Вложения
-
- Scan_5.png (38.73 КБ) 2046 просмотров
Re: ISP функциональный блок
Надеюсь, что это все-таки не не китайская логика , а временно неисправленный баг компилятора.
И резюмируя все вышеизложенное стало ясно, что баг проявляется внутри подпрограммы (между инструкциями CALL и SRET), и только при первом вызове этой подпрограммы. А именно при обработке инструкции LDP device, при условии что device="ON". Сигнал проходит через эту инструкцию, чего быть не должно. А вот с LDF такого не наблюдается(ну, хоть и на этом спасибо).
Поэтому, лучше не использовать LDP в подпрограмме, при первом ее вызове.
Спасибо всем, кто откликнулся.
Re: ISP функциональный блок
вообще-то это нормальная логика. поскольку вы инициализируете передачу параметров внутрь подпрограммы в момент ее вызова, соответственно для подпрограммы вновь появившийся сигнал X0 определяется как восходящий фронт.