- В этой теме 16 ответов, 3 участника, последнее обновление 3 года, 11 месяцев назад сделано
.
-
Сообщения
-
Собственно добавили в KPTags индексы тегов, но вопрос как его найти по имени тега ?
Так как это не просто List а IENumerable то такой функции как FindIndex для него нет… ну или я что-то не так делаю ???
У меня есть список или словарь имен созданных Тегов, как мне определить какой именно индекс у этого имени в KPTags соответствующий этому имени ?
Мда, еще один момент, а если мена тегов будут одинаковы, но из разных групп?
Например группа «Токи» — L1, L2, L3 и группа «Напряжение» — L1, L2, L3Произойдет облом при поиске по имени…. 🙁
Вот на примере Логики тоже. Теплосчетчик, к которому подключены два расходомера.
Группы «Расходомер 1» и «Расходомер 2» но имена тегов одинаковы для обоих групп.
При этом это разные теги, у них разные номера сигналов…
Получается выход либо делать уникальные имена или искать по сигналу, который в принципе по умолчанию должен быть уникальным.Перечисление можно прогнать через foreach или LINQ. Используйте сигнал это действительно уникальный идентификатор. Например, я его использую, чтобы получить номера каналов тегов в методе OnCommLineStart() для того чтобы запросить последнюю архивную запись по каждому каналу и архивное событие из БД RapidScada. Связка моих классов для работы с БД и тегами КП происходит как раз через сигнал.
Да вот же, сигнал вполне оптимален, я то я сперва через имя попробовал, а потом понял что само имя в составе группы может быть уникальным, но в составе всего КП может оказаться повторяющимся.
Ели без проверок то вот так получилось при использовании Linq. тут у меня profile[pf] переборка моего списка профилей с нумерацией сигналов. Так понимаю, если не будет ничего найдено, то индекс будет равен -1 ?
int itag = KPTags.Where(s => s.Signal == profile[pf].signal).GetEnumerator().Current.Index;Ссылка на объект не указывает на экземпляр объекта
Объект не существует, видимо не создан. Проверьте по коду. И зачем вот это GetEnumerator().Current.Index? Я думал Вам нужен стандартный индекс KpTags[i].Index.
Чтобы найти индекс KPTags, которому принадлежит сигнал надо прошерстить IENumerable
и уже потом обратиться SetCurData(index, Значение, Статус)
По другому никак. Либо при создание тегов самому сохранять индексы при создании.
Вот тут не знаю, что быстрее. Самостоятельно это делать или постоянно искать при помощи Linq. Хотя и там и там искать.
При шаблонном варианте не подходит сквозная нумерация тегов, что-то отключается в шаблоне, что-то включается и при сквозной нумерации сигналов происходит каша. Сигналы начинают писаться не туда, а это не очень удобно.
Ну тут Вам виднее, драйвер сами делаете. Но привязать индексы нужно либо при создании, либо при старте, но не каждый раз при SetCurData, это не оптимально.
Если не привязываться к индексам, то получается код создания тегов и их дальнейшего использования как в драйвере Меркурий.
Да и во многих драйверах Михаила, где команда SetCurData в рамках кода строго привязана.
типа tag = 0;
А далее
SetCurData(tag, Значение, статус);
tag++;Это нормально, когда из прибора читается строго типизированный список переменных.
Как только пришлось сделать настройку параметров через шаблон, то есть возможность включать/выключать из опроса переменные, то такой подход сразу все ломает, так как передача в SetCurData идет не по номеру сигнала, а именно по индексу тега.Отсюда и все эти пляски с бубном. Сперва обошел сохранением индексов самостоятельно, потом Михаил добавил индексацию непосредственно в KPTags, вот пытаюсь разобраться как эти индексы использовать, чтобы не создавать свои.
Думаю отличаться будут только способы поиска индекса, честно говоря думал они окажутся проще, чем создание своих…Если Михаил расширит возможности SetCurData, чтобы можно было работать сразу с номерами сигналов в нем, это очень сильно упростит код самого драйвера…. Например в самом начале кода указать, что SetCurData будет принимать именно номер сигнала и далее как обычно но в место по умолчанию SetCurData(tag, x ,x) будет дальше в коде SetCurData(signal, x, x) было бы здорово. Если нет переопределения, то работа функции по умолчанию.
Понятно, т.е. порядок может быть нарушен и иметь пропуски и просто tag++ не прокатывает.
Тогда Ваш Profiler должен хранить и индекс тега, в который нужно отправить значение. Так сложно что-то посоветовать, не видя как всё устроено.Да с сохранением индекса давно уже применяю, как только начал делать драйвера на шаблонах. Просто индексы ранее сохранял сам по совету Михаила. А потом он добавил номер индекса сразу в KPTags.
з.ы. собственно можете сами глянуть по коду моих драйверов. И Пульсар тоже использует и другие. Просто Меркурий давно писался, пытаюсь его в порядок привести 🙂там вообще все настройки на битовой маске были организованы, каждый бит отвечал за свой параметр. и строго последовательная организация тегов.
В другом коде я могу даже переставить в шаблоне запросы или вообще их удалить из xml и работа не нарушится. Правда не везде так… где-то может и пострадать…В общем, когда один код драйвера предназначен для чтения разных вариантов, пришлось изгаляться… ну не писать же по 100500 раз одно и то же, если можно путем изменения шаблона прочитать сразу два прибора или больше ?
Для этих целей было добавлено поле KPTag.Index
Каждый раз искать по всему массиву тегов слишком долго.У меня есть список или словарь имен созданных Тегов, как мне определить какой именно индекс у этого имени в KPTags соответствующий этому имени ?
Тогда нужно иметь
Dictionary<string, KPTag> myTags
То есть по имени myTags[name] обращение происходит быстро и Вы получаете переменную типа KPTag, которая содержит поле Index.
- Вы должны авторизироваться для ответа в этой теме.