Страница 1 из 2 12 ПоследняяПоследняя
Показано с 1 по 10 из 13

Тема: ошибка в DCON (Master) при Work Mode = By Command

  1. #1

    Exclamation ошибка в DCON (Master) при Work Mode = By Command

    Модуль DCON (Master) формат ASCII.
    При установке параметра Work Mode = By Command иногда (закономерности не заметил) происходит самопроизвольная передача запроса - без установки Status в 00FFh.
    Такая-же самопроизвольная передача всех (!) запросов стабильно возникает в момент подключения к PLC (Login), причем даже когда контроллер в режиме "стоп".

    PLC model MODEL PLC 150
    Binary VERSION 1.31.1
    Need Target version 1.31
    Последний раз редактировалось Generator; 15.03.2007 в 18:30.

  2. #2

    По умолчанию

    Уважаемый Generator! Используйте свежие прошивки. Тема уже поднималась в форуме.
    Тролль-наседка, добрый, нежный и ласковый

  3. #3

    По умолчанию

    PLC model MODEL PLC 150
    Binary VERSION 1.31.4
    Need Target version 1.31

    Такая-же ерунда.
    Когда ждать рабочие версии 2.00.0 .. 2.01?
    Последний раз редактировалось Generator; 16.03.2007 в 14:34.

  4. #4

    По умолчанию

    Цитата Сообщение от Generator Посмотреть сообщение
    PLC model MODEL PLC 150
    Binary VERSION 1.31.4
    Need Target version 1.31

    Такая-же ерунда.
    Когда ждать рабочие версии 2.00.0 .. 2.01?
    Просьба выслать Ваш проект
    Тролль-наседка, добрый, нежный и ласковый

  5. #5

    По умолчанию

    - да, действительно при увеличении времени опроса (PollingTime) до 300мс указанная проблема полностью изчезает.
    К сожалению время реакции системы с такими параметрами, да еще при наличии развитой сети, оставляет желать лучшего.

  6. #6

    По умолчанию

    Цитата Сообщение от Generator Посмотреть сообщение
    - да, действительно при увеличении времени опроса (PollingTime) до 300мс указанная проблема полностью изчезает.
    К сожалению время реакции системы с такими параметрами, да еще при наличии развитой сети, оставляет желать лучшего.
    Уважаемый Generator! При работе в режиме по команде/смене значения PollingTime не влияет на время реакции системы! Цикл запрос-ответ зависит от bodrate и времени ответа slave. И невозможно опрашивать параметры чаще, чем позволяет пропускная способность шины минус время формирования ответа slave-ом.
    Тролль-наседка, добрый, нежный и ласковый

  7. #7

    По умолчанию

    Сразу не ответил, хотя поспорить хочется, благо тема еще не закрыта :-)

    Цитата Сообщение от Филоненко Владислав Посмотреть сообщение
    ...PollingTime не влияет на время реакции системы! Цикл запрос-ответ зависит от bodrate и времени ответа slave. И невозможно опрашивать параметры чаще, чем позволяет пропускная способность шины минус время формирования ответа slave-ом.
    - оно конечно, хотя...

    1. В моем понимании время реакции системы составляет время получения образа процесса + время одного цикла PLC на обработку образа процесса (в данном случае не так существенно - процессор довольно шустрый) + выдача выходов из образа процесса на периферию. Т.к. обновление образа процесса для программы прозрачно, то можно считать, что время реакции системы составит два периода полного опроса сети.

    2. Как понимаю PollingTime - период с которым PLC инициирует запрос slav-у и, как следствие, чем реже запросы тем больше время реакции системы.

    3. Рассмотрим подробнее физический уровень: при 115kbps время на передачу одного «стандартного» (для обмена с модулями ввода/вывода) пакета ASCII Start(1)+Address(2)+Function(2)+Data(2)+CRC(2)+CR( 1)+LF(1) составит 0,95мс (10 бит на каждый байт – 8data+parity+stop) плюс пауза между пакетами около 1,8мс(!) – как видно и от bodrate не так много зависит. Итого общее время на передачу пакета несущего 2 байта полезного кода около 2,7мс. Добавим еще столько же на ответ slav-а (тоже шустрого ;-), хотя и ответ может быть короче, и получим затраты времени около 5,5мс на один обмен. После этого сеть готова к передаче следующего пакета.

    Итак, максимальная технически достижимая скорость реакции составит: 5,5*количество модулей ввода/вывода*2 (для получения и выдачи образа процесса), что было-бы совсем неплохо даже при наличии десяти модулей на шине (~0,1с).

    Но, при увеличении PollingTime ситуация меняется кардинально: невозможно опрашивать параметры чаще, чем позволяет пропускная способность шины минус время формирования ответа slave-ом, минус (очень немаленькое) время формирования запросов контроллером. И фактически при PollingTime в 300ms контроллер получает данные от одного (!) слейва только три раза в секунду.

  8. #8

    По умолчанию

    Цитата Сообщение от Филоненко Владислав Посмотреть сообщение
    При работе в режиме по команде/смене значения PollingTime не влияет на время реакции системы!
    У Вас именно ЭТОТ режим?

  9. #9

    По умолчанию

    Тут явно какое-то недопонимание друг-друга!
    1. Если у вас режим по команде, то чем чаще вы посылаете команду на чтение/запись, тем чаще будут формироваться запросы (с учётом того, что пока один запрос не обработается, другой не запустится). И Polling time тут не причём!
    2. Если же вы используете режим по таймеру, то тогда конечно при периоде опроса 300мс будут формироваться ~3 запроса в сек.

    Следует четко разделять эти два режима.

  10. #10

    По умолчанию

    а что делает Polling time в режиме Work Mode = By Command?

Страница 1 из 2 12 ПоследняяПоследняя

Ваши права

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