Передать строку ASCII из Коммуникатора в Сервер

[manjey73]

signal-1 прокатывает, когда номера сигналов идут последовательно с 1. У меня увы не так. например 32 сигнала определено под возможность формировать битовую маску каналов чтения, и когда они используются не все, следующий параметр все равно будет начинаться с 33-его сигнала, хотя для SetCurData 33-й сигнал может оказаться 18-ой ячейкой.

Это я победил немного другим способом, вроде как… так что создание массива целиком пока не потребовалось.

А вот с tagGroups совсем непонятка, можно ли в уже существующую группу добавить теги на лету ? или надо как-то сперва все упорядочить, а уже потом формировать теги ????

[Romiros]

Если конфигурация прибора неизменна в процессе работы, но зависит от настроек прибора и может сильно отличаться от его типа, может имеет смысл в каком-нибудь frmConfig сформировать все нужные теги, путем необходимых запросов к прибору и записать в xml. А потом уже на базе xml формировать группы и теги kp.

[manjey73]

Romiros оно так и есть, все лежит в xml, просто начал писать драйвер на теплосчетчик Пульсар и сравнивал протоколы для разных модификаций теплосчетчиков и понял, что писать драйвер под каждый глупо. По этому набросал конфигурацию в xml, где можно запрос сделать активным или неактивным для того чтобы можно было разнести во времени запросы текущих данных и данных параметров.

Но вот часть параметров это системные, часть конфигурационные, хотелось их объединить в разные группы тегов. Если буду делать это по жесткому, опять все поплывет.

Можно хотя бы при некоторых ограничениях не создавать разные группы а объединить например путем последовательно указанных запросов, проверяя имя группы ?

Просто пока не сделает tagGroup = new TagGroup(«Имя группы 1»);
То нет такого имени в списке от слова совсем. Непонятно как создать первый раз, а потом проверять и не делать эту команду ????

[manjey73]

Конфигурация не совсем неизменна, сейчас сделал так, что у меня фиксированные номера каналов и если я надумаю отключить некоторые каналы из запроса, и перезапустить Коммуникатор то номера у меня никуда не плывут и остаются на своих местах. Потом могу снова включить чтение других переменных и они снова будут на своих местах.
Иногда это экономит общее время запросов к прибору просто.

Еще заметил, что Коммуникатор дольше получает ответ чем родное ПО, аж даже странно.

[Romiros]

Так может это и самый правильный вариант.
Например у нас есть прибор УВП280. Он дико универсальный может считать газ, свет, воду, тепло, нефть и ещё кучу функций выполнять.
Но адресное пространство у него прописано жёстко, т.е. расход газа в одном регистре а электроэнергии в другом. Если писать универсальный драйвер, то необходимо вычитывать все, что у него есть, давая возможность пользователю самому определять какие группы данных не читать(какая-нибудь галочка активна у группы)

[manjey73]

Просто снять галочки активности не проблема, если запросы идут группами. Тут вроде нет проблем, я так с Меркурием230 делал на основе битовой маски. Но там у меня в разных запросах и нумерация сигналов была одинаковая.

На Пульсаре пошел немного по другому пути, чтобы сигналы были разные для запросов.
Просто в Пульсаре данные идут одним запросом, я их легко впихиваю в одну группу, а вот все настроечные параметры идут разными запросами, и не получается их кидать в одну группу. Похоже придется делать предварительный список, например Dictionary, а уже потом формировать список тегов. Раз механизмов в самом Коммуникаторе нет раскладывать по группам произвольные ответы.

[Mikhail]

например 32 сигнала определено под возможность формировать битовую маску каналов чтения, и когда они используются не все, следующий параметр все равно будет начинаться с 33-его сигнала

Можно завести не массив, а словарь:
Dictionary myDict = new Dictionary();
ключ — это индекс тега КП, а значение — признак, как отображать

[Автор]

Записи