ИЩУ РЕШЕНИЕ На стороне ПК засыпает USB и не просыпается

[alexins]

Есть такая проблема, как желание ПК (хост - host) тратить как можно энергии. Если устройство, подключенное к USB порту долго не общается с хостом, ПК переводит USB в спящий режим.
Если работать с библиотекой TinyUSB, то там можно найти описание TUSB_DESC_CONFIG_ATT_REMOTE_WAKEUP, рассказывающее о том, что подключаемое устройство может кричать хосту «проснись». Так работают клавиатуры, мышки и джойстики, заставляющие хост выйти из спячки.

Контроллеры станка CNC 3018 строятся на основе atmel 328P (Arduino Nano), без поддержки USB. За поддержку USB отвечает usb-ttl преобразователь CH340. Этот контроллер не умеет кричать хосту «проснись».

Если используется ноутбук без блока питания, на каком-то этапе usb хоста засыпает. На станке крутится шпиндель, но станок стоит на месте. Станок оживает, если передернуть usb кабель от станка.
Если ноутбук работает через блок питания, можно настроить систему питания так, что бы не засыпали usb соединения. В этом случае программа проходит без остановок.

Теперь, берем лилипута, скажем Raspberry PI 3B+. Эта штука всегда работает от блока питания. И при этом, она любит переводить usb в спящий режим. Это проявляется следующим образом. Запускаем, к примеру, Universal-G-Code-Sender, или bCNC. Подключаемся, отправляем команду разблокировать (снимаем alarm). Успеваем даже подвигать шпиндель туда-сюда. Выбираем файл управляющей программы. Пока Raspberry PI 3B+ не спешно загружает программу и рисует картинку, наш usb успешно засыпает. Достаточно пары минут, после последних движений по осям XY, и станок перестает реагировать на отправляемые команды управления от программы.

Возникает 2 вопроса.
1. Как объяснить Raspberry PI 3B+ (ОС Linux), что для подключенного устройства CH340 надо забыть о засыпании?
2. Есть ли реализация CNC контроллера, который умеет кричать хосту «просыпайся»?

По идее, контроллер Atmel 328U4 (Arduino Micro) имеет поддержку usb и реализует CNC IN/OUT (Serial Port). Соответственно, ее можно обучить кричать хосту «проснись». Думаю, для этого нужна и специальная прошивка, а не стандартная GRBL 1.1f.

 

[Бор33]

Если ноутбук работает через блок питания, можно настроить систему питания так, что бы не засыпали usb соединения. В этом случае программа проходит без остановок.

 

[demyuri]

Возникает 2 вопроса:
1. Как вы пришли к выводу, что виноват хВост УСБ?
2. Тему про защиту от помех не читали?

Соврал, есть ещё третий вопрос:
Вы всегда решаете аппаратные проблемы переустановкой (перепрошивкой) системы?

 

[alexins]

Я разве просил окно настройки в Windows?
Первый вопрос был задан для Raspberry PI.
Второй вопрос о существовании контроллеров, которые сами умеют кричать хосту "просыпайся".

"Защита от помех", это когда есть эти самые помехи. Но их нет. Ноутбук от батареи и от блока питания тому подтверждение.

 

[demyuri]

Защита от помех", это когда есть эти самые помехи. Но их нет.

Напомнить про суслика?

 

[alexins]

Если о помехах, они есть всегда. Достаточно вооружиться осциллографом. Не в помехах суть.
Можно на ноутбуке выставить засыпание usb через минуту, при работе от блока питания. Картинка будет такая же, как для Raspberry PI. Пока usb не выдернем и не подключим заново, станок не будет реагировать на команды от программы управления. Перезапуск программы не даст подключения к станку. Пробовал. Надо физически разорвать соединение и восстановить. Объясняем системе, что usb не должно засыпать, всё приходит в норму.

Ожидаемое поведение станка - ПК отдает команду, станок исполняет и выдает ответ "я готов".
Если станок не глупый и умеет работать с USB, он получит сигнал от хоста, что соединение уходит в спящий режим.
Со стороны устройств ввода, такой алгоритм вполне оправдан. Со стороны устройства, ожидающего команд от ПК, такой алгоритм не простая задача.

Возможно, надо на стороне управляющей программы смотреть библиотеки соединения серийного порта. Может, они умеют определять, что usb в спящем режиме и сами будят usb соединение.

 

[demyuri]

Не в помехах суть.

Удачи в поисках. Без нее вам ничего не светит.

 

[Бор33]

Достаточно вооружиться осциллографом.

Вы же все сами знаете. Вот сами и ищите или вы хотите чтобы другие за вас искали решение ВАШЕЙ проблемы?

 

[Techno71]

alexins, разработчики Klipper и Octoprint для 3Д принтеров бьются лбом в стену.
Ведь им так и не удалось добиться засыпания плат Raspberry и аналогичных, у них почему-то все работает без проблем.

 

[Иван Шмит]

А что вообще сообщает dmesg в этот момент ?

 

[alexins]

Если честно, я уже сам перестаю хоть что-то понимать с Raspberry PI. Стоят рядом ноутбук и эта RPI. На обоих машинках запущена программа UGS. Загружена одна и та же УП. Даю одну и ту же команду - объехать контур. В конце жму "вернуться в 0 по XY".
RPI объезжает и замирает. На возврат в 0 не реагирует. Ноутбук - всё отрабатывает как надо. Повторяю серию. На RPI, в какой-то момент перестает реагировать. На ноутбуке всё идет как надо. Я только и делаю, что кабель подключаю, то к RPI, то к ноутбуку. В некоторых ситуациях, на RPI, станок не доезжает до конца и замирает в непонятном месте.

По поводу 3D принтера. До какой-то поры, эта RPI стояла в Voron. Проблем управления не было.
dmesg пишет

[   34.449300] logitech-hidpp-device 0003:046D:4024.0005: HID++ 2.0 device connected.
[   50.725678] usb 1-1.2: USB disconnect, device number 4
[   57.425334] usb 1-1.2: new full-speed USB device number 7 using dwc_otg
[   57.528348] usb 1-1.2: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[   57.528365] usb 1-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[   57.528372] usb 1-1.2: Product: USB Serial
[   57.822324] usbcore: registered new interface driver usbserial_generic
[   57.822375] usbserial: USB Serial support registered for generic
[   57.828620] usbcore: registered new interface driver ch341
[   57.828779] usbserial: USB Serial support registered for ch341-uart
[   57.828930] ch341 1-1.2:1.0: ch341-uart converter detected
[   57.838220] usb 1-1.2: ch341-uart converter now attached to ttyUSB0
[  178.008765] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[  184.551261] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

UGS начала вести шпиндель по контуру основной УП и проехав пару сантиметров остановилась

В общем, нашел многолетнюю ошибку для RPI - ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 · Issue #2406 · raspberrypi/linux
В 3D принтере Voron стоит плата управления на STM32, а не какой-то чип CH340.

 

[Иван Шмит]

альтернативную операционную систему попробуйте
сч340 не виноват тут, думаю

 

[alexins]

альтернативную операционную систему попробуйте

Перед тем, как предлагать, посмотрите сами, какие есть альтернативы. Список официально поддерживаемых ОС на данной платформе: https://www.raspberrypi.com/software/operating-systems/

Я всё же, думаю, что проблема в режиме засыпания USB. Если кому-то кажется, что это проблема RPI, или его питания, пусть расскажет, почему после засыпания Windows 10/11, станок перестает двигаться. Почему обязательным условием нормальной работы от стационарного ПК или ноутбука, нужно запрещать системе отключать управление питанием на USB портах.

Проблема управления питанием возникла не только что в моей голове. Я нахожу кучу тем обсуждения разрыва соединения Windows с устройствами USB-Serial еще от 2018 и 2019 годов. И везде один и тот же ответ - надо запретить ОС управлять питанием USB портов.

 

[demyuri]

Эксперимент с отключённым шпинделем проводили? Какой результат?
БП другой пробовали использовать? Какой результат?
Фильтр на двигатель пробовали ставить? Какой результат?
Что вы в этот УСБ упёрлись, если результата нет?

 

[Иван Шмит]

Перед тем, как предлагать, посмотрите сами, какие есть альтернативы. Список официально поддерживаемых ОС на данной платформе:

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

Вы смотрите при поиске причины в сторону suspend, но где он в dmesg ?
У вас скорей всего просто отвал соединения, система никуда не переходила. Или же баг ос.

Так как, наверное, вы уже исключили отвалы по причинам питания, проводов и тп, вот я и предложил проверить работу ОС методом её замены.