开源改变世界!!

半自动换刀的当前工作流程 #29

推推 grbl 2年前 (2023-02-08) 215次浏览
关闭
kfmut 打开了这个问题 2021 年 7 月 2 日 · 36条评论
关闭

半自动换刀的当前工作流程#29

kfmut 打开了这个问题 2021 年 7 月 2 日 · 36条评论

评论

半自动换刀的当前工作流程 #29

你好,

我很好奇当前在Automatic touch off @ G59.3 ($341=3)模式下更改工具的工作流程是什么?Wiki 有两个地方有描述(https://github.com/grblHAL/core/wiki/Additional-or-extended-settingshttps://github.com/grblHAL/core/wiki/Manual,-semi-automatic- and-automatic-tool-change ) 但它们并没有反映事物的实际状态。从 wiki 我的印象是,首先将工具移动到原始位置进行物理更改,然后它移动到 G59.3 偏移量以进行自动触发,但我的测试显示没有移动到原始位置只是在 Z 方向提升,然后在Cycle Start移动工具之后到 G59.3 偏移量。

也许有人讨论过 grblHAL 中的半自动更改?看起来 github 上的搜索引擎最近发生了变化,搜索任何东西都变得非常困难:-(

半自动模式下的工具更改是否取决于 g 代码发送器?我怎么能理解发件人正确处理工具更改?

我正在尝试在我的路由器设置上为 BlackPill 配置带有自定义 BOB 的 STM32F4 驱动程序(NetBSD 下 rpi3 上的 bCNC),我使用的是最新的 bCNC 发送器,grblHAL 配置是:

$I
[VER:1.1f.20210608:]
[OPT:VNS2,35,1024,3,0]
[NEWOPT:ENUMS,RT+,HOME,TC]
[FIRMWARE:grblHAL]
[NVS STORAGE:*EEPROM]
[DRIVER:STM32F411]
[DRIVER VERSION:210606]
[BOARD:Custom BlackPill STMF411]
[PLUGIN:KEYPAD v1.00]
$#
[G54:-73.974,-317.996,-69.671]
...
[G59.3:-293.000,-17.000,-30.000]
[HOME:-299.000,-353.000,-2.000:7]
[TLO:0.000,0.000,-14.442]
[PRB:-293.004,-16.995,-78.005:1]

我不确定为什么在第二次更换工具后将 TLR 参考从此处的参数中删除并替换为 TLO。

$$
$0=10.0
$1=25
$2=0
$3=5
$4=0
$5=0
$6=0
$7=0
$10=511
$11=0.010
$12=0.002
$13=0
$14=7
$15=0
$16=0
$17=0
$18=0
$19=0
$20=1
$21=0
$22=5
$23=3
$24=30.0
$25=1500.0
$26=10
$27=2.000
$28=0.100
$29=0.0
$30=4800.000
$31=0.000
$32=0
$33=5000.0
$34=0.0
$35=0.0
$36=100.0
$37=0
$39=1
$40=0
$43=1
$44=4
$45=3
$46=0
$50=100.0
$51=600.0
$52=3000.0
$53=0.250
$54=500.0
$55=3000.0
$62=0
$63=2
$64=0
$65=0
$80=1.000
$81=0.010
$82=0.000
$84=0.000
$85=10.000
$90=0.000
$91=0.000
$92=0.000
$95=0.000
$100=33.334
$101=66.726
$102=199.077
$110=9610.000
$111=9610.000
$112=2550.000
$120=110.000
$121=110.000
$122=110.000
$130=301.000
$131=355.000
$132=85.000
$170=0.000
$171=0.000
$172=0.000
$341=3
$342=50.0
$343=30.0
$344=120.0
$345=120.0
$347=3.0
$348=2.500
$349=25.000
半自动换刀的当前工作流程 #29
作者

好的,看起来 bCNC 没有遵循工具更改协议,因为它试图在 grblHAL 处于工具状态时从 g 代码文件发送命令https://github.com/grblHAL/core/wiki/Manual-tool-change-protocol . 这就只剩下第一个问题了。

半自动换刀的当前工作流程 #29
贡献者

从 wiki 我的印象是,首先将工具移动到原位进行物理更改,然后它移动到 G59.3 偏移量以自动触发,但我的测试显示没有移动到原位,只是在 Z 方向提升,然后在循环启动工具之后移动到 G59.3 偏移量。

该行为取决于 $341 设置。不过,对不同变体的解释可能会更好。

也许有人讨论过 grblHAL 中的半自动更改?

一些,但在旧的回购协议中。

半自动模式下的工具更改是否取决于 g 代码发送器?

是的 – 如 Wiki 中所述,发送方必须确认工具更改并允许点动和设置偏移量(并允许特殊的 $ 命令,具体取决于模式 – 可能通过 MDI 或宏输入)。

我怎么能理解发件人正确处理工具更改?

它应该是发件人规格的一部分?工具更改协议是一个特定于 grblHAL 的扩展,所以除了 ioSender 之外,任何发送者都不太可能支持它?AFAIK 一些发件人诱捕 M6 并实施某种工具更改协议发件人端,而一些发件人完全剥离 M6?

半自动换刀的当前工作流程 #29
作者

@terjeio

不过,对不同变体的解释可能会更好。

是的,这会有很大帮助。出于某种原因,$341=3grblHAL 模式首先移动到 G53 Z0,然后退回到 G53 Z-1,而 HOME 位置是 G53 Z-2,我不明白为什么要这样做。

也许在机器坐标中明确指定物理工具更改位置会有所帮助(类似于 G30 http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g30-g30.1或者 G59 .2)?

有一些,但在旧的回购协议中。

很好,我会探索它们。

但从一开始我就可以在工具更换后确认软限制警报的行为 ( terjeio/grblHAL#225 )。我的测试显示它与探针工具和工作工具之间的工具差异有关,如果探针较短,则在工作工具返回到 XY 方向的恢复点后和 Z 移动之前立即发出警报。bCNC 具有相同的行为,因为它在工作偏移中进行返回移动,而不是通过 G53 或 G28。因此,如果 Z 中的空间不足,则会引发软限制警报。

AFAIK 一些发件人陷阱 M6 并实施某种工具更改协议发件人端

是的,bCNC 有这样的 WCS 翻译实现:

  • 首先校准:bCNC找到工件和对刀仪之间的Z差;
  • g 代码文件中的实际工具更改被动态替换为宏;
  • 刀具移动到物理换刀位置(通过发送器设置在 G53 中设置);
  • 换刀后,如果需要,将对刀仪夹放在立铣刀上,操作员按下Cycle start并将刀具移动到探针位置(通过发送器设置在 G53 中设置,与 grblHAL 中的 G59.3 相同);
  • 刀具探测并返回到换刀位置;
  • 如果需要,操作员从立铣刀上取下对刀器夹并按下Cycle start
  • WCS 是通过新工具和用于校准的探头之间的差异来转换的;
  • 工具返回到恢复点。
半自动换刀的当前工作流程 #29
贡献者

出于某种原因,在 $341=3 模式下,grblHAL 首先移动到 G53 Z0,然后退回到 G53 Z-1,而 HOME 位置是 G53 Z-2,我不明白为什么要这样做。

它应该迈出一步 – 到 Z home 或 Z home – 1 取决于设置。您程序中 M6 之前的 g 代码命令是什么?

也许在机器坐标中明确指定物理工具更改位置会有所帮助(类似于 G30 http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g30-g30.1或者 G59 .2)?

linuxCNC 使用 G59.3 进行工具更改/工具探测,所以我也为 grblHAL 选择了它。我不想要求额外的位置/偏移量,IMO 修改你的后处理器以移动到工具更改的特定位置,如果你想要一个与 341 美元已经支持的位置不同的位置。我考虑过为初始 Z 目标添加一个设置(作为 Z 主页的偏移量),现在这是硬编码的。也许还有一个用于探头缩回距离:

核心/tool_change.c

第 31 至 38 行 b685e18

//注意:仅在 settings.homing.flags.force_set_origin 为真时使用
#ifndef LINEAR_AXIS_HOME_OFFSET _
#定义 LINEAR_AXIS_HOME_OFFSET10f
#结尾
#ifndef TOOL_CHANGE_PROBE_RETRACT_DISTANCE _
#定义 TOOL_CHANGE_PROBE_RETRACT_DISTANCE 20f
#结尾

 

但从一开始我就可以在工具更换后确认软限制警报的行为 ( terjeio/grblHAL#225 )。

您的 g 代码程序是否移动到 M6 之前的 Z 起始位置?换刀算法会将控制点(刀尖)移回 M6 之前的位置,如果新刀具更长,将超出 Z 原点。更改后处理器以移动到具有足够净空的位置或根本不移动。

半自动换刀的当前工作流程 #29
作者

@terjeio

抱歉我延迟回答:-(

它应该迈出一步 – 到 Z home 或 Z home – 1 取决于设置。您程序中 M6 之前的 g 代码命令是什么?

是的,这是我的错误,配置与以前在简单的 grbl 和 bCNC 上的设置不同。它有 G28 移动,用于在第一次换刀之前从工件上清除探针/立铣刀(G28 位置设置得比以前高):

N00001 G17
N00002 G21
N00003 G94
N00004 G28 G91 Z0
N00005 G90


N00006 T124 M6

但是,如果初始位置显示[HOME:-299.000,-353.000,-2.000:7]为升降机移动的高度不应该是 Z-2 或 Z-3,为什么是 Z-1?也许定义 LINEAR_AXIS_HOME_OFFSET 应该是正数,因为这里使用了负运算?

tool_change_position = 系统。home_position [飞机。axis_linear ] – 设置。归位旗帜force_set_origin?LINEAR_AXIS_HOME_OFFSET:00f ;

 

无论如何settings.homing.flags.force_set_origin连接到哪个 $ 参数?我不记得要设置这样的东西……

G59.3 被 linuxCNC 用于工具更改/工具探测

LinuxCNC 没有硬编码的工具更改例程,它基本上是脚本化的,因此任何人都可以更改工具更改行为以满足他们的需要,在 LinuxCNC 中无需为每个设置修改后处理器。我的 LinuxCNC 用户说 G59.3 没有形状或形式的偏移被指定为 LinuxCNC 中的换刀位置。

您的 g 代码程序是否移动到 M6 之前的 Z 起始位置?换刀算法会将控制点(刀尖)移回 M6 之前的位置,如果新刀具更长,将超出 Z 原点。

为了清除工件上的探针/立铣刀,我在头部移动了 G28:

N00001 G17
N00002 G21
N00003 G94
N00004 G28 G91 Z0
N00005 G90


N00006 T222 M6
...
N00046 G0 X29.359 Y-.725 S12000 M3
N00047 Z15.000
N00048 Z2.400
N00049 G1 Z1.400 F390
N00050 X29.246 Y-.497 F760
N00051 G3 G17 X29.088 Y-.257 I-1.111 J-.556 F1250

第二个工具变化:

N03175 G3 X21.218 Y19.807 I3.349 J3.713 F760
N03176 G0 Z15.000
N03177 X9.533 Y-20.822

N03178 M5
N03179 T1 M6
...
N03221 G0 X9.533 Y-20.822 S4400 M3
N03222 Z15.000
N03223 Z4.500
N03224 G1 Z-2.085 F273
N03225 G0 Z15.000

我认为 Fusion360 中的标准 grbl 后处理器与标头中的 G28 具有相同的行为。

为什么在换刀例行程序中需要工件偏置移动?M6之后的第一步不会应用TLO吗?

半自动换刀的当前工作流程 #29
贡献者

但是,如果起始位置显示为 [HOME:-299.000,-353.000,-2.000:7],升降机移动的高度不应该是 Z-2 或 Z-3,为什么是 Z-1?

因为我选择 -1,目前它只能通过编辑tool_change.c或在编译器命令行上添加 LINEAR_AXIS_HOME_OFFSET 作为符号来更改。

也许定义 LINEAR_AXIS_HOME_OFFSET 应该是正数,因为这里使用了负运算?

Z-motion 在向下方向是负的,为了避免混淆我使用了负值。如果我将它移动到一个设置,负值对用户来说也是最明显的吗?

无论如何,$-parameter settings.homing.flags.force_set_origin 连接到哪个?我不记得要设置这样的东西……

$22,第 3 位(将机器原点设置为 0),grblHAL 比 vanilla Grbl 有更多的设置,这是为了摆脱大多数编译时选项。我现在看到我没有记录$22..

$$=22在终端窗口中发出返回:

$22: Homing cycle as bitfield where setting bit 0 enables the rest:
    0 - Enable (1)
    1 - Enable single axis commands (2)
    2 - Homing on startup required (4)
    3 - Set machine origin to 0 (8)
    4 - Two switches shares one input pin (16)
    5 - Allow manual (32)
    6 - Override locks (64)
    7 - Keep homed status on reset (128)
ok

我的 LinuxCNC 用户说 G59.3 没有形状或形式的偏移被指定为 LinuxCNC 中的换刀位置。

来自我的草率评论,IIRC 它通常用作触发传感器的位置,通常与工具更改结合使用。对不起。

我认为 Fusion360 中的标准 grbl 后处理器与标头中的 G28 具有相同的行为。

是的,我相信。对于 grblHAL,这会导致换刀算法出现问题。Grbl 不支持工具更改,所以我猜它是作为某种解决方法添加的?

为什么在换刀例行程序中需要工件偏置移动?M6之后的第一步不会应用TLO吗?

我不确定你的意思。探测完成后,换刀算法应用 TLO,然后移动到 Z 原点,然后移动到原始 XY 位置,最后移动到原始 Z 位置(在 M6 之前)。也许设置 TLO 应该延迟到最后的 Z 移动之前?

半自动换刀的当前工作流程 #29
作者
kfmut 评论了 2021 年 7 月 9 日  

@terjeio

我用Set machine origin to 0选项做了很少的测试,现在我完全迷路了:-)

LINEAR_AXIS_HOME_OFFSET 的目的是在换刀期间将轴从原点/限位开关移开,对吗?但是,如果Set machine origin to 0选项为真,则原点不会设置为触及限位开关的点,但该点会按 $27 选项的值进行转换。因此,在换刀期间,轴甚至不靠近原点/限位开关。在Set machine origin to 0选项的两个值中,工具更改位置不是原位(由 $# 命令显示),如文档中所述(https://github.com/grblHAL/core/wiki/Manual,-semi-automatic- and-automatic-tool-change),对吧?

Grbl 不支持工具更改,所以我猜它是作为某种解决方法添加的?

Autodesk 对编辑后处理器有奇怪的政策,任何人的要求都可以在没有太多讨论的情况下完成,所以在 G28 和 M6 上来回几次。我不确定那是什么背景。

我不确定你的意思。探测完成后,换刀算法应用 TLO,然后移动到 Z 原点,然后移动到原始 XY 位置,最后移动到原始 Z 位置(在 M6 之前)。也许设置 TLO 应该延迟到最后的 Z 移动之前?

我想我想尝试在没有最终 Z 移动的情况下使用工具更换例程,我不明白为什么需要它。也许可以在 tool_change.c 文件中评论或更改几行代码,以便我检查它?

半自动换刀的当前工作流程 #29
贡献者

如果将机器原点设置为 0 选项为真,则原点未设置为触及限位开关的点,但该点转换为 $27 的值

正确,我不知道为什么要这样做。是否应将其更改为 27 美元的牵引距离(符号由归位方向确定)以与将机器原点设置为 0设置为 false 一致?
如果Set machine origin to 0为 false,则设置为开关被击中的位置或最大行程 + 牵引距离,具体取决于归位方向。
请注意,grblHAL 会跟踪归位状态和位置,而 Grbl 不会。

还有一个让我有点困扰的相关问题,目前无法知道 G28 和 G30 位置是否已明确设置,它们都默认为 0,0,0 – 原则上应该默认为未知 (NAN)?另外如果机器没有回原点或者没有设置位置,G28和G30应该会报错吗?LinuxCNC 中有一个警告,如果没有归位或未设置位置,则不要使用这些命令 – 但我不知道如果发出不管会发生什么……

在 Set machine origin to 0 选项的两个值中,换刀位置不是原点位置,如文档中所述,它由 $# 命令显示,对吧?

是的,如果将机器原点设置为 0为真,则偏移$27值减去LINEAR_AXIS_HOME_OFFSE换刀例程中的 T。顺便说一句应该删除 – 它不需要。将起始位置设置为按下开关的位置不是一个好主意 – 如果启用硬限制,移动到那里可能会再次触发它并引起警报。LINEAR_AXIS_HOME_OFFSET

我想我想尝试在没有最终 Z 移动的情况下使用工具更换例程,我不明白为什么需要它。也许可以在 tool_change.c 文件中评论或更改几行代码,以便我检查它?

是的,你可以试试。如果没有在 gcode 中完成,则需要最后一步 – 不可能知道后处理器将输出什么…… IIRC 这是执行移动的地方:

核心/tool_change.c

第 128 至 129 行 222ba55

以前的。[平面。axis_linear ] += gc_get_offset ( plane.axis_linear );
mc_line (previous.values , & plan_data );

 

半自动换刀的当前工作流程 #29
作者
kfmut 评论了 2021 年 7 月 13 日  

@terjeio

我正在查看 LinuxCNC 文档以获得深入的解释,我必须说它有一个完全不同的设置原点和起始位置的过程。grblHAL 应该使用它作为参考吗?

在线http://linuxcnc.org/docs/html/config/ini-homing.html
PDF 文件在不同部分有更多信息http://linuxcnc.org/docs/2.8/pdf/LinuxCNC_Documentation.pdf(第 8.3 章和 3.7.11)

是否应将其更改为 27 美元的牵引距离(符号由归位方向确定)以与将机器原点设置为 0 设置为 false 一致?

我认为它至少应该保持一致,否则这两种设置之间的最大行驶距离(130,131,132 美元)会有所不同。它会以某种方式影响旋转轴吗?从来没有过,所以没有他们的经验。

如果 Set machine origin to 0 为 false,则设置为开关被击中的位置或最大行程 + 牵引距离,具体取决于归位方向。

LinuxCNC 文档指出,车床需要从轴原点开关明确设置机器原点。第 3.7.11 章:

The zero position is the location on the axis that is 0 in the machine coordinate system.
Usually the zero position will be within the soft limits. On lathes, constant surface speed
mode requires that machine X=0 correspond to the center of spindle rotation when no
tool offset is in effect.

因此,也许在 grblHAL 中,还应该使用 home 开关(LinuxCNC 中的 HOME_OFFSET)的原点偏移量?

顺便说一句,LinuxCNC 的 HOME_OFFSET 与 grblHAL 中的 LINEAR_AXIS_HOME_OFFSET 有什么关系???

还有一个让我有点困扰的相关问题,目前无法知道 G28 和 G30 位置是否已明确设置,它们都默认为 0,0,0 – 原则上应该默认为未知 (NAN)?另外如果机器没有回原点或者没有设置位置,G28和G30应该会报错吗?LinuxCNC 中有一个警告,如果没有归位或未设置位置,则不要使用这些命令 – 但我不知道如果发出不管会发生什么……

I don’t see why it would be a bad idea to post an alarm if the machine is not homed but G28/G30 commands are issued. Regarding checking if they were purposely set: if it’s possible to do without much effort, it would be great to have such check, countless number of people had problems with G28 when it was enabled by default in Fusion360’s post-processor dialog and they didn’t set that offset in grbl.

Setting the home position to where the switch was hit is not a good idea – a move there will likely trigger it again and cause an alarm if hard limits is enabled.

It’s so many options(shared/separate limit and home switches, only home switches with soft limits, only limit switches) that it’s tough to say what is a good idea and what is not :-)

Yes, you may try that. The final move is required if not done in the gcode – impossible to know what a post-processor will output… IIRC this is where the move is performed:

Thank you, I’ll try that.

半自动换刀的当前工作流程 #29

喜欢 (0)