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

[Филоненко Владислав]

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

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

[Generator]

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

...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 контроллер получает данные от одного (!) слейва только три раза в секунду.

[Малышев Олег]

При работе в режиме по команде/смене значения PollingTime не влияет на время реакции системы!

У Вас именно ЭТОТ режим?