- В этой теме 25 ответов, 3 участника, последнее обновление 6 месяцев, 4 недели назад сделано
.
-
Сообщения
-
1. Оказывается у нас проблема с дублированием имени драйвера, ссылка. Т.к. драйвер от @jurasskpark появился позже, то прошу Вас потратить небольшое время на переименование драйвера.
<<Переименовал драйвер в DrvPingJP2. deviceXXX.txt — при создании тегов задайте их формат, чтобы получить значение не 1.000, а On. Посмотрите пример в драйвере симулятора.
<<Исправил Format3. lineXXX.log — вместо фразы Data request было бы интереснее увидеть более подробную информацию о том, что запрашивается.
<<Сделал отображение формата 2023-02-21 01:24:49.95797 92.53.96.28 число байт=16 время=55мс TTL=574. Работает ли мастер создания каналов с Вашим драйвером?
Нет. Не работает. Я даже об этом не задумывался. 🙂5. Какой алгоритм пинга (обычными словами)?
<<Запускается поток, который идёт по списку тегов, не ожидая результата ответа. Когда приходит ответ — идёт запись значения. Опрос последовательный. Не асинхронный.
Как работают таймауты?
<<Я не знаю.
Будет ли задержка, если устройство недоступно? И т.п.
<<Нет.Вечером ещё исправлю.
Писал ночью и код ответа вставил в catch, а не в else, из-за этого на видео нет в логах сообщений, что устройство не ответили.
Вот этот кусок надо выше поднять. )
https://github.com/JurasskPark/RapidScada_v6/blob/master/OpenDrivers/DrvPingJP_v6/DrvPing.Shared/Ping/NetworkInformationExtensions.cs#L47Будет версия. 6.0.0.2 😅
Каналы было бы удобно создавать с помощью матера. Посмотрите пример. У Вас проще будет, чем в примере.
Линия связи уже имеет свой поток, который используется при вызове метода Session. Было бы логично его задействовать для отправки запросов. А ответы асинхронные могут быть. Надо продумать такую ситуацию, что запросы будут отправляться намного чаще, чем успеют ответить. Тогда где-то будут накапливаться ожидающие запросы бесконечно и, возможно, создаваться дополнительные потоки (при асинхронном ожидании).
Каналы было бы удобно создавать с помощью матера. Посмотрите пример. У Вас проще будет, чем в примере.
Добавил Добавление через Мастер, но если честно не понравился результат.
Зачем в каналы добавляются название устройства через дефис? Если я конкретно говорю, что название Тега вот такое, а мне мастер говорит, а будет вот такое. 🙂
И сиди потом опять удаляй. 🙂
https://www.youtube.com/watch?v=a6ZQMBt8G94Линия связи уже имеет свой поток, который используется при вызове метода Session. Было бы логично его задействовать для отправки запросов. А ответы асинхронные могут быть. Надо продумать такую ситуацию, что запросы будут отправляться намного чаще, чем успеют ответить. Тогда где-то будут накапливаться ожидающие запросы бесконечно и, возможно, создаваться дополнительные потоки (при асинхронном ожидании).
Если честно, то лично я заметил, что от асинхронных режимов Коммуникатор плохо останавливается и запускается. Поэтому я для себя остановился на том, что драйвер Romiros — асинхронный, JP — последовательный. Каждый выбирает что хочет. 🙂
Будет версия. 6.0.0.2 😅
Опубликовал версию 6.0.0.2
Михаил, можно на форум добавить плагин карма. Я хочу иногда manjey73 жирный плюс влепить. Но не могу. 😀
Отдельного программиста только для форума у нас нет, а время лучше потратить на разработку Rapid SCADA. Поблагодарите словами, @manjey73 поймёт 🙂
Выложил драйвер в репозиторий. Желательно создать аналогичную тему на английском форуме, чтобы я дал на неё ссылку.
https://forum.rapidscada.org/?topic=drvpingjp
Правильно ли сделал или нет — не знаю. Но я понял вас так. 😅
- Вы должны авторизироваться для ответа в этой теме.