cnc-club.ru

Argon-11 писал(а):не забывая про 2l/9.

подскажите, что это значит?

seet46 писал(а):подскажите, что это значит?

Можете здесь глянуть https://www.chipmaker.ru/topic/135284/
Правда, картинки куда-то исчезли. На словах: 2L/9 - это расстояние от краев поверочной линейки, на к-рых находятся точки наименьшего прогиба.
Обычно у поверочных линеек там находятся риски. Вот под этими рисками и ставьте какие-то упоры, на к-рых будет стоять линейка.

Накопилась некоторая статистика косяков станка и есть кое-какие неясности.
При обработке обширных горизонтальных поверхностей (ну к примеру 400x400мм) с малым шагом (2..4мм) изредка возникает ошибка joint x following error. Сегодня ночью произошли сразу 2 такие:
joint 0 following error
joint 1 following error
Это 2 привода по оси X.

Напомню, в станке применены шаговые двигатели, работа ведется через Mesa 7i92 посредством встроенной сетевухи мат. платы asus j3455m-e
Встроенная сетевуха - Realtek® RTL8111H
Первое, что приходит в голову - возникает какой-то случайный лаг в сетевом обмене.
Однако, при прочих (негоризонтальных) многочасовых операциях этого явления не замечалось. Почему?
Может, кто-то сходу подскажет возможную причину?
Обычно обрабатываю горизонтальные поверхности на скоростях 2000-3000 мм/мин
Ini:

http://wiki.linuxcnc.org/cgi-bin/wiki.p ... 20is%20set.

в моем случае "режимы шагогенерации" для ШД довольно щадящие даже для LPT порта, а используется шагогенератор Mesa, так что это скорее всего мимо.
здесь что-то связано с какими-то лагами или переполнением какого-то буфера.
Надо выделить время и погонять станок по площадям, может проявится систематичность этого явления.

Argon-11 писал(а):здесь что-то связано с какими-то лагами или переполнением какого-то буфера.

Я не силён в месах, но переполнения буфера быть там не должно. Ибо в RT системе вопрос/ответ отправляется строго по времени каждый сервопериод. Если есть перебой в отправке сообщения, то в следующем сервопериоде должна быть команда сделать шагов больше, чтобы догнать требуемую позицию. Если догнать таки не удаётся, то возникает joint following error.

Может FERROR очень маленький...
Можно попробовать моим Blackbox'ом зафиксировать состояние ошибки...

там, вроде, 1мм

UAVpilot писал(а):Может FERROR очень маленький...

а для ШД без обратной связи FERROR разве имеет значение?

Имеет. Обратная связь есть, от stepgen, если конечно сам её не ликвидировал.

После длительного простоя станка снова ловлю ошибку joint x following error, причем довольно часто.
Уже словил на каждую ось по паре раз.
В начале лета на форуме linuxcnc была подсказка в hal закомментировать вот это

setp pid.x.maxerror .0005

Опыт показал, что не сработало.
Поскольку ось Z медленная с малым ускорением, можно сделать вывод, что дело не в том, что Mesa 7i92 "не успевает выдать нужное кол-во шагов". FERROR и MIN_FERROR не при делах, ибо имеют заведомо большую величину.
Грешным делом думал, мешает WiFi usb свисток (постоянно мигает). Выдернул. Не помогло.
Проверял latency - все в порядке, не превышает ~17000, как и прежде.
Сейчас в отчаянии увеличил SERVO_PERIOD до 2000000, пока пилит, но ожидаю повторения проблемы. (UPD: не помогло)

Такое ощущение, что это нечто системное. До лета эта ошибка не была замечена в серийном количестве.
Может, у кого мысли будут дельные?
В ПК воткнут доп. Ethernet адаптер для связи с частотником. Могут быть лаги от его драйвера, которые RT ядро не может побороть?
да, и еще: в трее висит Teamviewer, но маловероятно, что он влияет.
Что вообще могло внезапно повлиять?

Каждый сервоцикл начинается с сообщения к месе с вопросом о позиции. Joint following error появляется, если пакеты не успевают уходить и приходить или разница между заданной и текущей позицией больше MIN_FERROR.

Помехи в Ethernet сеть случаем не залетают?

Поставь сервопериод 5000000 для проверки

вернул SERVO_PERIOD обратно на 1000000
про помехи - маловероятно, вокруг нет ничего искрящего/свистящего, кроме самого станка.
Но если помехи по Ethernet и будут, разве linuxcnc не застопорится с ошибкой "потеря связи"? По крайней мере выдергивание кабеля к этому и приводит.
MIN_FERROR у меня имеет неприлично большую величину 1.0, стало быть причину надо искать в чем-то другом.

сейчас увеличил STEPGEN_MAXVEL и STEPGEN_MAXACCEL в 2 раза от соответствующих MAX_VELOCITY и MAX_ACCELERATION (было в 1.5)
+ уменьшил STEPLEN и STEPSPACE с 5 до 4 мкс.
наблюдаю не дыша...

Помехи могут быть программные и аппаратные, причём, в самой системе. Ещё до отсылки и получения ответа

программные маловероятны - никаких обновлений или софта не ставил.
аппаратные - ну не знаю, сходил щас, системник продул компрессором )

TeamViewer говоришь? Как сам думаешь, будет ли эта сетевая программка лезть во все сетевые адаптеры, чтобы найти себе интернет?

Ну до лета она так не вредила, может и не в ней дело.
Кстати, интернет в этом ПК доступен через WiFi, TeamViewer вряд ли лезет по всем адаптерам.
В общем, мне эта причина кажется очень маловероятной.

Ты на всякий случай отключи всё лишнее сетевое и проверь. Я помню даже арткам зачем-то лез в LPT порт и мешал работе Mach3. Вощем, проверь всё методом исключения.

"вообще все" по отдельности проверить будет очень долго, т.к. глюк возникает примерно раз в 1.5-2 часа.
Сейчас вроде пока пилит после всего вот этого:
1. выключил TeamViewer
2. продул системник
3. увеличил STEPGEN_MAXVEL и STEPGEN_MAXACCEL
4. уменьшил STEPLEN и STEPSPACE
5. поменял Ethernet кабель на частотник (сомнительный был)

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

Спустя несколько беспроблемных дней сегодня снова словился глюк, причем в моем присутствии.
И показалось, что это произошло примерно в момент смены оборотов шпинделя. Напомню, что шпиндель управляется через отдельный от mesa Ethernet адаптер со своим адресным пространством.
Как это может быть связано с "joint x following error" - ума не приложу. Неужели работа с отдельным сетевым адаптером как-то влияет на latency?