cnc-club.ru

Nick, то я что-то ночью наверно не доглядел.
фильтр заработал корректно. станок упорно затыкается в месте встречи первого U или W

Можно сделать так, чтобы от одного пина могло исходить несколько сигналов
Вот например я сделал hal

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

#-----------Альясы(линки) с пинов input.N.btn- на номер кнопок.
#             Вообще такое впечатление,что компонент input не правильно сопостовляет кнопки джойстика и их название.
#             Лучше бы он их просто нумеровал
net gamepad.func_button_1-raw <= input.0.btn-joystick 
net gamepad.func_button_2-raw <= input.0.btn-thumb 
net gamepad.func_button_3-raw <= input.0.btn-thumb2
net gamepad.func_button_4-raw <= input.0.btn-top 
net gamepad.func_button_5-raw <= input.0.btn-top2
net gamepad.func_button_6-raw <= input.0.btn-pinkie
net gamepad.func_button_7-raw <= input.0.btn-base 
net gamepad.func_button_8-raw <= input.0.btn-base2 
net gamepad.func_button_9-raw <= input.0.btn-base3 
net gamepad.func_button_10-raw <= input.0.btn-base4
net gamepad.func_button_11-raw <= input.0.btn-base5
net gamepad.func_button_12-raw <= input.0.btn-base6 

#----------------Логика блокировки и переключения analog/continue режима кнопок
# Задание клавиш выбора через подключение к соответствующему сигналу
net gamepad.keymode-1 <= input.0.btn-pinkie
net gamepad.keymode-2 <= input.0.btn-base2 


net gamepad.keymode-1     => not.0.in
net gamepad.keymode-1-not <= not.0.out
net gamepad.keymode-2     => not.1.in
net gamepad.keymode-2-not <= not.1.out

# Если не нажата ни одна клавиша выбора или нажаты обе клавиши,то выполняется блокировка кнопок
# Если нажата только одна из клавиша выбора то выбирается соответствующий режим 
net gamepad.keymode-1     => and2.0.in0
net gamepad.keymode-2-not => and2.0.in1
net gamepad.select_keymode-1   <= and2.0.out
#
net gamepad.keymode-1-not => and2.25.in0
net gamepad.keymode-2     => and2.25.in1
net gamepad.select_keymode-2 <= and2.25.out

#----------------Button 1-------


net gamepad.func_button_1        => and2.1.in0
net gamepad.select_keymode-1     => and2.1.in1
net gamepad.func_button-1_mode-2 <= and2.1.out

net gamepad.func_button_1        => and2.2.in0
net gamepad.select_keymode-2     => and2.2.in1
net gamepad_func_button-1_mode-2 <= and2.2.out

Сигналы gamepad.func_button_6-raw и gamepad.keymode-1 имеют разный смысл и то что они исходят из одного пина,
кнопки джойстика есть следствие того. что мне удобно так, другой может сигнал gamepad.keymode-1 брать и их другого источника.
Конечно вопрос можно решить вплетя сигнал gamepad.func_button_6-raw в код, где осуществляется селекция режимов.
Но тогда уменьшится читаемость конфига.
Ну или как вариант вместо подсоединения нескольких исходящих сигналов к одному пину разрешить коннектить один сигнал к другому.

torvn77 писал(а):Ну или как вариант вместо подсоединения нескольких исходящих сигналов к одному пину разрешить коннектить один сигнал к другому.

И в каком направлении должно будет передаваться значение?..

В соответствии с =>
Другое дело что надо программе объяснить что в правой части стоит сигнал. а не пин.
может опцию -s сделать.

Если же смотреть более обще, то формат записи команды net надо улучшить.
Потому что в некоторых случаях желательно упорядочить строки по пинам, а не по сигналам.
Ну понятно что машине без разницы, но мне читать было бы удобнее.
Если развивать аналогию с dd то можно сделать так:
Для пинов
net -s ggg -op ggg.iii -ip ddd.hhh
а для сигналов
net -is ppp -os gggg

torvn77 писал(а):В соответствии с =>

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

Да и тогда получится, что сигнал не аналог провода/соединителя, а одностороннего проводника. Т.е. нарушает один из основных принципов HAL.
И как тогда соединять пины IO? И как соединить сигналы, к каждому из которых уже присоединены пины OUT?

UAVpilot писал(а):Да и тогда получится, что сигнал не аналог провода/соединителя, а одностороннего проводника.

С этим проблем не будет, так как к второму сигналу будут подсоединены только входные пины.
По этому направления от второго сигнала к первому просто не будет.
По сути , так как сигнал просто является меткой, по которой определяется откуда входные пины будут брать значение,
операцию коннекта пинов можно понять как что и пины ещё и из этого списка (т.е. второй сигнал) будут брать значение, откуда берут пины первого.
Т.е. с точки зрения недр хала вообще ничего не поменялось, изменения касаются только утилит.
Хотя не совсем, при таком понимании сигналы нельзя будет расконектить, так как в хале они объединятся в один большой обычный сигнал.
Чтобы произвести процедуру разъединения где то надо будет хранить информацию о том, какие пины в состав какого сигнала входят.

в общем я предлагаю смотреть на сигнал как на список входных пинов.

UAVpilot писал(а):Т.е. нарушает один из основных принципов HAL.

То есть сейчас я могу подсоединить к одному сигналу два выходных пина?

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

names=gamepad.and2_01,gamepad.and2_02,gamepad.and2_03,gamepad.and2_04,gamepad.and2_05,gamepad.and2_06,gamepad.and2_07,gamepad.and2_08,gamepad.and2_09,gamepad.and2_10,gamepad.and2_11,gamepad.and2_12,gamepad.and2_13,gamepad.and2_14,gamepad.and2_15,gamepad.and2_16,gamepad.and2_17,gamepad.and2_18,gamepad.and2_19,gamepad.and2_20,gamepad.and2_21,gamepad.and2_22,gamepad.and2_23,gamepad.and2_24,gamepad.and2_25,gamepad.and2_26:
 can only take 16 arguments

Это крах моей идеи разбить конфиг на автономные модули.

Почему количество имён ограниченно только 16 штуками, есть возможность снять или расширить это ограничение?

torvn77 писал(а):То есть сейчас я могу подсоединить к одному сигналу два выходных пина?

я имел в виду то, что сигнал - это не полупроводник.
Расскажи лучше как тогда быть с пинами IO?

torvn77 писал(а):Почему количество имён ограниченно только 16 штуками, есть возможность снять или расширить это ограничение?

Это ограничение препроцессора, который делает .c из .comp, зато

torvn77 писал(а):с ними жизнь простая

UAVpilot писал(а):я имел в виду то, что сигнал - это не полупроводник.

Какая разница,чем он является если поток информации в нём однонаправлен:
от единственного выходного пина к множеству входных.

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

UAVpilot писал(а):Это ограничение препроцессора, который делает .c из .comp, зато

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

torvn77 писал(а):Какая разница,чем он является если поток информации в нём однонаправлен:

В третий раз повт орю неудобный вопрос, вдруг в этот раз не проигнорируешь его:

UAVpilot писал(а):Расскажи лучше как тогда быть с пинами IO?

torvn77 писал(а):А зачем он это делает

Затем, что тебе удобно не писать каждый раз кучу констант и определений на C и ты пишешь на псевдоязыке comp. Но кому-то эти определения всё равно надо вставлять в код, вот halcomple и вставлятет то, что считает нужным.

torvn77 писал(а):Зачем было ограничивать число циклов 16?

Разработчики посчитали это количество достаточным для большинства применений.

UAVpilot писал(а):Расскажи лучше как тогда быть с пинами IO?

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

torvn77 писал(а):в общем я предлагаю смотреть на сигнал как на список входных пинов.

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

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

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

torvn77 писал(а):Так с точки зрения нутра хала коннект двух сигналов выглядит как один сигнал,

конект - да, но не передача информации от сигнала к сигналу - тут сразу появляются неоднозначности, в том числе и с направлением.

torvn77 писал(а):В общем одно из двух, либо моё предложение реализуется распространением правил двунаправленных пинов на обычные пины,

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

torvn77 писал(а):либо затруднения с пинами IO нету, так как хал всё равно не даст дополнительно подсоединять какие либо пины к сигналу соединяющему два IO пина.

К двунаправленным пинам можно присоединять сколько угодно пинов IN.

UAVpilot писал(а): К двунаправленным пинам можно присоединять сколько угодно пинов IN.

.А как хал решает, какое из двух значений out пинов подать на пины in?

А там нет двух значений out в один момент времени.

Пытался в *.comp файле сделать переменную массив, пишет что в строке используется недопустимый символ.
Так вот, сделал препроциссирование этого файла и нашёл место, где все упомянутые в variables переменные создаются и объявил массив там.
Всё скомпилировалось и установилось.
В общем можно попросить добавить в разрешённые для строки variables символы [] необходимые для определения и инициализации массива?
И почему в структуре нельзя создать инициализированный массив?

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

Хотя вообще хотелось бы просто вывести его в хал, он бывает нужен не только в текущей задаче.
Ну или лучше задавать положение машинного нуля методом присваивания значения пинов в axis,
используя для поиска дома отдельный компонент, что позволит делать свои собственные способы инициализации машины.
Например инициализироваться по отфрезерованной в станине круглой выборке.
Так же в этом модуле можно разместить и контроль выхода за лимиты при срабатывании которых он будет разрывать петлю сигнала ESTOP
(iocontrol.0.user-enable-out => iocontrol.0.emc-enable.in)

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

П.С.Почему разработчики не принимают коммиты через github?

torvn77 писал(а):Для этого надо чтобы хал компонент мог считать положение машинного нуля, как это можно сделать?

G53 X0
M68 вкл пин... по этому пину записываем ноль.

Или при во время хоуминга обнуляемся.

Что за хитрый компонент такой?

Nick писал(а):M68 вкл пин... по этому пину записываем ноль.

Не хотелось бы использовать средства с "не говорящими" названиями.

Nick писал(а):Что за хитрый компонент такой?

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

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

torvn77 писал(а):Вот я и предлагаю экспортировать ноль наружу.

Этого не хватит. Надо еще размер осей знать.

torvn77 писал(а):есть тот недостаток, что потенциально может быть выход за пределы оси z.

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

Nick писал(а):Надо еще размер осей знать

Ну хал же позволяет получать значения из ini.

Nick писал(а):"Потенциально" - да. Но он для начала должен не выехать за пределы во время сканирования.

А как вам другие предложенные примеры?

cnc-club.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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