Что я еще не знал о LinuxCNC, что нам еще предстоит сделать

[torvn77]

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

Возвращаясь к Re: Что я еще не знал о LinuxCNC, что нам еще предстоит сдел #311
Вот я сейчас делаю суброутинус для установки нуля заготовки,вообще по уму надо бы предоставить выбор того,какая координатная система будет инициализироваться.
Для этого надо сделать конструкцию вида G10 L2 P#<cor_syst_num> ,а саму систему выбирать радиобутоном на панели управления.
Но вот как завести данные в суброутинус.
Конечно можно воспользоваться аналоговым вводом выводом,но мне это представляется неправильным.
Лучше бы УП имела в хала собственный пин,по которому и получала значения.

[Serg]

Вот я сейчас делаю суброутинус для установки нуля заготовки,вообще по уму надо бы предоставить выбор того,какая координатная система будет инициализироваться.

А почему в текущей это не делать?

[torvn77]

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

[Serg]

А чем плоха текущаяя, та, что в данный момент выбрана?..

[verser]

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

Именно потому что "запись в ini может называться иначе или просто отсутствовать", разработчики linuxcnc и придумали способ доступа к любым параметрам ini и hal, на который я дал ссылку 5-ю постами выше, и не создали ни одного "Predefined Named Parameters" для параметров из ini и hal .

[torvn77]

Вы меня не так поняли,я имел ввиду вот эти группы параметров:7.4. Predefined Named Parameters и 7.5. System Parameters.
То есть у меня просьба коли уж сделали <_x> ,то было бы хорошо к ним и софт лимиты добавить.
Может ещё и макс. скорость шпинделя и перемещения.

В данный момент мне понадобился лимит по Z для суброутинуса установки нуля материала,
Там получение офсетов надо делать в инкрементальном режиме,ну и станок с самого верха может ехать слишком долго.
А чтоб отправить почти от поверхности материала,надо уменьшать запрашиваемое перемещение.
Цикл while приводит к неоправданно большому числу ускорений и торможений,и опять таки медленный.

[verser]

Вы меня не так поняли,я имел ввиду вот эти группы параметров:7.4. Predefined Named Parameters и 7.5. System Parameters.

И я имел в виду именно эти группы параметров. Именно в них отсутствуют параметры из ini и hal, и не спроста.

В данный момент мне понадобился лимит по Z для суброутинуса установки нуля материала

А чем не устраивает уже имеющаяся возможность обращения к лимиту по Z так: #<_ini[axis_2]max_limit> ?

[Serg]

Подпрограмма всё равно ведь указывается в INI в MDI_COMMAND - почему-бы просто эти значения не передавать в виде параметров?
Например вот так:

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

MDI_COMMAND = O<touch-z> CALL [-280] [500] [34.67]

#1 - min-z, #2 - feed, #3 - z-probe height

[Nick]

А чем плоха текущаяя, та, что в данный момент выбрана?..

И вообще, обмеры ( по крайней мере обмер инструмента ) лучше делать в G53. С материалом по Z тоже самое G53 G0 Z... без смены системы координат.

[Сергей Саныч]

И вообще, обмеры ( по крайней мере обмер инструмента ) лучше делать в G53. С материалом по Z тоже самое G53 G0 Z... без смены системы координат.

Хорошо бы, хорошо, было бы конечно... только в G53, кроме G0, ничего не работает

[Serg]

Я ж и говорю: "текущая".
В любой системе координат запомнили текущее положение и коррекции, сделали что требуется и восстановили всё как было (если требуется).

[Nick]

И вообще, обмеры ( по крайней мере обмер инструмента ) лучше делать в G53. С материалом по Z тоже самое G53 G0 Z... без смены системы координат.

Хорошо бы, хорошо, было бы конечно... только в G53, кроме G0, ничего не работает

Правильно:

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

( сначала едем в )
G53 G0 Z0 
G53 X... Y...
( потом )
G91 
( делаем грязное дело )
G90
G53 G0 Z0 

PS можно еще g28 куда-нибудь запихать, но это по желанию.

[torvn77]

А можно файлы для подсветки синтаксиса сделать отдельным от LCNC пакетом?
А то я подключил к домашнему ПК репозитарий,LCNC не ставится из-за не совместимости с системой и
в результате мне приходится работать без подсветки синтаксиса.
И хотелось бы чтоб по мимо gdita вы делали пакеты и для его форков:в первую очередь Pluma,ну и для тех кто не подключат матовские репозитории medit.
(хуже Plum'ы,но зато самостоятельный проект и для его установки репозитории подключать не нужно)

Нашёл тему и поместил gcod.lang куда нужно,но всё же хотелось бы его ставить автоматом из пакета.
В Plume файл появился и заработал,в medit'e не появился.

И помоему выделять красным фоном команды окончания работы программы не правильно.
Если пишется суброутинус то они могут быть в нескольких местах и забивать собой восприятие текста.
В общем не удобно.

[torvn77]

Добавил в styles/classic.xml
<style name="def:varning" foreground="red" bold="true"/>
В gcode.lang внес изменения:
<language id="gcode" _name="Gcode" version="2.0" _section="LinuxCNC">
и
<style id="stopping" _name="Stopping" map-to="def:varning"/>
<style id="spindle-control" _name="Spindle-Control" map-to="def:varning"/>

Теперь красный квадрат мне глаза не режет.

[torvn77]

Только вот как сделать это технически?
Чтобы добавить инстанс к компоненту придётся расширить выделенную ему память под его данные (переменные и пины), просто так её не раздвинуть - будут мешать области данных других компонентов. Единственный способ - создать новую область большего размера и скопировать в неё станые данные. Засада в том, что в процессе копирования кто-то может записать новые данные (у нас ведь РТ) в ту часть старой области, которая уже была скопирована - т.е. эти данные в итоге будут потеряны.
Можно конечно изменить концепцию написания компонентов (полностью переписав их все) и за счёт некоторого ухудшения их быстродействия добавить возможность дозагрузки, но опять-же как быть с именами клонов?..
IMHO гораздо проше воспользоваться помощью make, grep, sed или просто вынести загрузку всех копонентов в один обий файл.

Может решить вопрос так,сделать обработку файлов hal двухпроходной?
На первом проходе собирать все loadrt в единый список,после чего загружать нужные компоненты.
А второй проход выполнять как обычный,но только игнорируя ранее выполненые команды loadrt.

[Serg]

я именно так и делаю, но мой способ почему-то вам не нравится.

[torvn77]

Вы предлагаете это делать мне с помошью sed и grep.
А я хочу чтобы это делалось интерпретатором файла hal,а не мной.
А проблему с именами клонов можно и не решать,для типовых решений "с двумя MPG" можно сделать свой шаблон.
За не типовые решения пускай платят деньги.
Мне важно чтобы я мог "продать" типовую в достаточной мере функциональную конфигурацию.

[Serg]

В чём проблема-то? Сделайте как нравится или предложите денег тому, кто сделает. Ведь

За не типовые решения пускай платят деньги.

[torvn77]

Это я к тому,что конфигурация будет модульной,и мне надо чтобы пользователь мог подключать модули командой source без дополнительного редактирования конфига.
А в существующем синтаксисе если в двух модулях будет два однотипных компонента,то их строки загрузки придётся объединять.
Не хотелось бы навичка потратившего на mesa 14,5 тыр грузить такой работой,а то напутает и будет просить найти ошибку.

[torvn77]

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