ЛБ5.X ЛБ5.4-ШУЛК32-КЗ цепи безопасности

[revit]

После запуска первых двух ЛБ5.4 -ШУЛК32(v. 0.0.4) часто появляется КЗ ЦБ на обоих. Лифты в паре, работают нормально. Посмотреть в MBLog состояние контрольных точек нельзя. Откуда такой глюк?

 

[oleg]

После запуска первых двух ЛБ5.4 -ШУЛК32(v. 0.0.4) часто появляется КЗ ЦБ на обоих. Лифты в паре, работают нормально. Посмотреть в MBLog состояние контрольных точек нельзя. Откуда такой глюк?

Этот алгоритм перекочевал еще от релейных станций - "Одновременное наличие РОД и РКД".
ЛБ для ШУЛК32 получает сигналы из последовательного канала - РКД - это KV13, РОД - управление РОД.

При задержках возникающих в канале обмена (при ближайшем рассмотрении) возможна ситуация срабатывания данного алгоритма.
Решение простое - либо увеличить время в 213 ячейке, либо заблокировать в 32 ячейке. Для микропроцессорных станций контроль по данному алгоритму - избыточен. В следующих версиях микропрограмм для ЛБ - это исправится.

 

[revit]

Да так и сделал 32=0. Просто интересно знать причину.

 

[oleg]

Да так и сделал 32=0. Просто интересно знать причину.

Вопрос снят. В математике ЛБ6-ШУЛК32 - учтено...

 

[revit]

Кстати и на ШУЛК-17 такое иногда бывает.

 

[oleg]

Вопрос снят. В математике ЛБ6-ШУЛК32 - учтено...

Вдогонку... по результатам командировки в Новокузнецк. Для станции ШУЛК32 рестарт - штатная ситуация. После рестарта станция просыпается (до начала обмена) - 10-15 сек. Время обнаружения потреи связи со станцией в ЛБ-ШУЛК32 - 3 сек. соответственно много ложных сообщений о потере связи. Метод лечения - в яч 226 - записать 15. Что будет соответствовать 25 сек ожидания данных от станции до установления признака потери связи.

 

[revit]

....соответственно много ложных сообщений о потере связи. Метод лечения - в яч 226 - записать 15. Что будет соответствовать 25 сек ожидания данных от станции до установления признака потери связи.

Точно!, бывает иногда. Уже начал задумываться почему. Так что твой ответ как раз кстати.
Будем править 226-ю.

 

[revit]

226 подправили, но на одной станции почему-то иногда вываливается "отсутствует напряжение в цепи управления" и через минуту пропадает. Почему?

 

[revit]

Уточню: пропадала через несколько секунд. Поличил 208=15. Вроде выличилось. Буду наблюдать.

 

[oleg]

Уточню: пропадала через несколько секунд. Поличил 208=15. Вроде выличилось. Буду наблюдать.

Ремарка... Для начала обмена станции достаточно просто проснуться за 10 сек - "Отсутствует связь с MCS" не появится. А вот чтобы начать отдавать корректные данные - еще необходимо на малой скорости дотащиться до этажа и открыть двери - только после этого данные будут корректными и при такой ситуации возможно появление "Отсутствует напряжение в цепи управления" - ибо для ЛБ все это время нет корректных данных со станции...

Так что похоже будет все нормально.

 

[revit]

C 208=15? А почему на рядом стоящей станции такого не наблюдалоcь, и работают в паре.
А с другой стороны, конечно, в этом бреде отечественных разработчиков наверное очень нелегко разобраться?

 

[oleg]

C 208=15?

Именно.

А почему на рядом стоящей станции такого не наблюдалоcь, и работают в паре.

По идее можно разобраться... если нужно.

А с другой стороны, конечно, в этом бреде отечественных разработчиков наверное очень нелегко разобраться?

Ну... на счет отечественного бреда - это погорячился... у буржуев "тараканов" в мозгах железяк не меньше... (просто реже сталкиваемся или они хорошо прячутся).

А по поводу концепций диспетчеризации в родном отечестве - да небыло их в свое время. Этим и обьясняется многообразие и разношерстность в подходах к каждой станции.

 

[revit]

Ну да, да. А как обстоят дела со стандартизацией единого протокола? Пора бы вам что-нибудь такое придумать и раздавать нашим разработчикам в виде рекомендаций.

 

[oleg]

Ну да, да. А как обстоят дела со стандартизацией единого протокола? Пора бы вам что-нибудь такое придумать и раздавать нашим разработчикам в виде рекомендаций.

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

 

[revit]

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

 

[oleg]

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

У буржуев не лучше... только сейчас технология CAN-open - первая робкая попытка унификации железяк по интерфейсам, поддерживаемая кстати далеко не всеми ведущими производителями лифтов...