Кстати, у меня нет МКОНа. При наличии сделал бы простейший тест :а с реальным железов ???
ПЛК какой-нить 110й - 1 штука.
МКОН - 1 штука.
eth МКОНА воткнул в eth ПЛК, rs МКОНА в rs ПЛК ессно.
В ПЛК мастер по TCP (out register) и слейв по rs.
ПЛК меняет как-нить out regter мастера, взводит таймер и ждет когда оное прилетит в слейв.
Бродить данным кроме* как в МКОНЕ негде. Все в тепличных условиях. Многое показала бы статистика работы за ночь типа :
бродили 0mc - X раз
бродили 1мс - Y раз
...
бродили > 200..300мс - Z раз
И тоже, но с чтением из слейва.
Поменяли на слейве, засекли время, ждем когда пришли в мастера (in regiser)
*уж тут то конфигурация не должна подвести ж.
Последний раз редактировалось Валенок; 22.11.2020 в 23:31.
Не-а. Это не типовое. 110й даже без обмена уходить иногда пописать на 3мс. Иногда - это 1 раз в сек. За каким - это к вам для другой темы. И т.к. обмен по eth между циклами (в отличие от rs который на прерываниях) - вот и ответ почему 3мс. Иногда.
Но и не про 3мс вопрос. От клеммы до клеммы прохождение пакета даже с учетом этих 3мс - не более 20мс. Ведь с rs-1 напрямую на rs-2 именно так, и это заведомо более медленная петля. А тута tcp ж. Суть теста - в элементарной отбивке времени.
Главное : Если время будет больше 20..30мс (даже "иногда") - повод задуматься. И чем больше/чаще такое время - тем больше задуматся, ведь тормозящим звеном будет только МКОН, ведь просто с rs-1/rs-2 такого нету (на биб-ках во всяком случае, но и в конфиге покопатся если чо - тоже будет полезно)
А тест с 31-им слейвом по rs как по мене - не имеет большого смысла. Для обработчика со стороны rs что 100 раз к одному слейву обратится, что по одному разу к сотне - один хрен. Они ж последовательные.
Собсно зачем я кого-то уговариваю ? У меня МКОНа нету. И у Santi тоже нет. Теперь.