tonyk_av

Дошёл до платы. Опять непонятка. Загружаю изменения на плату, предварительно делая проверку. Получаю несколько ошибок вот такого вида: Открываю схему с этим компонентами и вижу: То есть, вроде, всё на месте. Редактор схем видит посадочное место, а редактор платы- нет. В чём может быть причина, куда рыть?

У меня работы хватает.

Ага, так и было. Проект иерархический и многоканальный, поэтому не сразу понял что к чему. Нужно было проверить подключения. Благодарю за пендаль!

Вот ответная часть. Вроде, всё подключено, а по факту- нет. А ведь куски взяты из проекта, где проблем с этим не было. Откуда проблема появилась? Вот что не понятно. Какая-то беда с сеткой. Тупо скопировал другую цепь, подключил, переименовал- подключилось.

Ещё непонятка. Перенёс проект из 17 в 21. В 17 проблем не было. В 21 поначалу тоже не было. Теперь в другом проекте в 21 скопипастил фрагмент схемы из сделанного проекта и на схеме получаю вот такую ошибку: Куда рыть, что проверять, что переделывать?

Делал печки, в которых кое-что плавили. Там нужно было сначала расплавить, потом поддерживать температуру расплава. Использовался адаптивный ПИД. Загрузка печки варьировалась от 0% (прожарка ёмкостей) до 100% (полная ёмкость для плавки). Если есть настроенный регулятор и есть возможность вычислять и/или загружать динамически уставку для него, то... задача как задача. Есть специфика, диктуемая физикой процесса, но это всегда так. И нет никакой разницы, какая абсолютная температура, +40 или +1200. Плойка разогревается до +140, но для экспериментов хватит и +40. В вашем случае нужно учитывать поглощённую теплоту. Если есть понимание _как_ это делать, то и проблем особых с решением нет, остальное становится инженерной рутиной.

Я в курсе.

SSR Какая разница, до какой температуры греть, +40 или +1200? Принцип один и тот же.

Зачем говорить? Для начала вполне хватает и этого. Вот стенд (громко не смейтесь) из плойки и NTC+Modbus: Вот как раз рассчитывал и проверял работу ПИД-регулятора в режиме нагрева и поддержания температуры. Так что мне теперь понятно, что нужно человеку.

Хм, в производственных помещениях не редки ситуацию, что есть три фазы, но без "нуля". Предлагаю определиться с питанием.

Вот-вот. Точно не представляет. ПЛК ведь не в воздухе висит, а взаимодействует с объектами реального мира, у многих из которых протоколы и объёмы информации гораздо сложнее и больше, чем "истина" и "ложь" у GPIO. Вот не самый сложный ПЛК, лежащий сейчас у меня на столе, поддерживает 7 протоколов на трёх интерфейсах.

:)))))))) Зачётный подъёбчик!

Там нет танцев. Читайте доки на ld, в них всё хорошо описано. У меня в текущем проекте много размещении переменных в памяти по нужным адресам. Линкёр для того и нужен, чтобы взять на себя эту работу. Достаточно рассказать ему, что тебе нужно. Видимо, вы не представляете себе что такое ПЛК. DMA там и так задействован на 100%, но вторая голова совсем не лишняя, даже без HMI.

...так сразу стало бы понятней. Зачем две термопары? Чем определяется та, по которой идёт формирование профиля?

Причём тут Куб? Вы работаете с GCC, и я пока не сталкивался с тем, что в нём что-то нельзя было сделать. Очень хорошо представляю. Давно хочу попробовать, но времени нет. Например, в ПЛК, когда на одной голове крутится программа пользователя, а на другая голова обслуживает коммуникационные интерфейсы и/или встроенную панель ЧМИ.

О как. Неожиданно. Благодарю!

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

К моему удивлению, при беглом просмотре увидел снижение цен на ряд компонентов. Глубоко не рыл, но есть в доступе и не дорого. Я это знаю, печками управлял. Я тоже не понял, какая сеть. Сначала показалось, что речь о трёхфазной, потом всплыла фраза что это тоже вариант. Пока прикинул для однофазной.

Так тут совсем другое описывается. По ссылке описывается выделение буферов по нужным адресам, потому что сетевой контроллер работает с ними. Или я чё-то не так понял в хотелках вопрошающего?

Измерение токов и напряжений в трёхфазной сети. Измерение температуры. Везде нужна гальваническая развязка. Плюс вы не учли ещё один температурный канал, который в случае сбоя МК хотя бы просто выключит печь. Обжиг керамики- зубы выпекаете? Намордничек с кнопочками-дисплейчиком точно не нужен? Хотя наличие 485-го намекает на удалённую настройку. По деталям в 5-7к при тиражности от 10 экземпляров можно попробовать уложиться.

А вот и не без разницы! new-delete учитывают _тип_ объекта в отличие от банальных alloc-free. Более, того ещё и с учётом сигнатуры, что явно не доступно в С. EdgeAligned, мы с тобой одновременно об одном и том же, только чуть разными словами. 🙂

Значит, не осознали его значимость и нужность по причине того, что пока не сформировалось объектное мышление. Простой пример: UART. Есть текстовый терминал, работающий по EIA-232, есть Модбас/RTU-мастер, работающий через EIA-485. Когда попробуете выделить у них общее, то с удивлением обнаружите, что у них на 95% общий код, и что создать для них общего предка становится естественным. Ну а разницу вынести в наследников. Так что тут я категорически не соглашусь, что наследование "в С++ прилеплено". Первое, что попалось на глаза: class FPU_device : protected IRQ { public: FPU_device( void ); ~FPU_device( void ); private: // Обработка исключений устройства с плавающнй точкой. virtual void IRQ_Handler( void ); }; То есть, следуя ОО-пардигме, любой объект, желающий обрабатывать прерывания, должен быть наследником класса IRQ и определить виртуальный метод IRQ_Handler(). class IRQ { .... protected: IRQ( void ); virtual ~IRQ( void ); //---------------------------------------------------------------------- // Обработчик прерывания. virtual void IRQ_Handler( void ) = 0; .... };

Где настраивается цвет точек соединений цепей?

А как же наследование? Как без него? А ты просто не используй эти переусложнённые шняги. Я при использовании С++ долго жил под угрозой переноса кода с ARM на МК с архитектурой х186, посему ориентировался на возможности Borland C++ 5.02. Это раз. А два проявилось при попытке использовать стандартную библиотеку. Кое-что можно использовать, но нужно хорошо понимать что и как в ней устроено, иначе добавление в программу двух строк приводит к увеличению потребляемого ОЗУ и ПЗУ на десятки килобайт. Вот-вот, только на неё не нужно ругаться. По-моему, она для того и сделана, чтобы каждый мог выбрать и использовать то, что нужно именно ему для его задач. И не нужно переживать, что остальное тебе не пригодилось.

Это чё за фигня?