Глюк при заливке ядра.

[tvf]

Доделываю объект, замороженный более года назад. Контроллеры Пиксель 2511. Версия лоджика 3.25.76 запросила обновление ядра. На 3 контроллерах обновление произошло штатно, за исключением того, что для обновления пришлось вытаскивать батарейку. Спишем это на старое ядро. А на одном из контроллеров процесс загрузки ядра пошел, но в процессе загрузки выскочило сообщение типа "Попытка загрузки ядра в неподходящий тип контроллера". Загрузка ядра оборвалась. Контроллер стоит с погашенным экраном и горящим красным светодиодом. На манипуляции с клавиатурой ни как не реагирует. При попытке обнаружить контроллер Лоджиком выскакивает сообщение типа "Попытка остановить работу мастера" и процесс обнаружения контроллера срывается. Танцы с бубнами типа вставления/удаления батарейки ни к чему не приводят.
Каковы варианты реанимации контроллера?

[Den]

Сообщение от tvf

Доделываю объект, замороженный более года назад. Контроллеры Пиксель 2511. Версия лоджика 3.25.76 запросила обновление ядра. На 3 контроллерах обновление произошло штатно, за исключением того, что для обновления пришлось вытаскивать батарейку. Спишем это на старое ядро. А на одном из контроллеров процесс загрузки ядра пошел, но в процессе загрузки выскочило сообщение типа "Попытка загрузки ядра в неподходящий тип контроллера". Загрузка ядра оборвалась. Контроллер стоит с погашенным экраном и горящим красным светодиодом. На манипуляции с клавиатурой ни как не реагирует. При попытке обнаружить контроллер Лоджиком выскакивает сообщение типа "Попытка остановить работу мастера" и процесс обнаружения контроллера срывается. Танцы с бубнами типа вставления/удаления батарейки ни к чему не приводят.
Каковы варианты реанимации контроллера?

1. Загрузить еще раз
2. Попробовать загрузить версию от Пиксель12
ПС: если светится красный светодиод, то работает бутлоадер, который ждет прошивку.

[tvf]

Если эти варианты не сработают, загрузка через Гипертерминал поможет решить проблему?

[Arsie]

Сообщение от tvf

Если эти варианты не сработают, загрузка через Гипертерминал поможет решить проблему?

Скажем так - гипертерминал является дублирующей программой.

В отличии от лоджика он как один раз более 20 лет назад был написан Микрософтом, так и существует в неизменном виде.

А лоджик постоянно меняется.

[tvf]

Вылечить удалось 1 способом.

1. Загрузить еще раз

Правда есть одна тонкость:
1. Не включая питания контроллера надо запустить поиск.
2. Потом прервать поиск.
3. Запустить обновление ядра.
4. Включить питание контроллера.

Возможно это не единственный вариант, но без запуска поиска обновление ядра не запускалось.

[Arsie]

Сообщение от tvf

Вылечить удалось 1 способом. Правда есть одна тонкость:
1. Не включая питания контроллера надо запустить поиск.
2. Потом прервать поиск.
3. Запустить обновление ядра.
4. Включить питание контроллера.

Возможно это не единственный вариант, но без запуска поиска обновление ядра не запускалось.

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

Я передал программистам, они поищут, но не факт, что найдут.

Этот контроллер теперь нормально перешивает своё ядро, если попробовать это сделать?

PS. Вообще, у меня есть мысли, что происходило:

Загрузка ядра прервалась не важно по какой причине (помеха, глюк или челябинский метеорит) и контроллер "встал" в непонятный бесконечный цикл с участием 485-го порта. Функция загрузки ядра увидела какое-то неправильно шевеление на линии и поэтому отказалась грузить, интерпретировав это шевеление по своему.

Включение вами поиска инициировало подавление лоджиком работы сети (так называемое "выключение мастера"), контроллер хоть и впавший в безумие, это отработал и перестал шевелить порт.

После этого загрузка ядра отработала корректно.

Если я прав, то за этим можно гоняться долго и безперспективно, т.к. отловить именно тот момент, когда у вас прервалась связь, практически нереально.

[tvf]

Краткое содержание предыдущих серий:

1. При заливке ядра произошел сбой. Загрузка прервалась, контроллер повис.
2. Попытка обнаружить повисший контроллер средствами лождика приводила к самопроизвольному сбросу поиска без объяснения причин.
3. Попытка повторно загрузить ядро без запуска процедуры поиска приводила к самопроизвольному сбросу загрузки без объяснения причин.
4. Загрузить ядро удалось при выполнении следующих манипуляций:

1. Не включая питания контроллера надо запустить поиск.
2. Потом прервать поиск.
3. Запустить обновление ядра.
4. Включить питание контроллера.

Теперь домыслы:

1. Домыслов нет.
2. Лоджик обнаруживает невозможность поиска контроллера и прерывает его, но не сообщает пользователю причину невозможности поиска. Не есть хорошо.
3. Необходимость предварительного запуска поиска для загрузки ядра сомнительна. В приведенном выше примере загрузка происходила вне зависимости от результатов поиска. Важен был сам факт запуска поиска.
4. Возможно не единственный рабочий вариант.

[Arsie]

Сообщение от tvf

2. Лоджик обнаруживает невозможность поиска контроллера и прерывает его, но не сообщает пользователю причину невозможности поиска. Не есть хорошо.

Вот это - баг.

Сообщение от tvf

3. Необходимость предварительного запуска поиска для загрузки ядра сомнительна. В приведенном выше примере загрузка происходила вне зависимости от результатов поиска. Важен был сам факт запуска поиска.

А вот это я попытался объяснить.

[tvf]

А вот это я попытался объяснить.

Если имелось ввиду это:

Включение вами поиска инициировало подавление лоджиком работы сети (так называемое "выключение мастера"), контроллер хоть и впавший в безумие, это отработал и перестал шевелить порт.

То данное действие не возывело желаемого результата.

Не все манипуляции с контроллером происходили в одном месте и в одно время.
На объекте происходило следующее:
1. Сам сбой загрузки.
2. Неоднократные попытки поиска контроллера средствами лоджика с описанными выше результатами.
3. Снятие/установка батарейки.
4. Неоднократные попытки поиска контроллера средствами лоджика с описанными выше результатами.
5. Демонтаж контроллера.

В офисе, на следующий день, происходило следующее:

1. Не включая питания контроллера надо запустить поиск.
2. Потом прервать поиск.
3. Запустить обновление ядра.
4. Включить питание контроллера.

Если поподробней, то поиск запускался при выключенном питании контроллера и ни как на работу контроллера повлиять не мог.
Кроме того, попробовал повторить те же манипуляции вообще без контроллера, но с подключенным преобразователем USB-Rs485. Все повторилось. Это факты.

Теперь домыслы.

Процедура поиска нужна для определения наличия связи с контроллером, определения адреса контроллера , записи/считывания свойств контроллера. То есть всех тех операций, которые идут через ModBus. На процесс заливки ядра не влияет.
Если обратиться к документации на контроллер, то заливку ядра можно сделать как через Лоджик так и через HyperTerminal. И протокол, через который идет заливка ядра в обеих случаях один и тот же - 1K Xmodem. А в документации применительно к нашей ситуации написано следующее:
"В процессе загрузки ядра произошел сбой. ... Процесс передачи необходимо возобновить. Выключите питание контроллера. Остановите процесс передачи по кнопке Отмена. Перезапустите процесс передачи HyperTerminal. Включите питание контроллера.
Примечание. Для инициализации процесса загрузки котроллер должен находиться в состоянии выключения не менее 3с." То есть примерно те же манипуляции, что и я проделал.

[Arsie]

Сообщение от tvf

Если имелось ввиду это:То данное действие не возывело желаемого результата.

Если поподробней, то поиск запускался при выключенном питании контроллера

Понял.

[Nick]

Сообщение от tvf

Если поподробней, то поиск запускался при выключенном питании контроллера и ни как на работу контроллера повлиять не мог.

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

[tvf]

В сети был 1 контроллер. Обычная приточка.

[Arsie]

Сообщение от tvf

В сети был 1 контроллер. Обычная приточка.

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

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

[tvf]

Длина кабеля RS485 маленькая, так что вряд ли дело в нем. Скорее всего в USB - не самый надежный в плане контактов интерфейс. А дергать пригодится часто.
Да и не сам сбой при загрузке был предметом обсуждения, а способ выхода из этой ситуации. Ко всеобщему удовольствию ситуация разрешилась.

[Arsie]

Сообщение от tvf

Длина кабеля RS485 маленькая, так что вряд ли дело в нем.

Согласование потенциалов никак не зависит от длины кабеля

[tvf]

Сообщение от Arsie

Согласование потенциалов никак не зависит от длины кабеля

Из документации на 2G:

При организации сети следует учитывать неявное присутствие третьего проводника – «земли». Ведь все приемопередатчики имеют питание и «землю». Если устройства расположены недалеко от начального источника питания, то разность потенциалов между «землями» устройств в сети невелика и для соединения достаточно одной лишь «витой пары». Но если устройства находятся далеко друг от друга и получают местное питание, то между их «землями» может оказаться существенная разность потенциалов. Возможные последствия: невозможность установления связи, либо плохое её качество, выход из строя приемопередатчика, а то и всего устройства. В таких случаях следует применять дренажный провод.

В документации на Пиксель этот вопрос не поднимается. Так же отсуствуют сведения о наличии/отсуствии гальваноразвязки RS485 на Пикселе.

Так есть гальваноразвязка RS485 на Пикселе или ее нет?

[Arsie]

Сообщение от tvf

Из документации на 2G:

Никакая документация не переборет проблему с разводкой заземления на объекте и/или отсутствием заземления блока питания ноутбука.

Сообщение от tvf

Так же отсуствуют сведения о наличии/отсуствии гальваноразвязки RS485 на Пикселе.

Гальванической развязки там нет.