Сообщений в теме: 63

[torvn77]

Задавайте сюда всякие вопросы по эксплуатации и базовой настройке LinuxCNC,
по мере наполнения темы будет создаваться фак и описание работы с программой

• Руководства по настройке LinuxCNC/EMC2 для работы через LPT порт для чайников
• Лицензия на фак и описание работы с программой
• Описание работы с программой
• F.A.Q.

Страница загрузки LiveCD c с предустановленным LinuxCNC 2.5 http://linuxcnc.org/...nglish/download
 
Имеющиеся репозитарии LinuxCNC с бинарными сборками релизов для Ubuntu и Debian http://linuxcnc.org/dists
 
Руководство на сайте linuxcnc.org.org

• wiki.linuxcnc.org
• LinuxCNC Documentation - devel version (HTML)
  Инструкция по подключению репозитария buildbot.linuxcnc.org

• LinuxCNC Documentation - 2.6 version (HTML)(Текущии стабильный релиз)
• LinuxCNC Documentation - 2.5 version (HTML)(Прошлый стабильный релиз)

Версии LinuxCNC на текущий момент 09,08,2014
2.7 (devel) текущая версия для разработчиков,которая только в будущем станет релизом.
Кто хочет себе приключений на голову,может пользоваться ею,
так как именно в неё помещается весь новый функционал для поиска ошибок и их исправления.
Но именно по причине первоочередного появления в ней последних версий функционала
многие люди предпочитают пользоваться именно ей.
2.6 текущая стабильная версия
2.5 это устаревающая стабильная версия двухлетней давности.
 
Добавление в редакторы Pluma и Gedit поддержки подсветки синтаксиса gcode
Открыть под рутом архив  Gcode_HighLight.tar.gz   3,88К   881 скачиваний и фаил LinuxCNC_gcode.lang распаковать в каталог
/usr/share/gtksourceview-2.0/language-specs
а файлы classic.xml и tango.xml  распаковать в каталог
/usr/share/gtksourceview-2.0/styles/
 
Файл  LinuxCNC_gcode.lang содержит не стандартное название типа данных varning и работает корректно только с этими двумя файлами стилей окна.
Тип данных varning в остальные стили окна добавляйте самостоятельно.
Так же можете изучив не сложный фаил LinuxCNC_gcode.lang сделать самостоятельный тип для файлов hal.

[torvn77]

pik мне в личку написал:

Благодарю ! Извиняюсь за чайниковские вопросы (
Есть вопросы по установке на ноль. У меня на самодельном станке стоят ограничивающие конечники предохраняющие станок и фрезы от поломок. 6 концевиков предохраняющих от выхода за габариты подключенные последовательно к аварийной кнопке, работающие как аварийная кнопка. Рисунок тут во вкладке схема http://www.npoatom.r.../drivers/g540/# В маче я в ручную выводил на нужное положение, вводил нужные координаты и запускал, а тут что то подобное возможно ? В принципе подключение концевиков не проблема, физически закреплены на станке, подключить к клемам как на схеме да и всего делов. В таком случае у меня три концевика будут определять минимумы соотв осей, по ним будет выставляться ноль. А три так и останутся estop. программа как то отслеживает концевики во время работы, т.е. если во время резки собьётся ноль и сработает концевик для установки на ноль станок аварийно остановится ?

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

Но я всё же думаю что датчики дома и лимитов должны быть отдельно.
Безопасность в одну сторону,а инициализацию в другую по аналогии с мухами и и котлетами

pik в личке писал:

Траектории загружаются. На экране справа видна заготовка и её размеры. Только почему то не активна кнопка "Начать исполнение текущего файла ®". Подскажите пожалуйста в чём может быть причина.

)Сначала самой правой кнопкой или клавишей F1 надо снять сигнал блокировки станка
)Затем F2 включить станок
)Затем нажав кнопку Home all инициализировать координаты станка,сами понимаете,если они не совпадут с реальными,
то исполнение УП закончится аварией.

Я в этом тоже по началу путался.
Такое сложное включение происходит от того,чтоLinuXCNC рассчитано в том числе и на управление сложным оборудованием,
а там так же,как и в телевизоре или компьютере,состояние выключено не всегда означает обесточено,
поэтому отключение станка дублируется сигналом аварийной остановки.

[T-Rex]

Программа останавливается по факту срабатывания концевика.
С другой стороны концевики нормально разомкнуты,

Внесу поправку. В грамотно сконструированном станке концевики лимитов нормально замкнутые. Размыкаются при срабатывании.
Почему так? А чтобы обрыв провода концевика не мог остаться незамеченным.

[torvn77]

Да,вы правы,но у меня они нормально разомкнутые.
Хотя у меня совмещнный датчик home-limit.
Да и на один провод тогда концевики не собрать.

[T-Rex]

Да и на один провод тогда концевики не собрать.

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

[torvn77]

Так у меня то они трёхпроводные и питание с сигналом имеют один общий вывод,как их собрать последовательно?
(Какие со станком продали,такие и использую)

Сообщение отредактировал torvn77: 26 Апрель 2014 - 23:46

[T-Rex]

Так у меня то они трёхпроводные и питание с сигналом имеют один общий вывод,как их собрать последовательно?

Было бы желание - собрать все можно. Например, подключить к выходам датчиков оптопары (либо электромеханические реле), получив тем самым "сухие контакты". И эти "сухие контакты" уже группировать, как вашей душе угодно.

Частный случай - при использовании "нормально замкнутых" датчиков с выходом PNP выходной сигнал верхнего в цепочке датчика используют, как источник питания для следующего. Результирующий сигнал снимается с выхода последнего датчика. Ограничение - нагрузочная способность датчика должна быть не меньше, чем сумма токов, потребляемых всеми последующими датчиками в цепи (на практике так можно соединить два, максимум три датчика). На датчиках с выходом NPN такой вариант "монтажного ИЛИ" не прокатит.

Да, я знаю, что китайцы во всех дешевых станках используют "нормально разомкнутые" датчики, совмещают функции "Negative Limit" и "Home" в одном концевике, а "Positive Limit" вообще не ставят. Ради того, чтобы себестоимость станка была "на два чатла дешевле".

[3D-BiG]

Внесу поправку. В грамотно сконструированном станке концевики лимитов нормально замкнутые. Размыкаются при срабатывании.
Почему так? А чтобы обрыв провода концевика не мог остаться незамеченным.

Ну, это одно из религиозных верований разработчиков систем автоматики - ибо есть давний спор в этих кругах, какая ошибка критичней: отрыв сигнальной шины датчика от контроллера ,или закорачивание сигнальной шины на корпус оборудования, что частенько бывает при перетирании проводов, или при разлохмаченных концах провода.. Что-то в стиле: сможет ли всесокрушающее ядро сокрушить несокрушимую стену... Сколько ядер было на эту тему разбито, сколько стен проломано!!!!!
Кстати этих верований в Китае среди фрезеростроителей придерживаются только на заводах Руиджи - только на "ружьях" я и встречал нормальнозамкнутые датчики, на всех остальных, виденных мною станках, придерживаются более ортодоксального нормально-разомкнутого верования...
Зато нормально-разомкнутые датчики с выходом открытый коллектор для аварийного останова при всего одной шине этого останова гораздо удобнее использовать, т.к. они великолепно работают по схеме "контактное или"...

Да,вы правы,но у меня они нормально разомкнутые.
Хотя у меня совмещнный датчик home-limit.
Да и на один провод тогда концевики не собрать.

Так у меня то они трёхпроводные и питание с сигналом имеют один общий вывод,как их собрать последовательно?
(Какие со станком продали,такие и использую)

При одном совмещенном Номе-Limit, который работает по просадке напряжения до нуля как раз нормально разомкнутые датчики и используют: собираются все земляные провода (голубые), и подключаются на - питания и к общей точке контроллера, собираются все провода питания, и подключаются на + питания ( и обычно от этого питания запитан и контроллер, но не обязательно), собираются все сигнальные провода (черные) и через резистор в 1кОм, так называемый - подтягивающий - обычно наличивствует на входе грамотно сконструированного контроллера, если к нему можно напрямую подключать датчики, подключаются к питанию контроллера, а весь пук черных проводов - ко входу контроллера...
Работает примитивно просто: если Ни один датчик НЕ сработал, то подтягивающий резистор на входе контроллера держит высокий потенциал, т.е. на контроллере нет сигнала, но если хоть один из датчиков сработал, то открытый коллектор датчика притянет потенциал к земле, что вызовет срабатывание контроллера, что и требовалось получить... Такая схема поиска дома предполагает последовательный поиск дома для каждой оси и только из начального положения несработавшего ни одного датчика дома... Так обычно поступали на системах управления через PLT-порт для экономии пинов порта и в TurboCNC , и в Масh, и, похоже, в LinuxCNC ( тут torvn77 -у, как почитателю этой системы, лучше знать)..

Сообщение отредактировал 3D-BiG: 27 Апрель 2014 - 09:19

[torvn77]

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

[T-Rex]

Скорее всего,тут вопрос не столько в экономии пина,сколько в том,что одновременный опрос дома просто сложнее программировать,а экономия времени в итоге в сравнении с общим временем не большая.

Да не так уж сложно. Та же NCstidio еще с версии 4.5 имеет раздельные входы для X/Y/Z-limit и, насколько помню, ищет дом в два приема: сначала поднимает до датчика ось Z (это правильно - чтобы избежать столкновения фрезы с деталью или оснасткой), а затем ползет одновременно по X и Y. На станке с большим столом одновременное реферирование сразу двух осей вполне прилично экономит время (не то, чтобы это было критично, ведь при работе не каждые 5 минут "дом ищешь" - но душу греет, особенно торопыгам).

Ну, это одно из религиозных верований разработчиков систем автоматики - ибо есть давний спор в этих кругах, какая ошибка критичней: отрыв сигнальной шины датчика от контроллера ,или закорачивание сигнальной шины на корпус оборудования, что частенько бывает при перетирании проводов, или при разлохмаченных концах провода..

В моей практике всего раз был случай закорачивания провода на массу на входе в гибкий кабелеукладчик (безграмотный монтаж - концевое звено укладчика закрепили длинным болтом, который прогрыз изоляцию кабеля), один-два случая внутренних замыканий между жилами и десятки "просто обрывов".
Собственно, в европейских стандартах это религиозное верование закреплено. Попробуй-ка найти "safety controller" (Pilz, Preventa и т.п.), у которого цепь безопасности построена по схеме "normal open"... не бывает таких.

[Menu/Exit]

Собственно, в европейских стандартах это религиозное верование закреплено. Попробуй-ка найти "safety controller" (Pilz, Preventa и т.п.), у которого цепь безопасности построена по схеме "normal open"... не бывает таких.

Люди вообще страшно консервативны, особенно разработчики нового.
На лазерах, фрезерах, плазмах голова всегда стоит спереди портальной балки.
Привычно, видно и вообще так придумано до нас.
Мы когда лазерный станок модернизировали, решили лазерный источник развернуть, ну что бы они все пуляли слева-направо, и соответственно у всех станков - верная сторона одна и та же. Проще привыкать и вообще. Единообразие - мать матерей красоты и порядка.
Вот на станке балку перекинули и голова стала ездить за балкой.
Так столько неожиданных плюсов открылось:
1. ни один мудвин в луч не залезет - балка лазерный луч закрывает.
2. уменьшился вынос консолей зеркал, уменьшилась вибрация, стал лучше рез.
3. уменьшился габарит оптического хода - луч лазера стал находится в габарите перемещателя, а не вне его.
4. упростились крепежи зеркал и регулировка, + ещё кое что по мелочи.

Когда на производство попадал кто то из разработчиков, все говорили "Но так же никто не делает!!!"
На что им всегда отвечали: "Ну мы то этого не знали,что так нельзя!!!"

[3D-BiG]

....
В моей практике всего раз был случай закорачивания провода на массу на входе в гибкий кабелеукладчик (безграмотный монтаж - концевое звено укладчика закрепили длинным болтом, который прогрыз изоляцию кабеля), один-два случая внутренних замыканий между жилами и десятки "просто обрывов". Собственно, в европейских стандартах это религиозное верование закреплено. Попробуй-ка найти "safety controller" (Pilz, Preventa и т.п.), у которого цепь безопасности построена по схеме "normal open"... не бывает таких.

А в моей практике были случаи, когда СОЖ (водная эмульсия) при разбрызгивании попадал на провода концевиков и так сдиффундировал в них, что концевики на выходе давали замыкание - кстати омроны!!! - после просушки стали работать без проблем, но вначале заменил их на новые и перепровел их другим путем, да, вдобавок через пластиковую гофру, в которую направил отработку одного пневмопривода, что дополнительно осушало все внутри этой гофры - пока был доступ к станку - больше не повторялась проблема...
Если бы нормальнозамкутость датчиков была бы жесткая догма, то нормальноразомкнутые бы датчики не выпускались, но обычно их большинство..

[T-Rex]

А в моей практике были случаи, когда СОЖ (водная эмульсия) при разбрызгивании попадал на провода концевиков и так сдиффундировал в них, что концевики на выходе давали замыкание - кстати омроны!!!

Сдается мне, что все-таки это были китайские "омроны", а не Omron. В каких только гадостях у меня не купались кабели настоящих фирменных датчиков (включая постоянное нахождение в увлажняющей жидкости печатной машины или теплой "трансмиссионке" ISO VG 68) - токовых утечек не было. Разрушение изоляции лет через 5 работы ("задубевший" из-за вымывания пластификатора кабель, полимер становится жестким и хрупким) - было, да...

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

Потому что в задачах общей автоматизации в основном они и востребованы. Там же зачастую "прямая логика" - доехала деталь по конвейеру до датчика, датчик напрямую (или через таймер) включил пневмоклапан сталкивателя...
А вот в релейной автоматике позиционирования (пример - автоматическая установка давления ракельного моста на трафаретной машине SPS Vitesse XP) - сплошь NC датчики. Там логика "обратная" - сигнал датчика дает разрешение продолжать работу сервопривода, опускающего ракель.
Но, в то же время - полным-полно 4-проводных датчиков, у которых сразу оба выхода, "NO" и "NC" (по европейскому стандарту это черный и белый провода в кабеле, при этом коричневый - питание и синий - общий). Как говорил Винни-Пух, "это ж-ж-ж неспроста"...

[torvn77]

pik в личку написал:

скорости подачи не соотв. забитой при настройке. Вводил скорости которые эксплуатировал на Mach, для Y например 50 мм/сек, а по факту на ручной подаче едет на порядок медленней. А при выставлении на ноль скорость вообще практически никакая, он с такой скоростью её несколько часов только на ноль выставлять будет, подскажите пожалуйста где задаётся скорость выставления на ноль ?

По стандарту в gcode,а значит и в LinuxCNC,как его реализации,подача забивается в расчёте на минуту,то есть в мм/мин.
С другой стороны вы могли поставить неоправданно большой Base Period,
вам надо его уменьшить и перенастроить скорости на вкладках настройки скоростей.

Так же проверьте положение ползунка feed owerrid в главном окне программы,он должен быть в положении 100%,
мало ли,потянули его из любопытсва и забыли..
Поэтому проверьте и положение его соседа spindle owerrid

Если не поможет то запакуйте папку ~/linuxcnc/config в архив и добавьте в сообщение в качестве вложения,
я гляну на ваши настройки.

[pik]

Скорость выставления на ноль нашёл. Base period настраивал как в руководстве, в качестве нагрузки запускал фильм высокого разрешения получил 13 364, но при загрузке программы появилась ошибка о недостаточности этого периода и я его постепенно поднял до 25 000 после чего ошибка появятся перестала. Это много ? Cудя по интерфейсу подача забивается в мм/сек, в руководстве на илюстрации оси X 55.5 mm/s и я её забивал из расчёта на мм/сек соотв. 50 мм/сек. А на самом деле это 50 мм/мин чтоли ?

[torvn77]

Значение базового периода не настолько большое чтобы так ползать,как вы описываете.Метра на два с половиной хватить должно.

В мастере значения действительно ставятся в секундах.

Попробуйте пошевелить станок стрелками на клавиатуре,скорости тоже будут не большие?

Нажав F5 перейдите в консоль MDI и наберите там
F2000
G0X0Y0
G1 X100

Станок должен отъехать вправо на 100 мм с подачей 2000 мм /мин,(то есть 2м за минуту.)

какая скорость у вас отображается при движении на экране?

Если что не так,сделайте скрин окна Basic Machine Configuration и окна X-Axis Configuration

Скорее всего что-то напутано в последнем

Сообщение отредактировал torvn77: 28 Апрель 2014 - 16:26

[pik]

Почитав сообщение пошёл в гараж "шевелить стрелками" так что пока не выполнил инструкции добавленные редактирование сообщения.
Но пока узнал:
Что скорость перемещения стрелками и мышкой на интерфейсе, визуально одинакова (на экране не обратил внимания). Забитые мной 10 мм/сек скорость поиска ноля, визуально так и ищет.
Дабы узнать реагирует ли программа на изменения параметра скорости увеличил (на оси Y) скорость с 50 до 100 мм/сек заметного эффекта не получил, увеличил до 500, эффект сразу заметен, визуально 50-60 мм/сек. При этом обнаружил, для меня непонятную, взаимосвязь. При выставлении этого гипертрофированного значения по Y скорости остальных осей (никак не редактируемых) увеличиваются, и визуально похожи на заданные. Изменение параметра на 50 и снова на 500 подтвердило зависимость, скорости падают (50) и снова увеличиваются (500). Повторил эксперимент выставив 500 на оси X и получил тот же эффект, увеличение скорости по Y и Z. Аналогично по Z.
скопировал config http://yadi.sk/d/s4UjwgH5NWS8E

Начало УП

T1M6
G0Z76.002
G0X0.000Y0.000S2400M3
G0X0.001Y0.001Z76.002
G1Z0.000F180.0
G1Y0.108F2520.0
Y399.999
X0.076
X0.151

Прикрепленные файлы

•  configs.rar   4,69К   490 скачиваний

Сообщение отредактировал torvn77: 28 Апрель 2014 - 19:25

[torvn77]

я буду некоторое время занят,вы еще сюда УП положите.
(Если перейти вмрасширеный режим редактирования сообщения то файлы можно и нужно грузить прямо на форум

[pik]

УП http://yadi.sk/d/eLTjGTjfNWwb4
файл не проходит по размеру (архив тоже).
Я, проверяя скорость, УП не загружал. Просто F1, F2, ручная подача. Вроде, по аналогии с mach, на скорость не должно влиять ?

[torvn77]

В УП обработка идёт на 2,52 м/мин.

G0X0.000Y0.000S2400M3
G0X0.001Y0.001Z76.002
G1Z0.000F180.0
G1Y0.108F2520.0

Единственно скорость шпинделя 2400 об/мин подозрительно низкая,вы бы хотябы тысяч 10~11 сделали.
Попробуйте её запустить(только на всякии случай инструмент из шпинделя достаньте)
Сейчас буду смотреть конфиги

Сообщение отредактировал torvn77: 28 Апрель 2014 - 19:20