Компания ДЭП - Форумы

Как произвести опрос в рабочей конфигурации всех железок (PLDA, AIN и т.д.), чтобы узнать серийный номер/адрес программно? Куда глядеть? Можно ли создать динамическую таблицу без конфигуратора?

Лучше дайте ответ кодом.

Пример чтения серийного номера модуля ввода/вывода серии Decont есть в этой теме http://www.dep.ru/forum/viewtopic.php?t ... 9%ED%FB%E9

про динамическую таблицу без Конфигуратора - не поняла((
Серийный номер модуля можно узнать только в контроллере, к которому подключен этот модуль. Если номера надо передать на ПК, то в контроллере запишите их в счетчики и используйте компонент "База-клиент".

Мне нужен код для создания отдельного независимого от Разработчика приложения для сбора номеров/адресов модулей.

А насчет счетчиков, каким должен быть номер сигнала? Можете показать конфигурацию с PLDA как это должно выглядеть? Если такое получится, то буду забирать номера из OPC.

Серийный номер не имеет номера сигнала, как входной счетчик, например. Чтобы получить серийный номер Вам надо написать (запрограммировать) свой компонент в контроллер (инcтрумент для создания компонентов - программа Разработчик). Компонент будет работать в контроллере - читать серийный номер из динамической таблицы и записывать в какой-нибудь счетчик. Этот счетчик компонентом "База-Клиент" вычитывается на ПК и там уже доступен по OPC

Спасибо, буду разбираться.

Вопрос скорее по Разработчику, но касательно меня волнующей темы.

Делал компонент в разработчике на основе выложенного вами примера чтения серийных номеров. Но компонент не стартует.

Тогда я создал «Новый проект» совершено пустой, так же собрал и зашил в Деконт. Ошибка аналогичная:


Существует ли подробное описание разработчика или есть ли рабочие исходники каких-либо компонент (на С)?
Очень хотелось бы разобраться, почему при добавлении моего компонента требутся зашить devlib и devlib2, когда собраны мной были LibMain.hex и LibIni.hex, а для «пустого» компонента даже вышеназванных не требуется.

Вот что у меня за текущий набросок компонента:
http://depositfiles.com/files/fzzbp859l (5,8 Кб)

Проверил и на Вашем и на пустом компоненте - нет проблем. Когда Вы записываете файлы менеджером файлов, нет ли сообщений об отсутствии каких-то файлов (может Вы собираете только под А9)? Какая версия разработчика у Вас?
devlib и devlib2 - это стандартные библиотека, они для любого компонента будут одинаковые. Для пустого компоненты их не оказалось в списке для записи, т.к. Вы уже их записали ранее (можете увидеть их в списке загруженных в контроллер).

Спасибо за мысли.

Виноватой оказалась старая (кривая) сборка Конфигуратора. Он не видел .hex файлы компонента. На тестовой машине поставил последние сборки с сайта, обновил прошивку в контроллере и все заработало почти как надо.

Прилагаю текущую сборку:
http://depositfiles.com/files/ko6bk9ae6

Сборка собирает 4 серийных номера с 0го экземпляра ALT-драйвера, 4 с 1-го и 4 с BUS драйвера. Помещает последовательно в 12 счетчиков.

Компонент работает по тактам. Приоритет низкий. В Конфигураторе я ставил такт 4 (вкладка Main-> такт). Это снизило нагрузку на процессор, что хорошо. Но при записи в таблицу счетчиков иногда пишется какая-то каша. Раз на раз не приходится. Откуда она появляется понять не могу. Это не связано с загрузкой процессора (не выше 50% в моей конфигурации).

И отсюда вопрос:
Как еще можно оптимизировать работу компонента, чтобы не появлялись ошибки? Этот всплеск можно отлавливать потом, но не хочется делать костылей в рабочей системе.

Проверили на модулях BUS-драйвера - "каши" не было замечено.

"Каша" во всех счетчиках одновременно появляется или то в одном то в другом;
- во всех счетчиках это бывает или только для ALT, или только для BUS-драйвера?
- как часто это происходит?
- может в эти счетчики помимо компонента еще кото-то что-то пишет?

Баев Владимир писал(а):Проверили на модулях BUS-драйвера - "каши" не было замечено.

"Каша" во всех счетчиках одновременно появляется или то в одном то в другом;
- во всех счетчиках это бывает или только для ALT, или только для BUS-драйвера?
- как часто это происходит?
- может в эти счетчики помимо компонента еще кото-то что-то пишет?

Проверяю на ALT. BUS проверить в данный момент нечем, возможно попробую позже.
Ситуация такая: серийные номера у PLDA имеют 3 или 4 знака. Например 1510. На тестовой машине у меня подключено два PLDA модуля к одному сегменту одного интерфейса. Их номера пишутся соответственно в 1й и 2й счетчик. В какой-то момент (ни с чем не связан, все спонтанно) на месте номеров оказывается 8 или 9, или 12 знаков. У обоих. То есть понятно, что к номеру это не относится. Где не настроены так и остается 65535 (0xFFFF как и должно быть). И они оба забиты этой кашей. При следующем опросе таблицы все в норме - имеем серийный номер.
Это происходит не стабильно (и это хуже всего). Может работать минуту, а может выскакивать "каша" через каждые 5 секунд.
Счетчики нигде никто не использует. Ошибка появляется в том месте, где подключены опрашиваемые модули. Я настраивал второй интерфейс для ALT на два модуля в одном сегменте. Там каши не появлялось, просто не давал номер (или давал запомненный ранее).
Так же пробовал менять функцию записи в компоненте с dep_CounterWrite2 на dep_CounterSet2. Добавлял бит динамики.

Это как-то связно с периодом опроса в базе клиенте (у меня виндеконт опрашивает деконт-182 с периодом 1)? Может просто не вовремя опрашиваю? Или этот экземпляр деконта 182 у меня проблемный? С другой стороны при просмотре "Номера Лусо" в динамических таблицах ALT драйвера номера никуда не скачут.

Я могу сделать скриншот "каши", но на мой взгляд она случайна. В 1м и 2м счетчике числа по значению близки, но при скачках не повторяются.

Вы сами подсказали в чем проблема))

SkazochNik писал(а):Ситуация такая: серийные номера у PLDA имеют 3 или 4 знака. Например 1510.

Серийные номера в PL имеют размер WORD, а читаются в переменную
DWORD dwSerNum;
Получается, что функция amGet изменяет только младшее слово dwSerNum, а в старшем остается мусор.

Надо перед вызовом amGet поставить: dwSerNum=0;
(в примере это было)

Светлана писал(а):Вы сами подсказали в чем проблема))
Получается, что функция amGet изменяет только младшее слово dwSerNum, а в старшем остается мусор.

То что нужно! Спасибо, не увидел очевидного. Нужно хорошенько выспаться на выходных.