Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot issue any Z-Axis adjustments during tool change #811

Open
madgrizzle opened this issue Nov 14, 2019 · 10 comments
Open

Cannot issue any Z-Axis adjustments during tool change #811

madgrizzle opened this issue Nov 14, 2019 · 10 comments

Comments

@madgrizzle
Copy link
Contributor

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 ‘~’.

@blurfl
Copy link
Collaborator

blurfl commented Nov 15, 2019

This is a non-trivial problem and GC/Maslow firmware differs from grbl in that grbl doesn't support the M6 gcode. I guess the essence of this issue is that the Maslow firmware doesn't really handle it either.

grbl users mostly handle the situation by breaking their job into separate files for each tool. Some gcode creation programs will automatically create separate files (CamBam?).

GC could scan a file on first loading, and warn the user that the tool change is problematic, suggesting re-creating the job as separate tool files. I think that generating the separated tool files is beyond what GC is meant to do.

@madgrizzle
Copy link
Contributor Author

What I plan to do on webcontrol is the following (unless someone has a better answer) because it doesn't affect the firmware.

  • If buffering gcode is DISABLED, upon parsing the 'Maslow Paused' message, set uploadFlag to 0 and send a '~'. This will kick the controller out of the pause loop allowing it to accept move commands.

  • If buffering gcode is ENABLED, upon parsing the 'Maslow Paused' message, set uploadFlag to 0 and DO NOT send the '~'.. therefore the controller will stay in the pause loop and not execute buffered gcode. All commands to move will be ignored by webcontrol.. they won't be sent to the controller.

If the user is wanting to enable buffer gcode AND do tool changes, they will have to use collets to set the bits to the exact correct height. There will be no ability to raise or lower the z-axis to set zero. If the user doesn't enable buffer gcode, then there is no harm in kicking the controller out of the pause loop since the uploadFlag is 0 until the user hits resume.

@madgrizzle
Copy link
Contributor Author

I think the solution, as @blurfl, suggested on the forum is to send the '~' immediately upon receiving a 'Maslow Paused' but also add a hook in serialPortThread to look for "M" commands that would cause the controller to pause and set uploadFlag to 0.

@BarbourSmith
Copy link
Member

That sounds good to me, although I am a little worried that with so many moving parts there we could end up in an unexpected state somehow, so some testing is in order

@ersdds
Copy link

ersdds commented Apr 27, 2020

I' m not sure if this is the same issue, since I have only just got my machine set up, but I am having a problem in tool change. I have touch zero control off of aux4. The code pauses for a tool change. I replace the tool and go into Z axis control. I use touch zero to set the new tool Z to Zero. Press resume cut....and nothing🤔. Just sits there. I tried to advance lines of code and press play...still nothing😥. (Is there any way to display line numbers of code in Ground Control?) Am I doing something wrong or is that the issue you are talking about? If it is, I am confused as to how the problem didn't come up earlier. Therefore, I must be doing something wrong. Can you tell me how you are supposed to Zero a new tool and resume play of G-code? Thanks

@madgrizzle
Copy link
Contributor Author

Which version of webcontrol?

@madgrizzle
Copy link
Contributor Author

Sorry, thought this was a webcontrol issue (was reading from phone)

@ersdds
Copy link

ersdds commented Apr 27, 2020 via email

@madgrizzle
Copy link
Contributor Author

The simplest is way is to download, extract, and run the single file version from here:

https://github.com/madgrizzle/WebControl/releases/tag/v0.932

Feel free to post a message on the maslow forums if you need help. Make sure to post within the Software->WebControl portion of the forum as I tend to notice those messages more.

@ersdds
Copy link

ersdds commented Apr 27, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants