Pause function no longer immediate

Swarvey

My printer is completely custom built, based on an old prusa design. Two steppers at the top to raise and lower Z axis, single stepper for X and Y, single stepper on a geared extruder. Control board is a "RepRap Melzi V2.0", made in the UK, design: Joe Mosfet & Adrian.

When I got it, I had absolutely no idea which firwmare (breed or version) was on it, but I needed to be able to calibrate it, as standard was nowhere near accurate.

So I used the online firmware tool to create and install Repetier Firmware, thinking this was my best option as I prefer to use Repeiter Host. The printer is permanently connected to an old Laptop, running Windows 10, combined with a UPS, both printer and host computer can withstand blackouts/brownouts without losing time or wasting filament. Printer is well and truly calibrated and producing excellent prints.

I also recently upgraded the Y axis (print surface) to run on a herringbone rack and pinion system. All in all, it works well.

Except for two little niggles.
1. The activity LED on my Melzi no longer functions, at all (non-critical)
2. The pause function is no longer reliable. Read on.

With the original firmware (whatever it was), if I click the Pause button in Repetier Host, the printer would pause, almost immediately. It might have executed one or two print/traverse moves, but it always paused pretty much straight away.

With Repetier firmware, the pause function kicks in an indeterminable point. It could do one or two moves then pause, or it could continue printing for upwards of a minute before it actually pauses.

So if I need to change filiments, or if there's another correctable problem with the print, I can no longer, reliably, click the pause button in Repetier Host and have it pause pretty much straight away.

Can anyone shed any light on the subject?

Swarvey

More information:
* Printable G-Code is stored on the HDD of the laptop, not the SD card reader on the Melzi board
* I am not using EEPROM to store modifications to printer setup. If I need to adjust a speed or steps/mm, I just modify firmware in the tool, re-download and re-install. Using EEPROM proved to be too problematic on the Melzi board for my liking.

Repetier

Not sure what the activity led is but we do not set any leds. These are normally hardware controlled or if it is for serial converter from the converter.

Pauses never were immediate. The firmware buffers motions for optimized path planning to get the good quality. Normally you have at least 16 moves buffered but that can be configured to be more. In addition host sends multiple commands so there might be 4-7 additional moves in the input buffer of firmware when you hit pause. These moves will always execute before the hosts pause takes effect which is just telling host to stop sending job commands. So these buffered moves will execute. If you pause inside a region with short moves it stops fast, if you have a big object and are printing infill with long lines pause takes longer. If your infill is some pattern like gyroid you will there always have short moves and faster pause. That is how it works since the pause exists.

Swarvey

Thanks for the reply and the good information. I'm certainly no expert on the subject of gcode, still early days for me. Assuming (dangerous, I know) I read that correctly,

* Pausing by button and by sending @pause as a command, have the same effect, in that the host simply stops sending the commands, the controller executes the moves in buffer, then just sits, waiting for the next command.

* Depending on how many commands are buffered, the printer will always complete a number of moves before it actually stops moving.

Ignoring print quality, does that mean I could modify how many commands are buffered? Therefore being able to adjust how quickly the controller responds to a pause?

I've just noticed the "Receive Cache Size" setting in the host is currently set to 127, but repetier setup guides suggest 63 if I'm unsure. I also have ping pong commands turned on, intentionally, to try and slow the commands down. Again, assuming I read the guide correctly, turning on ping pong commands, overrides the receive cache size, meaning the high 127 cache size, is not having an effect?

The LED with the original firmware illuminated whenever there was power to the board, not much else. It just doesn't work at all now.

Repetier

Yes, you understood everything correctly. I have plans for the future of Repetier-Server to speed up the process by splitting longer moves. But that is only planning so will need time to evolve into something working.