Страница 3 из 7

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 11:34
aftaev
mycnc, так что будет ответ откуда инфа что Hypertherm не будет использовать стойки Fanuc Siemens из-за неправильного пуска и из-за этого ни потерял рынок?
mycnc писал(а):Вот тут понятно, что Koike и видно, какая стойка.
И что это значит? Что на моем видео не видно стойку Фанук? Идем по моей сцылке и там в описание сказано: 8'8" x 43' Koike, MYNUC 4000D, Fanuc 15M, Plasma Bevel Head (2006),275 Amp Plasma
Вбиваем название станка в поисковик и находим http://www.surplusrecord.com/cgi-bin/adpop.pl?722389
01.jpg (3122 просмотра) <a class='original' href='./download/file.php?id=74350&mode=view' target=_blank>Загрузить оригинал (122.75 КБ)</a>

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 11:47
aftaev
mycnc писал(а):Просто ради интереса - покажите мне хотя бы одну плазменную машину с Fanuc.
У Fanuc есть такое: Fanuc Arc Mate

FANUC cерия Arc Mate. Роботы FANUC серии ArcMate предназначены специально для автоматизации сварочных процессов TIG, MIG, MAG, WIG. Также они прекрасно подходят для выполнения плазменной резки, лазерной резки и сварки.

Или робот - это не плазменная машина и резать сталюку ей нельзя?

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 11:57
aftaev
mycnc писал(а): Именно поэтому они потеряли рынок машин плазменной резки.
Мировые лидеры - Hypertherm, Kjellberg, Thermadyne, Esab, Lincoln, Messer, Koike, Multicam - не используют стойки Fanuc Siemens.
Видать они http://www.ebay.com/itm/Fanuc-Plasma-Cu ... SwFqJWnrRZ не знали страшной тайны которую ведает только mycnc и прилипендили HYPERTHERM на робота который управляется Funuc :)

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 12:13
torvn77
aftaev писал(а):и прилипендили HYPERTHERM на робота который управляется Funuc
(Это надо читать с юмором)
Управление роботом надо полагать намного сложнее, чем управление простым портальным станком?
Это и определило выбор в пользу Fanuc не смотря на наличие в нём такого значимого недостатка, как не запуск шпинделя после выхода из паузы.

А вот это я уже пишу серьёзно:
По моему весь этот скандал с примерами и контрпримерами есть следствие того, что гибкость управления выполнения Gcod'a стала меньшей, чем гибкость LinuxCNC в целом.
По этому надо не спорить о том, запускать шпиндель после выхода из паузы или нет, а подумать о том как сделать интерфейс более настраиваемым под нужды пользователя.

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 12:47
aftaev
torvn77 писал(а):Управление роботом надо полагать намного сложнее, чем управление простым портальным станком?
У MasterCam есть примочка Robomaster. Делаешь обработку в САМ программе для 3-5ти осей, и через Robomaster конвертируется в 6 сей робота ;)
torvn77 писал(а):Это и определило выбор в пользу Fanuc не смотря на наличие в нём такого значимого недостатка,
Если mycnc написал что там чавото нет и из-за этого они типо потеряли рынок, это еще не значит что оно так и есть пока не будут доказательств от mycnc. Я считаю это очередной выдумкой от mycnc.

Лазерные станки по принципу работы схожи с плазмой. Fanuc ставят на лазерные портальники(виде ниже). У лазера так же нужно менять расходники, чистить сопла, и бывают так же как у плазмы не прорезы. И тогда нужно вернуться назад и прорезать заново. И наверно Fanuc мировой лидер в ЧПУ с многолетним опытом, не может сделать паузу тип как нужно :idiot:

Звонил в Москву в Сименс (когда нужно было ставить много ЧПУ на токарные станки). В поддержке объяснили что если что то не устраивает в стойке Сименса, за не большую плату могут дописать. Если нужна не тривиальная какая нибудь кинематика или задача хитрая и силами программистов в Москве не решить, сделают это в ЕС. Не было задач которые нельзя было решить.

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

https://www.youtube.com/watch?v=ZFlYUBz ... SXe3YPw-Y3

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 13:24
torvn77
aftaev писал(а):а не одну как мы привыкли. Все это ради безопасности согласно каким то хххххх стандартам.
Ну и пусть себе следуют этим стандартам, LinuxCNC опенсорс и собственно не ЧПУ, а тулкит для его построения, по этому дать возможность делать свой вариант выхода из паузы и пусть каждый пишет так, как сочтёт нужным.

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 13:46
Serg
verser писал(а): всё же, функция ручного управления во время паузы актуальна.
А тут кто-то против? :)
torvn77 писал(а):дать возможность делать свой вариант выхода из паузы и пусть каждый пишет так, как сочтёт нужным.
Так делай как хочешь на своём станке. Кто против?

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 14:06
torvn77
UAVpilot писал(а):Кто против?
Вы против, при чём не только отказываетесь вносить нужные изменения в исходный код LInuxCNC, но и активно противодействуете соответствующему обсуждению в этой теме.
UAVpilot писал(а):Так делай как хочешь на своём станке.
В текущем виде для того чтобы настроить выполняемые при начале и в конце паузы действия надо изменять исходный код axis и помимо того, что для этого нужна квалификация программиста, так ещё и придётся её исходный код менять, что порушит получение актуальных обновление до актуальной версии.
По этому уже несколько человек в теме вас просят законтрибъютить в исходники LinuxCNC средства для определения своих обработчиков входа и выхода из паузы.

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 14:16
nkp
извиняюсь,что отхожу от линии словесных баталий... :thinking:
смешались в кучу кони , люди))
в начале темы - "остановить программу"...
как "остановить"??
стоп-поперемещались_куда_то-возобновить_с_такой_то_строки ??
или
пауза-поперемещались_куда_то-продолжить ??
как бы две (не)больших разницы))
что первый ,что второй вариант в емс "не доделан" , по субъективным(просто никто не доделал))), и
объективным причинам :
емс - просто "рыба"для всевозможных станков,и учесть все запросы просто невозможно
(я вообще считаю ,что многие слабые места в емс именно из-за попытки его универсализировать(есть такое слово?)))
но родители емс дали hal,как гибкий инструмент для желающих(есть желающие?))
итак есть два пути - через хал ,и встроить "внутрь" емс...
ссылки по наработкам уже давались:
http://www.cnc-club.ru/forum/viewtopic. ... =60#p55495
и еще так и не определились - что это такое ,как работает ,и какое практическое применение:
http://www.cnc-club.ru/forum/viewtopic. ... 8&p=204738

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 14:24
michael-yurov
torvn77 писал(а):
UAVpilot писал(а):Кто против?
Вы против, при чём не только отказываетесь вносить нужные изменения в исходный код LInuxCNC, но и активно противодействуете соответствующему обсуждению в этой теме.
Действительно, UAVpilot!, у тебя совесть есть! :hehehe: :pssdoff: :lol:
Ты почему отказываешься вносить правки в чужую программу?

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 14:38
aftaev
Надо UAVpilot обязать это сделать, народ и партия требует :lol:

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 14:44
torvn77
nkp писал(а):но родители емс дали hal,как гибкий инструмент для желающих(есть желающие?))
Не следует всё решать через hal то, что можно решить улучшением интерпретатора.
Ну или сначала сделать в Gcode реализацию именных DIO и AIO, а в halui именных пинов для каждой MDI команды.
Без этого активное взаимодействие Gcode программ и hal'a будет трудоёмко и приводить к опасным ошибкам в программировании.
nkp писал(а):емс - просто "рыба"для всевозможных станков,и учесть все запросы просто невозможно
ИМХО реализация сделанного мной предложения устроит значительную часть из тех, кто хочет его осуществления.
Изложил я его здесь: Re: Решен ли вопрос умного продолжения работы? #10
nkp писал(а):ссылки по наработкам уже давались:
Недавно обнаружил что теперь во время выполнения программы отдавать команды setp через halcmd нельзя.
Понадобилось мне это как раз для организации паузы с памятью, сделать я её думал так,
в постпроцессоре в секции PLUNGE я вместо вызова G00 сделал вызов gcode функции sys.plunge_move ну или как то иначе назвал, не суть , не помню.
Так вот, у меня был сигнал в hal без источника, и в зависимости от его значения программа вставала или снималась с "паузы", вызывая функцию обработчик джойстика.
План рассыпался на том, что во время выполнения УП команды отдаваемые через halcmd не выполнялись, ну а панели естественно блокировались тоже.
Ну и смысл то в упомянутых вами предложениях если органы управления ими блокируются?
Или аппаратную клавиатуру делать?

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 14:46
Serg
aftaev писал(а):Надо UAVpilot обязать это сделать, народ и партия требует :lol:
Собирайте пока "обязательства"... :)
torvn77 писал(а):Вы против, при чём не только отказываетесь вносить нужные изменения в исходный код LInuxCNC, но и активно противодействуете соответствующему обсуждению в этой теме.
:idiot:
Могу только посоветовать перечитать тему, чтобы осознать кто против чего...

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 14:59
nkp
torvn77 писал(а):Не следует всё решать через hal то, что можно решить улучшением интерпретатора.
аргументация ??
torvn77 писал(а):Недавно обнаружил что теперь во время выполнения программы отдавать команды setp через halcmd нельзя.
а как же "setp через halcmd" вставленные в пользовательские M коды?? отсегодня тоже не выполняются?
ну наверно это временно:
сегодня(и особенно завтра выполняются лишь Ж-коды
и никак не М-коды
причины столь чудных мартовских метаморфоз сокрыты под толщей пыли исторической :)

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 15:16
torvn77
nkp писал(а):а как же "setp через halcmd" вставленные в пользовательские M коды?? отсегодня тоже не выполняются?
Источник сигнала в данном случае оператор станка решивший поставить его на паузу.
Ну и сами понимаете, вставить M код на ходу может.

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 15:20
nkp
UAVpilot писал(а):Собирайте пока "обязательства"...
наверно нейрохирурги (или кто там по "плискам мозга головного"))подсказали бы точней, но
при наличии некоторого количества "обязательств" и мозг работает гораздо активней))
не знаю - могут ли ученные объяснить взаимосвязь такую :thinking:

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 15:28
nkp
torvn77 писал(а):Источник сигнала в данном случае оператор станка решивший поставить его на паузу.
Ну и сами понимаете, вставить M код на ходу может.
как тебе удается "отлавливать" так часто баги в емс??
надеюсь - ты сам их не генерируешь??
==============================
давай на человеческом языке повторим ситуацию:
работает емс(кстати - какя версия?)
выполняется программа (Ж-коды)
мы ,из консоли даем команду:

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

halcmd setp halui.program.pause 1
и ничего не происходит? в терминале не ругается никак?
я правильно смоделировал задачу?

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 15:42
torvn77
UAVpilot писал(а):Могу только посоветовать перечитать тему, чтобы осознать кто против чего...
Пожалуйста:
UAVpilot писал(а):Он изначально решён, правда "умным" должен быть оператор - перед стартом он должен будет подогнать фрезу в такое место, откуда она сможет не зацепив ничего по пути поехать в координаты кадра, который выбран для продолжения.
С точки зрения ваших оппонентов вопрос не решён.
UAVpilot писал(а):Да, оператор. Ибо только он знает надо-ли включать шпиндель, вдруг в нём стоит проводной датчик...
Почему все обязаны следовать этой методике работы?
UAVpilot писал(а):Я например обмериваю заготовку/деталь датчиком запуская специальную УП, и так-же как и все могу по какой-то причине в любой момент нажать "стоп" и потом захотеть продолжить... :)
Люди эгоистичны и хотят решить этот вопрос у себя, как он решон у вас в виду того, что ваше решение людей не устраивает никого не интересует.
UAVpilot писал(а):Разница только в ответственности за это. Хочешь взять ответственность на себя - программируй какие хочешь движения. Разработчики LinuxCNC видимо не хотят брать на себя такую ответственность.
Отказываетесь решать проблему.
UAVpilot писал(а):В случае плазмореза/лазера это легко реализуется логикой на HAL.
Но здесь речь не про плазморез/лазер, а про общий случай и про фрезер в частности.
Утверждаете что всё хорошо и ничего менять не надо, Но если это так, то почему этот тред появился.
UAVpilot писал(а):Мне не сложно и повторить:
UAVpilot писал(а):Ты прежде чем тут спорить и лепить плюсы кому попало попробуй понять, что я не против автоматизации частных случаев, я против автоматики, которая срабатывает всегда вне зависимости от условий.
Ну хорошо, предложенный мной в посту 10 вариант удовлетворяет этому требованию, вы даже что-то по нему отвечали, но не по главной сути этого предложения.
Re: Решен ли вопрос умного продолжения работы? #10
Re: Решен ли вопрос умного продолжения работы? #22
UAVpilot писал(а):Вот именно из-за этого 1% эту функцию не включают "по дефолту", а те остальные 99% кто пожелает этого, тот ССЗБ легко реализует её средствами того-же HAL.
UAVpilot писал(а):А тут кто-то против? :)
Социальный эгоизм элиты.
UAVpilot писал(а):Могу только посоветовать перечитать тему, чтобы осознать кто против чего...
Провоцируете переход этой темы в личные разборки, что же это как не прямой саботаж?

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 15:44
torvn77
Сергей Саныч, nkp, aftaev, nik1, UAVpilot, напишите, насколько вас устраивает то, что я предложил в уже упомянутых постах #10 и #22.
Конечно в самой простой реализации может терятся древо вызова суброутин, но раз мы это знаем, то можем предложить против этого меры, например отложить установку паузы до выхода из суброутины.

Re: Решен ли вопрос "умного" продолжения работы?

Добавлено: 07 мар 2016, 15:53
nkp
torvn77 писал(а):напишите, насколько вас устраивает то, что я предложил в уже упомянутых постах #10 и #22.
меня устраивает то ,что ты написал...
только как заставить таким образом работать емс?
давай по полочкам:
работаем по программе
при нажатии на паузу
нажали на паузу
программа отрабатывается до конца кадра,
ну ладно - это еще куда ни шло
вместо следующего кадра выполняется
вот тут вопрос - как же "выполняется" - мы же на паузе?
потом выполняется собственно код M2
мы же на паузе - как выполнить код м2?
и разблокируется ручное управление станком.
Оператор делает что ему надо и отжимает кнопку паузы обратно,