- В этой теме 42 ответа, 6 участников, последнее обновление 1 год, 11 месяцев назад сделано
.
-
Сообщения
-
Ermakov Andrey
1. нет, для этого надо допиливать драйвер, чтобы в канал писалось время в мс
2. Тут не могу сказать, дело в том, что мой драйвер не совсем зависит от timeout, выставленный в настройках Коммуникатора, скажем так, если в Коммуникаторе поставить 10 сек. То на первом цикле будет опрошено то количество ПК, которые успеют опроситься за эти 10 секунд, на следующем цикле будут опрашиваться другие ПК и так далее.
По этому надпись timeout скорее всего связана именно с отсутствием ответа от ПК за тайм аут, который для функции вообще предназначен.Ermakov Andrey, какую версию RapidScada используете?
Есть KpPing под 5.8. Время впринципе можно добавить.2. Тут не могу сказать, дело в том, что мой драйвер не совсем зависит от timeout, выставленный в настройках Коммуникатора, скажем так, если в Коммуникаторе поставить 10 сек. То на первом цикле будет опрошено то количество ПК, которые успеют опроситься за эти 10 секунд, на следующем цикле будут опрашиваться другие ПК и так далее.
По этому надпись timeout скорее всего связана именно с отсутствием ответа от ПК за тайм аут, который для функции вообще предназначен.manjey3, а адреса из списка опрашиваются последовательно? т.е. отправляем запрос, ждём в течение интервала по умолчанию для команды Ping (я нашёл в интернете, что это время = 1 сек), затем если ответа не было, то переходим к следующему адресу из списка?
Romiros, у меня версия 5.8 (кстати, не нашёл, где это можно посмотреть — пришлось искать установочный файл).
Я посмотрю исходники. У меня KpPing опрашивает все устройства паралельно. Последовательно получается слишком долго. Для времени ответа придется добавить доп сигналы. Ну и тайм-аут проверить
Исходники не нашел, видимо на другом компьютере.
Попробуйте пока эту библиотеку https://cloud.mail.ru/public/5CH8/5AdXATrFYErmakov Andrey да, из списка последовательно.
Драйвер Romiros у меня не взлетел на Linux, свой драйвер тоже пытался сделать в асинхронном режиме, но на Linux происходили зависания опроса напрочь.Не знаю, возможно связано где-нибудь с реализацией в Mono, а может и нет. Плюс Mono с тех пор много раз обновлялся, но нет времени пока на тестирование и проверки.
По сути какая разница, что опрос происходит некоторыми пачками, если мы ставим период опроса скажем раз в 5 минут, ну будет опрос фактически раз в 15 минут и так далее…
Драйвер Romiros у меня не взлетел на Linux
В этой версии драйвера асинхронность сделана по другому, но не знаю поможет ли это Linux.
А паралельный опрос необходим, если необходимо часто контролировать наличие связи.Исходники не нашел, видимо на другом компьютере.
Попробуйте пока эту библиотеку https://cloud.mail.ru/public/5CH8/5AdXATrFYRomiros, спасибо. Запустил, настроил Ваш драйвер — всё работает. Обратил внимание, что когда все устройства отвечают, то опросы происходят часто. Когда не отвечают — опросы происходят реже. Чем больше устройств не отвечают, тем медленнее увеличивается счётчик сеансов связи. Похоже, что здесь тоже опрос идёт последовательно, если я всё правильно понял.
Странно, такого не должно быть. Может я не ту dll выложил.
А сколько устройств у Вас? Там, если не изменяет память, организуется 16 параллельных запросов. т.е. одновременно запрашиваются 16 устройств. Можно увеличить, если что.Чем больше устройств не отвечают, тем медленнее увеличивается счётчик сеансов связи.
Всё правильно. Устройства опрашиваются одновременно, но сессия опроса ждёт ответа всех устройств.Romiros не, эту не смотрел. я давно ковырялся и писал свой вариант, там Mono еще лохматой версии был.
Вот может по этому что сессия ждет ответа от всех устройств и проблема ?
я на Raspberry тестировал тогда библиотеку и одновременно на рабочей машине с Windows10. на Винде работает, а на Linux через время просто уходила в ступор, потом через час мог проснуться а мог и нет. В итоге начал контролировать таймаут Коммуникатора и запоминать, на каком я остановился ПК и на следующем цикле читать следующие.
Если надо постоянно контролировать, то просто период по нулям и все… за 2-3 периода был опрос всех ПК. Не думаю, что это сильно критично.Вот может по этому что сессия ждет ответа от всех устройств и проблема ?
Я открою исходники и посмотрю. Сейчас просто не помню, как что сделано. Но по идее такого быть не должно.
Если надо постоянно контролировать, то просто период по нулям и все… за 2-3 периода был опрос всех ПК. Не думаю, что это сильно критично.
Когда я делал первый драйвер, он опрашивал последовательно и параметр «Таймаут» в настройках драйвера отвечал за ожидание ответа от устройства. Если у Вас штук 20 устройств, таймаут = 5 секунд и первые 19 не отвечают, то до 20-го опрос дойдет только спустя полторы минуты. Т.е. прибор возможно умер, а мы об этом ещё полторы минуты не знаем. В моём случае это было критично, поэтому я и сделал паралельные запросы. В таком варианте время сессии равно времени самого медленного ответа.
Короче надо доводить драйвер до ума и выкладывать исходники, чтобы каждый себе допиливал.
Странно, такого не должно быть. Может я не ту dll выложил.
А сколько устройств у Вас? Там, если не изменяет память, организуется 16 параллельных запросов. т.е. одновременно запрашиваются 16 устройств. Можно увеличить, если что.Romiros, у меня 24 устройства. Видимо, в первой группе есть одно устройство, которое не отвечает, и во второй тоже — поэтому получается увеличенное время ожидания ответа.
Romiros, добрый день!
Короче надо доводить драйвер до ума и выкладывать исходники, чтобы каждый себе допиливал.
Есть ли продвижение по данному вопросу?
Добрый день. Что-то я пропустил Ваш ответ, прошу прощения, и честно говоря ничего не делал :). Давайте выложу исходники, если поможет. Либо создайте несколько линий связи для параллельных опросов.
Сейчас неожиданно вылезли задачи по созданию конструктора виртуального тура, так что пока не до этого. Ну зато может получится добавить плагин виртуального тура в будущем 🙂
- Вы должны авторизироваться для ответа в этой теме.