Сразу скажу опыта по твидо нет. В общем надо было проанализировать работу оборудования. Изредко возникали проблемы. Подключился к контроллеру во время работы. Замечано:
1. Отображение работы (засвет зеленым) идет с задержкой. Ну полагаю так должно быть
2. Чтобы проанализировать интересующую цепь заснял видео на фотоаппарат. Т.к. глазами не успеваешь понять. Просмотрел покадрово. И обнаружил - фото первое. Т.е. наблюдаю разрыв цепи, но выход остается быть включенным. Так не всегда - было и нормально отключался.
Создается вопрос - это программа TwidoSuite глючит с отображением или всё-таки это в контроллере проблема.

P.s. была раз у нас интересная ситуация. В контроллере GeFanuc на оборудовании тетра пак завис также выход, но только навсегда. Пока в ручную из программы не сбросили. В моем случае выход работает, но по снятому видео получается "поздно "отпускает".

Отображение в Твидо Сьют с задержкой, да и сам он тормознутый немного.
Если снимали покадрово, то могли видеть через сколько секунд выход "погасал".
Для проверки выхода попробуйте в цепь добавить один из свободных входов ПЛК --| / |-- %Ix.x и подавая на него +24В наблюдайте как быстро среагирует программа.
Если хотите более оперативного обновления информации когда вы online то подключайтесь не по кабелю RS485/232 а через TCP/IP
Нажмите для просмотра прикрепленного файла

Меня больше интересует вопрос по п.2

Покадрово замечал как выключение выхода сразу при разрыва цепи, так и выключение с задержкой (как на фото1)

А на самом деле как?

Смотреть на выход %Q2.2 при этом следует не в программе а на модуле расширения (второй справа от ПЛК модуль, третья сверху лампочка в левом ряду)
Там идет индикация замыкания контактов выхода

Всё это быстро происходит, что углядеть невозможно. Это надо снимать и выходы на контроллере и работу программы одновременно, и покадрово сравнить одновременно ли выключается выход в программе и на контроллере.
В данный момент (что я снимал) оборудование работало нормально без сбоев. Но бывает 2-3 раза за смену, что устройства сталкиваются друг с другом. Т.е. у меня версия, что если подвисает выход (по фото 1). Площадка не опускается и другая площадка бьет по ней.
В принципе мой вопрос и заключался, может ли так глючить контроллер? Может кто сталкивался? Если может, то искать причину в этом. Если такого не может быть, то мою версию отбросить и искать дальше.
Если это было бы чаще, то проще было бы найти причину. А так 2-3 раза за смену не поймаешь.

Дело в том, что модули расширения для Twido не обладают собственным обработчиком и этим знят сам недоПЛК Twido из-за этого время его цикла меняеться в зависимости от того как часто меняються вх./вых. может быть даже так, что некаторые "моргания" на входах, ПЛК просто не "увидит", т.к. будет занят чем-то другим.
Из этого - упрощенно цикл вашего ПЛК:
обработка входов --> обработка программы пользователя --> изменение выходов

Если ПЛК занимался обработкой выходов и в этот момент приходит сигнал нга его входы, что пора двигать площадку
то это тутже подхватываеться в следующем шаге, меняеться логика работы (согласно программе пользователя) и передается изменения на выхода.

А если сигнал на вход ПЛК пришел в тот момент когда ПЛК заканчивал обработку своих входов, то ему придеться ждать целых два шага (обработка программы пользователя и обработка выходов) вот отсюда, я думаю и выросло Ваше "зависание".

Но на твидо тут не погрешишь, он и не позицианируется как быстродейственный ПЛК, т.к. это даже не ПЛК, это некое переходное состояние от ПР к ПЛК.

Вам выход один, разделить в программе по времени через таймер (хотя бы 50ms) два этих действия, будет чуть медленнее (на 50мс) но надежнее.
И еще можете выход добавить в блокировку на вторую площадку, так уж точно все хорошо будет.

Спасибо
А по блокировке:
Чтобы было понятней опишу. Есть площадка (выход Q2.2) - ход вверх\низ (низ - датчик на вход I0.9). Когда площадка внизу стол перемещается в исходное состояние (датчик на вход I0.7). Когда стол отводится (датчик на отвод стола I0.8) площадка поднимается. Стол управляется сервоприводом. Сигнал на старт стола Q0.3.
Проводил эксперимент. Отсоединял датчик I0.9 - стол никак не двигается. Потом только залез в программу. действительно там прописано - рис 2. На рис 1 управление площадкой. Единственное думаю попробовать вход I0.8 прописать между I0.0 и Q2.2. И посмотреть что будет.

Попутно вопрос. Не могу понять как в TwidoSuite поиск работает. Мне, например, нужно найти все строчки где присутствует I0.9.

Курсор на контакт %I0.9, правой кнопкой мыши "go to the reference" будете видеть все строки и секции где используеться контакт, единственное ограничение что отображаются только первые 20 (может чуть меньше/больше) упоминаний о переменной (если считать по программе сверху вниз, слева на право)

Исходные состояния : площадка в нижнем положении, стол в исходном состоянии (допустим крайнее левое положение)
1. Движение стола вправо до концевика %I0.8
2. Подъем площадки (странно что нет концевика)
3. Мероприятия на площадке
4. Спуск площадки до концевика %I0.9
5. Возвращение стола в исходное состояние (влево) до концевика %I0.7
6. = 1.
и т.д.
на всякий случай внес переменную "signal_up" для того что бы программа знала когда поднимать, когда опускать площадку

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

Описанная ситуация может возникнуть по нескольким причинам:
1. Обновление экрана компьютера происходит не синхронно с циклами контроллера. Интерфейс и протокол связи достаточно медленный для такой задачи.
2. Формирование состояния переменной, в том числе и состояние выхода может быть в разных рангах или секциях программы. Таким образом, возможно этот выход активируется в другом месте программы. При компиляции и загрузки, TwidoSuite выдаёт соответсвующее предупреждение.

Более интересно посмотреть состояние программы и контроллера в момент "зависания". Скорее всего это проблема в программе, но может и отсутствие внешних сигналов от концевиков, взаимоисключающие состояния входов которые не предусмотрены в программе.
Вы можете создать блок диагностики, в котором опишите допустимые состояния и недопустимые и создайте сигнал ошибки. Так же очень часто ошибку в программе может вызвать "дребезг" контакта датчиков, так как мало кто учитывает постепенный износ оборудования в своих программах.