cnc-club.ru

Argentum47 писал(а): Рядом со станком страшно стоять когда в программе есть постоянная скорость.

Почему?

Evgen91 писал(а):

Argentum47 писал(а): Рядом со станком страшно стоять когда в программе есть постоянная скорость.

Почему?

Потому что к центру заготовки пятитонный станок уже прыгать на 3500 начинает.

Argentum47 писал(а):Потому что к центру заготовки пятитонный станок уже прыгать на 3500 начинает.

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

Argentum47 писал(а):Рядом со станком страшно стоять когда в программе есть постоянная скорость при отрезе

Она же включается и отключается G-кодами. Соответственно отключи ее при отрезе.И включай только там где надо прямо программой.

Ваши бы слова да нашему наладчику в уши, я тогда на первом своём станке работал и что такое ЧПУ знал всего полгода, пластина калёную 40Х отрезала плохо, ну он пришёл, дописал код и ушёл, сказав работайте, мы включили и во время отреза чуть не обосрались, потом ограничил обороты до 2700. С тех пор я не доверяю станки на которых работаю кому-то ещё. Всем этим технологам, наладчикам, механикам и слесарям плевать чё там после них будет.

Taganrog писал(а):Соответственно отключи ее при отрезе.И включай только там где надо прямо программой.

Нужно задать макс. обороты.
G96, G97 Spindle Control Mode
G96 <D-> S- (Constant Surface Speed)
G97 (RPM Mode)

D - maximum spindle RPM
S - surface speed
http://linuxcnc.org/docs/2.6/html/gcode ... 97-Spindle

aftaev писал(а): Нужно задать макс. обороты.
G96, G97 Spindle Control Mode
G96 <D-> S- (Constant Surface Speed)
G97 (RPM Mode)

D - maximum spindle RPM
S - surface speed
http://linuxcnc.org/docs/2.6/html/gcode ... 97-Spindle

На Фануке оно задавалось параметром самой команды постоянной скорости реза, да не суть, осторожно надо просто с такими вещами.

Крайняя общедоступная 2.4 - дефекты визуализации 3d. (смотрим на поверхности, свободные от рельефа - там тоже есть свой, "паразитный" рельеф)
Оно, конечно, совсем не критично.

Потеря связи - опять. Отчёт сниму, когда доделается изделие (если это поможет, может быть, нужно снимать отчёт сразу после сбоя). Сбрасывается счётчик времени после сбоя - и "сколько прошло от начала работы", и "сколько осталось до завершения". После устранения сбоя и запуска работы на продолжение счётчики на нулях оба, "прошло от начала работы" считает, естественно, а "сколько осталось до завершения" на нулях. Как оценить оставшееся время до конца работы? Сделайте, пожалуйста, чтобы счётчик не сбрасывался. И ещё, счётчик постоянно врёт. Я задамся целью, сделаю подборку, выведу процент - насколько он врёт.

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

на мой взгляд - безсистемно сбои происходят. Перед фактом сбоя - никаких "шевелений/задеваний/тряски" проводов случайно/специально; никаких запусков 40 кВт движков рядом и т.д. и т.п. Конфигурация оборудования и набор софта одинаков и не меняется. За компом ничего не делается, когда идёт работа со станком. Сегодня, например, сбой вылетел буквально сразу, как только нажал в PM кнопку включения станка. Потом более 3х часов нормальной работы. Затем, где-то в первый час второй трёхчасовой работы - снова сбой.

Стабильность, чё...

Prav писал(а):Стабильность, чё...

Ради справедливости, отмечу, что сбои очень нечастые. С крайнего обновления, после 09.01.2019, ловил их не более 10 раз... А работает станок с конца января - по 4-5 дней в неделю, бывает и по 5-7 часов.

StavRos писал(а):Потеря связи - опять.

Да, присылайте логи, посмотрим.

StavRos писал(а):Сбрасывается счётчик времени

Принято, подумаем.

StavRos писал(а):И ещё, счётчик постоянно врёт.

А вот тут поймите правильно - невозможно точно рассчитать "в уме" время выполнения УП в железе, т.к. там в процессе работы профиль разгона и торможения считается на лету в зависимости от очень многих факторов. То время до завершения, которое выдает программа носит лишь оценочный характер.
PS: Просьба не дублировать одни и те же сообщения на различных форумах. Это добавляет нам лишней работы, т.к. оставлять сообщение без ответа не очень правильно, а отвечать на одни и те же заявки во всех форумах сразу - это бесполезная трата времени.

pm_dev писал(а): Да, присылайте логи, посмотрим.

Выслал.

pm_dev писал(а):А вот тут поймите правильно - невозможно точно рассчитать "в уме" время выполнения УП в железе, т.к. там в процессе работы профиль разгона и торможения считается на лету в зависимости от очень многих факторов. То время до завершения, которое выдает программа носит лишь оценочный характер.

Понял, принял, простил

pm_dev писал(а):PS: Просьба не дублировать одни и те же сообщения на различных форумах. Это добавляет нам лишней работы, т.к. оставлять сообщение без ответа не очень правильно, а отвечать на одни и те же заявки во всех форумах сразу - это бесполезная трата времени.

Понял, исправлюсь

В копилку хотелок:
- добавить возможность отсылки на е-мейл сообщений об ошибках программы во время работы (потеря связи, например)
- изменить алгоритм поведения при обнаружении потери связи (сейчас станок принудительно отключается) - чтобы питание не отключалось, это нужно, чтобы координаты не сбивались (для программы они не сбиваются, конечно, и можно продолжить выполнение кода с места остановки, но, по-факту, на изделии потом остаётся "ступенька", небольшая, но неприятная, видная глазу полоска; считаю, что это вызвано как раз тем, что фактически координаты, в частности, Z, немного "уходят" и в момент включения станка после потери связи истинные координаты отличаются от тех, которые запомнила программа) - всё описанное актуально для меня, возможно, ни у кого таких проблем более и нету...

StavRos писал(а): добавить возможность отсылки на е-мейл сообщений об ошибках программы во время работы (потеря связи, например)

Так это есть уже. При формировании запроса в техподдержку система сама предложит Вам отправить отчет при условии, что в системе установлена почтовая программа.

StavRos писал(а):изменить алгоритм поведения при обнаружении потери связи

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

pm_dev писал(а):Так это есть уже. При формировании запроса в техподдержку система сама предложит Вам отправить отчет при условии, что в системе установлена почтовая программа

Вы неправильно меня поняли. Нужна (мне) возможность автоматического уведомления на мой е-мейл о факте сбоя. Это полезно, считаю. Как пример, далеко ходить не нужно - сегодня опять "потеря связи" (лог в поддержку отправил). Станок стоит в кладовке, за закрытой дверью. Я сижу в комнате, занимаюсь своими делами, например. Произошла потеря связи, станок остановился, а я об этом же не знаю. Изредка заглядываю, контролирую работу. В этот раз станок простоял пол-часа после сбоя, пока я не заглянул в кладовку. Чистая потеря времени.

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

Факт того, что данные перестали поступать, программа отслеживает? Наверняка. Видимо, и знает о том, в какой точно момент времени эта "авария" произошла? Тоже, наверняка. Что стоит "отмотать" историю назад и начать чуть ранее места остановки? Именно с того места, где ещё не началось "уезжание по инерции". Если абсолютно точно нельзя определить этот момент, нужно возвращаться немножко заранее назад, с запасом. Опять же, что у программы такой буфер маленький, что она мгновенно теряется, если происходит потеря связи? Нужно, значит, встроить механизм "смотрим в код намного вперёд, знаем, что будет "за несколькими поворотами впереди", читаем код из "подсмотренного" куска, при потере связи у нас есть запас хода, данные же считаны уже, вот на этом куске и тормозим". Возможно, с точки зрения программистов, я тут чушь несу, но, по-моему, всё прозрачно. Далее, что мешает при такой "аварии" не вставать "колом" с выключением питания, а просто спокойно останавливаться (с учётом реализации вышеописанного механизма), питание не обрубать, а поднять шпиндель на безопасную высоту и только тогда его остановить (повторюсь - питание с ШД не снимать!). И сразу мейл послать - хозяин, беда, беги скорее ко мне

А если у Вас модуль PLCM завис? как он сможет управлять вашим станком? Может по этой причине и потеря связи

sivolap36 писал(а):А если у Вас модуль PLCM завис? как он сможет управлять вашим станком? Может по этой причине и потеря связи

Так это ж вопрос уже к разработчикам, не? И, разве ПО не видит, что контролёр себя не так как-то чувствует? Долго (по меркам ПО) не отвечает, не реагирует? Контролёр же - это механизм, как я понимаю? Сам он ничего без команды не делает, значит, управляет моим станком, всё же ПО (как и любое железо без софта - это просто бесполезный кусок "железки", так и ПО без железа - бесполезна; в связке же всё работать должно). В котором все мои описанные хотелки и можно реализовать, как я думаю

Я сильно боюсь, что реализация таких пожеланий вполне осуществима, но маркетинг скажет "стоять, эти фичи будут только в версии ПРО" Тогда для Purelogic это будет "фиаско, братан"