[WIKI] Работа с центроискателем в LinuxCNC

[verser]

В нижнем правом углу никаких окон с ошибками не выпадает.

а отдельно взятая G38, интересно, запущенная вручную в режиме MDI, будет работать?
...
А, еще, а оси координат направлены слева направо и снизу вверх?

[verser]

Программа Probe Screen, как оказалось, подходит только для такого направления осей X:возрастание слева-направо, Y:возрастание снизу-вверх.
Под другие варианты нужно переделывать файл probe_screen.glade

[yell]

G38.2 Y2 без проблем выполнил, вроде

X возрастает слеева-направо
Y возрастает снизу-вверх
Z возрастает снизу-вверх

[verser]

X возрастает слеева-направо
Y возрастает снизу-вверх
Z возрастает снизу-вверх

Здесь вопросов нет.
Может, при запуске из терминала какую-нибудь ошибку удастся словить?

[yell]

Спасибо. Проблема была в том, что не был указан путь к папке macros (из инструкции по установке было сразу непонятно).

Код: Выделить всё

emc/task/emctask.cc 389: interp_error: Unable to open file <yminus>
Unable to open file <yminus>
error Unable to open file <yminus>

При запуске linuxcnc вываливались такие ошибки ещё. Cпрошу здесь, т.к. в них упоминается gladevcp

Код: Выделить всё

LINUXCNC - 2.6.10
Machine configuration directory is '/home/cnc/linuxcnc/configs/cnc'
Machine configuration file is 'cnc.ini'
Starting LinuxCNC...
.
/usr/bin/gladevcp:185: GtkWarning: Unknown property: HAL_LED.pick-color-blink
  builder.add_from_file(xmlname)
/usr/bin/gladevcp:185: GtkWarning: Unknown property: HAL_LED.led-shiny
  builder.add_from_file(xmlname)
/usr/bin/gladevcp:185: GtkWarning: Unknown property: HAL_LED.blink-color
  builder.add_from_file(xmlname)
/usr/bin/gladevcp:185: GtkWarning: GtkSpinButton: setting an adjustment with non-zero page size is deprecated
  builder.add_from_file(xmlname)
****  probe_screen GETINIINFO **** 
 Preference file path: /home/cnc/linuxcnc/configs/cnc/cnc.pref
Xlib.protocol.request.QueryExtension
Xlib.protocol.request.QueryExtension
/usr/bin/gladevcp:292: GtkWarning: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 15
  gtk.main()

[Predator]

это я не подрасчитал, делал под 1024x768 теоретически, но проверить было не на чем

Попробуй тут проверить, если получится http://onlinewebtool.com/ru/newscreen.php
А еще в FF вроде можно задать окну нужное разрешение.

[Serg]

А причём тут вебсайты и FF?..

[Predator]

А причём тут вебсайты и FF?..

Да что-то тупанул

[verser]

Участник linucnc.org форума NitroCH3NO2 сделал подробное видео работы с Probe Screen (англ. язык)
https://www.youtube.com/watch?feature=p ... S9f0Nkoh8U

[yell]

Не полностью влезает в экран. Разрешение 1024x768. Подскажите, что можно сделать?

Хм, это я не подрасчитал, делал под 1024x768 теоретически, но проверить было не на чем, короче, ужму немного при очередном обновлении.

Планируется ли очередное обновление? И если да, то когда?

[Alexsh]

Присоединяюсь к yell.
С разрешением 1024х768 кнопочки не помещаюся на эране. Очень не комфортно.

[pkasy]

у меня почему-то не срабатывает ваша конструкция
#<y>=#<_y> (save start Y position)

в конце измерения станок либо отскакивает от детали на 3-4 см, либо бросается на нее грудью.
вот три измерения y+
09:59:43 Error: Probe tripped during non-probe MDI command. (наезд на деталь)
09:59:42 Y+ Y+=65.3365 Ly=74.7980
09:58:29 Error: Probe tripped during non-probe MDI command. (наезд на деталь)
09:58:21 Y+ Y+=65.2705 Ly=74.8640
09:57:21 Y+ Y+=21.0695 Ly=119.0650 ( отскок от детали дальше, чем начальная позиция Y)

я всего лишь три раза нажал на кнопку померить Y+. выводил из зацепления и подводил к заготовке с помощью клавиш вверх/вниз
что это может быть?

добавлю.
выполнена команда G0Y64
стартовая позиция по Y64
нажимаю измерить Y+
результат:
10:06:41 Error: Probe tripped during non-probe MDI command.
10:06:40 Y+ Y+=65.3735 Ly=74.7610
текущие координаты по Y 64.98 DTG 0.434
то есть он не доехал куда хотел, и это место явно не 64, не стартовая позиция!
(back to start point)
G1 Y#<y> F#<_ini[TOOLSENSOR]RAPID_SPEED>

если ни кто об этом не писал, значит, у всех работает правильно. что неправильного у меня?

[verser]

Может, для выявления косяка, попробовать в файл macros/yplus.ngc добавить дополнительные отладочные строчки print:

Код: Выделить всё

o<yplus> sub
 	
#<y>=#<_y> (save start Y position) 
(print,y = #<y>)
G91
F #<_hal[probe.ps_searchvel]>
G38.2 Y[#<_hal[probe.ps_probe_max]>]
(print,search probe Y = #5062)
G1 Y[-#<_hal[probe.ps_probe_latch]>] F#<_ini[TOOLSENSOR]RAPID_SPEED> 
F #<_hal[probe.ps_probevel]>
G4 P0.5
G38.2 Y[#<_hal[probe.ps_probe_latch]>*2]
(print, latch probe Y=#5062 )
G90
(back to start point)
G1 Y#<y> F#<_ini[TOOLSENSOR]RAPID_SPEED> 
	
o<yplus> endsub
M2

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

[Nick]

10:06:41 Error: Probe tripped during non-probe MDI command.

Датчик скорее всего шумит, надо на него debounce повесить.

[pkasy]

debounce висит давно, с момента установки датчика.

Код: Выделить всё

# put debounce between parport input pins and probe signals
net probe-in motion.probe-input
net debounce-probe-in debounce.0.5.in <= hm2_5i20.0.gpio.061.in
net probe-in debounce.0.5.out

[pkasy]

у меня
Linux wood-router 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc i686 GNU/Linux
LINUXCNC - 2.6.10

глючит стабильно. G38 может сменить направление движения на противоположное без объявления причин и загнуть датчик. все измерения я провожу, удерживая палец над кнопкой ESC. если глюк - я давлю кнопку, возвращаю на исходное и снова измеряю. после нажатия на ESC измерение проводится чисто. поскольку приходится измерять координаты отвестий на двигателях, то это надоедает.

[Nick]

G38 может сменить направление движения на противоположное без объявления причин и загнуть датчик.

Скорее всего отрабатывает и срабатывает следующая строка.

net probe-in motion.probe-input
net debounce-probe-in debounce.0.5.in <= hm2_5i20.0.gpio.061.in
net probe-in debounce.0.5.out

А параметры у него какие?

Посмотри в halscope, что у тебя происходит на пине hm2_5i20.0.gpio.061.in и debounce.0.5.out. И вообще вот такого при нормальной работе быть не должно:
Probe tripped during non-probe MDI command.
Датчик точно глючит - есть ложные срабатывания = надо разбираться с ним.

[pkasy]

Датчик точно глючит - есть ложные срабатывания = надо разбираться с ним.

я думаю, что датчик точно не виновен в том, что станок на него наезжает, ибо halmeter показывает контакт, а станок все равно на него прет.

параметры:
loadrt debounce cfg="6"
setp debounce.0.delay 20

[yell]

я думаю, что датчик точно не виновен в том, что станок на него наезжает, ибо halmeter показывает контакт, а станок все равно на него прет.

Буквально на днях у меня наехал станок на щуп. Благо отделался тем, что только отлетел шарик со щупа (ничего не раскурочило больше). Шарик новый приделал. Но стал как и ты над кнопкой Esc руку держать. И почти каждый раз ею пользовался. Станок в момент измерения стал вести себя нестабильно. Пока попросту не перестал реагировать на щуп.
Проблема оказалась в КЗ, которое приводило к тому, что сколько ни касайся датчиком, а на выходе все равно как будто никакого касания не было.

Поначалу как видишь в момент, когда нестабильность контакта ещё перемежающаяся, поведение станка подобно твоему.

Попробуй во время простого перемещения коснуться рукой. Станок остановится. Продолжай удерживать щуп в состоянии касания и попробуй переместить станок. Ты увидишь, что он без проблем поедет.
Мне самому не нравится такая логика поведения. Я даже вроде обращал на это внимание здесь уже.
С одной стороны да, нужна возможность ехать даже при сработавшем датчике (иначе как устранить касание). Но направление и продолжительность попытки устранить касание нужно жестко ограничить.

Всё это я к тому, что скорее всего у тебя нестабильно работает контактная цепь. Пружинка может криво стоит. Может станок сильно дергается и сбивает контакт. Может стружка в датчик налетела. Может где-то в другом месте на пути сигнала к ПК какой-то дребезжащий контакт.
Потом, какое у тебя напряжение на шариках? Если 5В, то этого может быть маловато. Я сразу делал 12В через шарики. И у меня нет никакого debounce. И все работает как калаш.

[Serg]

Попробуй во время простого перемещения коснуться рукой. Станок остановится. Продолжай удерживать щуп в состоянии касания и попробуй переместить станок. Ты увидишь, что он без проблем поедет.
Мне самому не нравится такая логика поведения. Я даже вроде обращал на это внимание здесь уже.
С одной стороны да, нужна возможность ехать даже при сработавшем датчике (иначе как устранить касание). Но направление и продолжительность попытки устранить касание нужно жестко ограничить.

Правильная там логика! Если датчик сработал, то по G38.2 и G38.3 движения не будет.