[gnea/grbl Issue#736] Where to ask detailed questions about GRBL code (for a custom GRBL machine)? About GRBL HAL

Issue #736 | 状态: 已关闭 | 作者: ranknfyle | 创建时间: 2019-10-09

Hi there, I don’t have any technical “issues” with GRBL, but I have rather detailed questions about the GRBL code (v1.1), I’m not sure where to ask them. I have a custom GRBL machine. It has X / Y axes, no laser, no spindle, no printer, but it has several servos. The servo motion is isolated, i.e. the servos are never used at the same time as steppers. Hardware-wise everything works. I want to address the servos using the same gcode as steppers, so I modified the GRBL code. The gcode command I “adopted” for servo control is M3, with the “T”, “S” and “F” parameters as follows: e.g. M3 T0 S30 F20. M3 – set servo position, T0 – servo ID is 0, S30 – set the servo to 30 deg angle, F20 – servo movement speed. If I issue this command from a Gcode sender (not as part of a gcode file), everything works fine. But if I include my servo commands in a gcode file, things get messed up with servos: incorrect angles, missed commands etc (regular gcode works fine) The problem I have is that I don’t quite grasp how the gcode “planner” works, and how it relates to the current “state” and the parsed “gc_block”. I.e. I don’t know how to correctly deal with gcode blocks, so that buffered servo commands are executed properly when streamed from a file. The code I’m dealing with is mostly in “gcode.c”, STEP 4: EXECUTE.

If there is a GRBL programmer who is willing to answer a few specialized questions (either here, or privately, via email), please let me know. Thanks.

#1 – MeJasonT 于 2019-10-10

Sending single commands via whats called mdi send a single jog like operation
when you send a job file the commands are loaded into a buffer – it can stack several lines of code which are read in a fifo First in first out like method. Im currently looking at a GUI’s parser for tool changes, unfortunately it dumps lines into the buffer before i can strip the T commands and cause the machine to do something else. It sounds like you are in a similar predicament. If the changes to grbl are working hardware and firmware wise then its the way you parse the commands prior to being sent to grbl that need investigating.
you need to understand what commands are being sent before and after the line you are sending
It looks like you using a post processor which is constructing the gcode file and including G0, G1 moves and then you are attempting to inject jog moves into the code. If you can monitor the verbose output from grbl then it might give you an indication as to what is happening.

原始Issue: https://github.com/gnea/grbl/issues/736

评论 (1)