Здравствуйте. На объекте в отдельном шкафу установлены неск. контроллеров Gesytec EMC4, которые через аналоговые выхода включают/выключают оптореле 5DC/220AC PhoenixContact. Сами релюхи (2 штуки на контроллер) управляют приводом клапана фанкойла - открытие или закрытие, управляющий сигнал - 24АС.
Через некоторое время, происходит подвисание обоих аналоговых выходов контроллера в состоянии 10В, соответственно включаются обе релюхи, привод начинает сходить с ума
При этом некоторые контроллеры продолжают работать нормально, выявить какую-либо закономерность в подвисании пока не удалось.
Программа написана на NodeBuilder, код управления оптореле выглядит след. образом:


Через 150 сек (время движения привода) происходит сброс реле в 0:


В Lonmaker Browser видно, что переменные nviAnalog ВСЕГДА отрабатывают нормально.

Библиотека EMC4.nc управления входами-выходами контроллера взята у Gesytec.

Как выходит из подвисания - самостоятельно, ручным reset'ом, программным reset'ом (watchdog) или как-то иначе?

Возможно зависает микропрограмма узла, тогда должен срабатывать сторожевой таймер и узел самопроизвольно перезапустится. В этом случае в статистике узла в причинах последнего reset'а будет записано Watchdog Timer.

Возможно выходы переходят в некое состояние по какой-то сетевой или иной причине. Когда подвиснут выходы надо посмотреть функциональный блок SFPTnodeObject и в его переменную nvoStatus (SNVT_obj_status), в этой переменной много битовых полей и возможно это даст дополнительную информацию.

Возможно это связано с настройками Heartbeat'ов входных переменных nviAnalog и выходной/ых переменных, связанных с ними. (Heartbeat выходной переменной в общем случае должен быть в 4 раза меньше Heartbeat'а связанной с ней входной переменной).

Выходит из подвисания либо сбросом питания, либо перепрошивкой.
Программный reset не пробовал.
Спасибо за советы - проверю на объекте.

WatchDog timer в ресете не прописан. Там либо software, либо power up.
В переменной nvoStatus (для большинства контроллеров) установлены битовые поля: disabled, comm_failure, report_mask.
Хотя все контроллеры через сеть видятся, состояние - online...
Возможно ли, что такое пагубное влияние оказывает некачественное заземление линии Lonworks (кабель - наш аналог Belden 7704NH)?
Некоторые участки линии проложены практически вплотную к силовым кабелям.

Вероятно, заземление линии Lonworks в данном случае не причем. Т.к. пагубность влияния на линии Вы бы наблюдали в интенсивно растущем числе ошибок приема и передачи (статистика самодиагностики узла). Кстати, не вредно это проверить.
Знать бы схему вашего узла?..
В качестве предположения,- если аналоговые выходы реализованы SPI ЦАП'ами, то подобное их поведение может быть вызвано сбоями на SPI шине, которые являются следствием каких-то помех, например, по питанию, или по иным линиям, гальванически связанным с "общим" Вашего устройства.

У меня был аналогичный случай с контроллерами MB2. Так вот там напряжение на аналоговом выходе менялось только если менялся последний млаший бит. Странно но факт. Попробуйте

сейчас подумал и вспомнил еще одну возможную причину. Проверьте узел на :

- внутреннее зацикливание программы
- статистику Lost message

Если да - свистните - расскажу что можно сделать дальше.

Подправил исходную библиотеку EMC4.nc от Gesytec - увеличил время обработки событий на входах-выходах. Плюс сделали заземление на линии LON через RC-цепочку. Пока зависания прекратились, надо далее наблюдать...
Аналоговый выход (как видно из куска программы выше) устанавливается всегда в константу (0 или 10В), Lost message не наблюдается, загрузка сети менее 1%.