2.0.0rc5 on Mac High Sierra Manual Macros Overruns Buffer

[see3d]

I am have generated a macro that creates a manual calibration sequence for my MP Mini Delta. It just taps down at 19 points with a G30 to get a Z reading and mark the bed with carbon paper for X,Y calibration points. I am connected via USB. The problem is that it spits out all the gcode to the printer at once (does not wait for the ok). The gcode is more than the buffer can hold. I deduced this, because I got rid of my ;comments and it made it further in the sequence in proportion the the number of characters I edited out. All the gcode is shown sent in the console window before the printer can even start executing it. Then the ok responses start happening. The printer stops when it runs out of commands because of overflowing the buffer.

Macro Probe: G0 X{0} Y{1} G30 G0 Z15

Macro BedC19: G28 G90 G0 Z15 ; Probe 0 50 Probe 0 30 Probe 0 10 Probe 0 0 Probe 0 -10 Probe 0 -30 Probe 0 -50 ; Probe -40 -30 Probe -24 -18 Probe -8 -6 Probe 0 0 Probe 8 6 Probe 24 18 Probe 40 30 Probe 40 -30 ; Probe 24 -18 Probe 8 -6 Probe 0 0 Probe -8 6 Probe -24 18 Probe -40 30

[sk8nfool]

I'm having the same problem with one of my macros on Ubuntu 18.04. It also acts like a buffer overrun. My printer is a Creality Ender-2 running unmodified firmware

>>> M115
SENT: M115
RECV: FIRMWARE_NAME:Marlin V1; Sprinter/grbl mashup for gen6 FIRMWARE_URL:http://www.mendel-parts.com PROTOCOL_VERSION:1.0 MACHINE_TYPE:Ender 3D EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
RECV: ok

The URL in the M115 response is kind of worthless since the domain name is currently unassigned.

[kliment]

This is something that is being addressed by https://github.com/kliment/Printrun/pull/924 and I recommend looking at the discussion there. The fix causes problems if used while a print is active (even if paused) as it causes line numbers to be reused. The core issue is that the printer firmware only supports a single queue of commands and we're attempting to squeeze other commands in between.

Regarding the M115 response, this is an unrelated issue - the M115 response is entirely defined by the firmware, creality should have changed this in their configuration but did not. The URL was valid back in 2011 when a parts shop paid for some firmware work to be done and added their URL in the default distribution. It has absolutely nothing to do with Printrun.

[sk8nfool]

I didn't mean to imply that the M115 response was anything more than to let you folks know where I'm at (old machine with old firmware). It most definitely is a Creality problem. Sorry for the confusion.

[sk8nfool]

I looked at #924 and at the moment it seems mostly a discussion on how to use git. However the last long comment did address this problem. There seems to be a couple of issues involved. The overrun problem is basically a communications protocol problem. The printer makes it's own decisions on whether or not a particular command needs to be buffered and for how long. It also decided whether or not the command just received has to be delayed or not. It has several ways to do this. The "ok" response seems to tell the sender that the command received has been handled completely (M114 seems to be a little different) and the printer is ready for the next command. As I understand it, Marlin does something like this - sends an OK whenever it buffers a command except when a command arrives that can't be completed until it actually needs to be complete (eg M0 - stop for user input). This can't be the only mechanism because the buffer isn't infinite. The OK must also depend on buffer space or there needs to be some "out of band" mechanism like the CTS signal or XON/XOFF characters. This needs some investigation.