[Halex07]

• 2.15. Первый неудачный запуск симуляции. Пляски с бубном или анализ возможных причин неработоспособности в симуляторе реально работающей схемы.
  Для запуска симуляции созданного нами проекта осталось нажать кнопку Play внизу слева в трее окна ISIS. Результат первого запуска на рисунке 26. Я уменьшил окно программы, чтобы разместить его целиком на рисунке, поэтому расположение панелей внизу немного отличается от полноэкранного режима, где они расположены горизонтально в ряд.
  О старте симуляции свидетельствует зеленая подсветка кнопки Play. Зеленый кружок с символом i свидетельствует о том, что запуск прошел без ошибок. Лог симулятора содержит 7 сообщений (Messages). При желании его можно открыть не останавливая симуляции щелкну по нему левой кнопкой мыши. Если бы были какие то отклонения при запуске симулятора, то вместо зеленого круга был бы желтый треугольник с восклицательным знаком, а при наличии критического сбоя симулятора - красный. В последнем случае окно лога открывается автоматически, т.к. симуляция не работает вообще. Но и наличие желтых "горчичников" тоже свидетельствует о том, что результат симуляции подлежит сомнению и дополнительной проверке. В таймере ANIMATING: происходит отсчет времени с начала запуска и показана загрузка процессора (CPU ) компьютера. Еще раз хочу обратить внимание на этот показатель. Математика симулятора PROSPICE, на котором базируется ISIS, отнимает значительные ресурсы компьютера, особенно при расчете работы аналоговых схем, где требуется провести очень большое количество расчетов как по времени, так и по уровням сигналов. Поэтому при загрузке CPU load 100% или близко к этому имитация работы схемы в реальном времени практически невозможна. Обычно Протеус предупреждает об этом наличием "горчичника" и сообщением в логе:
  Simulation is not running in real time due to excessive CPU load
  В этом случае необходимо либо прибегнуть к упрощению схемы за счет сокращения входящих в нее аналоговых компонентов, либо - попробовать проанализировать необходимые нам параметры с помощью графиков (Graph Mode), которые позволяют просчитать и получить результаты за счет более длительного но распределенного по времени вычисления, снимая при этом загрузку с ЦП компьютера. Этим мы чуть ниже и займемся, но совсем по другим причинам.
  Итак, мы видим, что даже при отжатой кнопке на входе частотомера вместо нормального показания 00.00000 уже несоответствие показаний, а если кнопку нажать, то показания индикатора пропадают совсем и лишь изредка на нем мелькает непонятная информация. Немного отвлекусь на управление активным элементом Button (Кнопка) в процессе симуляции (Рис.27). Дело в том, что модели активных компонентов коммутации Button (Кнопка) и некоторые Switch (Переключатели), входящие в стандартные библиотеки Протеуса могут управляться двумя способами. В первом случае управление происходит щелчком левой кнопкой мыши по нужному элементу управления черный кружок со стрелкой, а во втором при наведении курсора на само изображение управляемой части компонента. Если у переключателей положение после воздействия фиксируется, то единственный в ISIS компонент Button ведет себя иначе. При щелчке по элементу управления - кнопка ведет себя как кнопка с фиксацией (выключатель), а при наведении курсора на саму кнопку - нажатие левой кнопки мышки вызывает нажатие кнопки, а отпускание мышки - возврат в исходное состояние - т.е. имеем нефиксируемую кнопку. Кнопку SB4 в нашей схеме мы будем использовать как фиксируемый выключатель входа. Еще один нюанс - все активные элементы управления в Протеусе функционируют даже при выключенной симуляции, что позволяет провести предустановку параметров схемы перед выполнением симуляции. Например, установив в проект активную модель термопары (Thermocouple) или One-Wire температурного датчика DS18B20, Вы можете до начала симуляции установить им температуру на нужное значение.
  На этом закончим лирическое отступление вернемся к нашей схеме и попробуем понять почему индикация погасла при подаче на вход измеряемого сигнала. Первая причина - низкая частота подаваемого сигнала - в нашем случае 100Гц. Я не буду полностью расписывать принцип работы частотомера Денисова, а только напомню, что такая структура прибора предусматривает измерение по переполнению счетчика/таймера микроконтроллера. Поскольку входную частоту мы выбрали очень низкой, переполнение происходит редко, а индикация жестко завязана с циклом измерения - отсюда и редкие мерцания. Тот же эффект будет и в реальном устройстве. Остановим симуляцию и увеличим измеряемую частоту генератора CLOCK до 10кГц, тем более, что низкая загрузка CPU (в моем случае 7%) позволяет это сделать. Снова запустим симуляцию. При подключенном генераторе картинка изменилась - вместо редко мерцающих хаотичных сегментов - появились постоянно горящие, но от этого нам не легче.
  Исполним второе па "мармезонского балета" на этот раз с индикатором. Войдем в его свойства и найдем там параметр Minimum Trigger Time. По умолчанию там стоит значение 1ms (милисекунда). Что он означает? Согласно Help на данный компонент - это минимальное время присутствия сигнала на выводе индикатора при котором сегмент засвечивается. Правда в Help почему то указано по умолчанию 1us, но оставим эту очепятку разработчикам, а сами действительно установим такое значение. Снова запустим симуляцию. Картинка опять изменилась. Теперь при подключенном генераторе горит непотребное значение, явно отличающееся от подаваемого, а при отключенном - все нули, но в обоих случаях висят лишние десятичные точки, хотя должна быть только одна. Это уже "теплее", но не соответствует реальности. Дальнейшее уменьшение Trigger Time желаемого эффекта уже не дает, так что пляски с бубном придется прекратить и перейти к более детальному исследованию поведения динамической индикации в симуляторе ISIS PROSPICE. Для этого нам придется прибегнуть к помощи графиков (Graph).

Рисунок 26
Рисунок 27