Как стать автором
Обновить

Модельно ориентированное проектирование. Электропривод с бесколлекторным двигателем постоянного тока

Время на прочтение 5 мин
Количество просмотров 13K
Всего голосов 14: ↑12 и ↓2 +10
Комментарии 60

Комментарии 60

КДПВ — это гифка. Через какое-то время Шэрон Стоун перекинет ногу...

У вас карма спина белая
Она перекидывает кода текст прокручиваешь и он уходит за пределы экрана.
Что касается моделирования – это вопрос для наших приводщиков не новый. А вот автоматическую кодогенерацию программы контроллера электропривода из его модели, и в мировом масштабе, мало кто пробовал.…

Простите, но для кого тогда придумали Simulink? MATLAB генерит код для микроконтроллеров уже не знаю сколько времени, как. Есть целые компании, занимающиеся реалтаймовыми симуляторами моделей (dSPACE, как пример).
Вопрос лишь в том, что легальное использование стека технологий на базе MATLAB стоит неприлично огромных денег, потому все обходятся велосипедами

Что бы загрузить код сгенерированный из matlab в микроконтроллер и отладить вам нужно столько же програмистов, сколько для того, что бы его написать + специалист по matlab. А если у вас двигатель такой как в статье см. Рис.1, где модель двигателя из Simulinka не подойдет. И нужно будет писать еще и модель двигателя.
Ну и удаленная отладка, когда работа алгоритма, в контроллере отображается на схеме, этого тоже нет в Simulink.
А стоимость ПО это не главное.

Кстати пример dSPACE как раз и показывает, что для того что бы код из Simulink загнать на контроллер и посмотреть как же он всетаки работает нужно еще отдельную компанию подключать, которая смоделирует таргет. (dSPACE например)
В симулинке давным давно есть удаленная отладка кода. Это называется External Mode, и может быть разработана для любого процессора самостоятельно.

Для все ключевых MCU для управления приводами (TI, например) она есть. Более того, ребята хорошо показывают, что и высокочастотное управление на ПЛИС не сложно реализовывать. Вот трехлетний вебинар где и удаленная отладка, и генерация кода для СнК показываются. http://matlab.ru/webinars/razrabotka-sistem-upravleniya-na-baze-zynq-v-matlab-i-simulink.
Ошибся, извиняюсь, нормально там процесс показан. Только если бы там был двигатель с нестандартной ЭДС то расхождение было бы еще больше чем в видео семинара показано. И отладки непосредственно на схеме я не увидел, смотрят готовые графики записи.
Относительно контента вебинара — неправда. С 4:50 объясняется из чего состоит системная модель. И через несколько секунд показывается моделирование объекта управления.
уже посмотрел это я ошибся. воздействия не двигатель действительно, а не на код. Просто листал быстро.
Высокочастотное управление не сложно реализовать, сложно посчитать обратное воздействие, что будет на сенсоре для этого нужна модель объекта, которым мы управляем.
С SimInTech не работал, но модели двигателей в симулинк разные использовал, вплоть до параметризация данными FEM анализа из Ансис. Да и проекты под лютый китай с формами ЭДС зависящими от оборотов, нагрузки и фазы луны.Не замечал каких либо проблем.
То есть модель двигателя брали не готовую, в которой два вида ЭДС трапеции и синусойда а разрабатывали сами из стандратных блоков?

Нет, зачем. Там же просто подключаются результаты моделирования моторов в максвеле том же, если очень точно процесс нужно помотреть. А так готовые блоки отлично работают. Ещё очень нравится как реализованна завязка на тепло элементов схемы, при моделировании длительных процессов нам очень полезно оказалось.

Вот тут согласен, если моделировать в Simulink электродвигатель используя ANSYS Maxwell, то результаты могут быть и не плохие. Говорят суп из топора тоже наваристый получается, если гречки и тушоки добавить.
Ну так вы сделали тоже самое в статье, задали табличку по эдс только не из Maxwell данные а в ручную из CSV файла осциллографа полученные. К моделированию же способ параметризации не имеет отношения. А интересно ваши модели учитывают изменение потока машины от температуры?
Вобще то я ничего на задвал, я даже не автор статьи. Вопрос не ко мне, это вобще то не моя специальность, я до недавнего времени считал, что электропривод это настолько прост, что в любом моделирующем продукте все должно из коробки работать и там нет проблем и даже убогий Simulink должен считать его на раз два. Но оказалось, что там не все так просто. И попытки собрать на Simulink быструю и точную модель электромотора упираются в особенности и ограничения самого Simulink. Разрабочики электродивгателей попробовали SimInTech после Simulink и сказали, что тут гораздо быстрее считает и больше возможностей.
Исторически SimInTech работает там, где русские продавцы Matlab Simulink не могли решить конкретные производтвенные задачи (не важно это рукожопость продавцов или фатальный недостаток Simulink). :))))))
Если не барть в пример задачи управления АЭС, откуда изначально появлися SimInTech. то последнии кейсы:
1) расчет охлаждение датацентра, с учетом 8 000 юнитов на три сервера в каждом из которых 4 вентелятора со своей логикой управления.
2) расчет солнечной батареи спутника с учетом затенения от воспомогательных устройств.
В обоих случаях первое решение предлагаемое продавцами Matlab Simulink нихрена не работало так как нужно заказчику. С приводом получилось так же. Калачев Юрий Николаевич занимается приводами с 1987 года Автор книги Вектороно регулирование. Заметки практика. (в книге есть его почта для связи) И он всегда использовал Simulink пока как то раз не встретился с разработчиками SimInTech. В итоге он объяснил разработчику электрической модели SimInTech, что ему не хватет для счастья, электрик из SimInTech поставил задачу для доработки в математическом ядре и в итоге получился в продукт который покрывает Simulink в области моделирования электропривода как бык овцу. Сам удивлен. Подробнее в книге "Моделирование в электроприводе" Специалисты после практического использования решения в восторге об этом и текст.
Да особого восторга я не вижу, задача то не относится к сложным, мой опыт работы с моделями в simulink говорит о том, что все отлично работает и считается. Ну и не понятно раз вы сами ничего не делали, откуда утверждения, что есть какие то проблемы с приводами в Simulink, единственно с чем я сталкивался когда рассказывали про проблемы моделей Simulink, так это проблемы в восприятии мира у пользователей.
Юрий Николаевич, кстатие еще книги писал и модели в simulink делал.
В общем мне не понятно откуда крытье вашего быка овцами взялось, уверен проблема на user side.
Человек занимающийся приводами с 1987 года, вполне мог решить все проблем на user side. Это вобше не первый случай когда на практике Simulink паказывает свою неприменимость по различным причинам, возможно все встреенные нам пользователи были рукожопыми. Но SimInTech c 1998 года, тогда еще под именем ПК МВТУ решал комерческие задачи, там где Simulink валился на user side проблемах.
Вы извините но это на какие то оправдания похоже+)я тоже 10 лет приводами занимаюсь, с проблемами в Simulink не сталкивался, что дял синхронных что для асинхронных машин, SRM управление делали. Коллеги серво системы делали. В общем нелинейные эффекты в Simulink моделируются легко в базовых блоках.
Базовые блоки это понятно и не вызывает вопросоов. Еще можно легче в на матлабе на языке или даже на фортране написать мат модель модель. Вопрос как потом с ней работать. И я вобще считал что электромоторчики это где Simulink должен был зачистить всю поляну и решить все проблемы, но оказалось не так. А точ то у вас нет проблем с Simulink значит вам повезло, либо вы знаете Simulink досконально так что не наступаете на грабли. Вот допусти у меня ступор всегда вызвает одна проста вещица. включаешь график — и скорость расчета падает это шо? Это ошибка программиста 1 год обучения. Но до сих пор когда включаю в Simulink графики любой расчет начинает тормозить.
А вы работали с MATLAB вообще? реально там блоки и на фортране пишут, питоне, Сях и тд и нет проблем с работой, а если проблемы есть… Ну их нужно просто решить, поучиться там, не лениться. Мне кажется беседа скатилась комменты ради комментов. Ваша статья показывает что у вас есть среда моделирования и в ней можно решать задачи, попытка сказать что в Simulink что то не работает, провалилось. Думаю лучше развивать свое чем пытаться найти косяки в чужом. Уверен, копнув вашу среду можно много чего выкопать.
Я уже привел 3 примера включая видео, где показаны принципиально не решаемые проблемы Simulink на територии РФ. Принципиально не решаемые от слова совсем. По той причине, которую вы сам сформулировали разработчику Matlab не интерсны проблемы российских пользователей. Слишком мелкий рынок. Если для вас видео сравнения пользовательской модели ничего не говорит, то тут офтальмология бессильна. Мы же помогаем решать реальные проблемы. Та же проблем рассчета фильтра где расчет ускоряется в 10 раз, экномит время инженера и приносит реальную осязаемую прибыль.
Конечно если вы копнете нашу среду то выкопаете косяк и не один, но в отличие от Simulinк вы не будете посланы нах, поскольку найти разработчика который накосячил в MatLab невозможно. Мы же устраняем косяки практически сразу. Это преимущества тюнингованого барбуса, над среийной ренологан.
Так не вопрос написать любой блок на фортране для Simulink или SimInTech, вопрос в дальнейшей поддержки и его использованию. Написали вы чудесный блок привода на фортране, и отдали пользователю, а пользователю захотелось учесть изменения вязкость масла при условии работы привода в отрицательных температурах. И что ему делать? Изучать ваш фортран и пытаться понять где же здесь формула расчета трения скольжения? Вся прелесть структурного моделирования в наглядности решения и возможности его быстро анализировать и изменять под конкретные задачи.
Например вот в этом примере (Скрещивая ежа и ужа), у меня модель двигателя изначально была на фортране и я для меня это темный лес и фортран и тем более двигатель авиационный. Но когда фортран привели к структурной схеме (причем не важно Simulink или SimInTech) то сразу стало понятно, где и что нужно поменять для учета новых эффектов. Я подключал гидравлическую систему с расчетом течения топлива и управления электроприводом клапана и наглядно видел как мой двигатель изменения положения. В случае если бы это двигатель был на фортране мне пришлось бы потрать год на изучение теории двигателей и еще месяца 2 на освоение фортрана.
Вот тут например наш конкурент в свое время отказавшися изучать SimInTech поскольку он все считает на Simulink, описывает его user side пробелемы с моделирование простейшего гидравлического поршня в Simulink simscape:
engineerandreev.livejournal.com/3918.html
Цитата:
«Видно, что результат практически не отличается, за тем исключением, что Simscape почему-то начинает неистово дробить шаг в конце переходного процесса. Возможно, это связано со способом расчёта расхода, который в конце становится очень маленьким, а может и нет...»
«Примерно та же самая история. Результаты практически не отличаются, но Simscape почему-то безосновательно начинает дробить шаг. Что у него в голове? Я не знаю..»
Мои утверждения базируются на твредом финасовом оснвании, разработчики SimInTech уже 20 лет зарабатывает деньги на проблемах Simulink и с оптимизьмом смотрят в будущее! :))))
Ну я так понимаю, что SiminTech с его проблемами просто не интересен MATLABу, чтоб зарабатывать на них. На самом деле круто, что есть ваша среда, надеюсь количество ее скачиваний когда нибудь достигнет матлабовского.
Matlab как и любоу другом западному вендору не итересны любые проблемы пользователей России — слишком мала доля рынка. Им интерсны только деньги, что правильно. Но местные продавцы матлаба у которых SimInTech отжирает кусок уже рассылают заказчикам SimInTech смешные письма почему Matlab лучше. На сегодняшний день по соотношению цена/пользва SimInTech делает Simulink как тузик грелку. Пример с Миландром ниже, пример с гидроприводом я взял от инженера Андреева. А вот пример одного из заказчиков по моделированию простого фильтра. Я даже не знаю что это фильтр делает. Мы повторили модель у нас и сами удивились.
Видео сравнения скорости расчет Simulink и SimInTech
Кстати пример dSPACE как раз и показывает, что для того что бы код из Simulink загнать на контроллер и посмотреть как же он всетаки работает нужно еще отдельную компанию подключать, которая смоделирует таргет. (dSPACE например)
«VEOS is part of the MathWorks Connections Program. dSPACE works closely together with MathWorks to make sure that C code generated with the Simulink® Coder™ can be integrated and simulated with VEOS.»
А если вспомнить что для получение кода таргета и Simulink нужно использовать 3 (ТРИ!!!) продукта:
1)MATLAB Coder
2)Simulink Coder
3)Embedded Coder
При этом вся это красота сразу перестает работать, как только вы берете отечественный Миландр и проектируете свою плату, для которого нет поддержки соответствующего таргета.
В статье же пример реальный, когда весь процесс (Модель объекта — Создание ПО — Загрузка — Отладка на контроллере), выполняется в одной среде отсюда и восторг участников процесса.
выполняется в одной среде отсюда

Хорошо, среда поддерживает МК от TI или Infineon? Мне вот не интересен Миландр. Понятное дело, что продукты поддерживают ограниченный диапазон вендоров.


Монстроузность dSPACE-овских решений в том, что они делают Hardware-In-Loop тесты, то есть объект управления имитируется в FPGA _в_реальномвремени. Понятное дело, если вам не нужно тестировать алгоритм в реальном времени без реального железа, от этого можно отказаться.

Да что угодно поддерживает, если среда открыта и настраиваема, то обеспечить поддержку любого МК не является проблемой.
Объект управления в реальном времени в FPGA это возможно только для ограниченного набора моделей. Например уложить в логику FPGA модель какой нибудь теплообменника с «честной» теплофизикой вряд ли возможно.
С моей точки зрения, попытки загнать работу модели в «реальное время» на стадии отладки и проектирования ПО, не всегда оправданы. На стадии проектирования, достаточно обеспечить синхронизацию работы управляющей программы по тактам с модельным временем. И добиться того, что при заданных входных воздействиях система управляет объектом, так как требует проект. Даже если моделирование происходит медленнее или быстрее реального времени. После этого достаточно убедится, что цикл вычислений укладывается в временной такт работы в реальном времени на контроллере.
Хотя возможно для систем, где простые алгоритмы и главная проблема обеспечить передачу данных от сенсоров в контроллер и воздействия на исполнительные механизмы тестирование реальном времени действительно необходимы.
О поддержке иностранных МК в отечественном SimInTech:
Да что угодно поддерживает, если среда открыта и настраиваема, то обеспечить поддержку любого МК не является проблемой.

О поддержке отечественных МК в иностранном Simulink:
Это костыли и палки от продавцов в России

Хм-м… Кажется, всё дело в фатальном недостатке Simulink!
Вы сильно удивитесь на SimInTech стоит не сильно дешевле Simulink. В свое время его удалось продать даже Вексельбергу у которого даже яйца Фаберже. Когда проектировали трубопровод Восточная Сибирь Тихий Океан. Там покупалось все самое модное западное и фенушуйное. Но когда встал вопрос в каком моделирующем пакете собрать модель системы управления, оказалось что Simulink c Matlab валятся при попытке смоделировать управление одной насосной станцией, не говоря уже о десятке.
Так в этом вся и разница, один гребет, другой дразнится.
Когда вы настраиваете чужой продукт, без доступа к разработчику — вы бьетесь головой о стену, найти автора не представляется возможным физически и исправить по вашему желанию ничего нельзя. Потому что западному разработчику на 0.001% мирового рынка просто плевать. А когда вы можете зайти к разработчикам и поговорить о ваших проблемах, и для вас внесут изменения в ядро и допишут нужные функции это бесценно.
Или вот это недавник кейс, когда просто солнечную батарейку Simulink не осили в нужно постановке для заказчика. Простую солнечную батарейку.
simintech.ru/articles/2017_solar_panels.pdf
www.grs.de/en/content/support-software
И немцы SimInTech используют для того что бы не платить за лицензию!
The ATHLET GCSM Modeler was developed by GRS on the basis of the software SimInTech by 3V-Services, Russia (free run time licence). It substitutes the former GCSM Input Data Generator based on the expert system shell G2 of Gensym, USA, which required a license.
Это костыли и палки от продавцов в России, у которых нет доступа к ядру системы MatLab. Но даже при условии доступа к исходным кодам, продраться через три продукта до ядра, та еще задача. А если вспомнить что для получение кода таргета из Simulink нужно использовать 3 (ТРИ!!!) продукта:
1)MATLAB Coder
2)Simulink Coder
3)Embedded Coder
К тому же модель электродвигателя в этом проекте из Simulink не подходит. В реальности она работает по другому см. рисунок 1
Потом нельзя отобразить на схеме в процессе отладки кода в контролере его работу. Последний рисунок из модели которая подключена к контроллеру и отображает его работу на схеме.
Ну и сам код ПО из автоматического кодогенератора, тоже не без странностей. Например, для интегратора matlab генерирует такой код:

Отличное решение, -0.01 это временной шаг интегрирования.
Как только запустил с другим шагом система не работает. Опять генерит код, опять заливаем.
А ведь определение оптимального такта работы управляющей программы это практическая и реальная задача, при проектировании любой системы управления.
Так что восторг участников когда у них реально заработала понятен
Для создания пакетов поддержки микроконтроллеров для MATLAB не нужны палки и костыли, как и доступ к ядру, все описано в документации. И продираться через продукты не надо, они все работают слаженно из коробки.
Придирка к коду тоже странно выглядит, учитывая, что из Simulink без проблем можно генерировать код, исполняемый с произвольным тактом.
А выбрать оптимальный такт работы проще простого благодаря PIL-тестированию, которое работает по нажатию кнопки и позволяет проводить профилирование исполняемого кода на микроконтроллере прямо из Simulink.
Вы если что, всегда можете обратиться к российским представителям, они вас просветят по поводу возможностей. Может быть и модель двигателя более точную покажут.
Да что вы говорите. Генерится в миландр из коробки? Смешно.
Модель более точную они покажут? У них на стенде модель с реальной не совпадают в вебинаре выше ссылка. А здесь для двигателя с нестандартной ЭДС, да еще на нашем Миландре который сам по себе работает не так как написано в документации у них все заработает. Да верю, конечно в эти сказки венского леса.
По какому нажатю кнопки изменяется такт? Посмотрите внимательно это пример из матлаба, в коде шаг интегрирования в виде числа 0.1. Запускать это код с другим тактам просто нельзя.
Очевидно, не до конца вы освоили суть модельно-ориентированного проектирования, раз такое пишите :) Ничего, я объясню.
Сгенерированный код нужно запускать ровно с тем тактом, с которым алгоритм работает в модели, потому что код — это артефакт, производная модели, и расходиться с ней не должен.
Если же нужно сделать алгоритм, исполняемый с произвольным тактом, это в Simulink делается легко, например с помощью Triggered Subsystem, из которой также генерируется код. Если у вас есть лицензия на Embedded Coder, попробуйте. Если нет, можете запросить триал у представителей, они вам и с Миландром помогут разобраться. В сказки верить не обязательно, как и рассказывать их.
Про суть МОП очень смешно получилось. Как раз это извращение модельно-ориентированного проектирования почему то у Matlab даже в официальной документации проглядывается, а у русских продавцов матлаба это извращение вобще стало нормой.
На самом деле в модельно-ориентированном проектировании слово модель, это про модель объекта управления. Почему пользователи и продавцы Matlab считают, что здесь речь идет о модели программы управления, лично я не понимаю. Даже статью написал по этому поводу. Модельно ориентированное проектирование
Код программы управления и модель программы управления в нормальной среде это одно и тоже. По хорошему они вообще должны быть математически тождественны, с учетом возможностей таргета конечно.
Когда вы говорит о совпадении значения такта в моделирующей среде и на таргете, вы говорите о последних стадиях отладки кода.
Я же рассматриваю процесс проектирования целиком. На стадии проектирования, я ставлю блок интегратор, который должен интегрировать переменную и выдавать накопленное значение. С точки зрения разработчика СУ не важно какой шаг интегрирования важна накопленная сумма. А в процессе проектирования я должен иметь возможность запустить алгоритм с разным тактом, причем здесь Triggered Subsystem? Задача то исследовательская, я не знаю в начале какой шаг меня удовлетворит. В Simulink я должен при измени шага заново генерировать кода загружать его на таргет что бы посмотреть как он работает. В SimInTech я могу менять шаг интегрирования и такт исполнения, не запуская снова генерацию кода, при этом интеграл у меня будет содержать правильное значение вне зависимости от такта исполнения. Для больших проектов возможность анализировать запуск с разным тактом без повторной генерации большой плюс. Код Simulink этого не позволяет.
Например, измеренная ЭДС двигателя имела весьма причудливую форму, представленную на Рис.1.

Возможно, это техника third harmonic injection. В результате ток синусоидальный, а напряжение питания может быть меньше.
Вполне возможно, только это не поможеть использовать готовую модель из Simulik
Заинтересовала осциллограмма на рис.1
Позвольте уточнить сколько выводов было у этого двигателя (6? 4? 3?) и как был подключен к ним осциллограф?

Делали так, 3 фазы, к ним звездой подсоединены резисторы 100 кОм, чтобы нулевую точку получить. Осциллографы измеряют падение на этих резисторах.

На картинке ЭДС фаз, двигатель 3 фазы, звезда со средней точкой. Так и подключали.

Так понял, что автор текста вы. Позвольте еще раз уточнить сколько выводов было у двигателя? Вы ответили так, что их как-бы четыре — три фазы и средняя точка, а ваш директор чуть выше ответил так, что их как-бы три, а среднюю точку сформировали тремя резисторами по 100 кОм. Пожалуйста, можно припомнить не «как-бы», а «как было»? Спасибо.
На счет «директор» я ошибся. Извините, Юрий Николаевич.
А мы знакомы?
Нет. Не знакомы. Просто был невнимателен при первом прочтении к шапке. Во вводном слове авторство раскрыто, а в комментарии ниже признано под этим ником. Ну и еще вспомнил что видел такую фамилию на обложке. Пользуясь случаем, — спасибо за ваши книги.
А вы с какой целью интересуетесь?
Мне просто любопытно. Задумался как бы сам измерял ЭДС PMSM со звездой без вывода средней точки. А если есть возможность узнать как делают корифеи, так это очень даже любопытно. Конечно, если средняя точка была доступна, то вопросов у меня точно не возникает. Поэтому и уточняю так настойчиво.

Чисто интуитивно вариант со «слабой» искусственной средней точкой мне не очень нравится. Сам бы наверное начал с того, что посадил землю осциллографа на одну из фаз и измерил относительно нее ЭДС на двух других. Третий сигнал получил бы как разность двух полученных. Но может и не прав. Хочу разобраться.
Так вы будете мерить линейные ЭДС.
К фазным надо будет переходить по известным формулам.
У меня было время поразмышлять над этим вопросом. Пришел к следующим выводам:
Если необходимо знать фазные ЭДС, то начинать следует с измерения линейных ЭДС по описанной выше методике в режиме холостого хода. Затем необходимо оценить насколько близко эти графики могут быть апроксимированы синусоидами. Если получилось, то можно воспользоваться виртуальной средней точкой и напрямую измерить фазные ЭДС. Если линейные ЭДС на синусоиду не похожи, то виртуальную среднюю точку использовать нельзя, ее потенциал будет колбасить с тройной частотой и амплитудой до десятков процентов от амплитуды фазной ЭДС в зависимости от степени ее несинусоидальности. В этом плохом для нас случае все еще можно попытаться численно решить задачу. Будет попроще, если экспериментальные графики ЭДС имеют близкую форму, отличающуюся только фазой и возможно амплитудой. Если они заметно отличаются по форме, то задача усложнится еще на порядок.
Вывод:
Лучше разобрать двигатель и найти среднюю точку. Это будет надежно, точно и без мучений. Численное решение или измерения с виртуальной средней точкой при отличии линейных ЭДС от синусоиды могут дать плохую точность и трудно предсказать насколько.
Последнее замечание, наверное самое интересное, но и самое голословное:
Пока это интуитивно, доказательства не проводил. Назовем это гипотезой. Хайли лайкли, нам совершенно не нужно знать как ведет себя средняя точка обмоток относительно земли драйвера и соответственно не нужно пытаться ее просчитать. Более того, у нас есть значительная свобода в способе формирования линейных напряжений, которую и используют при «инжекции третьей гармоники» в виде синуса, треугольника или любой другой формы по желанию разработчика, выигрывая тем самым в понижении минимально необходимого напряжения на DC шине драйвера. Гипотеза состоит в том, что должна существовать методика, которая позволяет вычислять правильный закон управления для драйвера прямо из экспериментальных линейных ЭДС двигателя, минуя промежуточное вычисление фазных ЭДС. Причем, решение не единственное, если не задать дополнительные условия.

Как-то так. Не знаю только нужно ли это кому-нибудь из практиков. Им расковырять двигатель попроще будет. А вот для диплома или курсовой кто-нибудь мог бы и попробовать.
По поводу, что может, а что не может СИМУЛИНК и спорить не буду.
Наша система (СИМИНТЭК) мне удобней.
Очень важно, что она именно наша. Разработчики рядом, все тонкости знают, если что — помогут. Кодогенерацию тоже ориентируем на отечественные процессоры.
Сколько можно, господа, жить чужим умом? (причем обычно ворованным)
По поводу пассажа о «Рабоче-крестьянской революции, о необходимости которой всё время говорили большевики» в начале статьи — я эту фразу не писал и она тут лишняя (если кто не понял — я автор статьи)

Резануло слух — "приводщик". У нас говорили "приво́дчик". Наверное в разных школах свои традиции...

За книгу спасибо :)
Знания должны пренадлежать народу!
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории