@luben111: 当我有空的时候我会调查这个，但是首先你能验证当你注意到它失败时 Grbl 正在接收 0x85 命令吗？不确定最简单的方法是什么。也许编辑串行 RX ISR 代码以在读取 0x85 时切换引脚。

好点，我会检查这个

@luben111 ：你提到你正在使用 labview 你愿意和我分享你的工作吗，这样我就可以帮助/验证 grbl 的更多/新功能基本上我正在将 grbl 移植到 xmega avr，我的目标是添加 G33（点击/threading ) g 代码支持，我需要 labview 类型的应用程序来测试功能完整性

@shamsiqbal
LabView VI 在 LV 环境中处理串行 COM 上的通信，在您的情况下，与使用任何串行 COM 终端相比，它没有带来任何优势。这个 LV 代码非常复杂（状态机、位置轮询等），如果您对 LV 没有很好的经验，将很难让它工作。您想为 G33 命令测试什么以及为什么需要在 LabView 中完全完成？

@luben111
我过去曾在 labview 中为仪器接口开发许多应用程序，我也可以在你的帮助很少或根本没有帮助的情况下使用你的 vi
这里有一些关键的事情可以在 labview 中完成
pid 调整界面可以在 labview 中开发（在你现有的 VI ）这是主轴闭环控制所必需的，我将花费更少的时间与主持人一起开发全新的 GUI 我在 xmega 端口中添加了闭环 pid 控制
之后我可以将测试 VI 集成到现有 VI 中以获得 G33 功能完整性/有效性
是关于我可以在 labview 中工作的全部，它对我来说很容易，而不是从零开始

我已经改装了 beaver vc5 cnc 铣床，它是 xmega 和 arduino nano 的混合体，但下一个版本我将只使用 xmega128a1u
刚刚完成移植并添加 xmega 硬件驱动程序支持现在开始研究如何在 grbl 中实现该功能的慢跑键使用 xmega 的 GPIO 我为主轴 pid 调整添加了新的 grbl 参数，需要在 grbl 接口 GUI 中添加

@shamsiqbal
在您的情况下使用 LV 听起来很合理。清理代码需要一些时间，因为它是大型项目的一部分。让我知道如何通过电子邮件发送文件。

移植到 XMega128 听起来是个好主意（尽管很快就可以移植到 ARM），你有一些 PCB 吗？

关于慢跑 – 新的 GRBL v.1.1 内置了慢跑控制，我可以说它工作得非常好 – 使用 PC 键盘我可以获得技术上与使用吊坠相同的行为。

@luben111
好的 arm 端口不能解决任何问题 >———> 它将有
关于 arm 端口的 G33 g 代码支持我从 v0.9 开始就知道它对我来说根本没有用，
如果有的话将支持 grbl 中的 S 曲线运动规划，我可以说 16 MIPS 处理能力足以控制 6 轴闭环直流伺服控制，运动控制几乎没有速度限制，它只会受到
我选择的伺服电机速度的限制xmega 因为它有三个硬件正交编码器计数选项，处理能力是 avr mega 的两倍，它可以用来生成比 mega avr 更多的步数

关于 xmega pcb 我已经使用光敏胶片方法构建了分线板，你可以使用碳粉转移法构建一个它是一个简单的 smd to dip 分线板，一旦我完成移植，我将使用我自己构建的 cnc 铣床构建完整的 pcb

您可以通过shams@bosonelec.com 将文件通过电子邮件发送给我

我在 grbl 端口上使用 v1.0 而不是 v1.1，因为我在 v1.1 中发现了一些问题，我新添加的参数无法正确保存

@chamnit : good job to getting juices from arduino uno but plz admit this thing  that its almost end of arduino uno available resources due to flash memory limit so plz dont make grbl mega difficult where adding new function will become difficult i dont want to add a new issue stated above because i can understand that i wont be getting any helping answer from you 

我认为在 ARM 上移植 grbl 并不重要，但要进行 S 曲线运动规划。您选择了 lpc17xx arm 端口，但如果您选择了 stm32 nucleo 板，这将是一个不错的选择，因为它具有经济的价格和可用的板载调试选项，请查看 stm32 nucloe 板。cortex m3 vs cortex m4 和 fpu 有很大的不同我有 3k kintes mkv3 系列 cortex m4 mcu，但我仍然更喜欢 stm32f4 系列，在我看来，在 stm32f429i 发现板上可以使用独立的基于 grbl 的 cnc 控制器，我建议你考虑一下用于 grbl arm 端口的 stm32 系列板

@shamsiqbal：在你开始说你不知道的话之前，请尝试阅读其他问题线程。特别是关于转向 ARM 的话题。关于这个话题有一段很长的对话。此外，LPC 端口是由用户完成的，不是我的主要选择，因为您会看到是否阅读了该主题。对于要求使用这个 ARM 芯片或那个 ARM 芯片甚至 FPGA 的每个人，我都说完了。越来越荒谬了。

@shamsiqbal：我和我的兄弟将 grbl 移植到 lpc17xx，因为有大量出售的 CNC 板使用它，但运行不同的固件。据我所知，grbl-lpc 的步进率和阻塞率比任何其他 grbl 端口都快。M4性能会更好吗？或许。我们会看看您或其他人何时移植到它。

@chamnit：
看起来如果我打开问题，那么你将在问题上帮助我
“我使用 v1.0 而不是 v1.1 作为 grbl 端口，因为我在 v1.1 中发现了一些问题，我新添加的参数无法正确保存“

此外，这些是您对https://github.com/gnea/grbl-Mega/issues/17 thread
Grbl is being ported to 32-bit ARM
的评论 从未提到它是您的端口或其他端口我确实记得有类似的你在不同的问题线程上发表评论说你忙于 arm 端口，但我仍然为我对 arm 端口的评论道歉

在此线程中，我指出了三件事
i) G33（攻丝/线程）g 代码支持
ii）保持它与每个人的其他旧版本兼容，并为每个用户/开发人员添加新功能 v1.0 到 v1.1 的最小变化每个 GUI 开发人员的总修订
iii) S-CURVE 运动规划
亲爱 的@chamnit：
如果这些超出了 G33 的 grbl 范围，请告诉我
我已经开始研究它
以保持它的兼容性我也遇到
了 S 曲线运动规划的问题我将在 xmega 完成移植后进行研究

我从 v0.8 开始就一直在阅读 grbl 代码，我对 grbl 的经验比你少，如果我不能执行任何附加功能，那么向专家寻求帮助是显而易见的事情，这不是事情是如何工作的，而是关于代码兼容性的grbl中的现有功能

@tbfleming ?
干得好，帮助社区的好方法我确实有三个 lpc17xx 嵌入板，但我仍然不会使用这些板你提到了速度性能，这是显而易见的事情，16Mhz 与 100Mz 这就是你正在使用的 MCU 的速度差异，但这是我的主要问题你认为一个普通的步进电机和步进电机驱动器会接受高步进率并在
更高的步进率和转速下表现良好，步进电机的扭矩曲线差，
当我完成 xmega 端口 i 时实际位置丢失将在 youtube 上上传一个视频，说明我的系统是如何工作的

从来没有提到它是你的端口或其他端口

请停止自相矛盾。你在上一篇文章中提到了这一点。

您选择了 lpc17xx arm 端口，但如果您选择了 stm32 nucleo 板，这将是一个不错的选择，因为它具有经济的价格和可用的板载调试选项，请查看 stm32 nucloe 板。

请理解，回答有关这些问题线程的问题需要时间和精力。它用于确定是否存在错误或讨论重要问题。

不是为了教每个随机的人如何为 Grbl 编码。由于这个原因，代码被很好地注释了。当 v1.1 的一切都在向前发展时，尝试在旧版本的 Grbl 上帮助您也没有任何意义。你想要的对我自己和这里的其他人来说完全是浪费时间。

此外，您建议的所有改进先前已在多个位置进行过讨论，并且已经在计划中。请尝试使用 Google 并在此处发布之前做一些功课。这将节省每个人自愿提供帮助的宝贵时间。应该花在开发或制作某物上的时间。

你认为一个普通的步进电机和步进电机驱动器会接受高步进率并表现良好吗更高的步进率和转速步进电机的扭矩曲线差和实际位置丢失

ClearPath 伺服系统。

此外，当前一代业余爱好者激光器上的步进器运行频率接近 100 kHz。未来的爱好激光器可能需要更高的速率。

关于点动取消问题（很抱歉被其他帖子污染的线程）：

在 grbl.c（第 91 行 ..）中添加了以下代码：

@———————————————— ———————————————-
//确定该行是慢跑运动还是正常的 g 代码块。
if (line[0] == ‘$’) { // 注意：$J=传递给此函数时已经解析。
// 设置 G1 和 G94 强制模式以确保准确的错误检查。

// 10/02/2017 完成修改以检测是否接受了 JOG 命令。示波器应连接到 ISP 接头的引脚 4（MOSI – PORTB_Bit3）
//检查示波器是否在点动命令失败（未被接受）时获得脉冲
SPINDLE_ENABLE_PORT ^= (1<< 3); // 当接受新的点动命令时，切换 Uno 上的引脚 11**
gc_parser_flags |= GC_PARSER_JOG_MOTION;
gc_block.modal.motion = MOTION_MODE_LINEAR;
gc_block.modal.feed_rate = FEED_RATE_MODE_UNITS_PER_MIN;
#ifdef USE_LINE_NUMBERS
gc_block.values.n = JOG_LINE_NUMBER; //初始化点动时报告的默认行号。
#endif
}
@——————————————– ———————————————- –

每次接受新的点动命令时，代码都会更改 PB3（ISP 接头的引脚 4）的状态。我所看到的是，每次我发送一个点动命令时，它都会被正确接受。我使用的序列类似于最初列出的序列：
$J=G90X-558F2000 (2)
$J=G90X-558Y-2F2000 (3)
$J=G90X-558F2000 (4)
示波器快照如下 – 您可以看到正好有 3 次信号变化：

所以接收到点动命令是正确的，错误的应该是取消了正在运行的点动。现在将添加一些其他引脚更改，以及时显示点动取消作为示波器上的第二条轨迹。

我对 serial.c（第 161 行）进行了以下修改，以显示 0x85 取消操作 – 每次 0x85 取消时 PB5 都会切换（在 ISP 的引脚 3 上可见）。

@———————————————— ———————————————-
如果（系统.state & STATE_JOG) { // 阻止所有其他状态调用运动取消。
system_set_exec_state_flag（EXEC_MOTION_CANCEL）；
SPINDLE_ENABLE_PORT ^= (1<< 5); // 切换 PB5 引脚（ISP 上的引脚 3）
}
@———————————— ———————————————- ———-

以下是范围内的时间安排：

似乎确实存在一些问题，它发生在以下情况下

1. 发送点动命令
2. 发送 0x85 命令（取消上一条命令 1 的效果）
3. Send new jog command before the head movement of command (1) stopped
4. Short time after you send (3) and while the head is still moving from 1 send new 0x85 to cancel all jog commands.

The misbehaviour is – if 0x85 was sent before command 1 head movement stopped, command 2 will be executed, i.e. 0x85 is not affecting jog commands which were accepted and waiting to be executed while previous command was cancelled but head is still moving.

My explanation is:

• After you send 0x85 (2) the machine begins to decelerate – cancellation of (1)
• you send new jog command (3) immediately after (2). Notice that head is still moving.
• if you send new command 0x85 (4) before command (1) was completed (head stopped) it will be accepted but command (3) will not be cancelled (it’s hanging probably in some other buffer).

@luben111 : Thanks for digging into this. It’s possible there may be some bug in the state machine. I didn’t vet it as much as I have in the past prior to releasing v1.1. But, first:

• With sending (3) immediately after (2), what exactly does Grbl do? Does it start to slow down and then accelerate again? Does it stop and then go? Or does it continue moving like nothing has happened?
• If it starts slowing down and accelerates again, It’s possible that Grbl is doing what it is supposed to by stopping the machine. However, when you send the next command, it may have gotten queued somewhere between the serial buffer and the planner and executed immediately after the cancel completes.
• Regarding (4), sending another 0x85 jog cancel will be ignored, if the current one hasn’t been executed and cleared yet.

I suppose the question would be, what is the situation that you are sending a jog cancel and then still are sending jog commands?