Страница 2 из 7 ПерваяПервая 1234 ... ПоследняяПоследняя
Показано с 11 по 20 из 63

Тема: И снова "Ошибка связи #0: произошло отключение"

  1. #11

    По умолчанию

    Установил в оба контроллера прошивку 2.14.0. Сейчас ситуация такая - отключения всё равно происходят (по первому впечатлению, через бОльшие сроки, чем было), но после них хотя бы можно переподключиться.

    Зато появилась другая напасть - контроллер невозможно остановить. Выбор команд "стоп" или "сброс" приводят к затормаживанию обновления переменных и сабжевой ошибке #0. После переподключения контроллер остаётся в том же рабочем состоянии.

  2. #12

    По умолчанию

    Докладываю.

    Переход на прошивку 2.14.0 оказался катастрофическим - начались ошибки при UDP-обмене с расходомерами. На прошивке 2.15.9 таких не возникало за два с лишним месяца эксплуатации. Вернулся на 2.15.9, по совету Евгения сменил MinCycleTime с 0 на 3. За последние сутки ошибка #0 возникла один раз, переподключение оказалось возможно. Продолжаю наблюдение.

  3. #13

    По умолчанию

    Поскольку в личных сообщениях поинтересовались решением проблемы, подниму тему: с прошивкой 2.16 проблема не решилась, 2.17 ещё не пробовал (но надежды мало).

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

  4. #14
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,225

    По умолчанию

    Цитата Сообщение от Scream Посмотреть сообщение
    нихерасе совет...
    неожиданно.
    говорите что неожидано
    Единственный вариант - выводить переменные через блок Modbus TCP (он, к счастью, не зависает) и управлять "извне". А вот для обновления кода - контроллер приходится предварительно перезагружать. Соответственно, не надо планировать установку этих контроллеров на участке, которые могут быть чувствительны к необходимости выключать ПЛК.
    мало того, что правильный вариант для скады, модбас, стал каким то второстепенным, а главное это онлайн из КДС. Так теперь еще и вывод не использовать плк там где пропадает питание, вместо того чтоб создать загрузочный проект
    Bad programmers worry about the code. Good programmers worry about data structures and their relationships

    среди успешных людей я не встречала нытиков
    Барбара Коркоран

  5. #15

    По умолчанию

    Есть известная особенность ПЛК1хх - при интенсивной загрузке сети Ethernet ПЛК не в состоянии обработать все пакеты и начинает их пропускать. Как результат связь с CoDeSys-ом нестабильна.
    Вариантов 2.
    1 - использовать другой интерфейс
    2. Таки выделить ПЛК в отдельный сегмент сети и ограничить в нём паразитный трафик. Эта рекомендация для всего промоборудования на Ethernet.
    Тролль-наседка, добрый, нежный и ласковый

  6. #16

    По умолчанию

    Цитата Сообщение от capzap Посмотреть сообщение
    Так теперь еще и вывод не использовать плк там где пропадает питание, вместо того чтоб создать загрузочный проект
    Обеспечить надёжное питание в момент смены проекта/прошивки - это аксиома. Покажите мне прибор, к-й нормально переживёт пропадание питания при смене прошивки?!
    Тролль-наседка, добрый, нежный и ласковый

  7. #17
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,225

    По умолчанию

    Цитата Сообщение от Филоненко Владислав Посмотреть сообщение
    Обеспечить надёжное питание в момент смены проекта/прошивки - это аксиома. Покажите мне прибор, к-й нормально переживёт пропадание питания при смене прошивки?!
    обновление кода вижу, смену прошивки не вижу
    Bad programmers worry about the code. Good programmers worry about data structures and their relationships

    среди успешных людей я не встречала нытиков
    Барбара Коркоран

  8. #18
    Пользователь
    Регистрация
    24.07.2012
    Адрес
    Россия
    Сообщений
    1,492

    По умолчанию

    Цитата Сообщение от Филоненко Владислав Посмотреть сообщение
    Есть известная особенность ПЛК1хх - при интенсивной загрузке сети Ethernet ПЛК не в состоянии обработать все пакеты и начинает их пропускать. Как результат связь с CoDeSys-ом нестабильна.
    Вариантов 2.
    1 - использовать другой интерфейс
    2. Таки выделить ПЛК в отдельный сегмент сети и ограничить в нём паразитный трафик. Эта рекомендация для всего промоборудования на Ethernet.
    Интенсивная нагрузка это сколько? Сколько пакетов в состоянии обработать ПЛК?

    Паразитный трафик?? Рили?
    Это было во времена "тупых хабов", сейчас свитчи, они не будут кидать пакеты куда не нужно, каждый порт знает кто на нём сидит...

  9. #19

    По умолчанию

    Цитата Сообщение от capzap Посмотреть сообщение
    Так теперь еще и вывод не использовать плк там где пропадает питание, вместо того чтоб создать загрузочный проект
    Фейспалм. При чём тут загрузочный проект?

    Вы представляете, что использование ПЛК может быть несколько сложнее, чем программируемое реле, коммутирующее входы-выходы? У нас регулярно возникает задача поменять саму логику работы - изменить применяемые формулы расчёта не только на уровне коэффициентов, но и на уровне алгоритма. Заменить последовательность выполнения подпрограмм технологических цепочек. Загрузочный проект при этом, вы не поверите, создаётся.

  10. #20

    По умолчанию

    Цитата Сообщение от Филоненко Владислав Посмотреть сообщение
    Есть известная особенность ПЛК1хх - при интенсивной загрузке сети Ethernet ПЛК не в состоянии обработать все пакеты и начинает их пропускать. Как результат связь с CoDeSys-ом нестабильна.
    Вариантов 2.
    1 - использовать другой интерфейс
    2. Таки выделить ПЛК в отдельный сегмент сети и ограничить в нём паразитный трафик. Эта рекомендация для всего промоборудования на Ethernet.
    Теперь объясните, пожалуйста, как это может быть связано с тем, что пакеты UDP в рамках пользовательской программы ПЛК продолжает прекрасно обрабатывать (выведена статистика, по ней - никаких проблем и задержек нет вообще). Продолжает работать без проблем Modbus TCP - также без ошибок кадров, как в режиме мастера, так и в режиме подчинённого. А вот CoDeSys перестаёт подключаться вообще. Т.е. соединение не то что "обрывается", оно не устанавливается ни на секунду.

Страница 2 из 7 ПерваяПервая 1234 ... ПоследняяПоследняя

Похожие темы

  1. Ответов: 39
    Последнее сообщение: 15.02.2016, 12:39

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •