CraftBot - M110 S1
Hello!
At my workplace we use 4 CraftBot XL 3D printers with repetier, and they work OK.
I have 2 problems:
1 :
CraftBot has an unique command, M110 S1 and M110 S2. This command should set the display to "Remote Printig", but only M110 sent to the printer.
Is there any way to force Repetier to send the command without autocorrection to get line number?
2:
All of the print coming with Repetier server came out "Squareish", every round dimensions get rough parts, like the resolution is too low. But when the same thing printed from SD/USB, there is no such problem. It's like the printer having micro-pauses before moving. What coud cause the problem?
Thank you in advance.
At my workplace we use 4 CraftBot XL 3D printers with repetier, and they work OK.
I have 2 problems:
1 :
CraftBot has an unique command, M110 S1 and M110 S2. This command should set the display to "Remote Printig", but only M110 sent to the printer.
Is there any way to force Repetier to send the command without autocorrection to get line number?
2:
All of the print coming with Repetier server came out "Squareish", every round dimensions get rough parts, like the resolution is too low. But when the same thing printed from SD/USB, there is no such problem. It's like the printer having micro-pauses before moving. What coud cause the problem?
Thank you in advance.
Comments
Before print job starts:
#M110 S1
should prevent the interpretation and side effects. Strange idea to misuse such a standard g-code. Anyhow that should do the trick.
2: We send same commands as with usb so shape in general should be identical. What can differ is the speed used during print. Especially if curves have many very tiny moves and communication with the printer is slow this can cause the printer move buffer to drain causing slower speeds. To improve communication data you can disable ping pong mode with probably 127 byte input buffer. In printer settings->General->Communication there is a test wizard that tests error rate and lines per second possible. Other solutions would be slower outer perimeter speed or higher minimal movement length per command. Any of these would reduce effects from lower movement buffer. Sometimes over optimization with higher resolutions is counter productive. At least if you produce the stl models your self the exporter of cad software often allows setting how many triangles to generate on curves and here you need to find a balance between visible, size and speed.More segments then visible just add extra problems as you hopefully see with the reasoning.
Did not know they have own firmware so far. Always thought they use marlin. Found
https://support.craftbot.com/hc/en-us/articles/360007748177-CraftBot-FLOW-Generation-G-M-code-cheatsheet
but that's not much information. It evens says M110 S0 for start and M110 S2 for stop.
Do they send/use line numbers?
Which firmware are you using as base? Marlin? Is the response on communication errors correctly working?
We have a configuration driven firmware description, so if it behaves differently from marlin I can make a separate firmware description for it if needed, but not having such a printer it is a bit difficult.
1: Thanks, it worked !
2: Here is some pictures of what I mean about artifacts/squerish round parts: https://photos.app.goo.gl/QuDAzTNM7wSZJ1eq6
About speed: When adjusting printig speed multiplier (to 90-80%), the curved sides still get fragments.
I tired it using with Ping-Pong, and whitout, and here is my observation:
Ping-Pong: works great, pause, start, stop, works well.
Not Ping-Pong, 127 Byte buffer, max 1 paralell connection: Sometimes works great, start, stop, pause, sometimes doesnt start print after homing, sometimes can't pause print untill the buffer is empty, then it cannot be un-paused/started again, needs to be powered off and on again.
Same with 2 paralell: same as 1 paralell.
When testing the connection, all config comes back as working.
Also using RepRapFirmware option, because thats the most stable. Still gives some error messages:
[...]
After a while, the error gone, but the printing is not affected.
When using Marlin firmware option, it's a gamble again. Sometimes start, sometimes doesn't.
As much as I can see, it doesn't send back line numbers, only when there is an error. The Original CraftWare Printer software doesn't send line numbers: https://photos.app.goo.gl/X9FDaZf5SQWKZFf9A
I would thank you if you can make a firmware descprition for it, and I would love to help you out.
Marton
Firmware seems to be real unique Does not look like anything I know.
Log looks like it was with parallel commands so hard to say which answer belongs to what, but M400 seems not supported but is often used. M400 waits for end of moves. There exists no such command in the list I found. You should in printer configuration->g-codes->replacements add
^M400$
and replace it with
G4 P0
At least other firmwares do also wait for end of moves with G4 so maybe here the same. In any case you get no error messages from sending M400 any more.
that is a bit unclear. 2 ok for one command is not good in any case. Also line 111 when we just send line 281 is strange.
I will tomorrow write a mail to craftware and ask them if it is possible to get some more information on this topic. Hopefully I get some good infos or even contact to the developer.
You should activate logging and run a print with your curves. If you send me the log I might be able to extract more from it. It might be that during curves there is more communication like error messages due to wrong/unsupported commands. That could also drop transfer and cause the pauses/speed reductions.
The speeds are:
Ping-Pong: 969.4/ 3,252.6 / - Lines/s
W/o Ping-Pong, 1 Paralell, 127 Byte : 963.8 / 3,045.2 / - Lines/s
W/o Ping-Pong, 2 Paralell, 127 Byte : 1,304.3 / 3,385.4 / - Lines/s
I use Prusa Slicer, and the G-Code resolution is : 0.0125mm. Is that what you mean by segment size?
I can get all suported command from the printer through the terminal, they are the following:
I replaced the M400 with G4 P0, and seems like the errors have been gone. But not the artifacts, they are on it, no matter if Ping-Pong or Paralell.
https://photos.app.goo.gl/5YhZuX1LWFQQJAxe9
The logs are here: https://drive.google.com/drive/folders/1v_nJFy__YuMqEL1hxeAt0le1x6OUJi6Q?usp=sharing
Aftere these, I tried the same setting on the other 3 printers, and I found out, that SOMETIMES, I dont know why, but they print fine, but sometimes, they print fine for a while.... Left to right, Some artifacts, all atifacts, all good. All printed from Repetier, same sliced G-Code, same printer setting on the server side. https://photos.app.goo.gl/HTc3aMWcPTNbKb1z9
Thank you for helping out and contacting Craftware!
Marton
> I use Prusa Slicer, and the G-Code resolution is : 0.0125mm. Is that what you mean by segment size?
Not really. This is something different I think. That is the xy resolution it tries to achieve and any deviation smaller than that gets ignored. This has indirect influence on segment sizes, but is I mean the length of a G1 move being send to printer.
Example from log:
Send:13:08:29.010: N10469 G1 X160.679 Y108.486 E1.10474
Conmparing the first 2 moves:
G1 X160.432 Y108.668 E1.11512
dx = 0.247, dy = 0.182 => move length = sqrt(dx*dx+dy*dy) = 0,493mm
Now if printer has 16 moves buffered and all have lets say 0.5mm length incurves we can buffer a maximum of 16*0.5 = 8mm of movement. To decelerate to 0 with 3000mm/s (which is fast but what you defined)
Speed is 1200mm/s = 20mm/s
v = a * t => t = v / a = 20 / 3000 = 0.0667s
s = 0.5 * a * t^2 = 0.5 * 3000 * 0.0667^2 = 6.667mm
So to change speed from 20mm/s to 0 you need a distance of 6.67mm buffered ahead. The unknown is how firmware internally works so how many moves do they buffer, any tricks that reduces it. Jerk in other firmwares also reduces speed and we must also accelerate.
Now look at these 2 moves
dx = 0.06mm, dy = 0.026 => l = 0,065mm
That is surely too small if you have a bunch of them in a row.
You should have a look at your model. Did you create it your self? Normally you can see the segments if you open it in 3d. Every triangle along the constant z becomes a move so triangle size results in move size. And at least these models have too small gcodes resulting in that problem. What I don't understand so far is why sd printing helps here. Even with 300lines/s * 0,065 = 19,5mm/s so nearly the speed you have. But that will only the craftbot programmer be able to answer I guess. Or there are even smaller moves. Did not compute it for all lines of course. But in general that is what is happening here.
So firmware does not like P in M106 I guess. We use Px to select fan. They are using Tx for the fan id. You could fix it with this replacement rule:
^M106 (.*)P(.*)
Replaced by
M106 @1T@2
At least I think that should do as it is untested.
But the other prints (holder for scales) was generated in Solidworks, exported to 3MF, and after measuring, it has 1,96 segment size. But that still doesn't answear, why is it sometimes smooth, sometimes artifacted. all of the 3 pieces was printed with Repetier, same speed, same file, same settings: https://photos.app.goo.gl/h8tYGpAcezKeeKHq9
A video of the printig, its like micro-pauses every time it changes direction: https://photos.app.goo.gl/e5yzbmM41jDe6p9S8
I try the M106 replacement, but I'm not gona be online before monday, 30.05.2022.
The other thing is, when using (the problematic) original CraftPrint software to print through USB, the prints came out fine.
I try again all the 4 printers with same setting again with Repetier, with Craftprint and with SD.
(but I have a faint feeling it will be something with windows)
When you test CraftPrint do you with same g-code or generated by CraftSlicer? It might be that they reduce segments in either software to improve quality. Actually something I think about as well for server as this is a known problem to quality and since there is no indication of errors it is just a limit we have to work around. Either by coarser exported stl or reducing during slicing or sending g-code. The reason why sd card might be more constant is that there is no uncalculateble delay between lines receiving so it goes to a constant speed. Here a millisecond difference can make the pattern start or not start.
Soo...
I concluded a big test, half a day worth.
My conclusion is wierd.
You will see a spreadsheet in the drive folder, I concluded every try there with notes.
TL/DL: Using Marlin settings makes print better if it starts, but getting more error. Even CraftPrint makes wierd things.
Attached Pictures, most important logs, Printer config, .stl of test piece and .sldprt files, and .gcode.
https://drive.google.com/drive/folders/1KuYEw8YB5_vX1EKRwyVxU4nxCqvIj8Li?usp=sharing
What is the diference in communication between Marlin and RepRap, which makes it better?
Marlin gives more error, like:
Can you tell me what M115 would return. That seems the only command allowing detection of some features or distinguishing it from other firmwares.
That is misleading:-( It clearly comes from M73 that uses here prusa style time in addition.
You can download the new firmware description for testing:
https://www.dropbox.com/t/iRun1ItQjyQNOOYX
Place it in ServerInstallDir/firmwares and restart server so it gets read. Then select that firmware in stead. No replacements should be needed so far. With M115 response I might be able to improve a bit.
Marlin or RepRapFirmware should make no difference except with maybe errors from wrong codes that should be removed with new firmware description. What can make a difference is having 2 parallel commands allowed. This as you also tested can increase speed. But there is one problem with it - since we get no feedback about lines we will never see if one command was not seen due to com errors. So from such a point there would be only one command in reality making it as fast as ping pong. On the other side I have not seen any com errors in log so far, so seems very good communication quality.
What bothers me a bit is your frozen from start comment. Would be good to test before printing in console if you get answers e.g. to M114 so we know communication was ok before print start. Normally frozen on other printers is waiting for target temperature where it stops. But you should see the M-Code being send at least. If you have console with commands and ack enabled open in a second window you should have no problems seeing this correctly. The switch between connected.log and print.log might eventually swallow a command, but not an open console.
If you see any error or unusual responses, please let me know and I add them to firmware file. After all I just build it from only what you showed me and it has surely many useless responses that firmware will never send, but should at least work correct now.
But when starting with Marlin option (2 paralell, 127 Byte), it starts heating up, and print way better than Rep/Rap option (PingPong), without the micro-pauses (left Marlin option, right RepRap option : https://photos.app.goo.gl/eY2RNLBZTz4moe497 )
M115 returns this:
PROTOCOL_VERSION:0.1 FIRMWARE_VERSION:1.1.12376 FIRMWARE_NAME:pr3Dator MACHINE_TYPE:CraftBot EXTRUDER_COUNT:1
Also, more things I just found out:
M110:
When using M110 S1, it changes the printer screen to manual mode.
But using M110 S2 doesn't change back the screen to manual mode, even if it was written in the documents.
It has to bee M110 S0 THEN M110 S2. Weird.
M73:
Prusa Slicer doesn't add M73 to the gcode, I think Repetier adds it to it.
M73 also only accepts P and S. Testing it, M73 Px doesn't change anything. M73 Sx changes the percentage on the display.
M112:
Printer doesn't support emergency stop... We will look after adding MQTT support to our program (which can switch the power to the printers). Is it possible to send a MGTT trigger when pressing the emergency button?
M84 and M18 seems indiferent for the printer, both turn off the steppers.
M73 has added params for prusa printers. Prusa slicer can add them as well, but we do it also same style with marlin.
RepRapFirmware or marlin should not really differ. parallel/ping pong is completely firmware independent. Only difference are the default commands for both firmwares and expected responses that differ.
I made some more changes as I saw M117 was not good and also disabled some RepRapFirmware special things.
Here latest version:
https://www.dropbox.com/t/lp3lz0u6yhDTvPC3
You should not directly start printing. What I would really need is first just connect and a console log where you try single commands like heating, moving etc. to see if they are good. When you print not much matters as we mainly send gcode as it is, just M117/M73/M105 gets added depending on settings from us during print.
I also change M110 to S0 and S2 hoping it now works as expected. It is already included in craftbot definition.
Thanks for the MQTT, I will look into it!
M73:
M73 seems good now, thanks!
Firmware:
I tested the new Firmware option on all printers, and I FOUND THE problem.... It was never the errors, or the communication type, it was the queue. In the official craftbot doccumentation to how to use it with octoprint there is this:
And I used it in the run before job section.
So now when I went back to comment out the M110 S1 line, I commented out the M1020 S1 too. And where I commented out M1020, it fixed the micro pauses problem.
Soo I guess this was the biggest problem after all.
Here is a log of the connection, testing homing, mooving, and some commands (in the server log there are a lot of "postRequest:Connection refused", probably because the server is not connected to the internet): https://drive.google.com/drive/folders/185jGwldt_dBlXyaHEH0b-J57kUhwPKMP?usp=sharing
Everything seems to work nice now.
Starting the printing directly starts heating, and not freeze any more.
M110:
Sorry if I was ambiguous/missleading, what I meant was:
Starting the printing needs "M110 S1".
Ending the printing needs "M110 S0" and then "M110 S2" (Needs both command to change back screen from external printing).
Ending the printing originally only needs M110 S2, but... It doesnt work. But if I send M110 S0 and then M110 S2, it works.
https://www.dropbox.com/t/QXXgVU5V0oNBAx8i
Now enable queue on serial connection. Unclear what it does, but if it improves communication speed it should be enabled all the time I think. Also added the M110 commands as well as you described. So now it should work without special extra script code.
Also found the "postRequest:Connection refused" reason. It is the license verification that retries until it sees a server. I have silenced the test now as that is an allowed condition and should not bother users.
Sorry, maybe I was misleading again:
The Queue enabling M1020 is worsen the print quality, and doesn't add anything to the communication. Here is a example: https://photos.app.goo.gl/oyraw6C5U5J3A7eV8
I was soo close to perfection, so I made myself some modifications in the firmware description file, I hope you dont mind:
-Removed "M1020 S1"
-Removed "M107" from everywhere, because this made it freeze sometimes.
Also made 2 more G-Code replacement, here is the full list of replacements:
^M400$ -> G4 P0
^M106 (.*)P(.*) -> M106 @1T@2
M107 -> ;[nothing]
^M107 -> ;[nothing]
The communication is set back to PingPong again, as it seems the most stable.
Every other communication settings and the "G-Code before and after" is in the Craftbot_Printer.xml printer configuration file.
Now every printer can print at the same time, and every functions works.
Here is the last Firmware description .xml and a Printer configuration .xml if needed:
https://drive.google.com/drive/folders/1IFQgagI-Mz0GCsGvlv6duKpfDYkvfvaF?usp=sharing
And here is a video of the 4 printers printing at the same time, and a photo of the results:
https://photos.app.goo.gl/1RBDdNd8AZGYiAL78
This was a journey, but thanks again for everything!
If anything else needed, help or testing, I'm happy to help.
Have a nice day, take care of yourself!
M107 has a purpose, but can be replaced by M106 S0.
I have put all in next update. I have also internal replacements now programmed for M400/M106/M107 replacements of you, so with next update they should not be required any more. I did this because normal users won't know about them and would not add it.