syoma

Ну, например, в мире программирования в том числе встраиваемого и даже ПЛИС, народ ничего не имеет против Питона - языка для так сказать общепроизводственных задач, не имеющего ничего общего ни с Си, ни с Verilog, но позволяющего быстро проверить множество вещей. И они его учат - представляете? ПЛК - это в принципе и есть такая палочка выручалочка в мире электроники. Язык там - это Паскаль, который выучить можно за час и вполне стандартен, а можно вообще без него рисовать блок-схемами или релейными связями. А сама среда позволяет вам запустить реал-таймовый проект за 20 минут с нуля. Вместо ПЛК на первых порах можете взять Raspberry Pi - естественно, как же без него? Потратите от силы неделю времени. Много?

Я предлагал автору вообще не заморачиваться с "освоением", а взять готовые модули - например Beckhoff и подключить их к своим шаговым моторам и датчикам в диагностическом зале. Вывести наружу Ethernet кабель, подключить его к любому ПЛК с EtherCAT - например к чему-нибудь на Codesys. Подключить пульт телеуправления и написать простенькую программу на ST или чем-либо еще. Это первый пункт программы и может быть даже в данном проекте достаточный, так как сам манипулятор может стоить в кучу раз дороже этой электроники и экономить на ней не имеет смысла. И обойдется он вам в копейки по сравнению со стоимостью остальной разработки. Если же нет, то называем этот шаг "Демонстратором", показываем руководству, заказчику, кому нужно идею, спрашиваем "сертифицируете"? И если ответы положительные, начинаем разрабатывать свое решение по образу и подобию и в зависимости от поставленной цели, насколько следует удешевить электронику. А ПЛК и EtherCAT модули снимаем и используем в следующем проекте. В худшем случае, если никому они не нужны, забираем к себе на дачу и делаем контроллер отопления или автоматический полив - эта штука понадежней будет любых Ардуиноподобных контроллеров. И вот так, маленькими шажками двигаться к результату.

Интересно, как это вы устроили? В смысле реальный имитатор с конденсаторами и транзисторами или просто выход высоковольтный?

Ну если вы уверены, что сможете это прям из коробки достать, пройти все испытания и сертифицировать с первого раза - пожалуйста.

Начал читать. Прям с первых строк в точку и любителям RTOS.. KLOC - kilo lines of code.

Обновлю - в начале лета поменял на 8-ой. 5-ый прекрасно работает - отдал родственникам

С точки зрения вопросов безопасности, стоит выбрать вариант б) и стандартный интерфейс, который бы использовался в системах, где есть требования безопасности. Например есть такой интерфейс - EtherCAT. Через него вы сможете легко подключить ваши шаговики, клапана и датчики к телепульту. Вопросы контроля зависаний/защиты от ошибок там уже решены. Так что сделайте ваш пульт соответствующим образом и все будет ОК.

Надо хелп читать. Наверняка что-то, связанное с памятью и которое должно сохранять состояние между вызовами функции. Сорри, я по m-функциям не силен, а больше Симулинком занимаюсь.

Разве что у NASA может что-то заваляться. А так не видел.

Это только диагностика драйвера. Все остальное приходит другими путями и про спецификацию я указал то, что требуется для диагностики драйвера, а не всего инвертора.

Используются готовые драйвера Power Integrations, например вот такой: https://gate-driver.power.com/products/scale-2-plug-and-play-drivers/1sp0635/ для управления 1500А/3300В транзисторами. Там всего два сигнала в интерфейсе управления - оптический вход и оптический выход. Включили свет - драйвер включил IGBT, выключили свет - выключили IGBT. Свет в фидбеке есть - драйвер и транзитор ОК. Свет пропал - значит либо КЗ, либо питания нет, либо мониторинг напряжения на затворе сработал. В остальных случаях драйвер коротко подмигивает после изменения состояния входа, как подтверждение. Это, собственно и все, что мне по спецификации знать дано, и все, на что должна реагировать ПЛИСина. Всякие комбинации паразитных элементов меня как-то не очень интересуют, так как в результате все равно будет отсутствие света в оптике. Что мне надо бы проверить в железе - что времянки правильные, т.е. если фидбек пришел за ХХ наносекунд, то это должно быть расценено, как подтверждение, а не КЗ и т.д.

Привет. Не знаю, есть ли здесь кто-нибудь , кто занимается такими вещами плотно, но спрошу. Сейчас разрабатываем плату управления силовым инвертором на ПЛИС и для тестирования ее софта в реальном времени на реальной плате нужен HIL симулятор. Этот HIL симулятор должен будет имитировать работу силовой электроники, принимая управляющие импульсы от платы управления, и генерируя нужные напряжения и статусные сигналы для нее. Т.е. софт на плате должен думать, что управляет реальным инвертором. Все это в реальном времени, поэтому логически HIL будет построен на ПЛИС. И вот встал вопрос каким образом сопрягать симулятор с платой и появился спор с железячниками: они хотят включить в петлю управления побольше реального железа - т.е. например выходы платы для управления IGBT (оптика) подключить к реальным драйверам, а уже к их выходу подключать симулятор. Я говорю - нафига? Симулятор сможет имитировать драйвера легко и мало того - может имитировать и их поломки, в то время как реальный драйвер так не может (если его искусственно не убивать). Тем более что в обратной связи (измерение напряжения звена постоянного тока) ЦАП симулятора выдает +-10В, а плата требует сотни вольт и никто, ессно, не собирается из +-10В делать преобразователь на сотню вольт, чтобы потом в плате это напряжение поделилось обратно к тому же уровню чтобы придти на вход АЦП. Просто подключаем выход симулятора прямо на вход АЦП платы и все. Железячники обосновывают свои предпочтения тем, что хотят как можно больше реальности, и не доверяют симулятору. Я же хочу побольше гибкости и поменьше специфичного железа и мне важно проверить правильность функционирования софта согласно выдвигаемым к нему требованиям, а не железа. Может быть есть какие-то методики по оптимальному выбору точек подключения HIL симуляторов к Device Under Test? Может кто знает, как это в авиационной/автомобильной индустрии сделано? Неужели вплоть до мехатроники все реальным железом имитируют?

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

Я думаю такого софта нет. Если считать это такой себе "авторазводкой" по типу Spectra для PCB, то лучшие продукты, например Solidworks electrical, могут делать такую авторазводку проводов только в шкафах и только в 2D. Вроде уже пишут, что можно и в 3D, но это очень похоже на рекламу. В любом случае дешевой проги такого рода я не встречал.

Интересно, эта тема совсем устарела или нет? Вроде должна давать ответ на ваш вопрос