I've enabled the serial log, but I've not had the problem since.
But surely cancelling the print should interrupt the G-Code?
Unless, as we have already discussed, it is executing a command that takes a while, then the only G-Code that matters should be the cancel scripts in Octoprint.
The difference is the interuptability.
If you have a job printing and click cancel it will only cancel once these commands are cleared. Where as an emergency stop (with the relevant firmware parameter) will stop it dead.
But even if not the issue the serial log shows what was happening at the time, or the last thing to happen. Otherwise unless someone else has had the same issue it is hard to know what the issue is.
It is enabled now. When it happens again, I'll get back to you with the logs, though I'm starting to think it more likely that the issue is with the Firmware: I'll raise the point with them.
Well, it can be a simple matter of the buffer full and a lot of commands still in the printer's buffer.
IT happens to me sometimes too when the printer is performing some lengthy-commands that are still in progress and starting to get into progress after the cancel (or pauze by the way) command has been sent.
For example when it is printing the first layer all over the 300x300 buildplate with a speed of for example 5 or 15 mm/s and slowly moves inward, it can take 5 minutes easily before the buffer in the printer is emptied and the print is cancelled or paused.
Of course this can even be worse if the gcode is telling the printer to do a temperature-change, for example from first-layer to next layer with a increase or decrease of the bed-temperature. The printer will then 'wait' untill this new temperature has been stabilized before it does the next line of gcode.
And then finally after the last line in the buffer has been dealt with by the printer, it returns back in Octoprint as 'cancelled' or 'paused'.
I have this 'problem' sometimes when the first layer does not stick correctly and therefore sometimes simply press the reset-button on the printer or on another printer simply unplug the serial(USB) cable on the printer or turn the power of the printer (not the PI!) off.
For some reason I can't find a serial.log, apart from the one that tells me the serial log is not enabled.
But the latest fail is consistent with the hypothesis that it's waiting for the bed to heat up... which is not the behaviour that prompted me to post this query.
However, it is a bit daft IMO: is it not possible to interrupt that heating command other than by M112?
M108 will be able to cancel heat ups, as long as EMERGENCY_PARSER is enabled in your firmware, and is what OctoPrint will send if EMERGENCY_PARSER is detected as enabled in your firmware when you press cancel.
M140 set bed temp and continues & M190 sets bed temp and waits.
If you read the Marlin docs (As jneillii says above)
This command (M190) can block new commands from the host. To break out of wait for temperature using from the host, enable EMERGENCY_PARSER .
(https://marlinfw.org/docs/gcode/M190.html))
So this is Marlin behaviour rather than Octoprint per sa.
Which is why I installed this plugin to Octoprint
So that gives you two solutions.
Try to uncheck In Setup
Serial logging
Log communication to serial.log Warning While this can negatively impact performance, a serial.log can be incredibly useful for debugging any issues observed in the communication between OctoPrint and your printer.
It was unchecked, I have checked it. You're saying that I should uncheck it again?
Should I restart the server after these changes?
I don't see why I should need to and I hadn't done...
Ah, does "Exclusive access to the serial port" interfere with logging?
If so, then perhaps a note to that effect could be added to the warning?
No, it doesn't. The only thing that serial logging can cause is a bit of a performance loss (lots of data having to be written away fast), so it should be disabled unless stuff is being debugged. But no, I don't know what @joseph.bejm is going on here about.
He's quoting from the settings page.
I was referring to that.
Yes, I'd guessed that. I was referring to you not knowing what @joseph.bejm was going on about.
It was working last I looked, but I've not had a repeat of the problem to send the logs of it yet.
It's a puzzle why the serial.log wasn't working, but not one that I'm going to worry about.
That was why they suggested you turn off the serial.log, I did in fact realize that the rest was from the settings page, I wrote those lines myself 
Ah, now it makes sense...
I had twigged to that, just a little late...
Generally 3D Printers have a buffer to store commands, this buffer needs to be emptied before stopping
I think there is a command to do if
R32 NOT going to 32C going to about 54 on Heat bed
Marlin say :
This is normal, but can be overridden with "hidden" options.
In your configuration set MIN_COOLING_SLOPE_DEG_BED to the required degrees of temp change.
Set MIN_COOLING_SLOPE_TIME_BED to the number of seconds to wait before continuing.
Defaults: 1.5° in 60s.
No it took longer.