Відповісти

dimich · 2025-11-03 20:13:17

jokeer пише:

Ну, все одно це досить серйозний механізм повинен бути.

Так, якщо припустити, що цю силу прикладено до середини площини вікна, десь на відстані півметра від осі обертання, це момент 50 Н*м (5000 Н*см). І це не враховуючи ваги вікна.
Ваш варіант цілком виконує задачу, а більше й не треба.

jokeer · 2025-11-03 19:42:26

Сорян, поплутав кілограми з ньютонами Ну, все одно це досить серйозний механізм повинен бути.

dimich · 2025-11-03 15:56:37

jokeer пише:

0.4кПа (із справочника Стеля для розрахунку даху) * 0.25м2 (площа вікна) = 100 кг.

0.4 кПа * 0.25 м² = 100 Н ≈ 10 кгc.

jokeer · 2025-11-03 14:14:11

Та все жлобство окаянне..
Максимальне вітрове навантаження на вікно приблизно таке:
0.4кПа (із справочника Стеля для розрахунку даху) * 0.25м2 (площа вікна) = 100 кг.
Сервопривід із зусиллям в 50 кг (1 край вікна закріплений) буде коштувати як пів теплиці. І його треба тримати під напругою постійно, або майстрячити якийсь стопор. А склопідйомник 300 грн.

До речі, механізм відпрацював сезон досить вдало коли треба - вікно відкривалось, коли не треба - закривалось. Концепція сервопривода без токарних робіт робоча.

Юрко · 2025-11-03 12:52:48

Мався на увазі сервопривід з поворотом, 270 градусів, з тягою.

Юрко · 2025-11-03 12:51:06

З яких причин не розглядався сервопривід?
Замість реле для двигуна:
https://arduino.ua/prod5016-kontroller-shagovogo-dvigatelya-bts7960-modul

jokeer · 2025-05-12 19:24:13

ще додати pid регулятор

dimich · 2025-05-12 16:05:20

Ще додати відтворення звукового фрагмента: "Обережно, двері зачиняються. Наступна станція ..." (жартую )

jokeR · 2025-05-12 13:41:32

Ну, десь так Повільно, 10 см за хвилину, але свою задачу виконує

https://vimeo.com/1083471847/06e0a57a9c - походу на цьому форумі плеєр зламаний

dimich · 2025-05-08 22:01:11

jokeR пише:

Встигає за 1 мс ESP32 капєц швидка штука

Та справа ж не у швидкодії процесора. Записати кілька байтів у регістри - це і на atmega займає мікросекунди. А фактичний запис байта в EEPROM - 3.4 мс (1.8 мс, якщо без стирання).

Тут же важливий проміжок часу між виникненням зовнішньої події (падіння напруги нижче заданного рівня) і завершенням запису на фізичному рівні. А він залежить від купи різних факторів.

Якщо для моніторингу використовується компаратор, який генерує переривання - це одне (я не в курсі, чи є такий в ESP32). Якщо періодично читається АЦП - це інше. Впливатиме, з якою частотою йде опитування, чи задіяно паралельно інші канали, чи виконуються інші задачі, які пріорітети у задач (якщо це RTOS).

ESP32 пише на зовнішню флешку, підʼєднану по SPI. Впливатиме, чи будуть в черзі інші SPI транзакції, чи встигла флешка закінчити попередню операцію. У типової XM25QH32C запис сторінки - 0.5 мс, але якщо для запису потрібно стерти сектор - це вже 50 мс.

jokeR · 2025-05-08 20:16:02

має вистачити десь на 300 мс. Теоретично можна встигнути. Але це дуже оптимістична оцінка

    unsigned long start = millis();
    prefs.begin("actuator", false);
    prefs.putInt("position", position);
    prefs.end();
    ets_printf("actuator save time: %drn", millis() - start);
    position_changed = false;

Встигає за 1 мс ESP32 капєц швидка штука Нраіцца.

А зберігати в MQTT дійсно можна. Це працює, але без гарантій. Якщо wifi відвалиться - упсь.

jokeer · 2025-05-07 16:59:58

>> датчик на рухомій частині, а магніти в крайніх стаціонарних положеннях

прикольна ідея але трохи не зрозуміло як це зробити в цій конструкції.

>>моніторити струм двигуна.

Робив таке з двигуном від приводу Старлінка, нормально вийшло. Але тут 2 черв'ячні редуктори. Дуже мале передаточне число і дуже велике зусилля.

>> фрікцион

я зварювальник ненастоящий

dimich · 2025-05-07 15:11:26

jokeer пише:

Кінцевик один (не хочеться жмута проводів)

А, тепер зрозумів.
Як варіант - сам датчик на рухомій частині, а магніти в крайніх стаціонарних положеннях.
Ще варіант без кінцевика - моніторити струм двигуна. Але може знадобитись фрікцион. Бо якщо момент у двигуна великий, та ще й червʼячна передача, то поки система зреагує на зростання струму, може встигнути щось поламати.

jokeer · 2025-05-07 14:08:01

Та сама, але з телефону

Чому бажано знати положення приводу? Кінцевик один (не хочеться жмута проводів), і якщо не знаєш, в якому положенні воно ввімкнулось, є шанс відкрити більше ніж потрібно. В принципі, світло зникає не так часто, можна дійсно починати з закривання і не паритись
Зберігати кожний оберт якось параноїдально, і флешку не хочеться деградувати
А RTC то явно лишнє

dimich · 2025-05-07 13:40:43

jokeer пише:

Зберігати положення приводу непогано було б.

Це, мабуть, потрібно краще розуміти логіку роботи системи. Бо як розумію на даний момент, є два положення: вікно відчинене, вікно зачинене. Відчиняється або зачиняється в залежності від поточної температури? Яке тут положення приводу?
Якщо на старті алгоритм потребує, щоб система була в детермінованому стані, то можна привести її в початковий стан безумовно, наприклад, вікно закрите. А далі нехай працює алгоритм.

jokeer пише:

Є ще дивна ідея зберігання в retain message в mqtt

Ще ідеї, щоб зберігати при кожній зміні, а не тільки при зникненні живлення: якщо раптом надумаєте ставити RTC з батарейкою, то зазвичай там є кілька десятків байтів CMOS-памʼяті. Або зберігати в зовнішню FRAM

PS: соррі, не розумію, jokeR та jokeer (Гість) - це одна і та ж особа, чи ні.

Форум arduino.ua

Відповісти

Огляд теми (нові повідомленні вгорі)

Підвал форуму