Перейти к содержанию

    

Hexel

Свой
  • Публикаций

    233
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Hexel

  • Звание
    Местный
  • День рождения 09.05.1986

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Украина

Посетители профиля

3 176 просмотров профиля
  1. Добрый день! Ув. коллеги, поделитесь пожалуста опытом, кто пользовался такой софтиной? Меня интересует что понравилось, что не понравилось, с каким аналогами можно сравнить? Мне нужен пакет для управления проектом с железом и софтиной, начиная от формальной постановки задачи, со спецификацией, условиями проверки. Сейчас изучаю MBSE и хочу применить в будущем - такая опция там тоже есть. Немного смущает что весь этот паровоз жутко тупит, но может быть это чисто проблема ОС. В то же время, цена вроде бы справедливая.
  2. Спасибо, мыслей накидали. К сожалению подобных зарядных мне не приходилось видеть или держать в руках. Может выразился неточно - тип акума - свинец. И коль уж ув. khach упомянул ВЧ инжекцию, у меня возник новый вопрос: а чем собственно поведение акума в середине диапазона рабочего напряжения, отличается от поведения конденсатора? Тогда бы можно было схалявить и посчитать неизвестные из равности зарядов It = UC (сколько заряда было передано и на сколько изменилось напряжение). Ну с различными поправками В реализации-то оно все станет ясно, сейчас я хочу определиться, какое проектировать железо, а софт-то переписывается уже легче
  3. Если поконкретней, то емкость предполагается от 5 до 65, а то и 160Ач, 12В. Получается задача класса "объять необъятное", на как можно более широкий круг потребителя, а там как получится. Поскольку хочу применить двунаправленный инвертор 12В-385В, доступен зарядный ток до 30-35А. Потому и задумался, что хорошо бы найти адаптивный алгоритм заряда, пока по счетчику не определится реальная емкость. Хотя и по минималочке действительно, как говорится - тише едешь
  4. Добрый день! Ув. коллеги, подскажите пожалуста, есть ли какой-нибудь онлайновый алгоритм выбора тока заряда таким образом, чтобы он например, не превышал 0,2С? Онлайновый - в смысле который можно провести в процессе заряда. Это нужно для схемы резервного питания с внешней батареей, которая заранее неизвестна. Ни о каком определении емкости "в лоб" речи не идет, в схеме для этого будет установлен счетчик. Задача - определить максимальный зарядный ток, который не вызовет деградацию свинцово-кислотного аккумулятора. Одна мысль у меня конечно возникла - регулировать ток таким образом, чтобы получить фиксированное падение напряжения на батарее. Может быть, даже не нужно вычислять внутр. сопротивление, потому что чем оно ниже, тем массивнее акум и тем больший ток он выдержит до перегрева (перегрев я так понимаю и вызывает деградацию при чрезмерном зарядном токе). Ясно, что провода внесут большую неточность, но не в худшую сторону для акума - это самое важное.
  5. p_v Пожалуста, не нужно развивать этот спор. Вы поделились действительно полезным опытом, мне еще предстоит его осмыслить. Я нашел еще одну замечательную программу (опять же на рутрекере =) Visual Paradigm и пробую с нуля пройти весь цикл разработки. У меня еще появятся вопросы) Поэтому хотелось бы, чтобы вы не составляли общее мнение обо всех участниках. да, UML, BPM и IEEE конечно нужные штуки, но это не повод курицу ставить важнее яйца. и что я так уж продвинулся, тоже забегать не будем, в личном общении думаю я бы многих разочаровал своими познаниями
  6. сейчас я между прочим пытаюсь применить sybase PD16, так что действительно, у всех мозги по-своему. жестких временных рамок у проекта нет, потому есть время поизучать что-то новое. но пожалуста, не надо высказываться так категорично насчет того или иного подхода, я все их попробую и расскажу что у меня получилось. как не крути, они имеют примерно одну цель - смотрите, картинка с изображением электропривода изображает не что иное, как data flow. PD вот мне нравиться тем, что в нем можно составить перечень требований и назначить каждому элемент модели, хоть из бизнес-процессов, хоть из UML. он является как раз комбайном для всех задач, но есть ньюансы. это все еще творческий поиск, пока что я смог до конца определить, что хочу от девайса. дальше нужно нарисовать такую диаграмму, или таблицу, чтобы потом, забыв с чего все начиналось (такой момент однозначно наступит), я смог безбоязненно кодировать, рисовать схему (кстати в менторе =) и быть уверенным, что ничего не пролюблено, и в сборе будет работать. нужно заметить, что все эти задачи для одного меня, хотя это не значит, что я НЕ смогу запутаться в своих же ногах. это запросто случается)
  7. one_eight_seven Нормальная такая штука этот yed. Пока что я не уверен, что именно буду в нем рисовать, но это будет очень удобно. Потому что с наскока я не придумал как нарисовать схему с первого поста, с пакаджами, компонентами и их расположением на физических носителях (именно так я понимаю UML Deployment), хорошо бы увидеть примеры. a123-flex А что есть динамический список? Это когда в екселе нажимаешь Группировать и потом можно свернуть часть ячеек? Да, таким я пользуюсь, многоуровневым. Нет, задачу это не решает)
  8. Ексель - хороший вариант, но на данный момент я составляю в нем спецификацию модулей - перечень стеков, процедур, т. п. и так называемую карту переходов - по вертикали состояния устройства (вкл, работает, ошибка), а по горизонтали приходящие сигналы. На пересечении получается состояние, в которое переходит девайс (узел) в ответ на сигнал. Еще отдельно колонкой условия перехода. Потом таблица соответствий состояний узлов к состояниям верхнего уровня. Что касается полной картины, чтоб заранее увидеть грабли, которые обычно вылазят уже на стадии кодирования/капчи (схемы)/трассировки/использования =) , то я не смог такую диаграмму придумать в екселе. Как говорится, картинка стоит тысячи слов. Мешанина теплого и мягкого вытекает из того, что девайс и есть суть такой мешанины, и в голове она как раз не помещается. Диаграмма дает возможность анализа косяков, как например, в очередной раз взглянув на представленную мной картинку, заметил кольцевание между модулями, и теперь думаю дальше, как его избежать. Наподобие таблицы периферии я такое тоже сооружал, по ходу разработки эта таблица перерабатывается, и важно поддерживать ее актуальность.
  9. Добрый день! Такой вопрос, кто как составляет структуру, алгоритмы высокого уровня для своих девайсов? Я вот долго накатывал какие-то узлы, блоки, из которых можно потом сооружать новые девайсы с минимальными доработками. Но доработки постоянно приходилось вносить внушительные. Оказалось, что я ни разу не анализировал все взаимосвязи ни аппаратных, ни программных частей - просто рисовал в тетрадке и по ходу рисовал схему, писал код. Пока оно все в голове помещалось. Сейчас я уже понимаю, чтобы была уверенность в том, что все будет работать правильно, в голову всего набивать не надо, а надо в цифровом виде. Если конкретно, вот полная структурная схема девайса, нарисованная в визио. Компоненты в синем ящике - периферия проца, пакаджи - софтовые модули. Компоненты на свободном поле - участки схемы, в белых ящичках - коннекторы и соответствующие им входные цепи. Входа компонентов обозначены как интерфейсы (кружками), я старался размещать их слева. Например, модуль OutExt имеет процедуру SetOut, которая вызывается из модулей UserIF и Evt, и выдает наружу сигналы через выводы Ch1 и Ch2 и через периферию SPI. Местами путаница, но это промежуточный вариант, т. к. визио показался мне не самым удобным инструментом для даной задачи. Вот я и хочу спросить, кто в каком редакторе составляет такие диаграммы? Может быть, хотя бы для чисто софтовых проектов? На мой взгляд это должен быть UML, пока что только для структуры. За описание процессов я может потом спрошу P171207__________.pdf
  10. Должен признать, что SVC - не совсем то, что я бы применил для данной задачи. Получается слишком сложно, но это именно то, что я хотел прояснить. Итого процедура логирования выходит строк на 10, так что запрет прерываний мне кажется, оптимальное решение. Ну и выгрузка в EEP конечно будет происходить где-то ближе к мейну, или низкоприоритетному таймеру. Спасибо за советы! Ну и книжка многое прояснила
  11. В емкостной области я работать не собираюсь, только в индуктивной. Также стойка будет переключаться после рассасывания токового хвоста. Тут самая затратная статья по теплу - это жесткое переключение опережающей стойки. У меня FGH60N60SFD мостом по 4 в стойке тянут до 70А при 67-70кГц, а дальше нужно конденсаторную батарею наворачивать) Модуль будет работать на 15-50кГц
  12. Вот как раз что меня беспокоит: в процессе формирования сообщения может сработать прерывание. можно в первых строках процедуры запомнить текущий индекс StackTop и сразу его инкрементировать. тогда в локальном контексте разрыв уже не повлияет на работу, т. к. место в логе уже будет зарезервировано, а всю необходимую информацию для сообщения передать аргументами, ее на самом деле не так много. Весь лог будет держаться в оперативе, а сохранение в EEP может происходить не прямо сразу. А через ISR - это как? кажется, я все-таки плохо представляю механизм прерываний.
  13. Добрый день! Ув. коллеги, кто владеет темой, подскажите - хочу применить модуль SKM200GB125 в резонансном инверторе со сдвиговым управлением мощностью. При этом встроенный обратный диод принимает в процессе преобразования самое непосредственное участие, и насколько я понял из даташита, он должен справиться с такой задачей. Но - одно дело даташит, другое - реальная конструкция, и такого опыта у меня мало. Сейчас у меня в таком режиме прекрасно работают FGH60N60SFD по 2 в параллель, но это опять же не совсем то же самое. Потому и прошу совета. Напряжение 500-600В с 3-х фазки, рабочий ток 100-150А. Фазу опережения планируется изменять в пределах 18-180о (градусов). задача по сути - регулировка мощности.
  14. Добрый день! Ув. коллеги, подскажите пожалуста, как вызывая подпрограмму из разных уровней прерываний, обеспечить ее завершение таким образом, чтобы она не была прервана из более высокого приоритета? Речь идет об диспетчере событий (собственная терминология =), который фильтрует события из разных модулей и сохраняет отчет в EEPROM. Разрыв в неподходящий момент непременно приведет к порчи лога, и заметить это будет сложно. Например, чтобы при вызове такая процедура работала на самом высоком уровне. Я полистал документацию по АРМ, но даже не знаю, где копать. Отключать прерывания нахрен до завершения - топорно, но должно работать) По-моему, еще такой функционал реализует RTOS, но опять же я в этом новичок. Какие есть варианты? Проц STM32F334
  15. somebody111 Согласен, но такая теория в равной мере относится и к однофазному. Меня интересует более подробно сам процесс преобразования. Наиболее понятно он описан в ссылке от MegaVolt, где принимается, что в каждый момент времени напряжение одной из фаз равно нулю, т. к. имеет наименьший потенциал. Конечно, это справедливо только в случае постоянного (непрерывного) входного тока. Такой ток как раз и обеспечивается корректором мощности, так что тут все сходится. Гораздо более интересный вопрос, как это реализуется. Вот например форма фазных напряжений, которые "видит" схема управления, подключенная к общему проводу, минусу моста. И самое интересное. Если к каждой фазе применить алгоритм, описанный somebody111, получу ли я синусный ток в каждой из них?