cnc-club.ru

cutmaster cm325 станок. Они долго упирались его ремонтировать, но недавно у них появился инженер, с которым я быстро договорился... Вот такие дела.
Были проблемы с охлаждением контроллера PLC330, были случайные не срабатывания станка на команды, врезал кулеры в крышку блока и эти болезни прошли.

уже второй случай перегрева пурелогиков на форуме...

Алексс писал(а):из дома решим

получилось усовершенствовать?

2cme писал(а):получилось усовершенствовать?

получилось добавить файлик с процедурой на github.

Здравствуй, есть несколько вопросов:
А как параметры вводятся в эти процедуры? (или как их добавить)
В какую папку вы сохранили эту подпрограмму?
Какой командой вы вызываете сканирование?
Как выполнить баш скрипт в системе? (или дайте ссылку на мануал по конструированию этих команд)
Заранее спасибо.

vadim063 писал(а):А как параметры вводятся в эти процедуры? (или как их добавить)

В эту процедуру пока не вводится ...
Хмм надо и правда добавить все эти параметры...
В общем добавил.

vadim063 писал(а):В какую папку вы сохранили эту подпрограмму?

Сохранять в папкус ngc_files

vadim063 писал(а):Какой командой вы вызываете сканирование?

теперь o<scan-surface> call [#<x0>] [#<y0>] [#<h>] [#<w>] [#<step>] [#<search_feed>] [#<latch_feed>] [#<safe_z>] [#<search_z>]
Все параметры обязательны!
Чтобы было удобнее можно сверху дописать:
#<h> = 90
#<w> = 90
#<x0> = 110
#<y0> = 90
#<step> = 20
#<search_feed> = 100
#<latch_feed> = 1
#<safe_z> = 3
#<search_z> = -3

vadim063 писал(а):Как выполнить баш скрипт в системе? (или дайте ссылку на мануал по конструированию этих команд)

Какой именно? тупо в консоле bash +имя скрипта, или если в скрипте вверху написанно
#!/usr/bin/env bash и есть права на исполнение, то можно выполнить просто имя скрипта.

Nick писал(а):Сохранять в папкус ngc_files

nc_files

наверное правильнее всего этот скрипт использовать с ngcgui.

Лучше всего в CAM которая Gкод для платы готовит написать... но это в идеальном случае

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

PS: А с отключенной картой высот сползание наблюдается?

Да, наблюдается. Спасибо за идею со счетчиком, сегодня попробую сделать из чего-нибудь)

vadim063 писал(а):Да, наблюдается. Спасибо за идею со счетчиком, сегодня попробую сделать из чего-нибудь)

Я правильно понимаю (поправте если ошибаюсь), что контроллеры для шаговых двигательно вы готовый приобретали?
В таком случае может купить готовое?

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

Оборудование: plc330 контроллер, 3 оси, двигатели на 3 ампера.
Симптомы: несмотря на все мои ухищрения ось делала пропуски шагов стабильно в одну сторону, в результате чего получался брак. Чтобы точно определить причину я стабилизировал питание, перебрал кучу адаптеров-переходников, перебрал несколько компьютеров, заменил контроллер.
Причины: в связи с развитием принтеров, в которых производители начали ставить протоколы коррекции ошибок, производители материнских плат и PCI LPT адаптеров начали экономить и нагло халтурить. Проблема в том, что станок принимает любой сигнал, насколько кривым бы он не был, и вся эта кривизна вылезает в виде брака. Бытует мнение что в материнских платах с встроенным лпт портом, но это, к сожалению не так.

У меня были в распоряжении шустрый неттоп двухядерный с PCI PLT переходником, десктоп на материнке st-2001 700мгц 512ОЗУ, одноядерный комп с процом на 2.7ггц 1гб озу с внешней и интегрированными видеокартами (LPT порт на материнке был).

В итоге- EMC2 корректно работал на мощных компьютерах, но плохо вставал на самую слабую машину. Я попробовал ВСЕ диски, размещенные на сайте cnclinux, и в итоге смог-таки поставить убунту8 на слабый комп, путем временного подключения жесткого диска к более мощному собрату.
Первой проблемой были полосы на экране EMC2 после запуска, но эта проблема исчезла после обновления. Обновляться можно смело, главное не выполнять команду grub-update, т.к. это повлечет за собой выключение ядра реального времени и лишит вас сна еще на 3-4 часа....
Второй проблемой стало то, что конфиги старой EMC2 имели несколько другую структуру, и мне пришлось выполнять все калибровки вручную, чтобы все заработало. Банальное копирование конфига или приводило к феериям из ошибок или к глюкам вроде не включающегося шпинделя.

Решение:
1)Находите фотографию материнской платы, внимательно смотрите и ищете на ней чип winboard. Если он есть, все будет работать нормально.
2) выключаете любое энергосбережение в биосе компьютера
3) несколько раз убедитесь что вы правильно настроили длительности фронтов импульсов, что вы правильно вбили джиттер и у вас правильно установлен base_period

Всем желаю удачи. Спасибо форумчанам за помощь в настройке

vadim063 писал(а):Причины: в связи с развитием принтеров, в которых производители начали ставить протоколы коррекции ошибок, производители материнских плат и PCI LPT адаптеров начали экономить и нагло халтурить. Проблема в том, что станок принимает любой сигнал, насколько кривым бы он не был, и вся эта кривизна вылезает в виде брака. Бытует мнение что в материнских платах с встроенным лпт портом, но это, к сожалению не так.

На осцилограмме можете сравнить сигналы?

формы импульсов не отличаются в 99.9% случаев. отловить косяк даже на цифровом осциллографе будет очень сложно, без использования энкодеров (их у меня нет).
суть искажения - если долго включен импульс DIR, то дешевый микроконтроллер порта lpt с некоторой вероятностью включает что то вроде спящего режима для этой ноги. Только этим объясняется сползание фрезы каждый раз в одних и тех же местах (при наличии исправной программы и механики).

vadim063 писал(а):отловить косяк даже на цифровом осциллографе будет очень сложно

спасибо, расмешили...

vadim063 писал(а):Только этим объясняется сползание фрезы каждый раз в одних и тех же местах (при наличии исправной программы и механики).

Другми словами все выше (сообщение 454) сказанное это гадание на кофейной гуще???

Ну у меня цифровой осциллограф тектроникс и он может сделать на нужной частоте сделать запись не более 30 секунд входного сигнала, а программа выполняется 4 часа и никакого детектора, срабатывающего на сползание оси в распоряжении нет. Я делал счетчик импульсов на ардуино и он мне в итоге отобразил эту разницу. количество импульсов писал в буфер и выводил на комп в терминал раз в секунду. количество step импульсов всегда было одним и тем же, а dir импульсы терялись.

vadim063 писал(а):Ну у меня цифровой осциллограф тектроникс и он может сделать на нужной частоте сделать запись не более 30 секунд входного сигнала, а программа выполняется 4 часа и никакого детектора, срабатывающего на сползание оси в распоряжении нет.

Достаточно создать крохотный Gcode на котором ярко будет проявляться предполагаемый глюк.

vadim063 писал(а): Я делал счетчик импульсов на ардуино и он мне в итоге отобразил эту разницу. количество импульсов писал в буфер и выводил на комп в терминал раз в секунду. количество step импульсов всегда было одним и тем же, а dir импульсы терялись.

На всех осях (X Y Z) такая картина?
Всеравно непонятно, если затык в железе LPT (vadim063, по твоим дедуктивным умозаключениям), то почему другие с этим "эффектом халтуры на железе" не сталкивались?

2cme писал(а):почему другие с этим "эффектом халтуры на железе" не сталкивались?

Я сталкивался. Только это давно было, в начале 90-х. Делал что-то, кажется, программатор для СППЗУ, с интерфейсом LPT.
И он у меня шизовал, как только мог, хотя, казалось бы, все сигналы были в норме. С контроллерами LPT других производителей проблем не было - благо в тех компьютерах все втыкалось в шину ISA.
А с тем контроллером я все-таки разобрался. Оказалось, что в момент записи в регистр данных (3F8) единичек, на выходах на короткое время появляется нулевой импульс длительностью, примерно равной сигналу WR шины (доли микросекунды). На эту помеху и реагировала моя схема. Я уже не помню, чьи контроллеры так отличились - но было.
Причем эффект проявлялся, естественно, только при записи двух и более единиц подряд. При нулевой последовательности, или, скажем, при записи 0101001010001... "провалы" присоединялись к ближайшему нулю и ни на что особенно не влияли.
В конце концов пришлось поставить RC-цепочки и триггеры Шмитта.
А насчет "спящего режима" на отдельных ногах - это вряд ли. Энергосбережение в ЧПУшных компьютерах нужно выжигать каленым железом, это да, но по другим причинам.
Кстати, правильно включенные транзисторные оптопары могут служить неплохим фильтром такого рода помех. За счет своей инерционности.

Serg-tmn писал(а):В конце концов пришлось поставить RC-цепочки и триггеры Шмитта.

Я изначально поставил триггеры Шмитта 74hc14, работает стабильно.

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

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