FAQ (ЧаВО) по PROTEUS для начинающих и не только

[Halex07]

7.4. Пример создания активного семисегментного индикатора с десятичной точкой. Часть первая – графика.
В качестве первого пробного шара в создании собственных активных компонентов я решил использовать все тот же семисегментный индикатор с общим анодом. На его основе мы поучимся создавать простые Bitwise индикаторы. Не будем особо усложнять задачу, а просто сделаем индикатор желтого цвета – таковой отсутствует в стандартной библиотеке и попутно приклеим к нему десятичную точку. Для этого нам потребуется уже разобранный ранее 7SEG-COM-ANODE. От него мы используем существующую графику, только перекрасим ее. Кроме того, если вы обратили внимание, этот индикатор позиционируется как Schematic Model, следовательно, для него имеется файл MDF. Называется он 7SEGCOMA и расположен в библиотеке DISPLAY.LML. Как его добыть оттуда, вы уже знаете, повторяться не буду. Я просто приложил уже извлеченный в папке Prototip вложения. В довесок там же 7SEGCOMK.MDF для индикатора с общим катодом и LED.MDF для активного светодиода из библиотеки ACTIVE.LML для тех, кто хочет поупражняться самостоятельно в создании индикаторов. Итак, приступим.
Начало процесса не вызывает особых затруднений. Мы просто помещаем в новый проект модель 7SEG-COM-ANODE и применяем к ней Decompose. Теперь мы имеем разобранный на запчасти индикатор и кучку символов в селекторе символов (режим Simbol Mode). Их мы тоже извлекаем в проект все по порядку и «разбираем на запчасти» через Decompose, чтобы графика отдельно - ORIGIN отдельно. После этого селектор символов можно очистить, чтобы не путаться со старыми символами. Делается это, как и с компонентами – щелкаем правой кнопкой мышки в селекторе и выбираем опцию Tidy. Селектор чист, и можно приступить к созданию собственных символов. На этом первая стадия нашего эксперимента закончена, и я сохраню ее в этом виде в папке Begin вложения.
Приступаем ко второй стадии. Для начала перекрасим светящиеся и погашенные сегменты. Дважды щелкаем по первому темнокоричневому сегменту «а» и в открывшемся окне Edit path’s graphic style выбираем любой из Colour, а в открывающемся дополнительном селекторе кнопку other…. Для погашенных элементов я выбрал один из темных оттенков желтого цвета и добавил его в набор (Рис. 13).
Для того, чтобы перекрасить весь сегмент нам необходимо выбрать одинаковый цвет как для линии обводки (бордюра), так и для заливки фигуры (Рис. 14). После этого нажимаем кнопку This Graphic Only, чтобы сохранить изменения. Проделываем указанную процедуру со всеми погашенными сегментами.
Для засвеченных сегментов аналогично выбираем стандартный ярко-желтый цвет из палитры основных цветов: второй ряд – второй слева цвет. Кроме того, нам необходимо перекрасить в цвета погашенных сегменты на основном изображении компонента (Рис. 15).
Тело компонента, а также бывшая и будущая подложка с индексом _C на конце в покраске не нуждаются, хотя наиболее привередливые могут изменить цвет и у них, например, на стандартный для реальных семисегментников серый. Тут главное изменить цвет и у компонента и у подложки на один и тот же. На этом «малярные» работы заканчиваются, и мы приступаем к созданию своих символов.
Создание символов наиболее ответственный момент во всей процедуре, и тут нужно повышенное внимание, чтобы не напороть косяков. Выделяем первый по счету сегмент обязательно с принадлежащим ему маркером ORIGIN и через правую кнопку мышки выбираем опцию Make Symbol (Рис. 16).
Обратите внимание, что библиотека SYSTEM у меня не защищена и присутствует в окне выбора Library. Я достаточно уверен в своих действиях, как шутят автомобилисты – «мастер за рулем», поэтому сразу же выбрал библиотеку MY_SYMBOLS. В переключателе Type оставляем предлагаемый по умолчанию Graphic и задаем имя первого нашего символа. Я назвал его SEGYEL_0_0 по аналогии с разбиравшимся выше.
Здесь сразу хочу предложить одну «фишку» собственного пошиба. Чтобы каждый раз не набирать имя вручную – не торопитесь давить кнопку OK. После набора полного имени выделите его и скопируйте в буфер обмена через CTRL+С или правую кнопку мышки – «Копировать». При создании следующего символа достаточно в этом поле вставить из буфера готовое имя и поправить всего одну или две цифры. Этим вы по крайней мере гарантируете себя от ошибок в наборе имени, ну и чуть-чуть ускорите сам процесс. Есть еще один «неприятный нюанс» Протеуса. После создания каждого символа необходимо в левом тулбаре переключаться из режима символов в режим Selection Mode (самая верхняя кнопка с жирной косой стрелкой). Иначе курсор будет находиться в режиме рисования (карандаш) и вы не сможете выделить следующий символ. Следующим по счету будет светящийся желтый символ сегмента «а», а имя у него будет отличаться только последней цифрой SEGYEL_0_1. Третьим будет темный символ сегмента «b» с именем SEGYEL_1_0 и т.д. до заключительной подложки с именем SEGYEL_С. В финале селектор символов у вас будет выглядеть так, как представлено на рисунке 17.
Ну а если теперь заглянуть в нашу библиотеку символов, то можно убедиться, что все созданные нами символы представлены и там (Рис. 18 ).
Но мы собирались добавить к нашей модели еще и десятичную точку. Пора заняться и этим. Проще всего пририсовать для начала точку на полной модели с выводами. При этом у нас будет полная ориентация относительно всех сегментов и края тела модели. Здесь временно потребуется переключиться через меню View в режим сетки Snap 10th, иначе нам не удастся соблюсти нужные зазоры и размер точки. Кроме того, размер бордюра у нарисованной окружности необходимо установить в 0, как и у сегментов, ну и конечно выбрать для бордюра и заливки цвет погащенного сегмента. Сразу же добавим и необходимый вывод со скрытым именем H (Рис. 19 ). Теперь копируем полностью графическую модель на свободное место в проекте через Block Copy в двух экземплярах и удаляем на ней все лишнее, кроме самой точки и маркера ORIGIN. Таким «хитрым способом» мы точно обеспечим соблюдение смещения точки относительно маркера ORIGIN.
Нам осталось изменить цвет для светящейся точки и создать два дополнительных символа с именами SEGYEL_7_0 и SEGYEL_7_1 для погашенной и светящейся точки, как мы делали ранее.
На этом процедура создания графики для нашего семисегментного индикатора завершена. В следующем параграфе займемся созданием полной модели с пробной симуляцией.
Рисунки 13, 14, 15.
Рисунки 16, 17, 18.
Рисунок 19.

[Halex07]

7.5. Пример создания активного семисегментного индикатора с десятичной точкой. Примитивы для создания индикаторов. Часть вторая – модель.
Для начала предстоит создать графическую модель компонента, которая и будет представлять его в библиотеке, но попутно мы включим туда и свойства активного компонента. Итак, графическую (не симулируемую) модель создаем из того набора, что представлен на предыдущем рисунке вместе с добавленным выводом и десятичной точкой. Как и обычно, выделяем все это рамочкой и нажимаем нашу любимую кнопку Make Device. Именно девайс, символов мы уже насоздавались. И вот тут с самой первой вкладки начинаются новшества. Я уже упоминал, что мы создаем бит-зависимый активный компонент. Зададим ему имя, пусть он 7SEG-COM-ANODE-YEL (больше просто не упишется), префикс можно и не задавать, тут это не критично и делается как всегда.
Приключения начинаются в нижней части окна – Active Component Properties – ведь мы создаем активный компонент. В графе Symbol Name Stem вводим имя наших созданных сегментов. Вводится только общая часть имени, которая слева до первого символа подчеркивания, в нашем случае это SEGYEL. После этого становится доступным для ввода количество состояний – No. of States. Оно численно равно количеству различных видов символов – цифра после первого подчеркивания с учетом нулевого. Это означает, что если у нас номер последнего символа (в нашем случае добавленной десятичной точки) равен семи и нулевой символ – сегмент «а», то в этой графе мы указываем число восемь. Не ошибайтесь с подсчетом в этом месте, иначе один из символов работать не будет. Ну и, наконец, поскольку мы создаем многоэлементный индикатор, в котором каждый символ связан с состоянием определенного вывода компонента, включаем флажок Bitwise – «бит-зависимый» (Рис. 20).
В остальных вкладках функции Make Device можно пока ничего не заполнять и лихо проскочить их до последней, нажимая кнопку Next. На последней вкладке нам необходимо причислить нашу модель к какой-либо группе компонентов, либо создать новую. Я не стал мудрить в данном случае – выбрал из существующих, изменив только описание компонента – графа Device Description. Ну и сохранил это все пока в библиотеке USRDVC (Рис. 21).
Теперь наша модель присутствует в селекторе компонентов, и мы можем поместить ее в проект. Пора приделать к ней дочерний лист, чтобы на нем смоделировать внутреннюю структуру. Тут все, как и прежде – заходим в свойства и устанавливаем галочку Attach hierarchy module. Теперь мы можем спокойно проследовать на дочерний лист и заняться восстановлением структуры модели по файлу 7SEGCOMK.MDF. Если бы мы не добавили еще один элемент – десятичную точку, то можно было бы и вообще использовать этот файл, но теперь нам придется добавить недостающую часть внутренней структуры и для нее. Вообще, для активных Bitwise компонентов рисовать структуры – одно удовольствие. Достаточно воспроизвести структуру для одного символа и затем размножить ее через кнопку Block Copy. На рисунке 22 приведена часть восстановленной по 7SEGCOMK.MDF структуры с дочернего листа нашей модели. Здесь четко просматриваются два одинаковых «канала» для сегмента «A» и для сегмента «B». Каждый канал состоит из примитивов токового пробника RTIPROBE и аналогового выключателя VSWITCH. Всего таких каналов восемь, по числу используемых символов. Все отличие состоит в номере свойства Target Element у токовых пробников IP1…IP8 (на рисунке это свойство ELEMENT специально сделано видимым).
Рассмотрим предназначение элементов одного канала. Аналоговый выключатель в данном включении служит пороговым элементом по напряжению с напряжением включения VON=‹VF›. Напряжение включения VF задано в скрипте *DEFINE и равно 1.5V для всех каналов. Позже, мы пропишем его в свойствах модели с возможностью изменить из основного листа. Кроме того, в свойствах каждого VSWITCH в соответствии с MDF прототипа задано сопротивление в выключенном состоянии Off Resistance ROFF=100k и во включенном On Resistance RON=10. Таким образом, если между левыми и правыми группами выводов VSWITCH приложить напряжение менее полутора вольт, то он не включится и его сопротивление будет 100кОм, а если свыше 1,5В, то он перейдет во включенное состояние с сопротивлением 10 Ом между верхними по схеме выводами. Обратный переход произойдет при напряжении VOFF в нашем случае при 0В. Мы уже рассматривали управляемый ключ VSWITCH в п.4.13 и больше я на нем останавливаться не буду. А вот на свойствах примитива RTIPROBE и его собратьев по назначению остановимся подробнее, так как они являются основой для создания активных индикаторов. Все они расположены в библиотеке Modelling Primitives в подпапке Realtime (Indicators) и назначение их служить пробниками для определения состояний точек (цепей) схемы с выводом результата в виде меняющихся графических символов. Аналоговыми индикаторами являются два из них токовый RTIPROBE и напряжения RTVPROBE (Рис. 23). Соответственно токовый включается в контролируемую цепь последовательно и индицирует ток в ней, а пробник напряжения подключается к двум контролируемым точкам и индицирует напряжение между ними. Текущее состояние (индицируемый символ) определяется по схожим в написании формулам – я привел их на рисунке над соответствующими моделями. В них:
STATE – текущее состояние (отображаемый в данный момент символ);
NUMSTATES – возможное количество состояний (символов индикации) для аналогового индикатора (вспомните восемь разных по свечению состояний светодиода на рисунке 7 из п.7.2 выше) или количество бит-зависимых символов с двумя состояниями для Bitwise индикатора (это то, что мы прописывали на первой вкладке Make Device в графе No. of States на рисунке 20);
CURRENT (или VOLTAGE) – текущее значение тока (напряжения);
MIN и MAX – заданные в свойствах соответственно: минимальное и максимальное значение тока (напряжения).
Ну и сразу же рассмотрим оставшиеся свойства этих примитивов. На рисунке 24 приведено приведено окно свойств пробника напряжения – у него на одно свойство больше, чем у токового.
Load Resistance – нагрузочное сопротивление самого пробника (только для пробника напряжения).
Итак, в нашем случае использован токовый пробник RTIPROBE с установленным MAX=‹ION›, которое в свою очередь в скрипте задано 10mA. Так как мы используем Bitwise режим, то соответствующий символ (сегмент) станет активным (светящимся) в том случае, если ток через пробник стане 10мА или выше, а это произойдет при срабатывании ключа VSWITCH. Вот собственно и весь принцип работы одного канала индикатора.
Ну и несколько слов о цифровых примитивах RTDPROBE. Однобитные примитивы индикаторов ведут себя предсказуемо: если на входе лог. 0, то соответствующий Target Element (символ) не активизирован, если на входе лог. 1, то он активизирован. В той же папке имеются многовходовые RTDPROBE. Детально я их не исследовал, но при беглой логика входов абсолютно непонятна – что-то похожее на исключающее ИЛИ. К сожалению и в HELP на них описание весьма скудное. Соответственно свойства всех рассмотренных примитивов описаны в хелпе ProSPICE Primitives в разделе Real Time Modelling Primitives. Владеющие английским языком могут прочесть в оригинале. Ну а мы вернемся к «нашим баранам», т.е. индикаторам.
Есть еще одна немаловажная «фишка», об которую я в начале освоения Протеуса набил немало шишек. При создании модели индикатора на первой вкладке Make Device мы не указали префикс модели – Reference Prefix. Я пропустил его умышленно, поскольку именно так сделано и у существующих моделей семисегментных индикаторов. Но, со всей ответственностью могу утверждать, что наша активная модель с дочерним листом без него «светиться» не будет. Будет потреблять ток, никаких ошибок и предупреждений не будет, но нормальной работы мы не добъемся, пока не применим «превентивных мер». А сделать над всего-навсего следующее. Либо задать префикс уже в свойствах готовой модели в строке Component Reference, либо, находясь на дочернем листе зайти в верхнем меню Design =› Edit Seet Properties и там задать имя дочернему листу (Рис. 25). Причем имя должно быть обязательно задано только заглавными буквами латиницы или цифрами. Я и тут не стал философствовать, а просто набрал символику индикаторов HG.
Вот теперь можно вернуться на основной лист, подключить соответствующее питание и запустить симуляцию, чтобы убедиться, что наш индикатор работает (Рис.26).
Я умышленно врезал в цепь амперметр, чтобы показать, что наша модель чисто аналоговая. При питании от терминала 5V (по умолчанию) она потребляет ток 4А (!!!). Определяется он в данном случае параллельным включением всех 8 VSWITCH для которых задано сопротивление RON=10 Ом. Учитывайте это в своих разработках, используя подобные модели. Это не относится к индикаторам на основе DLL, о которых речь пойдет позже.
Ну и в заключение нам осталось сформировать файл MDF с дочернего листа нашего проекта, который представлен во вложении в папке Model_with_Child. Как это делается вы уже должны знать наизусть.
Окончательный вариант с отключенным дочерним листом представлен в папке вложения Final_model_with_MDF. Там же лежит и скомпилированный файл 7SEG_POINT_COM_AN.MDF. Теперь нам осталось еще раз пройти процедуру Make Device для модели и на третьей вкладке добавить сам файл MDF (Рис. 27), а также через Blank Item по аналогии с прототипом два свойства ION и VF, которые были у нас в скрипте *DEFINE дочернего листа (Рис 28 и 29 соответственно). Не забудьте открепить сам дочерний лист - снять галочку.
На этом модель полностью готова. Желающие могут перенести ее из USRDVC в какую-либо другую библиотеку, а файл MDF поместить в папку MODELS Протеуса для дальнейшего использования. Далее можете самостоятельно попрактиковаться в «раскрашивании» семисегментных индикаторов. Кстати, если использовать символы, которые мы создали для желтого и только менять цвета, то файл MDF для всех будет один и тот же, т.е. процедуру «приклеивания» дочернего листа повторять уже не придется. Мы просто перекрашиваем сегменты, создаем новый набор символов нужного цвета, затем создаем модель с оригинальным именем и присоединенным набором сегментов нужного цвета, а далее на третьей вкладке добавляем наш MDF и дополнительные два свойства.
Можно также самостоятельно пораскрашивать светодиоды – там и MDF менять не надо, оставляете родной. Я же на этом временно закончу рассмотрение индикаторов и перехожу к теме создания моделей на основе существуюших DLL, т.е. приступаем к созданию ранее представленного и обещанного регулируемого источника питания.
Рисунки 20, 21, 22.
Рисунки 23, 24, 25.
Рисунки 26, 27, 28.
Рисунок 29.

[Halex07]

8. Активные модели на основе существующих DLL.

8.1. Немного «тумана» о DLL и о том, что будет, а чего не будет в этом разделе.
Вот мы и подошли к тому моменту, когда количество изложенного материала даст нам и качественный скачок. Но сначала о том, что же такое DLL. Dynamic-link library – библиотека динамической компоновки – так гласит Википедия. Концепция применения DLL изначально заключалась в том, чтобы создать исполняемые модули, которые могли бы независимо использоваться различными приложениями. Да и структура динамических библиотек во многом схожа со структурой исполняемых файлов, они содержат исполняемый код, данные и ресурсы, которые могут полностью или частично использоваться разными приложениями Windows. Характерным примером DLL являются драйвера устройств. Компоновка программного кода в динамические библиотеки возможна в большинстве программных сред, работающих с языками высокого уровня. Возможность использования единожды загруженной в память DLL различными процессами в динамическом режиме позволяет добиться гибкости и высоких скоростей обработки информации.
Протеус, как программный продукт, работающий под управлением MS Windows, не является исключением. Именно использование DLL позволяет проводить имитацию поведения микроконтроллеров и других сложных электронных компонентов в режиме реального времени. Подавляющее количество библиотек для программных моделей в ISIS написано самим разработчиком – фирмой Labcenter Electronics в среде MS Visual C++ и скомпоновано в динамические библиотеки с именем имитируемой модели или группы и расширением DLL. В ранних версиях Протеуса, до версии 6.2 включительно в состав установочного пакета входили и средства для разработки программных моделей - Proteus VSM SDK. Для «неанглоязычной» и абсолютно незнакомой с программированием публики привожу расшифровку аббревиатуры и перевод. VSM – Virtual System Modeling – виртуальное системное моделирование, SDK – Software Development Kit – комплект средств разработки. Теперь, надеюсь, понятно, о чем идет речь. Это заголовочные файлы для среды C++ с расширением CPP, располагавшиеся в папке INCLUDE, а также файл помощи по их использованию. Кстати, ссылка на этот файл до сих пор фигурирует в меню Help ISIS, только вместо реального файла помощи там торчит «заглушка». Как это не печально, но, начиная с версии 6.3, доступ к средствам разработки был закрыт, поскольку фирма опасается плагиата со стороны возможных конкурентов. Если кто-то чувствует себя вполне уверенно в программировании на C++, причем не элементарном – две три функции, а с использованием классов, то может поискать старые версии Протеуса, к которым прикладывались средства для разработки. При тщательном поиске в сети можно обнаружить и PDF-вариант HELP, называется он Proteus VSM DSK (именно DSK а не SDK – не знаю кто, но допустил «очепятку» и так и не поправил ее).
Я же в последующем материале не ставлю перед собой цель обучить вас программированию на C++, и переписыванием вышеупомянутого VSM DSK на русском языке тоже увлекаться не собираюсь. Моя цель гораздо проще. Я хочу показать в этом разделе, что умело используя уже существующие DLL, можно создать достаточно «продвинутые» модели для применения в своих проектах. И для этого совсем не надо быть корифеем в C++, можно даже совсем не знать этого языка. Достаточно проявить нашу русскую смекалку и сообразительность, ну и немного «упертости» в достижении результата. Приступим…

[Halex07]

8.2. Библиотека SETPOINT.DLL и задаваемые для нее параметры на примере температурного датчика LM20.
Само название библиотеки, если разложить его на составляющие и перевести, говорит о ее назначении, Set point в переводе с английского – «установить точку». Именно для этих целей и написана SETPOINT.DLL. С параметрами, которые можно использовать при использовании данной библиотеки, проще всего познакомиться на конкретном примере. SETPOINT.DLL достаточно широко применяется в моделях Протеуса и мы встретим ее почти везде, где встречаются маркеры INCREMENT и DECREMENT и «миниатюрный дисплей» для вывода числового значения изменяемого параметра (Рис. 30). Для изучения свойств я выбрал модель температурного датчика LM20, хотя можно было воспользоваться и любой другой моделью с присутствующими в ее составе характерными элементами. Вы уже наверняка применяли в своих проектах подобные модели и знаете, что клик мышкой по маркеру INCREMENT (стрелка вверх) дает приращение параметра на один шаг (в этой модели Temperature Step в свойствах), а клик по маркеру DECREMENT (стрелка вниз) уменьшает значение на один шаг.
Чтобы познакомиться с тем, как подключена библиотека SETPOINT.DLL к модели LM20, а заодно и узнать об остальных параметрах воспользуемся все той же, любимой мною, функцией Make Device. Выделяем LM20 в поле проекта, задаем Make Device и смотрим что же интересного на первой вкладке (Рис.31).
Здесь мы можем убедиться, что наша модель является активной, поскольку заполнена нижняя часть вкладки – Active Component Properties. В составе модели имеются два символа с именем SETPOINT. В данном случае имя символов совпадает с именем библиотеки, но это совсем не обязательное условие работоспособности модели. Просто здесь имеет место случайное совпадение. А вот самым нижним флажком мы еще не пользовались. Именно он и привязывает активные свойства модели к программной библиотеке DLL. Link to DLL так и переводится на русский – «связь с DLL». Ну, к символам активной модели мы вернемся позже, а сейчас, чтобы лишний раз не выпадать из Make Device, проследуем на третью вкладку и посмотрим что еще интересного в свойствах нашей модели. И в первом же свойстве MODDLL мы встречаем привязку уже конкретно к библиотеке SETPOINT.DLL (Рис.32). Более, кроме того, что этому свойству присвоен тип Hidden (скрытое) нас в этом свойстве ничего не заинтересует.
Свойство MODFILE относится к конкретному MDF модели, и мы на нем пока останавливаться не будем, а рассмотрим только те, что связаны с SETPOINT.DLL.
STEP – шаг (Рис.33). Для этого свойства и последующих, относящихся к SETPOINT, при добавлении их к создаваемой модели следует выбирать опцию New=› Blank Item и вводить имя вручную, поскольку в стандартных они не прописаны. Написания имен должны быть именно такими, без всяких там «загогулин» и грамматических ошибок, т.к. именно так они фигурируют в SETPOINT.DLL. Итак, шаг определяет единичное изменение регулируемого параметра при нажатии на маркер INCREMENT или DECREMENT. В графе Description для этого свойства вы вольны писать все, что заблагорассудится, в том числе и на кириллице. Поскольку в данный момент мы рассматриваем датчик температуры там и написан Temperature Step. Type определен как Float, т.е. можно использовать дробные значения. Ограничения – Limits не установлены. В следующей графе Type определено будет ли показан данный параметр при открытии окна свойств модели и доступен ли он для редактирования. Значение Normal в данной графе предусматривает и то и другое. Ну и, наконец, в Property Defaults назначено значение по умолчанию 1 и для Visibility определено Hide Name & Value, т.е. по умолчанию рядом с моделью на месте серого ‹TEXT› это свойство демонстрироваться не будет.
SETPOINT – установленная точка (Рис.34). Это свойство задает модели начальное (стартовое) значение. Опять-таки, поскольку у нас датчик температуры, то ему и задано Description как Current Temperature. Тип задан тоже Float, а вот на графу Limits я прошу обратить особое внимание. В ней из раскрывающегося списка выбран тип Specific (надеюсь, хоть это слово переводить не надо) и ниже заданы особые ограничения минимальное -40 и максимальное 125. Т.е. это предельные значения для задания температуры. Я не знаю, какие цели преследовал автор модели, задавая именно эти значения здесь, так как для большинства модификаций датчиков LM20 эти значения по даташиту равны соответственно -55 и 130. Но в одном я ему благодарен, поскольку у меня есть возможность показать, как это ограничение работает в ISIS. Если вы попробуете открыть окно свойств датчика (Рис. 30) и ввести там для Current Temperature, допустим значение 128 и попытаетесь потом закрыть окно свойств, то получите предупреждение о недопустимом значении температуры. Аналогичное сообщение выскочит и при задании температуры ниже -40. Ну, больше для этого свойства ничего интересного нет, следующий Type задан Normal, поэтому в окне свойств модели (Рис. 30) мы видим Current Temperature отдельной строкой с доступным для изменения окошком значения, которое по умолчанию для «свежевытащенной» из библиотеки модели равно 25 градусам (окошко Default Value на рисунке 34).
Ну а теперь небольшой фокус. Для отдельно стоящих свойств MIN (Рис. 35) и MAX (Рис. 36) заданы соответственно именно те значения из даташита -55 и 130. Эти свойства передают программной модели SETPOINT пределы изменения нашего параметра с помощью кнопок-маркеров INCREMENT и DECREMENT. Так вот, автор здесь задал значения шире, чем те пределы в свойстве SETPOINT. И с помощью этих кнопок мы можем изменять температуру именно в пределах -55…130, и Протеус при этом ругаться не будет. Вот такой парадокс. Ну, раз уж мы плавно перескочили к рассмотрению свойств MIN и MAX, то хочу обратить ваше внимание на то, что для них нижний Type задан Hidden (скрытый). Поэтому в окне свойств датчика LM20 (Рис. 30) мы их не видим, но можем увидеть и даже менять заданные значения, если поставим галочку Edit all properties as text в левом нижнем углу этого окна. Более о них сказать нечего, Minimum Temperature и Maximum Temperature говорят сами за себя.
FORMAT – название этого свойства тоже не нуждается в переводе, а относится оно к формату числа, выводимому в окошечко зеленого дисплея. Это подтверждается и тем, что в Description автор модели указал Display Format (Рис. 37). Обратите внимание, что верхний Type для этого свойства задан, как String – текстовая строка. Нижний Type тоже скрытый, поэтому оно видно только при установленном флажке Edit all properties as text. Ну а теперь о самом главном для этого свойства – Default Value. По умолчанию оно задано как 3.1, что означает три знака до десятичной запятой и один после. При желании эти значения можно изменять, только следите за тем, чтобы общее число символов уместилось в зеленом окошке.
Следующие два свойства STATE – активное состояние при старте симуляции и TSWITCH – время переключения для большинства активных моделей на основе SETPOINT в основном будут иметь именно те значения, которые показаны на рисунках 36 и 37 соответственно. Первое из них отвечает за то, какой параметр будет активным (доступным для изменения) при старте симуляции. Поскольку он у нас всего один, то и STATE=0. Ну а время переключения TSWITCH=1ms – это то время, за которое наше значение изменится после нажатия на соответствующую кнопку-стрелку. Соответственно им тоже задан нижний Type скрытый, а в ряде случаев ими, в частности TSWITCH, можно и вообще пренебречь и при создании своих активных моделей не указывать.
Ну а мы на этом закончим нудную, но нужную для понимания того, что мы будем делать ниже описательную часть, и переходим к практическим действиям – созданию активных моделей на основе SETPOINT.DLL.
Рисунки 30, 31, 32.
Рисунки 33, 34, 35.
Рисунки 36, 37, 39.

[Halex07]

8.3. Простые регулируемые источники на основе SETPOINT.DLL.
Отлаживая свои проекты в среде Протеуса, как то я обратил внимание на некоторое упущение разработчиков программы, доставляющее массу неудобств. В ISIS абсолютно отсутствуют готовые средства, с помощью которых можно в процессе выполнения симуляции изменять напряжение или ток, в какой либо цепи. Конечно, можно их реализовать с помощью обычных генераторов и тех же активных моделей потенциометров, но это получается настолько громоздко и неудобно в использовании, что весь эффект применения сводится на нет. И вот однажды, отлаживая очередную схему, в которой присутствовала активная модель датчика температуры, я подумал – а нельзя ли подобным образом реализовать, например, изменяемый источник напряжения для питания какой либо части схемы. И удобно, и наглядно. Ну и дальше все просто, «подумано» – сделано.
Я изучил, как сделана модель датчика температуры, что мы проделали выше, а затем заглянул в ее файл MDF. Для любопытствующих я поместил уже извлеченный из NATDAC.LML файл LM20.MDF. И тут меня ждал весьма неприятный сюрприз. В PARTLIST файла модели (см. ниже) фигурировал элемент VOUT, который отсутствует в библиотеках Протеуса. Пошарив в других MDF, использующих SETPOINT.DLL, я обнаружил его во всех списках компонентов этих моделей.

*PARTLIST,6    
AVS1,AVS,"(-3.88E-006*V(A,B)^2)+(-1.15E-002*V(A,B))+1.8639",PRIMITIVE=ANALOGUE
C1,CAPACITOR,1uF,PRIMITIVE=ANALOGUE
I1,CSOURCE,10uA,PRIMITIVE=ANALOGUE
R1,RESISTOR,10k,PRIMITIVE=ANALOGUE
R2,RESISTOR,100,PRIMITIVE=ANALOGUE
V1,VOUT,1V,MODDLL=SETPOINT,PRIMITIVE=ANALOG,SETPOI  NT=‹SETPOINT›

Поначалу меня такой сюрприз обескуражил, но логически помыслив, я пришел к выводу, что раз он так широко используется, то, скорее всего, реализован в виде встроенного в среду примитива и можно попробовать «обмануть» Протеус, подсунув ему собственную модель с теми же свойствами. Попробуем реализовать его на основе двухполюсника генератора напряжения VSOURCE из библиотеки Simulator Primitives. Функционал – источник постоянного напряжения у них совпадает, значит осталось только придать прототипу недостающих свойств. Помещаем извлеченный из библиотеки VSOURCE в поле проекта и применяем к нему мою излюбленную Make Device. Смотрим на последнюю строчку приведенного выше PARTLIST. Наша модель должна иметь имя VOUT и префикс V, что и прописываем на первой вкладке (Рис. 40). Напомню, что в ней все свойства разделены запятыми, а VALUE стоит третьим сразу после имени VOUT.
Вторую вкладку проходим транзитом, поскольку корпус нашему девайсу не нужен и переходим на третью. Здесь убеждаемся, что уже присутствующие свойства PRIMITIVE (Рис 41) и VALUE (Рис. 42) соответствуют записанным в строке для VOUT из приведенного выше PARTLIST.
Теперь добиваем через кнопку New недостающие MODDLL (Рис. 43) и SETPOINT (Рис. 44). Последнее, по большому счету, добивать необязательно, всегда можно добавить вручную в окне свойств компонента, но на первых порах, чтобы не забыть о его существовании - лучше вставить.
Обратите внимание, что его Default Value стоит в угловых скобках (знаки больше-меньше на клавиатуре). Это дает команду Протеусу подставлять значение из внешнего по отношению к модели окружения. После этого доходим до последней вкладки и сохраняем наш VOUT в какой-либо библиотеке. Я тут не мудрствовал и сохранил в USRDVC, оставив все категории компонента, как и у VSOURCE, чтобы не забыть, где его впоследствии искать (Рис. 45).
Если теперь вытащить наш VOUT в поле проекта и запустить симуляцию, то вылезет желтое предупреждение в логе об отсутствии значения для SETPOINT, т.е. ISIS не нашел конкретного значения. Однако если поместить в поле проекта скрипт следующего содержания:

*DEFINE
SETPOINT=6.3

Наша модель начинает благополучно работать и «выдавать на гора» то напряжение, которое задано в скрипте. Такая подстановка вам уже знакома из создания схематичных моделей, но я счел нужным лишний раз напомнить – как это работает. В папке Create_VOUT присутствует проект, с которого сделан скриншот рисунка 46. Если кому то очень лень (некогда) заниматься такими пустяками, как создание VOUT – можете просто применить к стоящей в этом проекте модели Make Device, пройти ничего не меняя все вкладки и сохранить в собственной библиотеке Протеуса. Если ничего не трогать, то сохранится он в USRDVC, а в библиотеке его можно будет найти в Simulator Primitives =› Sources.
Ну вот, теперь нам осталось создать активную графику для нашего будущего источника. Тут тоже не стоит мудрить – давайте «разберем на запчаcти» все тот же LM20 и воспользуемся его символами. Итак, помещаем в поле проекта LM20, Decompose его и видим, что у нас в селекторе символов появились два символа с именем SETPOINT: SETPOINT_0 и SETPOINT_1.
Я не стану в этот раз заморачиваться с изменением символов, поскольку в активной модели, как я уже указывал, сдвиг графики относительно маркера ORIGIN повлечет за собой коррекцию всех остальных графических элементов. Поэтому, оставляем все как есть. На рисунке 48 приведены препарированные с помощью Decompose символы SETPOINT_0 и SETPOINT_1, чтобы вы имели представление о местоположении маркера ORIGIN. Полностью разобранный на запчасти LM20 в проекте Prepare_LM20.DSN папки Create_VREG вложения. Это как бы первый, подготовительный этап создания нашего источника. А мы переходим ко второму и заключительному.
Теперь нам необходимо убрать все лишнее из графики и добавить свое. Лишним в данном случае является скрипт и выводы компонента, в том числе и скрытые выводы питания, которые появились после разборки модели на запчасти. В результате у меня получилась «конструкция», показанная на рисунке 49 слева с которой я и начинаю выполнять создание нашего источника с помощью Make Device. На первой вкладке заполняем все так, как на рис. 49.
Особое внимание правильности заполнения нижней части, относящейся к активным свойствам. Не забудьте, что символы SETPOINT должны быть доступны в селекторе SIMBOLS этого проекта. Я сделал так, вот тот предыдущий проект Prepare_LM20.DSN сохранил в этой же папке с новым именем Create_VREG.DSN, а после этого убрал все лишнее и добавил свои выводы (Pins). При этом символы остались доступными. Далее следуем в Make Device на третью вкладку и начинаем добавлять свойства по аналогии с LM20. У нас и так в этом параграфе переизбыток картинок, поэтому ограничусь моментом добавления MODDLL, при этом у нас окно свойств еще девственно чистое (Рис. 50). Не забудьте, что по умолчанию нижний Type для MODDLL будет предложен как Read Only (только для чтения). Это означает, что в окне свойств модели он будет показан, но не будет доступен для изменения (закрашен серым). Мне на это любоваться неохота, тем более что необходимо будет другие свойства сделать доступными, в отличие от LM20, поэтому здесь я выберу Hidden (скрытое).
Также, через кнопку New и опцию Blank Item обязательно добавляем следующие свойства:
STEP – в графе Description я набрал Voltage Step (Шаг напряжения), верхний Type – Float, нижний Type – Normal, Default Value – 0.1.
SETPOINT – в графе Description я набрал Current Voltage (текущее значение напряжения), верхний Type – Float, нижний Type – Normal, Default Value – 0.0. Обратите внимание, что ни здесь, нигде более я не воспользуюсь Limits, поскольку моя модель для отладки, но MAX и MIN заведомо достаточно большие я все же введу, иначе изменение значения с помощью кнопок будет криво работать.
MAX – в графе Description я набрал Maximum Voltage (Максимальное значение напряжения), верхний Type – Float, нижний Type – Normal, Default Value – 500.
MIN – в графе Description я набрал Maximum Voltage (Минимальное значение напряжения), верхний Type – Float, нижний Type – Normal, Default Value – -500.
Я сделал максимальное и минимальное напряжения видимыми в свойствах, потому что вдруг да не хватит значения 500V, всегда можно поправить. Остальные свойства я пока вводить не буду, чтобы доказать, что и без них мы получим вполне работоспособную модель.
Доходим до последней вкладки и сохраняем нашу модель. Я сохранил ее в Debugging Tools, создав там дополнительную подкатегорию Sources (Рис. 51). Если кому то это не нравится, может сохранить в другом месте.
Если теперь поместить нашу модель, появившуюся в селекторе компонентов в поле проекта и зайти в ее свойства, то мы увидим все наши добавки с третьей вкладки Make Device, причем в том порядке, в каком мы их добавляли там (Рис. 52). Обратите внимание, что MODDLL здесь нет, потому что для этого свойства мы выбрали нижний Type – Hidden. Порядок отображения свойств в этом окошке можно изменить. Если мы запустим еще раз Make Device, то на третьей вкладке можем переставить порядок расположения уже существующих свойств с помощью кнопок со стрелками справа от этого окна. Кликаем по свойству, которое надо передвинуть, и этими кнопками передвигаем его на нужное место. Средние стрелки передвигают на одну позицию, крайние верхняя и нижняя соответственно в начало или в конец. Естественно, чтобы изменения сохранились надо пройти Make Device до конца и подтвердить изменения при сохранении модели.
Теперь, как обычно, в свойствах устанавливаем флажок Attach Hierarchy Module, уходим на дочерний лист и там собираем «архисложную» субсхему нашего девайса (Рис. 53).
Как видите, вся схема состоит из свежевыпеченного нами выше VOUT и двух терминалов, имена которых выбираются из раскрывающегося списка. А в списке будут фигурировать только наши два вывода модели с именами + и -. Ну вот и весь процесс, осталось вернуться на основной лист проекта, прицепить для контроля к выводам нашего источника вольтметр и запустить симуляцию. Пробуем кнопками менять напряжение и убеждаемся, что все работает как надо (Рис. 54).
Нам осталось скомпилировать с дочернего листа файл MDF, я назвал его VREG.MDF, затем запустить для нашего источника еще раз Make Device и на третьей вкладке добавить свойство MODFILE, указав ему в графе Default Value имя нашего скомпилированного файла. Мы это уже неоднократно проделывали при создании схематичных моделей, и, надеюсь, тут разъяснять дополнительно ничего не требуется. Окончательный вариант с файлом MDF представлен в папке VREG_with_MDF вложения.
Ну а мы теперь модифицируем наш источник и превратим его в источник тока. Модификация заключается в том, что на дочернем листе нам придется добавить еще один примитив – управляемый напряжением источник тока VCCS или AVCCS с коэффициентом передачи 1.0 (Рис. 55). После этого компилируем с дочернего листа новый файл IREG.MDF. Сама графика остается без изменений, но необходимо вновь пройти Make Device. На первой вкладке даем нашей модели другое имя, например, IREG. На третьей придется поправить Description у большинства свойств, заменив там слово Voltage (напряжение) на Current (ток), чтобы потом самим не путаться. Ну, можно еще сменить ограничения для MIN и MAX на разумные, поскольку ток в 500А нам на фиг не нужен. Ну и конечно, для MODFILE надо указать новое значение IREG.MDF. Проект с дочерним листом представлен в папке Create_IREG вложения. А в папке IREG_with_MDF уже модель с присоединенным MDF и сам IREG.MDF.
Ну и несколько заключительных слов по использованию этих моделей. Я пошел навстречу «идолопоклонникам» русского интерфейса и в папке RUS вложения лежат проекты, в которых Description моделей сделан кириллицей. Для них в конце имен я добавил RUS. Причем файлы MDF для них остаются неизменными. Меняется только Description на третьей вкладке Make Device. Вам остается только выбрать то, что вы хотите использовать в своих проектах, протолкнуть для выбранных моделей Make Device, ничего не меняя во вкладках, чтобы эти модели появились в ваших библиотеках ISIS и переложить файлы VREG.MDF и IREG.MDF из выбранных папок в папку MODELS Протеуса. Обращаю ваше внимание, что если вы перед применением Make Device запускали симуляцию, изменили напряжение или ток, сменили в окне свойств какие либо параметры, например, STEP или FORMAT, то модель сохранится именно с этими параметрами, если конечно вы их не исправите на третьей вкладке к другим значениям.
Рисунки 40, 41, 42.
Рисунки 43, 44, 45.
Рисунки 46, 47, 48.
Рисунки 49, 50, 51.
Рисунки 52, 53, 54.
Рисунок 55.

[Halex07]

8.4. Модель датчика давления с выходом 4-20мА на основе SETPOINT.DLL.
Я бы изменил своему нынешнему профессиональному эго, если бы не поделился с вами еще одной своей наработкой в области моделирования. По своей сфере теперешней деятельности – проектирование и монтаж автоматики мне постоянно приходится работать с различными датчиками: температуры, давления, расхода и т.д. и т.п. Львиную долю датчиков давления среди всего этого разнообразия занимают датчики с типовым выходным токовым сигналом – 4-20мА. Конечно, можно использовать в этих целях и обычные примитивы генераторов тока, но это обычно доставляет массу неудобств при моделировании поведения девайса в реальном времени. Каждый раз при смене значения придется полностью останавливать симуляции. «Прикручивание» к ним активных моделей потенциометров тоже не меняет дело к лучшему. В конечном итоге, как правило схемы для моделирования представляла собой нечто вроде изображенных на рисунке 56.
Мало того, что такие «примочки» в проекте занимают много места, так еще приходится держать перед глазами и таблицу пересчета давления в ток или иметь под рукой калькулятор для этих целей. Естественно меня такое положение дел не устраивало. Ну и сам собой напрашивался прецедент иметь в ISISмодель универсального датчика давления для разработки своих устройств.SETPOINT.DLL для этих целей подходит как нельзя лучше. Для начала немного арифметики. Предположим, мы имеем датчик избыточного давления от 0 до 100кПа (ну или 0–1кгс/кв.см, что практически тоже самое). Для покрытия этого диапазона нам отводится токовый диапазон от 4мА (соответствует 0) до 20мА (соответствует верхнему пределу), т.е. 20-4=16мА. Разделив 16 на 100 получим, что изменению давления на 1кПа соответствует изменение тока на 0,16мА. Эта ориентировка поможет нам в дальнейшем.
Теперь создаем нашу модель. Художник из меня еще тот, но все же я постарался изобразить нечто напоминающее реальный датчик (Рис. 57).
Поскольку в данном случае графика модели создается «с нуля» остановлюсь на некоторых нюансах. Изображение резьбы в разрезе выполнено с помощью ClosedPathиз левого тулбара, затем в свойствах изображения снимаем галочку с Fillstyleи выбираем режим косой штриховки (Рис. 58 ). Там же, сняв флажок Width, выбираем более тонкий контур для обрисовки объекта - 8th.
Индикатор в данном случае тоже нарисован свой. Для этой цели в режиме рисования прямоугольников выбираем в селекторе опцию INDICATORи рисуем наш экран в нужном месте. Чтобы не ошибиться с размерами – лучше поместить рядом что то из реальных моделей, содержащих аналогичный микродисплей, например, – вольтметр. В принципе, вы можете нарисовать индикатор хоть на поллиста проекта, но все же необходимо учитывать, что его параметры взаимодействуют с SETPOINT.DLL, а там о них уже до нас позаботился программист, создавший эту библиотеку. Поэтому мы будем иметь тот шрифт и цвет, которые уже есть, ну а максимально индицируемое число, я думаю, вам не составит труда определить самостоятельно, если вспомнить, что мы его в свойствах задаем как float.
Ну и, наконец, о маркерах инкремента и декремента. Поскольку это маркеры, мы их и берем из селектора в режиме 2DGraphicMarkersMode(Рис. 60).
С остальной графикой, надеюсь, проблем не будет. Надписи помещены чисто в «напоминательных» целях и никаких подводных камней в них не зарыто. Выводам присвоены только имена «+» и «-» , нумерация нам не нужна, поскольку корпуса эта модель содержать не будет. После того, как прорисована вся графика полностью, выделяем все ее элементы с помощью обводки с зажатой левой кнопки мышки и через BlockCopyразмножаем в двух экземплярах для создания символов. На одной копии удаляем выводы, экран и маркеры инкремента/декремента – это будет база, символ с индексом _0, а на другой оставляем только экран и маркер ORIGIN– это будет символ с индексом _1 (Рис 61). Затем из того, что изображено на этом рисунке создаем символы. Я назвал их SENSOR_0 и SENSOR_1. Создав символы, убедитесь, что при переходе в режим символов (кнопка S в левом тулбаре) они доступны в селекторе. Только после этого можно приступать к созданию самого девайса из того полного графического изображения вместе с выводами, что я привел на рисунке 57.
Сразу же хочу обратить ваше внимание, что вот такой порядок создания графики для активных компонентов заведен и у самих разработчиков в Лабцентре. Т.е. сначала прорисовываем все в совокупности, затем копируем через BlockCopyи тупо тыкаем левой кнопкой в нужных местах, размножая нужное количество раз полное изображение. Ну, а уж потом, как скульпторы, на копиях отсекаем (двойной клик правой) все ненужное для каждого конкретного символа. При этом минимален риск получить неправильное позиционирование нашего символа относительно маркера ORIGIN, если конечно сдуру нечаянно не кликнуть пару раз правой и по нему. Мне этот «фокус» лабцентровцев подсказал Тень, хотя, к тому времени я уже и своими извилинами «дополз», что так получается быстрее. Особенно прирост скорости скажется при создании многоэлементных индикаторов или клавиатур, чем мы займемся чуть позже. Но привыкать к такому порядку я призываю заранее.
Итак, с графикой разобрались. Теперь мой любимый Make Device. На первой вкладке задаем имя нашему девайсу и задаем параметры активной графики (Рис. 62). Ну, тут все, как и с источниками, за исключением того, что символы у нас теперь с собственными именами.
Да и на третьей странице мало что изменилось, разве что в Descriptionя поставил другие названия, например для самого SETPOINTтам стоит ActualPressure– текущее давление (Рис. 63).
Я не стану здесь приводить все скриншоты с третьей вкладки, желающие могут открыть пример Graphic_Child.DSN в папке вложения Simple_Model, войти в свойства или запустить Make Device для уже готовой модели и посмотреть на третьей вкладке – что и как я «обозвал». К данному моменту это вы уже должны усвоить это как дважды-два. Можете также перевести Descriptionна русский, мне, честно говоря, это делать лень, тем более, что меня никакими коврижками не заманишь пользоваться «русифицированной» версией. Боюсь, что даже если Тень когда-либо сподобится раскрутить свое начальство на выпуск официальной русской локализации интерфейса. После нескольких лет работы настолько привыкаешь к оригиналу, что «уписанное» на место лаконичной английской фразы наше родное, вечно не помещающееся в строку и поэтому урезанное до невозможности типа «Тпр. пр. гр.» расшифровать гораздо труднее, чем полную аглицкую фразу. Ну, это так, небольшое отступление от темы, а мы создаем девайс до конца, сохраняем и как обычно в свойствах «приклеиваем» дочерний лист. На нем создаем внутреннюю структуру нашего девайса, или Testjig, как это именуется в оригинальной документации VSMSDK (Рис. 64).
Давайте разберем эту «джигу» по косточкам. Связка первых двух компонентов аналогична управляемому источнику тока, рассмотренному ранее, вот только у G1 в передаточной характеристике стоит «хитрая формула». Я ее нарочно расписал поподробнее, чтобы было проще объяснять. Первый множитель – 0.001 переводит наше значение тока в миллиамперы. Стоящая в скобках разность ‹MAX›-‹MIN› дает нам полный диапазон изменения давления нашего датчика. Причем, мы вольны задавать им любые положительные значения или ноль для минимума. А отношение 16.0 (полный диапазон тока, мы определили его выше) к диапазону изменения давления даст нам коэффициент пересчета давления в ток. Таким образом, VOUTбудет менять свое значение от MINдо MAX, а G1 пересчитывать его в ток от нуля до 16мА. ИсточникI1cтоком 4мА в сумме сдвинет нам диапазон в 4-20мА, что нам и надо. У кого затруднение с пониманием параллельного включения G1 и I1 – попросите у детей физику за 7-й класс и перечитайте законы Кирхгофа. Хотя, это я официально учил в 7-м, а неофициально – самостоятельно в 4-м, а что там сейчас учат, одному директору школы известно. Ох, опять в ностальгию ударился. Идем дальше…
Ну, в общем, идем на ParentList запускаем и тестируем нашу модель, используя различные диапазоны значений давления. Все это доступно в упоминаемом выше примере. Я не стал вводить ограничения для MINи MAXна третьей вкладке, чтобы вы могли убедиться, что при использовании отрицательных значений дляMINмы получим полный бардак на выходе. Если кому то нужна полностью работоспособная модель с такой внутренней структурой, то рекомендую «мэйкануть» ее еще раз и на третьей вкладке для MINвыбрать вLimitsиз раскрывающегося списка ограничение PositiveOrZero(положительное или ноль), А для MAXпредел PositiveNon-Zero(положительное, не ноль). Затем с дочернего листа скомпилироватьMDFи на третьей вкладке добавить его через MODFILE.
Я же, пошел дальше и решил сделать более универсальную модель – датчик лавления/разрежения или на языке КИПовцев – тягонапоромер. Если ей задать нижний предел ноль – это обычный датчик давления, если меньше нуля – тягонапоромер. Поменялся при этом только дочерний лист, а что за «джига» у меня получилась показано на рисунке 65, а также в примере Uni_Sens_1.DSN из папки Uni_Sensor_with_Child.
Какие здесь встретились заморочки. Во-первых потребовалось сдвинуть диапазон VOUTв область положительных значений. С этой целью введены V2 и AVS2. Почему получилось так сложно? Просто для обычных источников функция abs(абсолютное значение или по другому модуль) не работает, она предназначена только для ArbitrarySource (см. материал из предыдущих частей или HELPпо примитивам). С этой же целью иACS1 тоже взят arbitrary. Там для обычного VCCSпочему то не работала подстановка диапазона ‹UPPER› из скрипта *DEFINE. Формулу я упростил, перемножив заранее 0,001 на 16. Для этой модели я уже скомпилировал MDFи приложил для тестирования в папке Uni_Sensor_MDF. Там модель уже с присоединенным MODFILE. Достаточно протолкнуть для нее Make Device ничего не меняя и переложить MDFв папку MODELSдля использования в своих разработках. Вот здесь я для MAXввел Limits, а для MINне стал. Вряд ли кому придет в голову делать MINбольше MAX, хотя у наших доморощенных умов…
На этом абстрактный материал по SETPOINTзакончен, но, пожалуй, добавлю далее еще одну модельку из RealityShow, тем более она мне и самому понадобилась.
Рисунки 56, 57, 58.
Рисунки 59, 60, 61.
Рисунки 62, 63, 64.
Рисунок 65.

[Halex07]

8.5. Модель датчика давления FreescaleMPX5010 из модели MPX4250.
Предыстория создания этой модели заключается в том, что мне захотелось иметь персональный электронный манометр для контроля давления природного газа на бытовых газовых котлах и промышленных газовых горелках. Есть у нас на работе и поверенные сертифицированные, но бывает так, что под рукой отсутствует, а срочно нужен. Поскольку для этих целей я буду тратить «свои кровные», захотелось создать дешевую и доступную по комплектующим конструкцию. В качестве датчика давления мне приглянулся недорогой MPX5010 отFreescale (он же бывшийMotorola). Конечно, для портативного прибора лучше было бы использовать более современный MP3V5050 с трехвольтовым питающим напряжением, но как сказал слесарь Полесов: «при наличии отсутствия пропитанных шпал…» придется обойтись тем, что есть в продаже.
В Протеусе датчики давления представлены всего двумя довольно архаичными моделями в библиотеке Transdusers=›Pressure. Это датчик абсолютного давления MPX4115 с пределом 15…115кПа и датчик относительного давления MPX4250cпределами 0…250кПа. Если кто-то первый раз сталкивается с датчиками давления, поясню, что датчики абсолютного давления используются в основном для контроля атмосферного давления в тех же электронных барометрах и метеостанциях (например, любимые нашими синоптиками 760 мм ртутного столба соответствуют 101,308кПа). Датчик относительного давления контролирует превышение давления на его входе относительно атмосферного. Такие датчики применяются для контроля давления в трубопроводах, резервуарах, автошинах и т.п. Мне нужен датчик относительного давления. Предел в 250 кПа меня мало устраивает, мне достаточно 10, но «за основу», как говорили всякие партократы-бюрократы эту модель принять можно, тем более, что сделана она довольно профессионально и заслуживает рассмотрения с точки зрения внутренней структуры. Подключение модели и выдаваемое ею напряжение при минимальном и максимальном давлении показано на рисунке 66.
Для начала заглянем в окно свойств модели этого датчика (Рис. 67) и сопоставим их с даташитом.
В основном окне доступны для изменения только два параметра Granularity (шаг изменения) и Pressure – стартовое значение давления. Модель построена на основе все того же SETPOINT, поэтому назначение этих параметров не вызывает затруднений. А вот в раскрывающемся списке AdvancedProperties«зарыты» именно свойства связанные с даташитом датчика, который, кстати, можно скачать, нажав кнопку Data. Рассмотрим их:
Sensitivity –SENS(здесь и ниже черным жирным указано как они трактуются в режиме EditallPropertiesastextи на третьей вкладке Make Device). Чувствительность датчика –типовое значение 18,8 мВ/кПа по таблице OPERATING CHARACTERISTICS на стр. 2 даташита. Соответственно в Протеусе эта запись будет выглядеть как 18.8E-03.
Offset – OFFSET – смещение. Значение 0,04 фигурирует в формуле Transfer Function (передаточная функция) на стр. 3 и 4 даташита.
PressureErrorBand – PEB –диапазон ошибки давления максимальное значение 3,45 кПа приведено на графике стр. 4 даташита.
Temperature– TEMPERATURE – указанное в свойствах значение TEMP(по умолчанию 27°С) берется из параметров симулятора (меню System=›SetSimulationOptionsвкладка Temperature) и позволяет имитировать поведение датчика в зависимости от температуры. О температурном моделировании я уже рассказывал во второй части FAQ.
Теперь восстанавливаем структуру по файлу MDF(Рис. 68 ).Так, предчувствую скептические замечания, - опять автор «чудит». Где он взял эту сороконожку –ACS1 – в примитивах такого нет. Да просто надо внимательно читать HELP по примитивам. Открываем раздел The Arbitrary Controlled Source Models - AVS, ACS и находим там следующий абзац:

Voltage input values are referred to as V(A), V(B), V(C) etc. within the expression, these values referring to the voltages at pins named A, B, C. The form V(A,B) is also supported, this meaning the differential voltage between pins A and B.

В вольном переводе это звучит следующим образом:
Значения входных напряжений описываются в выражении как V(A), V(B), V(C) и т.д., где значения соответствуют напряжениям на ножках (пинах) с именами A, B, C. Форма записи V(A,B) также поддерживается и соответствует разности напряжений между выводами A и B.
Как видим, в стандартных примитивах все ArbitrarySource с двумя входами – Aи B, хотя их может быть … и т.д.. А вот это самое V(C) фигурирует в выражении для AVS1в MDF модели датчика (выражение выделено желтым цветом на рисунке 68. Но вывода С у примитива не было, пришлось срочно «припаять». Так что ничего сверхъестественного – я просто разобрал (Decompose) существующую модель AVCCS и приделал к ней еще один вход с именем С, ну а потом «мэйк девайснул» свое новое творение. Верхний слева по схеме вывод и есть этот пресловутый C. Для большей компактности схемы мне пришлось отразить модель AVS1 по вертикали и поэтому выводы входов получились снизу вверх: A, B, C. Именно этот примитив и является основным в модели датчика, и в выражении, описывающем его передаточную характеристику, заложена основная формула преобразования.
Вообще данная модель, с моей точки зрения, обладает даже некоторой избыточностью. Попробую описать назначение остальных узлов схемы, как я их понял. Основным управляющим элементом является все тот же VOUTV2, связанный с SETPOINT.DLL. Источник V1 со значением PREF=0 вероятно был заложен для коррекции передаточной характеристики в зависимости от VOUT, но поскольку в конечном итоге он оставлен с нулевым напряжением, это явное излишество. Источник V3, значением которого является температура, и связанный с ним источник AVS1 с длинным полиномом в передаточной характеристике, призваны имитировать поведение датчика при температурном анализе. Ну и, наконец, источник AVS2, передаточная характеристика которого зависит от напряжения питания, имитирует поведение датчика при изменении питающего напряжения.
Восстановленная из MDF cтруктура MPX4250 приложена в проекте Stucture_MPX4250\ Struct_MPX4250.DSN вложения.В этой же папке приложен и извлеченный из библиотекиTRXD.LMLфайл MPX4250.MDF.
Я же приступаю к подгонке структуры под свои нужды, т.е. созданию MPX5010. Как я уже предупреждал, источник V1 отправляю на свалку, соответственно в свойствах упраздняется параметр PREF. Максимальное значение в свойствах изменяем сMAX=250наMAX=10, минимальное остается неизменным. Ошибка давления для новой модели приведена на стр. 6 соответствующего даташита, и составляет:PEB=0.5 kPa. Несколько сложнее обстоит дело с чувствительностью. В таблице характеристик датчика MPX5010 даташита есть небольшая «очепятка» верхнее значение для Sensitivity это как раз 450 mV/kPa, а не какие то там подозрительные mV/mm. Нижнее значение для миллиметров водяного столба указано правильно.
Как видите, и на Freescale «бывает проруха», это лишний повод мне напомнить, что своя «соображалка» должна быть всегда начеку. Ставим в свойствах SENS=450E-03.
Далее необходимо заняться формулами, описывающими передаточные характеристики источников в структуре MPX4250. Нам необходимо сопоставить, что там требуется заменить и как в новой модели. MPX5010.
Для начала обратим внимание на передаточную характеристику (TransferFunction), представленную в даташитах на датчики.
Для MPX4250 она описывается как: Vout = Vs x (0.00369 x P + 0.04) ± Error
где: Error = Pressure Error x Temp. Factor x 0.00369 x Vs
Vs= 5.1 ± 0.25 Vdc

Для MPX5100 она описывается как: Vout = Vs x (0.09 x P + 0.04) ± Error

где: Error = Pressure Error x Temp. Factor x 0.09 x Vs
Vs= 5.0 ± 0.25 Vdc
Ну, даже беглый взгляд, сразу подсказывает, что там, где в формулах для MPX4250 стоит напряжение 5,1 для MPX5010 нам надо поставить ровно 5.
Длинный «член» вAVS1 оставим неизменным, поскольку, если внимательно посмотреть температурные зависимости в даташитах обоих датчиков, то они полностью совпадают. Получившаяся структура представлена в проекте Struct_MPX5010.DSN из папкиStucture_MPX5010 вложения. Далее надо создать графическую модель MPX5010, и поменстить нашу структуру на дочерний лист для тестирования. Мудрить с графикой я не стал. Поступаем просто: берем модель MPX4250 и применяем к ней Make Device. На первой вкладке переименовываем в MPX5010, на третьей удаляем, ставший ненужным параметрPREF, а также временно удаляем MODFILE, позже мы присоединим новый. Там же правим значения остальных свойств:MAX, PEB, SENS, как было указано выше.Ну и перед сохранением на последней вкладке в окне DeviceDescriptionисправляем предел с 250 на 10 kPa, чтобы потом не путаться самим. Теперь как обычно помещаем нашу модель в проект, присоединяем к ней дочерний лист и помещаем туда нашу структуру. Этот вариант представлен в папке MPX5010_Child вложения.
Тестируем, затем с дочернего листа компилируем MDFи еще раз пройдясь черезMakeDevice присоединяем на третьей вкладке наш MODFILE. Готовый вариант с MDFпредставлен в папке MPX5010_MDF вложения.
Ну и под занавес я не удержался от того, чтобы проверить – как влияет вот тот длинный «член»-полином температурной зависимости в AVS1. Этот проект представлен в папке MPX5010_TEMP. Для того, чтобы получить зависимость выходного напряжения от температуры, я воспользовался графиками DCSWEEP. В свойствах датчика для Temperature подставляем вместо TEMP значениеX, а в свойствах графика дляX задаем значения от -40 до 125 – как в даташите. Я сделал два графика при нулевом и максимальном давлении. Они представлены на Рис. 69.
Ну, по большому счету, можно сказать, что «многочлен» работает – налицо характерные завалы вверх ниже нуля и выше 80 градусов, которые есть и на графике в даташите. Даташиты на датчики MPX4250 и MPX5010 также присутствуют во вложении, так что можете убедиться самостоятельно. Я же на этом заканчиваю материал с моделированием на базе SETPOINTи перехожу к другим программным моделям на основе DLL.
Рисунки 66, 67, 68.
Рисунок 69.

[Halex07]

8.6. LEDMPX.DLL – основа всех активных «светящихся» цифровых индикаторов в ISIS.

«Все-таки модель индикатора в протеусе штука глючная.»
shamber (30.01.2011)

Наконец-то я добрался до подробной разборки с этой библиотекой, чтобы раз и навсегда положить конец утверждениям «чайников» о глючности сегментных индикаторов в ISIS. Видимо информации в первой части FAQпо динамической индикации оказалось недостаточно. Будем «жевать» дальше.
Итак, из самого названия библиотеки можно вынести уже достаточно информации. LEDговорит нам о том, что предназначена она для создания всевозможных светодиодных индикаторов, а MPX – принятое «за бугром» сокращение слова multiplexing. Вот именно на этот последний термин почему то многие откровенно «наплевали и забыли», а зря. Приведу дословно одно из толкований, встречающихся в Интернете: «Процесс объединения отдельных потоков или каналов в один логический поток данных таким образом, что они позднее могут быть восстановлены в прежнем виде без ошибок. Двумя наиболее широко используемыми технологиями мультиплексирования являются частотное разделение каналов, когда для передачи различных сигналов используются несущие с различной частотой, и временное разделение каналов, когда отдельные сигналы передаются в свои временные промежутки». Пожалуй, такая трактовка наиболее полно отражает то, что уже в самой библиотеке заложено мультиплексирование, т.е. разделенная во времени обработка сигналов. И об этом забывать никак нельзя, особенно когда вы на эту динамику накладываете еще и свою, пытаясь симулировать динамическую индикацию со СВОИМИ временными параметрами, подчас, далеко не идеальными. Вот и попробуйте мысленно представить себе – что должно получиться в итоге, когда вы наложите друг на друга:
· Ваши собственные импульсные последовательности сканирования катодов индикаторов (раз) и анодов индикаторов (два);
· Времянки самой LEDMPX – по умолчанию MinimumTriggerTimeустановлено, как 1мсек (три)
· Параметры мультипликации самого симулятора на экране – по умолчанию вSystem =› SetAnimationOptionsчастота смены картинок FramesperSecondравна 20 (четыре).
Для того чтобы эти четыре составляющие дали адекватный результат нужно очень внимательно соотнести их параметры и универсального рецепта тут нет и быть не может. Всегда требуется индивидуальный подход, поскольку один применяет динамическую индикацию с частотой 25 Герц, другой – 40, а третий может вообще задрать до 200. Поэтому, только при грамотной установке временных параметров симулятора и самой модели на основе LEDMPX.DLLв соответствие с выходными параметрами симулируемой динамической индикации вы увидите именно ту картинку, которая должна быть в реальности. Ну и конечно не стоит забывать о гашении при переключении разрядов индикатора, о котором шла речь в первой части FAQ. На этом я заканчиваю «лирическое отступление» и перехожу непосредственно к самой LEDMPX.DLLи моделям на ее основе.
Определить, что модель индикатора основана на LEDMPX.DLLсовсем не сложно, для этого достаточно обратить внимание на правый верхний угол окна PickDevices(Рис. 70). Кроме того, у многих индикаторов в названии встречается само сочетание MPX, например, 7SEG-MPX4-CA.
Все модели на основе этой DLLрасположены в категории Optoelectronics, а более конкретно в четырех ее подкатегориях: 14-SegmentDisplays, 16-SegmentDisplays, 7-SegmentDisplays, DotMatrixDisplays. На рисунке 71 приведены наиболее характерные представители этих категорий, причем во включенном режиме. Я бы хотел здесь еще раз напомнить, чтобы вы не путали одиночные семисегментные индикаторы на основе LEDMPX со Schematic, которые мы рассматривали ранее – ведут эти модели себя совершенно по-разному. Характерная особенность одиночных индикаторов на основе LEDMPX, который их сразу выдает визуально, – уменьшенный до 50th шаг выводов. Эти модели и 14-ти 16-ти сегментные индикаторы появились только в последних версиях Протеуса, если не изменяет память, то с версии 7.4. Тогда же кардинально была изменена и сама LEDMPХ.DLL, хотя HelpПротеуса об этом скромно умалчивает вплоть до версии 7.8, видимо Лабцентр придерживает эту «фишку» на будущее.
До хелпа по мультиплексированным LEDдисплеям можно добраться как через:
ПУСК =› Всепрограммы =› Proteus 7 …. =› Proteus VSM Model Help =› LED and LCD Display Models,
так и непосредственно из окна свойств любой модели вышеупомянутых индикаторов, нажав кнопку Help справа. Раздел, посвященный этим моделям, называется MULTIPLEXED LED DISPLAY. Я не стану здесь дословно переводить весь этот раздел, но характерные особенности в моей трактовке изложу ниже.
LEDMPХ.DLL может использоваться для моделирования произвольной светодиодной матрицы состоящей из знакомест (цифр или строк матричного индикатора) и сегментов (столбцов матрицы). Характерными приложениями для данной библиотеки является моделирование многоразрядных сегментных индикаторов и точечных светодиодных матриц. При этом обеспечивается двумерный массив строки (или знакоместа сегментного индикатора) обозначаются цифрами – 1, 2, 3 и т.д. а столбцы (или отдельные сегменты цифры) индикатора обозначаются буквами латинского алфавита – A, B, C, Dи т.д. В оригинальном хелпе указано, что максимальное количество строк и столбцов может быть до 8, т.е. максимум можно было смоделировать 64 светящихся точки (сегмента). Так и было в действительности до тех пор, пока LEDMPХ.DLL не была расширена под 14-ти и 16-ти сегментные индикаторы. Библиотеку расширили, а хелп оставили нетронутым. Но взгляните на 14-ти сегментный индикатор на рисунке 71 – он явно противоречит хелповской догме. Буковок, то бишь, столбцов матрицы (сегментов) – 14, а никак не 8, да еще и точка DP. Подозреваю, что на данный момент матрица имеет ограничения как минимум 16х16 строк/столбцов, проверять на максимум пока лень, дождемся пока Лабцентр «разродится» свежим хелпом.
Второй важной особенностью моделей на основе LEDMPХ.DLL является то, что модели обладают чисто цифровыми свойствами. И об этом разработчики честно сообщили в help:

The LEDs are modelled at the digital level only; there is no attempt to simulate their analogue behaviour (i.e. diode characteristics).

Но, первая из бед России в данном случае превалирует над дорогами, мы и по-русски то с ошибками, где уж дорасти до заглядывания в аглицкие хелпы. Вот и плодятся на форуме утверждения, подобные «эпиграфу» данного параграфа.
Ну, что-ж, давайте еще раз разжевывать эту жвачку. Поскольку модели на основе LEDMPХ.DLL не обладают аналоговыми свойствами, они по определению цифровых моделей обладают бесконечно большим сопротивлением и не потребляют ток от источников сигнала. Проверяем данный постулат. Взгляните на рисунок 72. Тут как в избитой телерекламе, «трюк самостоятельно не повторять, опасно для жизни». Какой реальный индикатор такое издевательство выдержит? А виртуальный работает, и даже дым от экрана дисплея не идет. Обратите также еще раз внимание на нулевые показания амперметра, сейчас мы и это «разжуем и проглотим».
Опять-таки характерной ошибкой пользователей «с дудочкой» является попытка управлять ЦИФРОВОЙ моделью индикатора с помощью аналоговых элементов, например, транзисторных ключей. Ну, в схеме, которую взяли из книжки, журнала, Интернета так нарисовано, значит должно работать. В жизни да, а вот в симуляторе…. Обратимся к следующему примеру (Рис. 73).
Здесь у индикатора с общим катодом все четыре цифры включены по-разному. Мы видим, что даже резистораR1 сопротивлением 10гигаОм в цепи катода достаточно, чтобы спровоцировать зажигание сегментов цифрового индикатора (левая цифра), что уж говорить о закрытом транзисторе Q1 с заземленной базой (вторая слева цифра). Но, стоит зашунтировать цифру сопротивлением R2, пусть и очень большим в 1гигаОм, но аналоговым элементом (третья цифра) и на ее ножке и коллекторе Q3 уже появился неопределенный уровень, а сопротивление в 100мегаОм (четвертая цифра) уже дает вполне реальную логическую единицу на коллекторе Q2. Именно этих цифровых парадоксов модели и не учитывают начинающие пользователи. Причем, в отговорки иногда пускается и такое – у меня нет аналоговых элементов, я питаю через ключ, например, столь у нас популярный ULN2003. Да модель то этого ключа в Протеусе схематичная и с аналоговыми свойствами. По-другому и быть не может, вы загляните в даташит этого ключа (Рис. 74) – все те же транзисторы на выходе. Поэтому подходы к симуляции здесь могут быть разными. Если вы собираетесь трассировать печатную плату в ARES, то надо делать два проекта – один для создания печатной платы с полным набором схемотехники, а второй для отладки – в нем «все лишнее за борт». Если же Вам необходимо только проверить проект в симуляторе, а печатную плату вы будете делать в чем то более продвинутом, чем ARES, то можно сразу пойти по упрощенному пути. В частности те же транзисторные ключи на рисунке выше можно заменить обычными цифровыми инверторами, тогда и шунтирующие резисторы не нужны, и работать все будет как надо. Ну а если все-таки надо имитировать многоразрядный индикатор и аналоговые ключи, то придется идти на такие вот навороты, как на рисунке 73. Хотя, уж если подходить к этому вопросу корректно, то надо параллельно сегментам вешать не резистор, а диод и резистор, чтобы обеспечить проводимость в одном направлении – это будет ближе к реальности.
Итак, надеюсь, больше на том, что все рассматриваемые далее индикаторы являются исключительно цифровыми моделями, останавливаться не надо.
Я же хочу заострить ваше внимание на последнем параграфе хелпа по LEDMPX, посвященном временным характеристикам и полярности сигналов, подаваемых на выводы индикатора для зажигания того или иного сегмента. Здесь тоже есть небольшая неточность в хелпе, кочующая из версии в версию, вплоть до 7.8. Специально цитирую именно оттуда:

By default, a segment is drawn as lit if the corresponding row and column pins are both high for more than 1us during a given animation frame (typically 50ms). This gives a crude but effective representation of persistence of vision; in the real world, the segments are driven with a heavy current for short period of time, and the eye averages out the brightness.

Ну и почти дословный, слегка «облагороженный», с точки зрения фразеологии мой перевод:
По умолчанию, сегмент принимается, как светящийся, если соответствующие выводы строки и столбца находятся в состоянии логической единицы более чем 1 микросекунда в течение данного фрейма мультипликации (типовое значение 50мсек). Это позволяет грубо, но эффективно представить элемент, как светящийся, в реальности же сегменты управляются короткими сильноточными (от слова ток) импульсами, а глаз воспринимает среднюю яркость свечения.
Это как раз то, о чем я толковал в начале данного параграфа, за исключением одного маленького казуса. Если вы заглянете в свойства любого индикатора, то по умолчанию MinimumTriggerTime там равно 1ms, а не 1us, как написано в help. Это существенная разница, и зачастую простое уменьшение значения к рекомендуемому в helpможет значительно поправить вид индикации.
Теперь о полярности сигналов. Я вовсе не ошибся в переводе, и в самом Helpтак же сказано. Сегмент должен светиться при высоких уровнях на выводах соответствующих строки и столбца. Это если в свойствах модели не проинвертированы значения сигналов на одной из групп – столбцы или строки. А они обязательно проинвертированы, именно этим и достигается имитация индикаторов с общим катодом или с общим анодом и больше ничем. Заглянем для примера в окно свойств любого многоразрядного индикатора с общим анодом и поставим там галочку Edit all properties as text(Рис. 75).
Ну вот, именно об этом и идет речь в последнем абзаце Help. Мы же для себя делаем очень важную «зарубку» в памяти – для индикаторов на основе LEDMPX.DLLдолжны быть проинвертированы в свойствах состояния тех выводов (пинов), со стороны которых предусматривается управление нулевым логическим уровнем. Т.е. для индикаторов с общим анодом должны быть проинвертированы состояния сегментов:
INVERT=A,B,C,D,E,F,G,H
а для индикаторов с общим катодом состояния цифр (знакомест):
INVERT=1,2,3,4 и далее по количеству цифр.
Ну и заключительные комментарии из Help для LEDMPX.DLL, касающиеся непосредственно активной графики, к созданию которой мы перейдем в следующем параграфе. Индикаторы на основе данной библиотеки являются бит-зависимыми (с этим термином мы уже встречались при создании семисегментного Schematicиндикатора). Общий символ (опять оттуда же, символ с индексом _C) определяет ширину знакоместа. Более понятно это станет при создании собственного индикатора, чем мы далее и займемся.
Рисунки 70, 71, 72.
Рисунки 73, 74, 75.

[Halex07]

8.7. Активная графика сегментных индикаторов на основе LEDMPX.DLL. Трехразрядный индикатор из четырехразрядного.
Чтобы лучше понять, как строится графика индикаторов на основе LEDMPX.DLL, займемся непосредственно практикой. В качестве подопытного «символа года» воспользуемся красным четырехразрядным индикатором 7SEG-MPX4-CA. Добываем его из библиотеки, помещаем в поле проекта и производим над ним варварское действие с помощью молотка, т.е. Decomposeэтот девайс. Теперь, если переключить левый тулбар в режим Simbol Mode (кнопка S), то в селекторе мы увидим полный набор символов из которых состоит наш индикатор (Рис. 76).
Ничего нового и интересного вы тут не найдете, все это мы уже проходили в п.7.2 нашего FAQ. Те же символы 7SEG, погашенные с индексом _0 на конце, зажженые – с символом _1. Всего в составе индикатора 7 символов для сегментов, начиная с нулевого, и символ десятичной точки – 7SEG_7. Имеется и базовый символ (подложка) с индексом _С. На рисунке 77 я разобрал все эти символы с помощью Decompose, а также нанес для каждого синим пунктиром границы подложки, чтобы вы имели представление – как они построены. И тут для нас пока ничего нового нет.
Но вернемся все же к предыдущему рисунку 76 и обратим внимание на положение маркера ORIGIN– в левом верхнем углу самого левого знакоместа. Этот момент очень важен! Отсюда начинается отсчет знакомест в правую сторону. Ширина каждого знакоместа равна ширине символа подложки (Common) с индексом _C. Сколько таких «подложек» мы расставим вправо, столько и будет знакомест (столбцов) в нашем индикаторе и столько же должно быть выводов для их сканирования – выводов с именами 1, 2, 3 и т.д. Я на этом рисунке специально отодвинул выводы от тела компонента и включил подсветку их имен. Обратите также внимание, что черные надписи, обозначающие имена выводов остались при этом на месте, потому что это просто текстовые надписи и ничего более, а в модели их применили чисто в справочных целях, чтобы пользователь не заблудился – где какой вывод. Именно поэтому они нечетко совпадают по позициям с соответствующими выводами, а выводу Hсоответствует в надписи обозначение DP (от английского DecimalPoint– десятичная точка). Это первый этап нашего эксперимента и я приложил его в папке Step1 вложения.
Ну а теперь перейдем ко второму этапу и займемся чудесным превращением индикатора в трехразрядный. Делается это очень просто и не отнимет у нас много времени. Выполняем поэтапно с иллюстрациями. Для начала удаляем графическое изображение подложки самого правого, т.е. четвертого знакоместа (Рис. 78 ). Обратите внимание, что я не зря употребил термин «графическое изображение». Внутри графики компонента используются не символы, которые сами по себе содержат внутри маркер ORIGIN, а именно простые графические изображения – в данном случае закрашенный прямоугольник определенной ширины. Это я к тому, что если вы собрались наоборот добавлять знакоместа (столбцы), то надо либо скопировать соседнее вместе с графическими изображениями сегментов, либо вытащить на свободное место символ подложки и предварительно его разбить (Decompose), чтобы убрать оттуда маркер ORIGIN.
Теперь выделяем и удаляем графические изображения сегментов и точки того же знакоместа (Рис. 79). Сейчас это сделать проще с помощью «лассо», т.е. обводим их с зажатой левой кнопкой мышки и потом жмем клавишуDelete. Теперь уже нет риска зацепить выделением что-нибудь нужное, они достаточно отдалены от соседнего знакоместа.
Далее нам предстоит сдвинуть нужные нам выводы с именами 1, 2, и 3 левее, чтобы они оказались под третьей цифрой. Туда же сдвигаем и надпись «1 2 3 4» и редактируем ее, убрав ненужную цифру 4. Эта операция представлена на рисунке 80.
Теперь нам осталось сдвинуть влево правую границу серого прямоугольника, обрамляющего весь наш индикатор и удалить оставшийся «за бортом» вывод с именем 4 (Рис.81).
Все, коррекция графики на этом закончена. Выделяем с помощью лассо всю нашу модель, включая скрипт, и нажимаем любимую кнопку MakeDevice (Рис. 82).
Если мы не забыли зацепить скрипт, то на первой вкладке процедуры MakeDevice нам достаточно только поправить имя нашего девайса, т.е. изменить 4-ку на 3-ку (Рис. 83). Поскольку мы не меняли количество и имена символов, и они присутствуют в селекторе, то в поле ActiveComponentPropertiesвсе остается без изменений. Достаточно только убедиться, что включены флажки BitwiseStatesи LinktoDLL.
Немного остановлюсь на третьей вкладке. Здесь тоже все остается без изменений, но на будущее, если вам надо создать такой же индикатор, но с общим катодом, то достаточно еще раз запустить процедуру Make Deviceдля того индикатора, который мы сейчас сделаем. На первой вкладке изменить в имени CAна CC (от английского CommonCatode), а здесь для свойства INVERTуказать не сегменты, а знакоместа, т.е. в поле DefaultValueдля трехразрядного индикатора вписать 1,2,3 (Рис. 84).
Ну и теперь доходим до последней вкладки, приводим в Description в соответствие количесво цифр нашего индикатора и сохраняем (Рис.85). У меня для сохранения сейчас открыта толькоUSRDVC, но можете заранее открыть для записи в менеджере библиотек ту, в которой хранятся семисегментники и сразу сохранить наш девайс там. Библиотека называется Displayи на сегодняшний день там свободно 13 позиций.
Нам осталось запустить тестирование нашего устройства и убедиться, что оно работает (Рис. 86). Второй этап нашего эксперимента на этом завершен. Он находится в папкеStep2 вложения. Для того, чтобы сохранить трехразрядые индикаторы в своих библиотеках достаточно пройти процедуру MakeDeviceничего не меняя для уже готовых индикаторов с общим анодом и общим катодом из этого проекта. Как видите, здесь не требуется даже использовать дополнительные файлы моделей, вся необходимая информация уже содержится в свойствах самой графической модели. Аналогичным образом можете создать самостоятельно индикаторы с другим цветом свечения и с другим количеством разрядов. Необходимо только помнить, что для LEDMPXзнакоместа располагаются в один ряд по горизонтали слева направо от маркера ORIGINи постараться не превысить общее допустимое количество строк (сегментов) и столбцов (знакомест) матрицы LEDMPX.DLL. Из личного опыта сразу могу предупредить, что если допустимое количество будет превышено, то в вашем девайсе будут светиться одновременно не один сегмент (точка), а сразу два. Далее мы поупражняемся с точечными матрицами на основе LEDMPX и на этом закончим материал по этой DLL.
Рисунки 76, 77, 78.
Рисунки 79, 80, 81.
Рисунки 82, 83, 84.
Рисунки 85, 86.

[Halex07]

8.8. Активная графика точечных матриц на основе LEDMPX.DLL. Идем на рекорд – матрица 16х16.
В исходном варианте библиотеки Optoelectronics в ISIS точечные светодиодные матрицы (DotMatrixDisplays) представлены двумя наиболее распространенными видами: 5х7 и 8х8 точек. Это матрицы синего, зеленого, красного и оранжевого цвета. Все эти матрицы построены на основе LEDMPX.DLL.
Интерес разработчиков к использованию точечных светодиодных матриц в последнее время значительно вырос. Они широко используются как в рекламных проектах, так и для создания всевозможных индикаторов типа бегущей строки. Наряду с уже давно заполонившими наш рынок матрицами фирмы Kingbright, появились в продаже матрицы китайских Betlux, NingboForyardOptoelectronics. Выпускает матрицы и компания Rohm. Причем в продукции этих фирм можно встретить матрицы форматов 5х8, 5х9, 6х8, 16х16 элементов, которые отсутствуют в библиотеках ISIS. Сразу сделаю оговорку для нетерпеливых – построить двухцветную, а уж тем более RGB-матрицу на основе LEDMPX.DLL не выйдет. Вспомните сам принцип работы LEDMPX – точка (сегмент) может иметь только два состояния (_0 или _1 в конце обозначения соответствующего символа) в данный момент времени, определяемый знакоместом (цифрой). Но, тем не менее, облегчить себе жизнь при разработке проектов с использованием одноцветных матриц мы попробуем.
Итак, в качестве примера создадим зеленую матрицу формата 16х16. Заодно и проверим, насколько расширились возможности LEDMPX.DLL. Берем зеленую матрицу 8х8 – модель MATRIX-8X8-GREEN и разбираем на запчасти с помощьюDecompose(Рис. 87). Если перейти в режим отображения символов, то в селекторе мы обнаружим восемь символов точек с индексами с нулевого по седьмой и общий базовый символ с индексом _C.
Я пошел на небольшое ухищрение, чтобы не делать много скриншотов - совместил максимум в одном. Итак, на рисунке также представлены «декомпозированные» символы с индексами 0, 7 и базовый. И тут меня ожидал очень подозрительный сюрприз. Обратите внимание, что у символа LEDMATRIX_G_C после Decomposeмаркер ORIGIN сдвинут влево и ниже. Я оставил подсветку сетки с шагом 50th на скриншоте, чтобы вы имели представление о том: куда и насколько. Честно говоря, мне непонятен этот ход разработчика модели, поэтому в своей я это применять не стану и размещу маркер как и обычно. Сам символ имеет LEDMATRIX_G_C форму прямоугольника для одного столбца, т.е. он как бы и определяет ширину знакоместа для одной колонки (в семисегментниках цифры). В середине рисунка 87 показана полная графика «разбитой» MATRIX-8X8-GREEN. Я опять отодвинул от тела выводы и подсветил их имена, за исключением вывода A, который оставлен на месте для лучшей ориентации. Ну и наконец справа на рисунке показана подключенная матрица 8х8. Мы видим, что сверху (со стороны сегментов-букв) для зажигания точки необходимо подать логический ноль, а снизу (со стороны знакомест-колонок) – логическую единицу. Это подверждается тем, что в свойствах матрицы прописано INVERT=A,B,C,D,E,F,G,H. Я убрал фигурные скобки «скрывающие» это свойство и оно видно на рисунке. Весь этот подготовительный этап в примере вложения папка Step_1.
Ну и теперь, зная особенности LEDMPX, сразу становится ясно – что нам предстоит сделать для того, чтобы получить модель формата 16х16 точек.
В первую очередь изменяем основную графическую модель, т.е. растягиваем черный квадрат подложку и расставляем на нем погашенные точки. Напомню еще раз, что здесь используются не символы из селектора с внедренным в них ORIGIN, а просто графические изображения соответсвующих элементов – квадрата, круга. Само-собой разумеется, что нам предстоит добавить еще по восемь выводов – сверху с именами букв латиницы – I, J, K, L, M, N, O, P, а снизу с именами в виде чисел – 9, 10, 11, 12, 13, 14, 15, 16 (Рис. 88 ).
Далее нам предстоит скомпилировать с помощью Make Symbol недостающие символы погашенных и светящихся точек в столбце и удлинить вниз прямоугольник базового символа. И вот здесь нас ожидает еще одна неприятная неожиданность Протеуса, о которой я «в пылу азарта» забыл упомянуть. Максимальное количество букв, цифр и спецсимволов подчеркивания в имени символа не должно превышать 15. Кстати, это же ограничение качается и DeviceName на первой вкладке MakeDevice, так что возможно кто-то уже сталкивался с ним. Теперь посмотрим внимательно на исходные имена символов, начинающиеся с LEDMATRIX_G. Это уже 11 позиций, значит, нам под остальное осталось только 4. Делалась эта модель еще в ранних версиях Протеуса и тогда автор об этом не задумывался. Пока номера символов состояли из одной цифры, этого хватало, но, мы то пойдем дальше – будут и 10 и 11 и т.д. Ну что-ж, придется делать все символы сначала, укоротив имя. Я просто выбросил гласные буквы из слова MATRIX, и мои новые символы имеют обозначение LEDMTRX_G. Почему я не убрал вместо этого _G в конце имени? Да все из того же любопытства – не повлияет ли этот первый символ подчеркивания, находящийся в имени символа, на работу модели. Забегая вперед, скажу, что не повлиял. Следовательно, допустимо использовать в имени символа знак подчеркивания.
Но, продолжим наш титанический труд. Формирование новых символов, да и вообще работу с графикой активных индикаторов лучше делать с шагом сетки 50th. И править их лучше в непосредственной близости от готового графического изображения всего компонента, чтобы не потерять ориентацию. Для начала удлиним базовый символ и скомпилируем его с новым именем LEDMTRX_G_С (Рис. 89). Попутно восстанавливаем «статус кво» маркера ORIGIN – я разместил его непосредственно над прямоугольником на том же расстоянии, что и в графическом изображении всей модели.
Затем начинаем формирование погашенных и светящихся точек матрицы. Поступаем также, ка и с базовым символом помещаем их поблизости от изображения всего компонента на уровне первой строки. MakeSymbol из левой погашенной точки и маркера ORIGIN над ней символ LEDMTRX_0_0, а из светящейся точки и ее маркера ORIGIN– символ LEDMTRX_0_1. Затем смещаем обе точки (только точки, без маркера) на две клеточки вниз – вторая строка матрицы, и создаем соответствующие символы LEDMTRX_1, опять смещаем вниз – создаем LEDMTRX_3 и так до символов последней строки матрицы LEDMTRX_15.
После этого нам осталось только Make Device нашу новую модель, но не забудьте, что мы поменяли имена символов и увеличили их количество. Поэтому на первой вкладке MakeDevice изменяем эти значения (Рис. 91). Если при создании модели используется скрипт от старой модели 8х8, то в имени девайса достаточно просто поправить имя, если же вы создаете устройство «с нуля», то необходимо ввести DeviceName полностью. Не забудьте также и про флажки бит-зависимости и связи с DLL.
Вторую вкладку назначения корпуса проходим транзитом, на третьей остановимся подробнее. Если использовался старый скрипт, то свойства будут взяты оттуда и здесь, кроме добавления имен сегментов (точек) в свойство INVERT, ничего менять не надо. Если же мы создаем устройство заново, то необходимо через кнопку New добавить и отредактировать следующие свойства:
MODDLL – В графе Description умолчание или по своему усмотрению, первый Type – String, второй Type – ReadOnly, DefaultValue – LEDMPX, или полностью LEDMPX.DLL (Рис. 92);
PRIMITIVE – В графе Description умолчание или по своему усмотрению, первый Type – String, второй Type – Hidden, DefaultValue – DIGITAL,LEDMPX– через запятую без пробелов (Рис. 93);
INVERT – В стандартных нет, добавляется через BlankItem. В графе Descriptionу молчание или по своему усмотрению, первый Type – String, второй Type – Hidden (но тем, кто активно работает, с матрицами рекомендую поставить Normal, чтобы оперативно менять полярность выводов), DefaultValue – A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P – все через запятую без пробелов (Рис. 94);
TTRIGMIN – В стандартных нет, добавляется через BlankItem. В графе Description– Minimum Trigger Time (русскоязычные пользователи могут вписать– Время переключения), первый Type – Float, выбрать ограничения Limits– Positive, Non-Zero, второй Type – Normal, DefaultValue – 1ms (Рис. 95).
Я ничего не сказал по PACKAGE – корпус, потому что пока мы его не добавляли и он по умолчанию примется None (отсутствует). Кроме того, для TTRIGMIN я указал значение, как и у остальных моделей – 1 миллисекунда, хотя сам же рекомендовал его уменьшать. Но это сделано только для того, чтобы не путаться при добавлении в проекты, а то у одной модели так, у другой по-другому.
Проходим нашу процедуру MakeDevice до конца и сохраняем матрицу в разделе оптоэлектроники, в подкатегории точечных матриц (Рис. 96). У меня для сохранения на данный момент открыта только USRDVC, но вы можете сохранить в своей библиотеке, предварительно создав ее в LibraryManager. Напомню, что все остальные матрицы лежат в DISPLAY, но там только 13 свободных мест. Если собираетесь и далее создавать активные индикаторы, то лучше создать свою библиотеку, например, DISPLAY2 на сотню «посадочных мест».
Нам осталось только проверить нашу матрицу в работе, что я и сделал (Рис. 97). Здесь я специально подсветил только угловые и центральные точки матрицы, чтобы убедиться, что нет повторных подсвечиваний точек и библиотека LEDMPX.DLL ведет себя адекватно с таким размерностью матрицы.
На этом рассмотрение данной динамической библиотеки завершено, но не закончен материал по ее применению. Я вознамерился окончательно расставить точки над «и», да и в матрице тоже, с вопросами по динамической индикации в ISIS. Поэтому в следующем материале на примере данной матрицы мы этим и займемся. Первоначально хотел сделать это прямо здесь, но думаю данный вопрос заслуживает отдельного параграфа.
Рисунки 87, 88, 89.
Рисунки 90, 91, 92.
Рисунки 93, 94, 95.
Риунки 96, 97.