ошибка в 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.
Уважаемый Generator! Используйте свежие прошивки. Тема уже поднималась в форуме.
Тролль-наседка, добрый, нежный и ласковый
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.
Просьба выслать Ваш проектСообщение от Generator
Тролль-наседка, добрый, нежный и ласковый
- да, действительно при увеличении времени опроса (PollingTime) до 300мс указанная проблема полностью изчезает.
К сожалению время реакции системы с такими параметрами, да еще при наличии развитой сети, оставляет желать лучшего.
Уважаемый 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 контроллер получает данные от одного (!) слейва только три раза в секунду.
У Вас именно ЭТОТ режим?
Тут явно какое-то недопонимание друг-друга!
1. Если у вас режим по команде, то чем чаще вы посылаете команду на чтение/запись, тем чаще будут формироваться запросы (с учётом того, что пока один запрос не обработается, другой не запустится). И Polling time тут не причём!
2. Если же вы используете режим по таймеру, то тогда конечно при периоде опроса 300мс будут формироваться ~3 запроса в сек.
Следует четко разделять эти два режима.
а что делает Polling time в режиме Work Mode = By Command?
Ваши права
