Open moefear85 opened 2 years ago
brakthehun
commented
2 years ago This was a request I made years ago. My issue was the buffer was getting full as I was doing high speed lasering and it was stuttering. In Grbl,, once you put the board in M3 or M4 mode,, it stays there until a change. Once th redundant M4 was removed,, My lasers stopped stuttering.
moefear85
commented
2 years ago @brakthehun you're confused. I'm talking about (the most recent) marlin firmware. It doesn't work without M3/M4 commands, irrespective at what speed. SVG wasn't even supported back then!
arkypita
commented
2 years ago G0/G1 are modal commands (as well as M3/M4). According to specifications for modal commands, once they are sent once they stay active, so is no needs to repeat them. Therefore it should be possible to send lines containing only positions or power changes without needs to repeat M or G command.
arkypita
commented
2 years ago What does Marlin firmware developer say about this behavior?
moefear85
commented
2 years ago Hi,
I don't know, though laser features are still experimental. I think I need try the "full compatibility mode with lasergrbl" feature, which I haven't gotten around to yet. Once I know for sure if it does/not work, I'll respond.
But the main issue remains the fact that lasergrbl outputs gcode differently depending on the imported file extension. Hence I only encounter this for svg, as well as specific slicing algorithms. I haven't returned to this in quite a while, so I don't remember exactly, but a standard slicing process ends up producing code that marlin accepts without any problems, as it then includes the M parameter on every line. Hence it would be awesome if one can configure this, even for svg files.
I would have used lasergrbl as a firmware, but I need to retain 3D printing capabilities on the same machine.
FarFlyer
commented
2 years ago I have the same problem with Marlin 2.0.9.2 with M4 inline commands. With a raster image tracing it's fine and the S parameter is at the end of the G1 move command. But with SVG or raster image vectorized, the S parameter is on a new line and it doesn't work.
Example of raster image tracing:
G1 X0 Y0 F3000
M4 S0
G1 X9.9 S200
X10 S187
X10.1 S28
G1 X10.1 Y0.1 S0
G1 X10 S28
X9.9 S187
X0 S200
S0
G1 X0 Y0.2 S0
G1 X9.9 S200
X10 S187
X10.1 S28
G1 X10.1 Y0.3 S0
Example of vector (for cutting):
M4 S0
F2000
G1 X0 Y0.085
S50
G1 X9.899 Y9.985
S0
G1 X9.956 Y9.985
S50
G1 X10.007 Y9.933
S0
G1 X10.007 Y9.951
S50
G1 X0.056 Y0
S0
Is it possible to standardize the output (to the first example)?
datibi
commented
2 years ago I opened ticket for the same issue half year ago
Describe the bug Usually all power parameters (for example S255) are present at the end of a G0/G1 command. According to specifications, If S parameter is present without G0/G1, it should be preceded by M3/M4. But in specific modes (such as trying to engrave an svg file but also for some other non-standard planning algorithms), lasergrbl begins to output S commands alone on individual lines, for example:
This however causes marlin firmware to keep generating "unknown command" after each S line, because marlin is expecting either:
But if I open a png file and use standard settings, then lasergrbl will only output Sxxx as an extra parameter at the end of every G0/G1 statement. marlin understands these without problems.
To Reproduce Steps to reproduce the behavior:
Expected behavior That M3/M4 preceed any sole Sxxx parameter
Screenshots Will upload soon
Hardware and software configuration (please complete the following information):
Additional context First: I'm a laser cnc noob, so sorry if I missed something i should have researched first.
Second: I realize there might be an incompatibility between marlin and lasergrbl, because although marlin supports continuous/dynamic inline modes, it requires the "I" parameter to be specified along with M3/M4 to enable/disable it, but lasergrbl never seems to use that parameter. Are there any plans to make the two packages work together?
Update: I realized there is a GCODE_MOTION_MODES option in marlin, but I haven't tested it yet, and it is unclear if it is related to this issue. i will try it and update this report.