- В этой теме 81 ответ, 5 участников, последнее обновление 12 месяцев назад сделано
.
-
Записи
-
Опер данные идут без разрывов одной командой, а всё остальное уже с разрывами, поэтому и не опросить одной командой их.
90*20 + 20*30 и все это деленное на 2 минимум, если речь о регистрах. = 1200 каналов всего займет. Нет? я не прав?
Просто я не очень понимаю. как вы планируете модулем контролировать процесс завершения ответа. Это не реально кажется. Это совершенно разные потоки из разных неймспейсов по коду.
то есть 90 байт на все 20 устройств по оперативным данным + по 30 байт по настроечным на каждое устройство и они уже идут с разрывами. Правильно?
Да. Только не 30 байт, это была условная цифра, там примерно 49 получается, а оперативные 96, с учётом modbus.
В базовом классе модуля я видел, пару методов, которые, как мне казалось должны помочь, один обрабатывает результат команды, но как оказалось, он никак не реагирует на то что происходит в том месте куда команда послана, только то что она дошла, а что дальше неизвестно. Так же видел пару методов с событиями, которые по идее должны указывать на обновление данных, или некие процессы над ними, но они тоже вызываются рандомно, независимо от опроса. Ну и обработчики событий, но они вообще никак не реагировали, возможно мне стоило подключить события для некоторых моих каналов. Хотя как мне кажется что-то должно быть на стороне сервера, что укажет, что данные в искомом канале обновились после опроса, но я пока не пошёл так глубоко.
так 96 это с заголовком, каналов внутри сколько на каждый из приборов?
Вот только их надо будет дублировать по устройствам, чтобы настройками сделать опрос через настроечные параметры.66 каналов на 1 устройство с настроенными данными, там битовые маски используются частично, на опер данные выходит в районе 120.
Блин, опять вы не понимаете. 96 байт = оперативные данные СО ВСЕХ УСТРОЙСТВ?
49 настроечные на ОДНО устройство * на количество устройств?96 этих байт читаются одним запросом?
Вот эти 96 надо продублировать по разным устройствам, чтобы получился опрос
96
49(1)
96
49(2)
96
49(3) и так далее…96 байт, даже с масками вряд ли 96 каналов. Ну без масок это 48 каналов, пусть с масками 66. — 66*20 = 1320 каналов «лишних» в базе (чуть меньше)
Вам жалко ? 🙂
Да, опрос оперативных данных идёт одной командой на все устройства, я уже это раз 10 писал, одна команда для всех. А потом уже отдельно по каждому устройству запрашиваем подробные(настроенные) данные по 49 байт.
96 байт — 1 бай 8 бит — 1 бит 1 канал сигнала 1/0. Так что 120 каналов вполне может быть, если вы конечно под битовой маской не что-то другое предполагаете.
Ну как я по итогу понял, к сожалению, задать повторный опрос устройства в сессии опроса нельзя.
-Можно ли как-то в модуле определить обновление конкретного канала после опроса?
-Если можно, укажите, какой место в программе отвечает за опросы, или область, я бы пошарился там, может на будущее что-то придумал. Я про конкретный класс, или пространство.все маски каналов вы потом уже будете делить, когда соберете копии реальных регистров в расчетные каналы от всей толпы устройств оперативных данных.
Так что не будет там 120 каналов на устройство.Блин, вы бы на примере двух устройств попробовали, вы же уже опрашиваете устройства как понимаю.
Но это решение проблемы малой кровью. Потому что как-то взаимодействовать между модулем и драйвером я даже не представляю.
Я пробовал опрашивать через радиоканал, там пришлось timeout выставлять 3000 мс, то быстро, то с задержкой был опрос.Ну как я по итогу понял, к сожалению, задать повторный опрос устройства в сессии опроса нельзя.
только если перелопатить штатный драйвер Modbus. В реальности вполне можно, добавив префикс при создании опроса из списка опросов…
- Для ответа в этой теме необходимо авторизоваться.