Pull to refresh
102
1.5
Send message
А льете в силикон тоже сами, или кому-то отдаете? Я видел участок литья двухкомпонентными смолами в силикон — ну там места нужно побольше, чем для 3D-принтера. Один только вакуумный шкаф и сухожар чего стоят…
Дельта хороша, когда нужны высокие детали. Но два момента: чем выше деталь, тем дольше (сильно дольше!) она печатается. И, к сожалению, именно в высоту на разрыв у детали наименьшая прочность. Я бы для инженерных задач с удовольствием погонял принтер с печатным полем «дельта на боку», т.е. 200x600 или 300x600, а в высоту 100-200 мм и не более.
Тоже вариант. И если бы речь шла о сотне (ну или хотя бы десятках) ножей — даже предпочтительный вариант. А когда речь идет о нерегулярном изготовлении (к счастью, ломают их не каждый день) — вариант с силиконовой формой проблемнее. Все-таки форму нужно где-то хранить и потом искать. А 3D-модель лежит себе на диске, физического места не занимает, есть не просит — но в случае нужды через 20 минут нож готов. Прямо-таки production on-demand, как классики хотели…
Да, чем более плоская деталь — тем легче и с ABS. Но после PETG — желания колдовать с ABS-ом не осталось ровно никакого! И если брать для технических деталей — берите в естественном цвете. На уровне ощущений — сваривается лучше и прочнее, когда без краски в составе.
Может еще от сопла зависеть… У меня сопло 0.3 — и оно не любит пыль. Как забыл прицепить фильтр — так через пару часов начинаются проблемы с подачей. И да, тоже прокаливаем! Про ABS ничего хорошего не скажу. Размер 10x15 по-моему и будет либо отклеиваться, либо расслаиваться. Нужна термокамера (и иногда помогает concentric заполнение — напряжения в углах поменьше). Мы оставили ABS только для случаев, когда ожидается эксплуатационная температура >80-90C. Во всех остальных случаях пользуем что-нибудь менее капризное: PETG нравится очень.
Фильтр для снятия пыли с филамента с каплей касторового масла присутствует? У меня пока все случаи прекращения печати — это засорение сопла пылью. Стекло клей-карандашом покрываем всегда. Если это не нейлон или не большая деталь из ABS — отлипов быть не должно. Стол, правда, у нас с подогревом. При перерывах в печати, чтобы не пылить на клей — накрываем листочками A4…
Коллеги уже попробовали. В этом случае выламывается кусок корпуса, в который вставляется нож. В общем, если весь принтер не переделывать — в нем так и будет что-то ломаться. Уж пусть тогда нож — его по крайней мере менять легко. Причем по конструкции видно, что производитель предусматривал легкую замену — но… передумал!
Да ладно! Если не брать сложные в работе пластики, то PETG и PLA отлично хранятся в картонных коробках при нормальной влажности — по крайней мере, не помню с ними проблем при печати после этого. Следить за принтером после первых двух-трех слоев тоже смысла нет. Это же не фрезер — фреза не тупится, СОЖ не льется, стружку убирать не нужно. По мне, так 3D-принтер — самый самостоятельный из всех настольных станков! :-)
Однозначно за 3D-печать! Причем, самые нужные детали — не всегда самые сложные. И это — ни разу не корпуса и не статуэтки, блин!

Вот, например, пластиковый нож отделителя этикеток для принтера штрих-кодов. Ломается, но в запчасти не поставляется — предлагается купить новый отделитель (по нынешнему курсу >5 т.р.). А деталь очень простая: и в моделировании и в печати (никаких поддержек или навесов...). И как жить без принтера в такой ситуации?

На фото — черная деталь оригинальная, белые — две примерочные из разных видов пластика.

image
В простых системах, пожалуй да. А если нужно от пользователя через запрос тащить какой-нибудь seciruty-token через всю бизнес-логику, чтобы где-то в конце упихать его в подсистему аудита (а то и в лог БД)? А если с требованием, чтобы если аудит не записался, то и операцию не исполнять? Как тут провести различие между бизнес-логикой и безопасностью. По сути, они в ТЗ делают требования безопасности частью логики бизнес-процессов.
А нет впечатления, что вот этот подход спринга к безопасности очень похож на ситуацию, когда мы сначала нарисовали приложение — а потом (вдруг!) решили навесить сверху разграничение доступа. То есть для простых приложений — это где-то и удобно: сделали MVP, потом улучшили, потом набросили какую-то безопасность, и оно живет. Но в более-менее сложном и критичном приложении безопасность полагается интегрировать. И чтобы оно при нарушении этой подсистемы, желательно, вообще работать не могло…
Ну вот, я же говорю — тут каждый балансирует как может. Мы в свое время наелись магии и чертовщины в Java EE, и теперь очень критично выбираем фичи из фреймворков. Из того же спринга, пользуемся только Transactional, Autowired, RequestMapping и еще парой-тройкой сопутствующих аннотаций. Может быть везет что задачи специфичные — но пока хватает. А может быть возраст и опыт прививают аллергию на сложные решения… В общем, я остаюсь по отношению к внешним компонентам на позиции: пусть или оно незаметно сразу правильно работает «из коробки», или пишем свой функционал и явным образом где нужно вызываем. А сложная магия — ну ее: и порог вхождения для специалиста выше, и при отказе — поди-пойми куда бежать…
Вот при всем моем уважении — вариант с явным вызовом валидатора обладает одним преимуществом, которое на длинной дистанции перевешивает все его минусы. Даже для человека, который только вчера начал программировать и увидел проект первый раз в жизни — совершенно очевидно, что в этой точке производится валидация параметра, и ясно — какой класс (объект) за это отвечает. И если что-то пошло не так, то можно поставить точку останова и посмотреть — что, где, и почему… А в случае с аннотациями — вызов валидатора утонет в сгенерированных проксях и магии байткода. И когда это как-то сломается (а ломается рано или поздно все!) — разборки с магией могут длиться часами и днями.

Мой опыт в программировании для промышленного производства показывает, что код системы следует писать так, чтобы он был очевидным для разработчика квалификации ниже средней. Не потому что разработчики плохие — а потому что если разработчика в два ночи поднять срочным звонком, работоспособность и острота мышления (оказывается!) сильно снижается. А проблему надо решать, и притом прямо сейчас, и с первого раза. Когда код изначально был написан так, чтобы «дураку понятно было» — это очень помогает. Пусть даже ценой некоторого дублирования и общей некрасивости.

Как это обычно бывает — не догма, и your mileage may vary! :-)
Тут нужно крепко считать. По косвенным признакам — если уж этот регион освоили без дирижаблей, то и эксплуатировать тоже без них наверняка можно. С другой стороны, лучше один рейс большого дирижабля чем -надцать вертолетных — эффект масштаба никто не отменял. С третьей стороны — весь регион нельзя поставить в зависимость от исправности одного-двух супердирижаблей: отказоустойчивость транспортной системы тоже никто не отменял… Мне кажется, что период окупаемости этого проекта уйдет за горизонт оставшегося срока жизни тамошних месторождений.
Судя по тому, насколько быстро дирижабли вытеснили с рынка даже относительно примитивные самолеты 30-х годов — как транспортная система они не получились:

— Сложность уравновешивания и дифферентовки. Плавучесть дирижабля меняется даже от температуры воздуха и его относительной влажности. Отсюда или необходимость постоянно сбрасывать то газ, то балласт — или уравновешивать корабль с отрицательной плавучестью, а разницу добивать аэродинамическими силами или тягой двигателей. Но в последнем случае получаем комбинацию недостатков и самолета/вертолета и дирижабля…

— Высокая стоимость и относительная редкость гелия (на водороде, вроде бы, после Гинденбурга никто летать не хочет). После доставки груза нужно куда-то девать избыточную плавучесть — или сбрасывать газ, или совершать работу по его сжатию/охлаждению для последующего использования. Напомню, что на дирижаблях 20-х и 30-х годов использовали, например, систему конденсации воды из выхлопа двигателей чтобы плавучесть не так сильно изменялась при израсходовании топлива.

— Метеозависимость и огромная ветровая нагрузка. Мы сейчас возмущаемся задержками рейсов — а на дирижаблях это было бы массовое и неустранимое явление. Причем задержки сутками и неделями, а не часами. Еще обледенение нужно не забыть!

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

В результате — что дирижаблем возить-то? Пассажиры хотят скорость и регулярность — то есть самолет. Где нет инфраструктуры — вертолет. Грузы? Тут дешевле океанской перевозки все-равно ничего не будет. Остаются абсолютно нишевые задачи, которые дирижабли как систему не окупят. В конце-концов, даже если нужно доставить что-то большое в места без инфраструктуры — можно напрячься и сделать это разборным, или изготовить прямо на месте. А как только перевозки становятся сколько-то регулярными — люди строят шоссе/жд/аэропорт, и на место дирижабля приходит альтернативный вид транспорта…
Здесь два момента. Во-первых, мы не против опровержения нашей теории. Мир, в котором тест памяти реально убивает ноутбуки — ужасен.

Во-вторых, когда за утро у тебя без видимых причин умирают два ноутбука корпоративного класса — на ум приходит одна цитата из Стругацких: "… Нам разрешается прослыть невеждами, мистиками, суеверными дураками. Нам одного не простят: если мы недооценили опасность. И если в нашем доме вдруг завоняло серой, мы просто не имеем права пускаться в рассуждения о молекулярных флуктуациях — мы обязаны предположить, что где-то рядом объявился черт с рогами, и принять соответствующие меры, вплоть до организации производства святой воды в промышленных масштабах." © Жук в муравейнике
В Lenovo на EC заводится стабильное напряжение с шины VCC3M. Если ноутбук выключен и не находится на питании с адаптера — EC обесточен. Под напряжением только VCC3SW от RINKAN. От этой же VCC3SW сделана подтяжка кнопки питания. Если не нее нажать, то пара RINKAN/PMH заведет главный преобразователь питания, запитает по VCC3M микросхему EC, и дальше уже EC получит контроль над платой.
Результаты обсуждения ситуации на канале libreboot:

— Они склоняются к спонтанному выходу из строя двух RINKAN по независимым причинам. Возможно, их спровоцировал нагрев платы в процессе длительного MEMTEST-а. Возможно, по предположению omz, виноват блок питания.
— Общая статистика выхода RINKAN от тошиба из строя, по их словам, плохая. Заменять рекомендуют на аналог от ROHM.
— Описанный в статье сценарий КЗ LDO Rinkan через PMH они считают маловероятным. В худшем случае они ожидали бы подгорания выходов PMH, а не стабилизатора RINKAN
— В стабилизаторе RINKAN есть встроенное ограничение по току на уровне 55mA
— Неиспользуемые пины PMH должны действительно висеть в воздухе
— PMH напрямую подключен к ICH по шине LPC, и от прошивки EC это не зависит
— Тем не менее, они рекомендуют провести эксперимент с запуском memtest и ограничением тока LDO VCC3SW.
Как выясняется (см второй апдейт статьи) — в RINKAN есть встроенная защита по току 55 ma. Мы запустим мемтест с внешним ограничением по току VCC3SW и посмотрим как будет вести себя ток на этой шине. Если ограничение по току не сработает — значит никакого КЗ по VCC3SW при запуске memtest не было — и, следовательно, отказ RINKAN произошел по другим причинам (наиболее вероятно, из-за адаптера). Если случится ограничение по току — значит memtest все-таки может вызвать состояние КЗ (или, скажем корректнее — нерасчетно высокого потребления тока) по этой линии питания, и механизм образования КЗ придется уточнять.
BIOS не слетал, следов пайки на платах нет. Сервис тоже ничего не шил — «диагностировали» смерть материнки, и сказали что если мы принесем исправную — они за наши деньги ее заменят. То есть они даже из шасси ее не вынимали. Первый ноутбук ожил после отпайки VCC3SW на RINKAN и подаче на VCC3SW внешнего питания 3.3В. Причем, ожил полностью и попытался загрузиться. Опираясь на это мы начали искать и паять внешний LDO.

Я лично нес в руках бук N1 с момента его выключения после memtest и до попытки включить в переговорке. Он реально был рабочим 30 минут назад, а потом не реагировал даже на штекер питания (должен светодиод загораться, даже если бук не включен).

Information

Rating
1,234-th
Registered
Activity