CraftBot - M110 S1

matoth

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.

matoth

For the first question, this is the g-code that should be sent:
Before print job starts:

			T0 ; select head 1 
			M110 S1 ; initialize the printer and the display
			G28 ; Home all axes
		        M1020 S1; Set queue 1

Repetier

In server prepend # to line to send it 1:1 without interpretation of server. So
#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.

matoth

Thank you for the answears!

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:

[...]

Send:13:13:00.101: Slow command added:M400

Send:13:13:00.101: N111 M400

Recv:13:13:00.101: ok X:0.00 Y:0.00 Z:0.00 E:0.00

Send:13:13:00.101: Slow command added:M400

Send:13:13:00.101: N112 M400

Recv:13:13:00.101: ok Q:256

Send:13:13:00.101: Slow command added:M400

Send:13:13:00.101: N113 M400

Recv:13:13:00.101: ok Q:256

Send:13:13:00.101: Slow command added:M400

Send:13:13:00.101: N114 M400

Recv:13:13:00.116: ok Heat maximum temperature=300

Send:13:13:00.116: Slow command added:M400

Send:13:13:00.116: N115 M400

Recv:13:13:00.116: ok Plane Acc:3000, Dec:3000 MinFeed:1200

Send:13:13:00.116: Slow command added:M400

Send:13:13:00.116: N116 M400

Recv:13:13:00.116: ok Q:256

Send:13:13:00.116: Slow command added:M400
[...]

Send:13:13:00.800: N278 G1 X178.599 Y99.968 E7.99884

Recv:13:13:00.800: ok ?: Unsupported command: M400

Recv:13:13:00.800: ok ?:Line: 110/11 Syntax error, char: '3' (0x33) :

Send:13:13:00.800: N279 G1 X179.341 Y101.813 E8.07211

Recv:13:13:00.800: ok ?:Line: 110/12 Syntax error, char: '4' (0x34) :

Send:13:13:00.800: N280 G1 X179.807 Y103.983 E8.15388

Recv:13:13:00.800: ok ?: Unsupported command: M400

Send:13:13:00.800: N281 G1 X179.888 Y106.084 E8.23132

Recv:13:13:00.800: ok ?:Line: 111/11 Syntax error, char: '3' (0x33) :

Recv:13:13:00.800: ok ?:Line: 111/12 Syntax error, char: '5' (0x35) :

Send:13:13:00.800: N282 G1 X179.635 Y108.057 E8.3046

Recv:13:13:00.800: ok ?: Unsupported command: M400

Send:13:13:00.800: N283 G1 X179.376 Y109.072 E8.34318

Recv:13:13:00.800: ok ?:Line: 112/11 Syntax error, char: '4' (0x34) :

Send:13:13:00.800: N284 G1 X178.599 Y111.032 E8.42087

[...]

Recv:13:13:00.800: ok ?:Line: 117/11 Syntax error, char: '3' (0x33) :

Send:13:13:00.800: N298 G1 X156.907 Y111.949 E9.39399

Recv:13:13:00.800: ok ?:Line: 117/12 Syntax error, char: '8' (0x38) :

Send:13:13:00.800: N299 G1 X156.401 Y111.032 E9.43257

Recv:13:13:00.800: ok X:0.00 Y:0.00 Z:0.00 E:0.00

Send:13:13:00.800: N300 G1 X155.659 Y109.187 E9.50584

Recv:13:13:00.800: ok Q:256

Send:13:13:00.800: N301 G1 X155.193 Y107.017 E9.58761

Recv:13:13:00.990: ok Q:251

Send:13:13:00.990: N302 G1 X155.112 Y104.916 E9.66506

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</div></div> I would thank you if you can make a firmware descprition for it, and I would love to help you out.

Marton

Repetier

Ok, first the curves look like segments are not that short or they add pauses in between. What you see is acceleration/deceleration which causes extrusion thickness to change (that is what advance in firmwares tries to compensate). What is the speed you get in ping pong mode? If you multiply this with minimal segment size you see what we can send as movement command per second, also many moves are of course longer. This is just for getting an idea. With marlin it is normally no problem to get 200-300 lines/s. Depends a bit on operating system and latency for sending new usb packages.

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.

Send:13:13:00.800: N281 G1 X179.888 Y106.084 E8.23132

Recv:13:13:00.800: ok ?:Line: 111/11 Syntax error, char: '3' (0x33) :

Recv:13:13:00.800: ok ?:Line: 111/12 Syntax error, char: '5' (0x35) :

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.

matoth

Yes, they looks like segments.
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:

Recv:13:00:48.779: - G1: Linear move: E F S X Y Z

Recv:13:00:48.779: - G0: Linear move: E F S X Y Z

Recv:13:00:48.779: - G4: Dwell: P S

Recv:13:00:48.779: - G20: Set units to inches.

Recv:13:00:48.779: - G21: Set units to millimeters.

Recv:13:00:48.779: - G28: Move to origin: X Y Z

Recv:13:00:48.779: - G69: Random XY Killer: L Q S U V X Y

Recv:13:00:48.779: - G90: Set to absolute positioning.

Recv:13:00:48.779: - G91: Set to relative positioning.

Recv:13:00:48.779: - G92: Set position: E X Y Z

Recv:13:00:48.779: - G101: Relative linear move: E F X Y Z

Recv:13:00:48.779: - G197: Pause.

Recv:13:00:48.779: - M18: Disable stepper motors.

Recv:13:00:48.779: - M82: Set extruder to absolute mode.

Recv:13:00:48.779: - M83: Set extruder to relative mode.

Recv:13:00:48.779: - M84: Stop idle hold.

Recv:13:00:48.779: - M106: Turn cooling fan on: S

Recv:13:00:48.779: - M104: Set extruder temperature: H L S T

Recv:13:00:48.779: - M109: Set and wait head temperature: S T

Recv:13:00:48.779: - M1400: Start heating and waiting: B E H P Q T

Recv:13:00:48.779: - M107: Turn cooling fan off.

Recv:13:00:48.779: - M110: Print Start or Stop: S

Recv:13:00:48.779: - M114: Get current position.

Recv:13:00:48.779: - M115: Get firmware version.

Recv:13:00:48.779: - M140: Set bed temperature: H L S

Recv:13:00:48.779: - M190: Set and wait bed temperature: S

Recv:13:00:48.779: - M220: Set speed override percent: S

Recv:13:00:48.779: - M221: Set extrusion override percent: S

Recv:13:00:48.779: - M300: Play beep sound: P S

Recv:13:00:48.779: - M900: Linear advance beta version: A D K

Recv:13:00:48.779: - M906: Set motor currents: E H R X Z

Recv:13:00:48.779: - M907: Set decay mode: A B E Z

Recv:13:00:48.779: - M73: M73 progressbar refresh: P S

Recv:13:00:48.779: - M1001: Get Printer Version.

Recv:13:00:48.779: - M1002: Get unique ID: S

Recv:13:00:48.779: - M1003: Get firmware version: S

Recv:13:00:48.779: - M1004: Get HMI version.

Recv:13:00:48.779: - M1005: Get HMI board version: S

Recv:13:00:48.779: - M1006: Set limits s=1 Case / S=2 Head: H L S

Recv:13:00:48.779: - M1014: Get ADC values: S

Recv:13:00:48.779: - M1015: Get PWM duty.

Recv:13:00:48.779: - M1114: Get machine coordinates.

Recv:13:00:48.779: - M1115: Get queue.

Recv:13:00:48.779: - M1123: Set T7 pin high or low: S

Recv:13:00:48.779: - M1160: Fan control (Case,Head,Obj): C H O

Recv:13:00:48.779: - M1200: Set feed properties: F H L

Recv:13:00:48.779: - M1201: Set axis ratio: E X Y Z

Recv:13:00:48.779: - M1202: Set axis soft limit: E X Y Z

Recv:13:00:48.779: - M1203: Set XY acceleration: A D F

Recv:13:00:48.779: - M1204: Set Z acceleration: A D F

Recv:13:00:48.779: - M1210: Set extruder correction: F K

Recv:13:00:48.779: - M1212: Set thermal runaway: Q S

Recv:13:00:48.779: - M1300: Set extruder PID: D F I P W

Recv:13:00:48.779: - M1301: Set bed PID: D F I P W

Recv:13:00:48.779: - M5000: Set jog feed: X Z

Recv:13:00:48.779: - M5001: Set mechanical parameters: E X Z

Recv:13:00:48.779: - M7001: Set WIFI SSID/Pass.

Recv:13:00:48.779: - M7005: Set e-mail address.

Recv:13:00:48.779: - M7008: Overwrite Wi-Fi SSID.

Recv:13:00:48.789: - M9090: Set parser limits: S X Y Z

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

Repetier

Impressive speed. So ping pong ist already faster as many other printers who have no artefact problems. So it is not really communication speed.

> 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:28.995: N10468 G1 F1200

Recv:13:08:28.995: ok Q:256
Send:13:08:29.010: N10469 G1 X160.679 Y108.486 E1.10474

Recv:13:08:29.026: ok Q:256

Send:13:08:29.026: N10470 G1 X160.432 Y108.668 E1.11512

Recv:13:08:29.042: ok Q:256

Send:13:08:29.042: N10471 G1 X160.215 Y108.87 E1.12516

Recv:13:08:29.068: ok Q:256

Send:13:08:29.068: N10472 G1 X160.198 Y108.93 E1.12727

Recv:13:08:29.074: ok Q:256

Send:13:08:29.074: N10473 G1 X160.138 Y108.956 E1.1295

Recv:13:08:29.081: ok Q:256

Send:13:08:29.081: N10474 G1 X159.923 Y109.22 E1.14102

Recv:13:08:29.102: ok Q:256

Send:13:08:29.102: N10475 G1 X159.802 Y109.423 E1.14902

Recv:13:08:29.118: ok Q:256

Send:13:08:29.118: N10476 G1 X159.652 Y109.134 E1.16004

Recv:13:08:29.128: ok Q:256

Send:13:08:29.128: N10477 G1 X159.381 Y108.48 E1.184

Conmparing the first 2 moves:

G1 X160.679 Y108.486 E1.10474
G1 X160.432 Y108.668 E1.11512
dx = 0.247, dy = 0.182 => move length = sqrt(dxdx+dydy) = 0,493mm

Now if printer has 16 moves buffered and all have lets say 0.5mm length incurves we can buffer a maximum of 160.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² = 0.5 * 3000 * 0.0667² = 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

Send:13:08:29.068: N10472 G1 X160.198 Y108.93 E1.12727

Recv:13:08:29.074: ok Q:256

Send:13:08:29.074: N10473 G1 X160.138 Y108.956 E1.1295
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.

Also I see no real errors in ping pong variant, only:

Send:13:08:28.614: N10455 G1 Z1.24 F6600

Recv:13:08:28.691: ok Q:256

Send:13:08:28.691: N10456 M106 P0 S252

Recv:13:08:28.691: ok ?: Invalid item for G1: P

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.

matoth

The test cylinder is created in Prusa slicer, when inported to Solidworks, it show a 0,3mm segment size: https://photos.app.goo.gl/JFdXhEdqge9WHgrk6 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)

Repetier

On video it looks quite smooth, so no real pauses. I think it is just the acceleration/deceleration pattern for short segments. 0.3mm segment size is just too much for most printers. You already print slow and I think if you use speed multiplier in server at some point it will start to get smooth again.

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.

matoth

Thank you soo much for the much needed help!

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:

Send:15:18:00.471: N422 G1 X174.93 Y116.873 E5.75089
Recv:15:18:00.486: ok Q:239
Send:15:18:00.486: N423 M73 P58 R5 Q58 S5
Recv:15:18:00.486: ok ?: Invalid item for G1: R
Send:15:18:00.486: N424 G1 X174.421 Y117.608 E5.78385
Recv:15:18:00.486: ok ?: Invalid item for G1: Q
Send:15:18:00.486: N425 G1 X173.867 Y118.31 E5.8168

But still maneges to bee better somehow.
What should I change, or add more G-Code replacements?

Repetier

I'm just working on making a firmware description with RepRapFirmware.xml as base but without the unsupported commands and wrong commands replaced. I also added detection of unsupported commands so they get detected and removed on second appeareance. For next release also M110 Sx will prevent special handling in server.

Can you tell me what M115 would return. That seems the only command allowing detection of some features or distinguishing it from other firmwares.

Recv:15:18:00.486: ok ?: Invalid item for G1: R

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.

matoth

I just tested the Craftbot Firmware option you made, but it freezez when it starts. And not waiting for heat up, because the display shows that it's just waiting for... something. I tired to manually send some commands, but it doesn't react to anything. Not even #M110 S2. Video: https://photos.app.goo.gl/UX9Zn79NTuCiyKDM6 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.

matoth

Sorry for leading you in the RepRap direction, I was blindfolded at the start because RepRap could work in PinPong and Paralell, but I stopped testing Marlin at the paralell, and only now after we started to talk I tested the Marlin Paralell, which is way better.

Repetier

First simple thing. MQTT trigger is easy. You can use gcode replacement and just replace M112 by the server mqtt command that triggers your power script. If you check server commands you see that we also support sending mqtt if you are connected with mqtt server.

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.

matoth

MQTT:
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:

Before print job starts:

T0 ; select head 1

M110 S1 ; initialize the printer and the display

G28 ; Home all axes

M1020 S1; Set queue 1

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.

Repetier

Thanks for the update. I have made a new firmware version with the new informations

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.

matoth

Thanks for the update too!

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!

Repetier

I see you get the hang of the flexible configuration possibilities:-)

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.