syv

По хорошему, для данной схемы надо три преобразователя. Два силовых и один вспомогательный для питания собственных нужд. Первый преобразователь будет работать на относительно высокой частоте (порядка 100 кГц). Это необходимо для снижения габаритов трансформатора. Из входного сетевого напряжения он будет делать гальванически развязанное постоянное напряжение 150 вольт, соответствующее амплитуде выходного сигнала. Второй преобразователь, выполненный в виде моста, будет нарезать выходную частоту из полученного первым преобразователем постоянного напряжения. При использовании МК в качестве управляющего вторым преобразователем устройства, возможно получение синусоиды на выходе. Однако, в этом случае потребуется достаточно хозяйский, а, следовательно, дорогой выходной фильтр и выходное напряжение первого преобразователя потребуется поднять до 170-180 Вольт. Третий преобразователь обеспечит гальванически развязанное питание затворным цепям моста второго преобразователя и системам управления первым и вторым преобразователям. Можно, конечно, отказаться от третьего преобразователя и намотать необходимые обмотки на трансформаторе первого преобразователя, но это геморрой. В общем-то, девайс достаточно сложный и дорогой. Простая переделка компьютерного БП здесь не поможет.

Многие так и поступают. Зато много людей, готовых заплатить и немало именно за надежные технические решения, даже в этих областях. И еще забыли. С каждой новой ОС требуется все больше ресурсов. Другой путь есть. А то, что творится в области программирования и ОС, в том числе и встроенных систем, на мой взгляд, напоминает театр абсурда. Лично я в этом стараюсь участия не принимать. В принципе - это дело вкуса. Про "железо" немного не понял. Если речь идет о МК, то нет - разрабатывать его не надо, а вот изучать матчасть строго необходимо, тщательнейшим образом, начиная с программной модели и заканчивая временными параметрами. Ассемблер выбранного вычислителя просто обязательно. Если же подразумевается обвязка МК, то да - ИМХО, тот, кто пишет программу должен делать обвязку. Уверенность по поводу ОС проистекает из просмотра кода от УКОС, как ее самой, так и портов к ней. Все решения достаточно тривиальные и громоздкие. Не говоря о явных проколах. По поводу работы с RTOS. Есть такой раздел медицины - уринотерапия называется. Многим помогает. Но для того, чтобы определиться, подходит это дело твоему организму или нет, вовсе не обязательно пробовать его на вкус. Достаточно со стороны ознакомиться с самой методикой. Насчет ошибок в программе. А Вы уверены, что они есть в любых программах? Компиляторы с ЯВУ, по возможности, просто не использовать. Вот и все. Средства должны быть соразмерны со сложностью задачи. А если взял грех на душу, то проверять нещадно... Я прекрасно осведомлен о наличии ОС в ПЛК. Но в отличие от всяких новомодных RTOS эта штука прошла проверку временем, хотя иногда и с ней случаются сбои. Результаты этих сбоев, к стати, выглядят не очень... Речь, однако, была не об этом. Технологу-программисту тоже нужны все прелести, якобы предоставляемые RTOS - переносимость, скорость программирования и т. д. Однако, разработчики ПЛК имея внутри достаточно мощный вычислитель, почему-то отказались не только от внешнего ЯВУ, но и от внешней оболочки и предпочли примитивнейшие языки типа Ассемблера, совместимые исключительно внутри линейки ПЛК одного типа. Почему, как Вы думаете? Постараюсь ответить. Можно, но только после тщательного изучения внутренностей, чтобы никакого сала и свинины. Обычно там ничего хорошего нет, сплошные задержки в виде замкнутых на себя циклов.

Рискую вызвать эмоциональные возражения в свой адрес, но тем не менее, скажу следующее - для ответственных встроенных систем RTOS не нужна. На это есть ряд причин: 1. Использование чужого софта, каковым является любая RTOS, - это бомба замедленного действия, поскольку до конца не известно какие глюки будет иметь дядино сочетание RTOS+порт. 2. Повторное использование кода - задача вполне решаемая с помощью сочетания кнопок Ctrl+C и Ctrl+V, при условии, конечно, что Вы хорошо структурируете и документируете свои тексты. 3. Реализация пвсевдопараллельности вычислительных процессов (т. е. многозадачности) и обмен данными при правильном подходе - дело достаточно простое даже при значительном количестве этих самых процессов. 4. Время, потраченное на изучение RTOS, можно смело считать выкинутым на ветер. Нового, с познавательной точки зрения, там ничего нет. Лучше потратить это время на что-то более стоящее, вот к примеру :cheers: ... 5. Весь Ваш проект целиком будет работать медленнее под RTOS, чем без оной. Ну это очевидно и без меня... В защиту своего подхода сошлюсь на методики, принятые в промавтоматике. 1. Использование де-факто LD или FBD в качестве основных языков программирования для PLC (стандарт МЭК 61131-3). 2. Полное отсутствие каких либо внешних ОС. 3. Жесткие требования к структуре программы и данных, реализуемые на уровне среды проектирования. 4. Жесткие требования к платформе, на которой реализуется проект. Она должна быть абсолютно надежной и испытанной. Иное дело системы HMI, документирование больших объемов данных и другие задачи с большими массивами информации. Но там используются достаточно дорогостоящие методы резервирования и защиты от потери данных.

Есть вопросы. 1. Входное напряжение - сеть или что-то еще? 2. Почему бы не применить МК? 3. Все 4 канала одинаковые или нет?

Действительно, работа проделана достаточно большая. Только к программируемым логическим контроллерам (ПЛК) и промавтоматике отношения не имеет. Надо было LD интерпритатор или компилятор реализовывать вот, например и внешние входы/выходы делать 24 вольтовыми. А так, получается непонятно, для кого это сделано, хотя сама работа, безусловно, заслуживает уважения.

Есть у меня одна. Правда на 4 кВт. До сих пор выпускают. Если крепко почесать репу, то найти можно... Но повторю - с трансформатором придется помучаться. Если Вы готовы к тяжелым испытаниям в виде трансформаторостроения, то пишите на e-mail.

Разработка велась в 1989 году. Тогда было доступный=существующий :) А по мне так вообще лучше всего сердечник с распределенным зазором типа МП140 или MPP125. Естесственно для мощностей до 300 Вт. И плевать на деньги - надежность дороже. Насчет "косого полумоста" и обратноходового режима могу сказать следующее - лично наблюдал как все это работает при выходной мощности 5 кВт минимум. Тут все дело в трансформаторе. В том, что я держал в руках индуктивность рассеяния была около 3 мкГн при сечении центрального керна 16 см2 и зазоре 1 мм.

У этих микросхем одна стандартная беда - неустойчивая работа собственного генератора. Советую обратить внимание на пилообразное напряжение. Смысл тут вот в чем - когда переключается выходной драйвер, то на пиле появляется всплеск напряжения - помеха. Если в этот момент пила приближается к напряжению срабатывания компаратора генератора, то происходит его перезапуск не по достижению пилой заданного уровня 2.8 Вольта, если не ошибаюсь, а при другом, обусловленном помехой. И потом, никто не обещал все 100%. В документации речь идет по-моему о 98% максимум. Есть так называемое "мертвое время", определяемое емкостью конденсатора генератора. Как правило 100 % заполнение в реальных девайсах не нужно. И еще вопросы. 1. Каков коэффициент усиления внутреннего усилителя. 2. Вы пробовали регулировать скважность мимо внутреннего усилителя?

Идея следующая - обратноходовая схема.

Это что - радар? В смысле передатчик от него? Я так понимаю с эффективной импульсной мощностью излучения порядка 10 кВт. А где же остальные длительности? Здесь дело отнюдь не в схеме, а в качестве самого трансформатора, в том смысле, что паразитные его параметры должны быть минимальными. А сами схемы есть, начиная со схем на основе формирующих линий и заканчивая схемами на полевых транзисторах. Подойдут любые схемы от передатчиков радаров.

Я так понял, что Ваш регистратор будет снабжен собственной оригинальной RTOS, написанной специально для этого случая? Уже сделал. Пост №81 в этой теме. Однако сразу скажу, что все, что там написано, касается только МК с ограниченными скоростями и внутренними ресурсами, т. е. достаточно дешевых. Ваш случай отличается в сторону сложности задачи. Тут и математика, и флэш, и съемный диск... Не знаю как у Вас, но обычно я стараюсь разделить задачи физически. Задачи реального времени, такие, как управление объектом, сбор данных, их первичная обработка, решаются с помощью МК, которых может быть несколько, а задачи работы с дисками с помощью компьютера, снабженного полноценной ОС. Ну он же тоже кое-что сделал в этой жизни... А что касается общения, то может быть проще проигнорировать, чем напрягать нервы? На мой взгляд, общение, даже такое, должно доставлять положительные эмоции.

Не факт. Абсолютно. Здесь Вы меня не убедите никогда. Поэтому предлагаю ничью по этой части дискуссии. Каждый остается при своем. В том виде, как мы с Вами представляем, к сожалению, нет. Я, лично, уже около 10 лет таковым не являюсь. Стремление к мат. благам перевесило. Пошел сменным инженером на крупное производство. Занимаюсь техническим творчеством только, когда сильно попросят или для души. Зато могу взглянуть на процесс разработки со стороны. Да и подходы, принятые в пром. автоматике, оказали свое воздействие... Ну вот Вам и капец нашим разработчикам. Индусов много, процент дураков среди них такой же, как среди нас. По-любому дешевле... У меня нет семафоров. Есть входные переменные. Вообще-то я не пишу софт. Обычно я делаю девайс. Поскольку я беру за это Деньги, то всегда существует опасность испортить себе лицо в прямом смысле этого слова, если с девайсом что-то будет не так. В наших краях с этим очень просто. Под написанием софта я понимаю создание программок для РС. В этом вся разница. Это две абсолютно разные индустрии. Со своими правилами и устоями. Хотя есть примеры удачного сочетания. Пробовал. Был такой зверь - "Электроника 60" назывался, PDP/LSI-11 по-ихнему. Я на нем в юности программки валял прямо в кодах, даже без Ассемблера. А сейчас даже и пытаться не буду. Я больше скажу. Я и Visual С++ пользоваться не буду. Потому как человеко-машинный интерфейс там не очень. По мне так Borland C++ Builder самое то. Но одно дело встроенные системы, которые должны быть особо надежными и совсем другое системы на основе РС, обеспечивающие HMI. У них иные требования, и надежность среди них - не самое первое. Хотя справедливости ради отмечу, что в свое время наблюдал создание полноценной системы визуализации с нуля на процессоре I80186 без всяких встроенных RTOS и ОС. Так наизусть никто и не заставляет... Здесь важно осознать, я бы сказал, "почувствовать" архитектуру определенного класса МК. А для этого надо навалять пару, тройку не очень сложных программуль на Ассемблере, желательно с использованием прерываний и каких нибудь внутренних переферийных узлов МК. Я вообще время не считаю. Временные переменные (разных типов) ничем не хуже и не лучше всех остальных. В рамках встроенных, ответственных систем не для меня. В системах на РС, где халява имеет место быть - безусловно да. Пересмотрел хренову тьму пром. оборудования. Везде одно и то же. Концептуально от задачи ничего не зависит. Меняется мощность PLC и размер панели.

Когда и кем написанная? Кем написаны порты? К примеру, в порте uCOS для PIC18 я нашел принципиальный недочет, приводящий к фатальной ошибке при определенных условиях. Это раз. А во-вторых, зачем мне кусок ничего не делающей программы, которая не решает ни одной из поставленных задач? Есть стили программирования, когда даже нет понятия о контексте задачи. Да и понятия задачи тоже. Сначала надо определиться с подходом, и при его правильном выборе вопрос о RTOS отпадает сам собой. Не будет этого никогда. З. П, разработчиков будет только уменьшаться по отношению к остальным. Это общемировая тенденция. И кто такой Бангалор? О дисках речи нет, поскольку лично я подразумеваю МК с ограниченными ресурсами. Я так понял, что Вы утверждаете, что машинное время МК совершенно не тратится на обслуживание разных семафоров, мьютексов и прочей ерунды? Между прочим, судя по порту uCOS для PIC18, простое переключение между задачами - это 10 команд и 20 машинных циклов. Всегда. Для меня лично это непозволительная роскошь. Значит Вы утверждаете, что ядро RTOS никакого места в памяти программ не занимает? А где оно хранится тогда? Смотря что понимать под велосипедом. Мне кажется, что время, потраченное на RTOS, лучше потратить на освоение методик программирования при которых потребность в оной отпадает, даже при задачах любой степени сложности. Для того, чтобы организовать оптимальное взаимодействие между различными задачами (по-вашему, поскольку у меня другое определение для этой сущности) даже при большом их количестве вполне достаточно здравого смысла и правильной методики программирования. А что - это проблема? Есть Паскаль, Бэйсик, ну и Ассемблер. На мой взгляд человек, не освоивший Ассемблер выбранного МК, не имеет права применять ЯВУ, а тем более надстройку над ним в виде RTOS для создания встроенных систем, как не освоивший архитектуру системы. Это, естесственно, не касается инструментальных систем на РС. Там совершенно иные правила. Я так и говорил, что одно как минимум прерывание потеряно. Для меня это существенно. И еще большой вопрос как это все будет между собой взаимодействовать. Ну да. Трах с железом абсолютно неизбежен, но к нему добавляется еще и трах с RTOS. Смотрел я на этот стандартный интерфейс к железу... Еще раз напомню, что речь шла о встроенных системах без файловых систем и сложных графических интерфейсов. Обычно в пром. автоматике эти вещи разъеденины. Управление машиной - это PLC с примитивным языком или простой МК, а визуализация - PC с полноценной ОС. И где тут место для RTOS?

Дело тут не в частоте, а в полевиках и выходных диодах. Попробуйте заменить транзисторы IRF540 на полевики с меньшим Rdson и выходные диоды на другие, к примеру на сборки КД637 с соответствующей буквой по напряжению.

Сразу оговорюсь, что все нижеизложенное отражает только лишь мое личное мнение. 1. Использование RTOS снижает надежность системы на МК, поскольку сама она вещь в себе и кроме этого есть порты неизвестно кем и как писанные. 2. Использование RTOS снижает производительность системы хотя бы из-за необходимости сохранения достаточно обширного контекста задач. 3. Большинство RTOS принуждает использовать ЯВУ, в частности С, даже там, где для этого нет необходимости. В нашей ситуации это приводит к воровству софта, что после в ступления в ВТО может пагубно отразиться на многих из нас. Исключение GCC для AVR и частично MCC18 и С30 для PIC. 4. Использование RTOS в общем случае замедляет работу системы на время обслуживания собственных процессов. 5. Использование RTOS уменьшает доступные ресурсы системы. В частности уменьшает доступную память на величину, необходимую для хранения ядра и на хотя бы один таймер, используемый для службы времени. 6. Использование RTOS принуждает к изучению вторичной информации о ее функциях, методах и событиях, никак не связанных с решаемыми реальными задачами. Это непроизводительные временные затраты и необходимость хранения "в голове" абсолютно бесполезной информации. 7. Использование RTOS приучает к определеннму стилю программирования, на мой взгляд не очень красивому и эффективному. Пример этого стиля - использование замкнутых на себя циклов в качестве задержек. 8. RTOS зачастую не всегда хорошо отображается на архитектуру конкретного МК. Может я в чем-то не разобрался, но на мой взгляд RTOS только мешает эффективному использованию системы прерываний, особенно векторной. 9. RTOS приводит к появлению новых сущностей, таких как семафоры, мьютексы, майл-боксы, планировщики заданий и т. д. и т. п. На мой взгляд все это лишнее и только уводит разработчика от "железа" МК и внешнего оборудования, а это плохо. Пока все. Если что появится, тогда добавлю еще.

Вопрос о многоканальном регистраторе. Если этот проект выполнять на МК c DSP ядром или чистом DSP, то каково должно быть тех. задание, чтобы RTOS стала необходимостью? И в чем близость между гармониками и RTOS? Без шуток... Лично для себя я решил, что в своих проектах на МК с ограниченными внутренними ресурсами постараюсь обойтись вовсе без нее. Причины этого могу изложить по пунктам, если кому будет интересно. Что же касается серости, то мне кажется, что все мы не без этого греха в той или иной степени. Эмоции по этому поводу считаю просто излишними. Всегда рад оказать посильную помощь.

Открыл учебник по пром. электронике и прочел следующее. ... вентильный преобразователь потребляет от сети реактивную мощность, которая зависит от угла управления, величины и характера нагрузки. Ниже написано В трехфазных системах, гармоники, кратные трем, обычно в силу симметрии отсутствуют, и гармоническими составляющими напряжения в сети бывают 5, 7, 11, 13-я и т. д. гармоники. Низшие из них наиболее интенсивны. Далее следует описание системы поддержания коэффициента мощности на максимальном уровне при изменении реактивной мощности, потребляемой преобразователями. Присутствует и простая мат. модель. Т. е. насколько я понял измерять 7-ю гармонику необходимо для того, чтобы улучшить качество регулирования т. наз. управляемого конденсаторно-тиристорного источника реактивной мощности. Отсюда, я думаю, можно получить и желаемую точность. Впрочем, могу быть неправ. Вот название учебника. Горбачев В. Г., Чаплыгин Е. Е. Промышленная электроника: Учебник для вузов/ Под ред. В. А. Лабунцова. - М.: Энергоатомиздат, 1988 - 320 с.: ил. Вам может понадобиться глава 7 и в частности параграф 7.3 на стр. 269.

Перешел на ADUMы и доволен. Аналогично. Только это не оптика.

К сожалению, мои сведения по этому вопросу ограничиваются учебником по пром. электронике и Datasheet'ами на стандартные промышленные сетевые фильтры. Если Вас это устроит, могу дать ссылки на эти данные.

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

Специально для Вас можно добавить еще два варианта: 3 - профессионалы оба, 4 - никто из них таковым не является. Интересно, что бы Вы выбрали в этом случае? Ну, DSP и силовые агрегаты вещи не такие уж и разные. Решение уравнений обобщенной модели электрической машины в реальном времени для частотных инверторов никто не отменял. А это силовой агрегат. Тем не менее, я согласен с последним Вашим высказыванием. Нет не видел в силу ряда причин. Но пойду гляну. Обязательно посмотрите. Что-то не нашел. Одни порты. Их реализация для PIC18 особого экстаза не вызвала. А где взять сам уКОС2? На Рапидшаре стерли за ненадобностью. Помогите....

Согласен. Но вопрос задан конкретно. Кто профессионал? Варианты ответов: 1 и 2. Вопрос хоть и конкретный, но некорректный. Вот я вам задам аналогичный вопрос: "Вы уже перестали бить свою жену по ночам?" Вариантов ответа даю вам два - "Да" и "Нет". Выбирайте. Ваш вариант- софистика в чистом виде. Изначальное предположение о том, что я бью жену по ночам может быть ложным. Скажем так, у меня жены просто нет. В своем вопросе аналогичного предположения я не вижу. Если Вы его увидели, то укажите где?

И что? Думаете, будут брать? Почему? Вы - Бог? Вы не можете сделать безглючный агрегат? Если можете, то как вы докажете что он безглючен? Но не глючат ведь. Стоят себе в своих пусковых шахтах и не взрываются, на команды отвечают. Уже много лет... Вот и все доказательство. Еще один способ - выпуск большой партии агрегатов и их продажа большому числу клиентов. Если возвратов нет и все клиенты живы и здоровы, значит не глючит. Вы о чем? Модель обычно используется для отладки девайса. А как же многоконтурные регуляторы с наблюдателями? Не всегда модель используется только для отладки, нередко и для обеспечения функционирования. Сам не проверял, но пишут, что регуляторы с наблюдателями обеспечивают наилучшее качество регулирования. С первым предложением согласен. А вот второе не понял. В чем Вы видите "абстрактность" и "фиктивность " RTOS? Вы uCOS видели? Нет не видел в силу ряда причин. Но пойду гляну.

Это что же за микросхема такая, которую надо понимать? Может перед ней еще и сплясать надо? Так не должно быть. Микросхема должна работать во всех оговоренных в документации режимах. Без всяких там бомб. По поводу магнитных монолитных микросхем. Взгляните хотя бы на ADuM1300/ADuM1301. Я этим добром пользуюсь. Претензий не имею и бомб пока не обнаружил. Впрочем не только я. К торсионным полям отношения не имею.

У мосфета изоляция затвора тоже оксидная, это что же - "в ём бомбы"? Есть одно НО. У МОСФЕТА напряжение между затвором и истоком 20 Вольт максимум. А вот напряжение между внутренностями кармана и остальной частью микросхемы 500 Вольт. А где там бомба я не знаю. Поскольку не использую. И другим не советую.