I'm posting my forum post here.
What I am seeing is that after sending a “T1 M6” gcode, the controller does not respond back with an ‘ok’, rather it just responds back with the “Tool Change: Please insert tool 1” followed by a “Maslow Paused” from the executeMcodeLine() function. After sending those messages, the controller enters a pause() loop where it seems to only process serialCommands and not actually execute gcode.
Because the controller doesn’t respond back with an ‘ok’ after processing the ‘T1 M6’ line, neither the bufferSpace nor machineIsReadyForData get updated:
if lineFromMachine == "ok\r\n" or (len(lineFromMachine) >= 6 and lineFromMachine[0:6] == "error:"):
self.machineIsReadyForData = True
if bool(self.lengthOfLastLineStack) is True: #if we've sent lines to the machine
bufferSpace = self.bufferSpace + self.lengthOfLastLineStack.pop() #free up that space in the buffer
So, even though the user issues move commands via the Z-Axis popup, which “puts” them in the gcode_queue, they never get executed because bufferSpace != bufferSize and machineIsReadyForData is False:
if self.bufferSpace == self.bufferSize and self.machineIsReadyForData:
if self.data.gcode_queue.empty() != True:
command = self.data.gcode_queue.get_nowait() + " "
self._write(command)
By sending the ~ to the controller, the controller responds back with two ‘ok’ messages. The first ‘ok’ is for the ~ command that gets processed by readSerialCommands (which is called during the pause() loop), and after the pause() loop returns (because it received the ‘~’) to executeMcodeLine(), another “ok” gets sent for the original “T1 M6” command. These two “ok” messages makes bufferSpace = bufferSize (and makes machineIsReadyForData true).
However, even if the ‘ok’ message thing is cleared up, the controller still enters the pause() loop waiting to receive a "~" before continuing. I think the controller is still capable of processing quick commands and such because the pause routine calls execSystemRealtime() which calls readSerialCommands(); however, I think gcode only gets executed during the main loop() which is the only function calling gcodeExecuteLoop(). I think the controller is stuck in the pause() loop in this state until it receives the ~ and won’t execute gcode. This is what I think, not know.
If I’m correct, then to execute gcode you have to get the controller out of the pause loop and the only way to do that is to send the ‘~’ to the controller. This in itself isn’t necessarily an issue and is what webcontrol does when it receives a controller-initiated pause (i.e., “Maslow Paused” sent to webcontrol). It just makes the controller hop out of the pause() loop and re-enter the main loop() so gcode can be processed. Webcontrol is still, itself, paused (uploadFlag is 0) so it doesn’t send any more gcode file lines. The problem with this is that if buffer gcode is enabled, then there could be multiple commands already sent to the controller that is in the controller ring buffer and those will get executed. This is why I disabled buffer gcode in webcontrol last night.
From what I can tell, the only way for ground control to send a “~” is when the resume button (i.e., the pause button) is pressed. This would move the controller out of the pause loop but that button also sets uploadFlag to 1 and therefore ground control resumes sending gcode file lines… but obviously at this point the user never got a chance to move the Z-Axis. I’m pretty sure I moved the Z-Axis at one point so it must have worked at one time. Did, at one time, the controller not enter the pause() loop?
What I am worried about is 1) I’m misunderstanding ground control / controller source code and misinterpretting something or 2) If we broke something along the way, what was broken? I would think part of this could be resolved by the controller issuing an “ok” after sending the “Maslow Paused”. This would clear-up the bufferSize/bufferSpace and machineIsReadyForData issue and allow groundcontrol to send commands from the gcode_queue (which Z-Axis popup uses). But the controller is still in pause() loop and I don’t think it would execute any gcode commands until it receives the ‘~’.
I'm posting my forum post here.
What I am seeing is that after sending a “T1 M6” gcode, the controller does not respond back with an ‘ok’, rather it just responds back with the “Tool Change: Please insert tool 1” followed by a “Maslow Paused” from the executeMcodeLine() function. After sending those messages, the controller enters a pause() loop where it seems to only process serialCommands and not actually execute gcode.
Because the controller doesn’t respond back with an ‘ok’ after processing the ‘T1 M6’ line, neither the bufferSpace nor machineIsReadyForData get updated:
So, even though the user issues move commands via the Z-Axis popup, which “puts” them in the gcode_queue, they never get executed because bufferSpace != bufferSize and machineIsReadyForData is False:
By sending the ~ to the controller, the controller responds back with two ‘ok’ messages. The first ‘ok’ is for the ~ command that gets processed by readSerialCommands (which is called during the pause() loop), and after the pause() loop returns (because it received the ‘~’) to executeMcodeLine(), another “ok” gets sent for the original “T1 M6” command. These two “ok” messages makes bufferSpace = bufferSize (and makes machineIsReadyForData true).
However, even if the ‘ok’ message thing is cleared up, the controller still enters the pause() loop waiting to receive a "~" before continuing. I think the controller is still capable of processing quick commands and such because the pause routine calls execSystemRealtime() which calls readSerialCommands(); however, I think gcode only gets executed during the main loop() which is the only function calling gcodeExecuteLoop(). I think the controller is stuck in the pause() loop in this state until it receives the ~ and won’t execute gcode. This is what I think, not know.
If I’m correct, then to execute gcode you have to get the controller out of the pause loop and the only way to do that is to send the ‘~’ to the controller. This in itself isn’t necessarily an issue and is what webcontrol does when it receives a controller-initiated pause (i.e., “Maslow Paused” sent to webcontrol). It just makes the controller hop out of the pause() loop and re-enter the main loop() so gcode can be processed. Webcontrol is still, itself, paused (uploadFlag is 0) so it doesn’t send any more gcode file lines. The problem with this is that if buffer gcode is enabled, then there could be multiple commands already sent to the controller that is in the controller ring buffer and those will get executed. This is why I disabled buffer gcode in webcontrol last night.
From what I can tell, the only way for ground control to send a “~” is when the resume button (i.e., the pause button) is pressed. This would move the controller out of the pause loop but that button also sets uploadFlag to 1 and therefore ground control resumes sending gcode file lines… but obviously at this point the user never got a chance to move the Z-Axis. I’m pretty sure I moved the Z-Axis at one point so it must have worked at one time. Did, at one time, the controller not enter the pause() loop?
What I am worried about is 1) I’m misunderstanding ground control / controller source code and misinterpretting something or 2) If we broke something along the way, what was broken? I would think part of this could be resolved by the controller issuing an “ok” after sending the “Maslow Paused”. This would clear-up the bufferSize/bufferSpace and machineIsReadyForData issue and allow groundcontrol to send commands from the gcode_queue (which Z-Axis popup uses). But the controller is still in pause() loop and I don’t think it would execute any gcode commands until it receives the ‘~’.