Pull to refresh
17
0
Send message
столешница лежит прямо на боковых ножках и давление на столешницу переходит на ножки

Это понятно. Я говорил про держатели полок, видимо надо было уточнить.
Жесткость от перекоса (при высоте до 1 метра) создает нижний элемент panel_rack_bracing

При плече 1 метр эти элементы будут вырваны с мясом если кто-то просто на этот стеллаж решит облокотиться. У вас это не так существенно, так как справа стеллаж упирается во вполне приличный шкаф, но вот рекомендовать подобное решение для отдельно стоящего стеллажа/стола я бы не рискнул. Посмотрите на тот же стол от IKEA в начале вашей же статьи — там сзади видна вполне приличная поперечина.
Но как вы сделаете с помощью них стенки «аля филёнка»

Для сборки брусов с филёнкой куда логичнее использовать конфирматы (мебельные шурупы) — и соединение жёстче будет намного и их можно хоть каждые 20 сантиметров воткнуть. Кстати, на высоком шкафу у вас ещё может вылезти неприятная проблема со временем — так как длинные вертикальные брусы работают под нагрузкой, то со временем от просушки и торцевой нагрузки их может «повести» как винтом, так и дугой. И если при жестком конфирматном соединении их бы удержал мебельный щит, то три хиленьких пластиковых дуги их вряд ли удержат.
PS: профессионально изготовлением мебели не занимаюсь, но для себя собственноручно сделал три кровати из бруса и мебельных щитов и некоторое количество шкафов, в основном из ЛДСП. 3D принтер есть, но использовать его продукцию в качестве силовых элементов мебели мне бы и в страшном сне в голову не пришло.
Первая проблема, которую я вижу — отсутствие хоть какой-то защиты от перекоса. В тех же икеевских шкафах от перекоса защищает жёстко прибитая задняя стенка. А любое усилие на перекос в вашей конструкции вызовет немедленное выламывание крепёжных элементов, так как рычаг огромный.
Второе — всё-таки как-то странно сделать несущие элементы по принципу «как получилось», то есть несущая способность определяется уже в готовой конструкции опытным методом. Причём совершенно непонятно — что мешало добавить в конструкцию стандартные металлические мебельные уголки.
Как всё сделать максимально неправильно и получить на выходе полный бред.
Там же распарсить оригинальную структуру заголовка и нормально обработать файл можно десятью строками кода — в любом случае для корректной обработки надо иметь в виду как минимум BitsPerSample и BlockAlign. Да и размер чанка данных после обработки неплохо бы привести к корректному значению.
в режиме «коллективного управления», который изменяет шаг лопастей равномерно, а также с помощью режима «циклического управления», при котором наклон лопасти зависит от угла поворота ротора

Это не режимы — это два параметра работы винта (системы винтов). В русскоязычной практике они называются общий шаг и циклический шаг винта. Реализуется это с помощью автомата перекоса.
Автомат перекоса
Есть гениальная история про отпугивание мейн-куна :)
Цитата:
Кот пришел через пару часов, когда мы заснули. Прыгнул со шкафа на фольгу. Фольга зашуршала, кот страшно перепугался, взвился в воздух и упал на мужа.
В чистом итоге: минус десять метров фольги, минус сорок капель пустырника на двоих взрослых. Плюс развлечение коту.

Но рекомендую прочитать полностью:
ru-cats.livejournal.com/19218540.html
ru-cats.livejournal.com/19238701.html
ru-cats.livejournal.com/19428775.html
Немного оффтоп. А почему для иллюстрации была выбрана именно такая картинка? Просто я совершенно чётко вижу, что на иллюстрации вовсе не компьютерная серверная, а что-то типа аппаратной какого-то вещательного комплекса — какие-то кодеры и эфирные процессоры, коммутационные панели с XLR (это такие звуковые разъемы) и т.д.
А зачем там вообще используется прерывание, если по сути вы его никак не используете? Куда проще прямо в рабочем цикле проверять состояние датчиков.
Всё, что под if (firstStart) надо переносить в setup — это типичная инициализация, для которой setup и предназначен.
Ну и вложенные циклы с одним и тем же условием isSensorStarted — это что-то за пределами моего понимания
Прежде всего несколько непонятно — у вас обычные BLDC двигатели (под трапецию) или рассчитанные на векторное управление (под синус)?
Двигатель ниже 5 об/мин двигается рывками, а ток сильно возрастает

момент при малых оборотах высокий, а с увеличением оборотов нелинейно падает, и чем меньше напряжение питания, тем хуже зависимость

Собственно — это одна проблема. И она называется «противоэдс». То есть вращение ротора вызывает ЭДС в катушках. В управлении бездатчиковыми двигателями этот эффект используется для уточнения положения ротора.
По большому счёту вам надо рассчитывать подаваемое напряжение с учётом требуемого ускорения и текущей скорости. Либо работать с токовыми драйверами.

первый шаг периодически сопровождался рывком ротора. Удар можно убрать, путем снижения амплитуды первой половины шага (в моем случае 20% от максимума) и значительно увеличив время первой половины шага по сравнению с другими шагами.

Здесь имеет смысл плавно (линейным нарастанием) вывести на максимальное значение чтобы плавно поставить ротор в заданное положение и дальше уже регулировать напряжение в зависимости от требуемого ускорения.
PS: На всякий случай хочу заметить, что даже при использовании DMA чудеса ещё как бывают.
Стандартный приём при использовании DMA — наличие ДВУХ буферов — один сейчас «в эфире», второй копит данные. При окончании данных в первом буфере — натравливаем DMА на второй буфер, а данные льём в первый. И так они по очереди и работают. В таком случае мы избегаем любых блокировок или потерь данных.
А зачем здесь вообще DMA? Подобные задачи (низкоскоростной вывод) куда проще решаются через кольцевой буфер и прерывание по пустому буферу передачи. Никаких блокировок.
Копируем данные в кольцевой буфер и смотрим — свободен ли сейчас буфер UART. Если свободен — кидаем туда первый байт.
Дальше по прерыванию просто кидаем следующий байт и всё. Дошли до указателя последнего байта — остановились.
> конденсатор ёмкостью 0,1-1 мкФ (маркировка 103 или 104)
103 — 0.01мкФ
104 — 0.1мкФ
105 — 1мкФ
А с чего вдруг получится сверхмалое потребление тока? Яркость приблизительно пропорциональна среднему току через светодиод. Чем мы его достигаем — ШИМом или активным элементом последовательно светодиоду — да пофиг — потери в любом случае равны (Uпитания — Uсветодиода)*I. А напряжение на светодиоде почти не зависит от тока — их даже раньше использовали в качестве этакого стабилитрона.
Единственный способ понизить потребление — индуктивность последовательно светодиоду, ШИМ и схема стабилизации тока. Но это такой геморрой, что это имеет смысл только на каких-то уж очень больших цифрах.
Это не ШИМ заметен, это частота обновления. В большинстве библиотек делают частоту обновления порядка 10 герц и «ступенчатость» изменения яркости очень заметна.
Я когда делал свою снежинку/гирлянду делал частоту обновления порядка 100Гц и все зажигания/потухания сделал плавными. Визуально очень хорошо смотрится.
Это типичная проблема, когда площадка общая для двух SMD компонентов — при расплавлении паяльной пасты силы поверхностного натяжения «стягивают» компоненты вместе. Надо было оставить полоску маски, тогда такого бы не было.
Оказалось, что давление 0.00 Bar начинается когда 7-й байт содержит значение 97. Не ясно почему так.

Скорее всего там просто абсолютное давление, умноженное на 100. То есть при абсолютном давлении 1 бар (без избыточного давления) на выход должно идти 100. 3 единицы — просто погрешность.
А цветастость была важным условием? Всё-таки адресные светодиоды весьма крупные, из-за этого приходится делать «ножки-световоды», которые дают некрасивые «пучки» света снизу.
Не было идеи просто сделать плату подсветки на копеечных SMD светодиодах формата 0805? Тогда нижний торец можно было бы сделать плоским и подсветка была бы намного равномернее.
Хотя даже с текущей конструкцией можно было бы существенно улучшить равномерность подсветки если сделать ножки не прямоугольниками, а трапециями и матировать нижнюю грань (обращённую к светодиодам).
Ох, как будто вернулся в конец 90х — начало нулевых… Когда Резонит драл за платы неадекватные деньги, китайцы еще не раскачались и всё делали ЛУТом. Когда нормальных микроконтроллеров еще просто не было и всё делалось либо на MCS-51, либо на at2313. И да, приходилось всё делать на ассемблере, так как каждый байт был на вес золота.
Много что еще можно вспомнить. И так удивительно видеть всё это в конструкции 2019 года.
Извините, но Вы серьезно ссылаетесь на Wiki, как на серьёзный источник?
Вообще-то, в сети без проблем находятся оригинальные документы. И в них это называется:
«Испытание турбоагрегата №7 Чернобыльской АЭС в режиме совместного выбега с нагрузкой собственных нужд»
accidont.ru/Prog1985.html

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

Information

Rating
Does not participate
Registered
Activity