Тоже не согласен. Вуз и не должен гнаться за новомодными фичами, про которые через 5 лет все забудут. Есть фундаментальные вещи, которые не меняются на протяжении более чем 50 лет. Их и должны изучать в вузах. Иначе мы получим вместо вуза ПТУ, а вместо инженера — узкого специалиста, который не будет способен сделать шаг вправо или шаг влево.
Например технологии, которые уже много лет не меняются:
1. Транзисторы и транзисторная схемотехника существуют более 60 лет
2. Антенны. Со времён Герца и Попова (120 лет) ничего принципиально нового не придумано
3. Классическая радиотехника существует 90 лет
4. Зубчатые передачи существует со времён Древнего Рима
5. Язык С. Существует более 40 лет. И будет в ходу ещё столько же
6. ОС Unix. Тоже существует более 40 лет и ничего лучшего на данный момент нет
Ну и не говоря уже, например, про теоретическую и экспериментальную физику. Вы её тоже дистанционно осваивать будете?
Статья освящает ситуацию однобоко. Сам работаю доцентом (основная работа) в филиале Московского технического вуза (г. Калуга), некомпьютерная специальность. До этого работал ассистентом-совместителем, основная работа была на заводе. Далее прокомментирую некоторые утверждения автора:
1. Бумажная бюрократия. Да, есть такое. Согласен с автором. Сейчас действительно творится кошмар. В прошлом году ещё было терпимо. Но в следующем году вроде бы виден просвет.
2. У нас аудиторная нагрузка около 600 часов с учётом консультаций и т.п. 900 часов — что-то не в порядке с вузом. Не согласен с автором.
3. Зарплата у нас в вузе превышает зарплату инженера той же специальности в промышленности. За последние 2 года з/п у нас подняли в два раза. Но, конечно, можно бы з/п и побольше. Не согласен с автором. Но я знаю, что в Москве ситуация с з/п преподавателей и научных работников значительно хуже. Но тоже зависит от вуза. В национальных университетах з/п весьма достойная. Мой знакомый работает с.н.с в институте при РАН. У него з/п около 20000 руб. в Москве.
4. Разница в возрасте. Не согласен автором. У меня на заводе в подчинении был вообще дед 70 лет и работали нормально.
5. Научная работа. Не согласен с автором. Диссертацию стало защитить сложнее, но возможно. Учился в Москве в заочной аспирантуре, параллельно работая на заводе, и сделал диссертацию за 3 года. Научную работу в вузе вести можно. Давления со стороны начальства, чтобы оно мешало что-то делать нет. Финансирование действительно только после конечного результата если делается неизвестно что с нуля. Но я например занимаюсь разработкой open-source научного софта и у меня затраты на материальное обеспечение и оборудование равны нулю. Для прохождение аттестаций необходимо представить несколько опубликованных статей в год.
6. Дополнительная работа. У нас есть возможность участия в заказных разработках от предприятий. Оплата весьма достойная.
7. Качество студентов. Да, есть такая проблема. Студенты зачастую не понимают зачем нужно то, что преподают. Но на старших курсах обычно студенты идут работать на завод и там приходят понимание, что деньги будут платить не за навыки игры в AngryBirds на телефоне, а за знание электроники и программирования. И ситуация выправляется. На лекциях я тоже стараюсь донести до студентов это утверждение. Блатные обычно на технические специальности не идут.
8. Психологическая несовместимость. У автора как раз оказался такой случай. У нас тоже ранее на моём месте был аспирант, который прямо в середине семестра уволился.
9. Отдушина. Упоминается алкоголь. Не согласен с автором. У вас явно проблемный вуз.
Зачем вам исходный код САПР-системы, что там можно увидеть?
Можно исправить глюк. Например в DraftSight долгое время было поломано открывание файлов с кириллическими именами. Фикс бы занимал несколько строчек. Техподдержка на данный баг никак не реагировала.
Каковы шансы того, что непонятная опенсерсная система будет поддерживать требования отечественных ГОСТ-ов?
Никаких шансов нет. Это относится не только к open-source, но и ко всем остальным. Производитель САПР не обязан соблюдать все имеющиеся в мире стандарты.
Кстати, из того с чем мне приходилось работать лучшая поддержка ГОСТов из коробки у КОМПАС.
C машиностроительными open-source САПР ситуация очень плохая. DWG-совместимой САПР нет. FreeCAD — это другой класс ПО. FreeCAD движется в сторону аналога SolidWorks. Сравнивать с ним Нанокад некорректно. LibreCAD имеет множество ограничений.
С САПР электроники ситуация намного лучше. Здесь есть почти полный набор инструментов для инженера.
Совершенное верно, SPICE существует ещё с 80-х годов.
Если интересна мотивация авторов симулятора Qucsator, то можете поискать их статьи по имени авторов (Michael Mrgraf и Stefan Jahn). Они публиковались в International Journal of Numeric Modelling. Если вкратце, то авторы хотели создать симулятор, который содержал встроенные модели длинных линий, моделирование S-параметров и т.п. Их ещё не устраивала методика расчёта шумов в SPICE. Авторы работали в области СВЧ-электроники, и должное внимание моделированию во временной области не уделили (там остались баги). Около 2009 года они прекратили разработку GUI Qucs и симулятора Qucsator, и перестали отвечать на все вопросы, связанные с симулятором. Казалось, что симулятор умер. Но примерно с 2011-2012 года за симулятор и GUI взялась новая команда некромантов разработчиков.
Ngspice наоборот базируется на коде оригинального SPICE3f5 и его разрабатывает всё время одна команда.
Лично я считаю, что разработка своего симулятора с нуля было очень вредной идеей. Я тоже не вполне понимаю, что мешало доработать тот же Ngspice, который уже существовал на данный момент. В будущем это могло только породить костыли. Поэтому я придерживаюсь мнения, что наш симулятор должен следовать SPICE. Но есть люди, которые думают иначе.
Если кому-то интересна тема симуляторов, не основанных на SPICE, то ещё есть такой полуживой консольный симулятор Gnucap. В настоящее время разработка возобновлена по-моему первоначальным автором.
Да, теперь ОУ работают вместе с Qucs. Нужно использовать не ОУ из стандартной библиотеки (т.к. они прошли двойную конвертацию Spice->Qucs->Spice), а применять специальный компонент «Схема SPICE» (находится в группе «Файловые компоненты»). Ему нужно указать на файл со SPICE-моделью ОУ. В этом случает SPICE-модель напрямую передаётся SPICE-симулятору. Подробнее этот процесс описан здесь: qucs-help.readthedocs.org/en/spice4qucs/SubLib.html#using-manufacturers-component-data-libraries
В следующих версия ожидаются библиотеки, которые будут включать в себя неконвертированные SPICE-модели. Если выбран дефолтный симулятор, то будет подгружаться Qucs-netlist, а если выбран SPICE-симулятор, то SPICE-netlist.
Начинать с теории цепей перменного тока (расчёт методом комплексных сопротивлений), затем рассмотреть теорию четырёхполюсников (Z, Y- параметры), затем теорию длинных линий (телеграфные уравнения, падающие и отражённые волны, коэффициент стоячей волны, согласование, МПЛ, волноводы), затем матрицы рассеяния (S-параметры), затем теорию антенн.
В доступном виде начала теории антенн и длинных линий (с практической стороны) изложены например в книге Ротхаммеля «Коротковолновые антенны» Там рассматриваются антенны для любительской КВ и УКВ связи, но принцип действия у всех антенн примерно одинаков. В последнем издании по-моему есть информация и об антеннах СВЧ-диапазона.
Вы не поверите, но под Linux давным-давно есть и нормальные компиляторы (типа gcc) и даже САПР (напрмер Eagle(закрытый с беспл.версией) или KiCAD(открытый)).
Если вы пользуетесь всеми фичами Altium'a, то самодельная САПР вас не устроит, а если Altium у вас используется только потому, что его скачали с торрента, то вам ничто не мешает прямо сейчас перейти на Eagle или KiCAD и использовать например Linux, если у вас цель перейти куда-либо с Windows.
Вы пишете САПР с нуля или переносите уже существующую? Чем например не устроил вариант например портировать KiCAD? (хотя не могу утверждать возможно ли это для вашей ОС)
Если пишете с нуля, то это путь в тупик, т.к. САПР потребует создания библиотек и т.п. и их поддержания. Создание САПР с нуля достаточно длительный процесс, требующий отдельного коллектива разработчиков, сравнимого по масштабам с вашим коллективом.
САПР тоже будет на Ассемблере? Тогда при всём уважении к вам она так и останется курьёзной поделкой.
А вот MicroCAP — это лучший проприетарный симулятор схем — ещё более неитуитивен, чем Qucs. Чтобы симулировать в нём схему, требуются вообще начальные знания SPICE. Если программа неитуитивная, это ещё ни о чём не говорит.
Так что не говорите за весь open-source. Если у вас проблемы с open-source можете воспользоваться закрытым, но бесплатным LTSpice. Но он тоже не настолько интуитивен.
Да, есть специальный компонент «подсхема» (subcircuit). При помощи него можно создать например подсхему ОУ и УГО для него и вставить его в другую схему.
Также есть комопонент «Заданное уравнением устройство» (Equation defined device). Его можно использовать если известны уравнения, которыми описываются токи, втекающие и вытекающие из устройства.
Я имел в виду ШД. Примерно 6 лет назад я делал моделирование стабилизатора тока обмотки ШД (не в Qucs). ШД заменял RL-цепью. Результат получался довольно сносный.
Читайте руководство к программе (доступно по F1)! Программа сама сообщает об ошибке! Чтобы смоделировать схему, нужно на схеме разместить специальный компонент, который отвечает за моделирование. У вас никакое моделирование не задано, а должно быть моделирование переходного процесса или DC-analysis. Ещё на схеме ключ закорочен.
Моделей двигателей нет. Их следует заменять индуктивной нагрузкой (RL-цепь).
Например технологии, которые уже много лет не меняются:
1. Транзисторы и транзисторная схемотехника существуют более 60 лет
2. Антенны. Со времён Герца и Попова (120 лет) ничего принципиально нового не придумано
3. Классическая радиотехника существует 90 лет
4. Зубчатые передачи существует со времён Древнего Рима
5. Язык С. Существует более 40 лет. И будет в ходу ещё столько же
6. ОС Unix. Тоже существует более 40 лет и ничего лучшего на данный момент нет
Ну и не говоря уже, например, про теоретическую и экспериментальную физику. Вы её тоже дистанционно осваивать будете?
1. Бумажная бюрократия. Да, есть такое. Согласен с автором. Сейчас действительно творится кошмар. В прошлом году ещё было терпимо. Но в следующем году вроде бы виден просвет.
2. У нас аудиторная нагрузка около 600 часов с учётом консультаций и т.п. 900 часов — что-то не в порядке с вузом. Не согласен с автором.
3. Зарплата у нас в вузе превышает зарплату инженера той же специальности в промышленности. За последние 2 года з/п у нас подняли в два раза. Но, конечно, можно бы з/п и побольше. Не согласен с автором. Но я знаю, что в Москве ситуация с з/п преподавателей и научных работников значительно хуже. Но тоже зависит от вуза. В национальных университетах з/п весьма достойная. Мой знакомый работает с.н.с в институте при РАН. У него з/п около 20000 руб. в Москве.
4. Разница в возрасте. Не согласен автором. У меня на заводе в подчинении был вообще дед 70 лет и работали нормально.
5. Научная работа. Не согласен с автором. Диссертацию стало защитить сложнее, но возможно. Учился в Москве в заочной аспирантуре, параллельно работая на заводе, и сделал диссертацию за 3 года. Научную работу в вузе вести можно. Давления со стороны начальства, чтобы оно мешало что-то делать нет. Финансирование действительно только после конечного результата если делается неизвестно что с нуля. Но я например занимаюсь разработкой open-source научного софта и у меня затраты на материальное обеспечение и оборудование равны нулю. Для прохождение аттестаций необходимо представить несколько опубликованных статей в год.
6. Дополнительная работа. У нас есть возможность участия в заказных разработках от предприятий. Оплата весьма достойная.
7. Качество студентов. Да, есть такая проблема. Студенты зачастую не понимают зачем нужно то, что преподают. Но на старших курсах обычно студенты идут работать на завод и там приходят понимание, что деньги будут платить не за навыки игры в AngryBirds на телефоне, а за знание электроники и программирования. И ситуация выправляется. На лекциях я тоже стараюсь донести до студентов это утверждение. Блатные обычно на технические специальности не идут.
8. Психологическая несовместимость. У автора как раз оказался такой случай. У нас тоже ранее на моём месте был аспирант, который прямо в середине семестра уволился.
9. Отдушина. Упоминается алкоголь. Не согласен с автором. У вас явно проблемный вуз.
Можно исправить глюк. Например в DraftSight долгое время было поломано открывание файлов с кириллическими именами. Фикс бы занимал несколько строчек. Техподдержка на данный баг никак не реагировала.
Никаких шансов нет. Это относится не только к open-source, но и ко всем остальным. Производитель САПР не обязан соблюдать все имеющиеся в мире стандарты.
Кстати, из того с чем мне приходилось работать лучшая поддержка ГОСТов из коробки у КОМПАС.
Ещё есть кроссплатформенный BricsCAD (платный) и DraftSight (также кроссплатформенный и бесплатный)
С САПР электроники ситуация намного лучше. Здесь есть почти полный набор инструментов для инженера.
Меня тоже всегда такое удивляет у наших импортозаместителей. Это не только Нанокада касается.
Если интересна мотивация авторов симулятора Qucsator, то можете поискать их статьи по имени авторов (Michael Mrgraf и Stefan Jahn). Они публиковались в International Journal of Numeric Modelling. Если вкратце, то авторы хотели создать симулятор, который содержал встроенные модели длинных линий, моделирование S-параметров и т.п. Их ещё не устраивала методика расчёта шумов в SPICE. Авторы работали в области СВЧ-электроники, и должное внимание моделированию во временной области не уделили (там остались баги). Около 2009 года они прекратили разработку GUI Qucs и симулятора Qucsator, и перестали отвечать на все вопросы, связанные с симулятором. Казалось, что симулятор умер. Но примерно с 2011-2012 года за симулятор и GUI взялась новая команда
некромантовразработчиков.Ngspice наоборот базируется на коде оригинального SPICE3f5 и его разрабатывает всё время одна команда.
Лично я считаю, что разработка своего симулятора с нуля было очень вредной идеей. Я тоже не вполне понимаю, что мешало доработать тот же Ngspice, который уже существовал на данный момент. В будущем это могло только породить костыли. Поэтому я придерживаюсь мнения, что наш симулятор должен следовать SPICE. Но есть люди, которые думают иначе.
Если кому-то интересна тема симуляторов, не основанных на SPICE, то ещё есть такой полуживой консольный симулятор Gnucap. В настоящее время разработка возобновлена по-моему первоначальным автором.
В следующих версия ожидаются библиотеки, которые будут включать в себя неконвертированные SPICE-модели. Если выбран дефолтный симулятор, то будет подгружаться Qucs-netlist, а если выбран SPICE-симулятор, то SPICE-netlist.
Ещё gschem умеет экспортировать схему в spice-netlist.
В доступном виде начала теории антенн и длинных линий (с практической стороны) изложены например в книге Ротхаммеля «Коротковолновые антенны» Там рассматриваются антенны для любительской КВ и УКВ связи, но принцип действия у всех антенн примерно одинаков. В последнем издании по-моему есть информация и об антеннах СВЧ-диапазона.
Если вы пользуетесь всеми фичами Altium'a, то самодельная САПР вас не устроит, а если Altium у вас используется только потому, что его скачали с торрента, то вам ничто не мешает прямо сейчас перейти на Eagle или KiCAD и использовать например Linux, если у вас цель перейти куда-либо с Windows.
Если пишете с нуля, то это путь в тупик, т.к. САПР потребует создания библиотек и т.п. и их поддержания. Создание САПР с нуля достаточно длительный процесс, требующий отдельного коллектива разработчиков, сравнимого по масштабам с вашим коллективом.
САПР тоже будет на Ассемблере? Тогда при всём уважении к вам она так и останется курьёзной поделкой.
А вот MicroCAP — это лучший проприетарный симулятор схем — ещё более неитуитивен, чем Qucs. Чтобы симулировать в нём схему, требуются вообще начальные знания SPICE. Если программа неитуитивная, это ещё ни о чём не говорит.
Так что не говорите за весь open-source. Если у вас проблемы с open-source можете воспользоваться закрытым, но бесплатным LTSpice. Но он тоже не настолько интуитивен.
Также есть комопонент «Заданное уравнением устройство» (Equation defined device). Его можно использовать если известны уравнения, которыми описываются токи, втекающие и вытекающие из устройства.
Моделей двигателей нет. Их следует заменять индуктивной нагрузкой (RL-цепь).