-
Notifications
You must be signed in to change notification settings - Fork 4
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
Craftbot: print3d hangs after M104 because the response is interpreted as a M105 response #36
Comments
After sending Relevant part of the log
Print3D seems to think the response Please advice users about this current workaround. |
But why doesn't this happen with the start gcode? This should also contain a temperature change command. |
My theory is that when it just misses 1 normal 'ok' (because of the On Mon, Feb 15, 2016 at 7:02 PM, Peter Uithoven [email protected]
|
But, there is no such queue? It only advances to the next line when it receives an ok. If we miss one ok it should just stop sending lines. I don't understand what triggers print3d to send the next line. |
I think you're right Peter. It was the prototype where send 5 lines at the On Mon, Feb 15, 2016 at 8:44 PM, Peter Uithoven [email protected]
|
In https://github.com/Doodle3D/doodle3d-firmware/blob/master/src/conf_defaults.lua#L225 there does not seem to be a |
Attached is the log of sevaral sucessful prints. @peteruithoven wanted to checkout the |
As requested the relevant part of the log.
Ending code:
|
Craftbot(Using Pronterface) Marlin default start gcodeSet nozzle target temperature marlin default end gcodeSet nozzle target temperature Marlin preheat / heatup command:Same g-code as start gcode. Regulier commando, zoals Ultimaker2(Using p3d on WiFi-Box because of baudrate) So sending |
Quick options:
I'll check if the Craftbot software uses a special cooldown gcode command. |
The g-code from CraftWare ends with:
So this uses a regular |
Sending |
A workaround for now would be to use an M109 S180 in Doodle3D's end-code for the CraftBot. |
I got a response from CraftUnique. Their experiment shows that M104 S180 returns 'ok T:21' which is not according to the RepRap specs but still it does return something. I confirmed this by connecting the CraftBot to my Mac and opening the Arduino IDE's Serial Monitor. It gives this response indeed when using the correct line-endings (LF). |
Interesting: Sending an |
Can you see in Processing whether the response line-feed is the same after a M104 and a M115 for example? |
The response ends in both cases with a line-feed (ASCII character 0x0A) |
As the response to an
|
We've also confirmed that we do receive a response from the Craftbot when sending a |
Currently, in the marlin driver, we have 2 communication "lines" to a printer. One in which we occasionally check the temperature and one in which we send the buffered gcode commands. See our drivers docs for more info. Where we parse responses: It's probably useful to build on the upcoming gcode buffer improvements, since includes a lot of gcode buffer changes and improvements. |
We did do a commit where we added custom endcode for the craftbot, where we replaced the M104 with a M109. But as mentioned above this is a waiting / blocking command, so the user can only do something else after is has reached the preheat temperature. |
The Craftbot firmware has some small differences causing print3d to hang. For example "M104 S200" returns ok wíth temperature which is different from Marlin. Here's (http://reprap.org/wiki/G-code#M104:_Set_Extruder_Temperature) a description of M104 on the RepRap site.
The text was updated successfully, but these errors were encountered: