Initial over temperature situation on I3B with Server but not with Host

This is the first I've noticed this.  I have a simple tube design stl file that I slice with Slcr3 using Host then save the gcode to a file and print the file from server to my I3B Pro (GeeeTech).  Upon initial print the hot end temp, which is set to 214 degrees, overshoots to 250 degrees.  Then the temperature quickly reduces to 214 degrees and printing continues normally for the entire print.  If I print the same design from within Host that overshoot does NOT occur.  The host printing has slightly diffrerent gcode syntax than the server version which I highlighted the hotend temperature sets in the the two communications scenarios happening between the PC and the printer below.  Any idea what is causing the server to behave this way.  I am very skeptical of leaving the printer alone when I see temperature overshoots like this.  I do not believe this is a hardware issue since printing from the host doesn't have the overshoot.

Server version (bad);
Recv:10:57:01.820: echo: External Reset
Recv:10:57:01.820: Marlin1.0.2
Recv:10:57:01.820: echo: Last Updated: Apr 9 2017 10:03:00 | Author: (geeetech, I3 config)
Recv:10:57:01.820: Compiled: Apr 9 2017
Recv:10:57:01.820: echo: Free Memory: 3748 PlannerBufferBytes: 1232
Recv:10:57:01.820: echo:Stored settings retrieved
Send:10:57:01.820: N1 M110
Send:10:57:01.820: N3 M115 ; Get firmware capabilities and info
Send:10:57:01.820: N4 M220 S100 ; Speed multiplier 100%
Send:10:57:01.820: N5 M221 S100 ; Flow multiplier 100%
Send:10:57:01.820: N6 G92 E0
Send:10:57:01.820: N7 G90
Send:10:57:01.820: N8 M82
Recv:10:57:05.263: echo:SD init fail
Send:10:57:05.263: N9 G21 ; Use mm as unit
Recv:10:57:05.325: FIRMWARE_NAME:Marlin V1.0.2; Sprinter/grbl mashup for gen6 FIRMWARE_URL: PROTOCOL_VERSION:1.0 MACHINE_TYPE:Allen 3D EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
Send:10:57:05.325: N10 M114
Send:10:57:05.325: @getip
Recv:10:57:05.341: X:0.00 Y:0.00 Z:0.00 E:0.00 Count X: 0.00 Y:0.00 Z:0.00
Send:10:57:05.341: M117 M117 Finished
Send:10:57:05.341: M117
Send:10:57:15.071: N22 M75
Send:10:57:15.071: N23 M73 P0 R88 Q0 S88
Send:10:57:15.071: Slow command added:M190 S60 ; set bed temperature and wait for it to be reached
Send:10:57:15.071: N24 M190 S60 ; set bed temperature and wait for it to be reached
Send:10:57:15.071: N25 M104 S214 ; set temperature
Send:10:57:15.071: Slow command added:G28 ; home all axes
Send:10:57:15.071: N26 G28 ; home all axes
Send:10:57:15.071: N27 M114
Send:10:57:15.073: N28 G1 Z5 F5000 ; lift nozzle
Send:10:57:15.089: Slow command added:M109 S214 ; set temperature and wait for it to be reached
Send:10:57:15.089: N29 M109 S214 ; set temperature and wait for it to be reached
Send:10:58:20.943: M117 ETA 12:15:14 day 24
Recv:10:59:03.560: X:0.00 Y:0.00 Z:0.00 E:0.00 Count X: 0.00 Y:0.00 Z:0.00

Host version (good);
11:11:38.632 : echo: External Reset
11:11:38.632 : Marlin1.0.2
11:11:38.648 : echo: Last Updated: Apr  9 2017 10:03:00 | Author: (geeetech, I3 config)
11:11:38.648 : Compiled: Apr  9 2017
11:11:38.648 : echo: Free Memory: 3748  PlannerBufferBytes: 1232
11:11:38.648 : echo:Stored settings retrieved
11:11:38.866 : N1 M110*34
11:11:42.112 : echo:SD init fail
11:11:42.112 : N2 M115*36
11:11:42.159 : FIRMWARE_NAME:Marlin V1.0.2; Sprinter/grbl mashup for gen6 FIRMWARE_URL: PROTOCOL_VERSION:1.0 MACHINE_TYPE:Allen 3D  EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
11:11:42.159 : N3 M105*36
11:11:42.175 : N4 M114*35
11:11:42.190 : X:0.00 Y:0.00 Z:0.00 E:0.00 Count X: 0.00 Y:0.00 Z:0.00
11:11:42.190 : N5 M111 S6*98
11:11:42.206 : N6 T0*60
11:11:42.221 : echo:Active Extruder: 0
11:11:42.221 : N7 M20*22
11:11:42.237 : Begin file list
11:11:42.253 : End file list
11:11:42.268 : N8 M80*19
11:11:42.268 : N9 M220 S100*104
11:11:42.284 : N10 M221 S100*81
11:11:42.299 : N11 M111 S6*87
11:11:42.346 : N12 T0*9
11:11:42.346 : echo:Active Extruder: 0
11:11:44.953 : N13 M105*21
11:11:48.013 : N14 M105*18
11:11:51.074 : N15 M105*19
11:11:54.132 : N16 M105*16
11:11:57.192 : N17 M105*17
11:12:00.283 : N18 M105*30
11:12:03.341 : N19 M105*31
11:12:06.400 : N20 M105*21
11:12:09.458 : N21 M105*20
11:12:12.533 : N22 M105*23
11:12:15.577 : N23 M105*22
11:12:18.729 : N24 M105*17
11:12:21.804 : N25 M105*16
11:12:24.863 : N26 M105*19
11:12:27.922 : N27 M105*18
11:12:30.981 : N28 M105*29
11:12:34.039 : N29 M105*28
11:12:37.114 : N30 M105*20
11:12:40.203 : N31 M105*21
11:12:43.247 : N32 M105*22
11:12:46.324 : N33 M105*23
11:12:49.383 : N34 M105*16
11:12:52.442 : N35 M105*17
11:12:55.502 : N36 M105*18
11:12:57.935 : N37 M140 S55*97
11:12:58.560 : N38 M105*28
11:13:01.619 : N39 M105*29
11:13:01.666 : N40 M140 S0*81
11:13:04.677 : N41 M105*18
11:13:07.736 : N42 M105*17
11:13:10.795 : N43 M105*16
11:13:13.853 : N44 M105*23
11:13:14.524 : Slic3r command:C:\Program Files\Repetier-Host\Slic3r\slic3r-console.exe --load "slic3r_settings.ini" --dont-arrange --layer-height 0.2 --fill-pattern honeycomb --top-infill-pattern rectilinear --bottom-infill-pattern rectilinear --fill-density 5.00 -o "composition.gcode" "composition.amf"
11:13:14.571 : Preferred name from fastentrs-short locking tube with flange to fastentrs-short locking tube with flange
11:13:15.352 : <Slic3r> => Infilling layers
11:13:15.352 : <Slic3r> => Processing triangulated mesh
11:13:16.881 : N45 M105*22
11:13:19.907 : N46 M105*21
11:13:21.810 : <Slic3r> => Preparing infill
11:13:22.512 : <Slic3r> => Generating brim
11:13:22.543 : <Slic3r> => Exporting G-code to composition.gcode
11:13:24.228 : N47 M105*20
11:13:27.287 : N48 M105*27
11:13:27.942 : <Slic3r> Done. Process took 0 minutes and 12.590 seconds
11:13:27.942 : <Slic3r> Filament required: 4418.9mm (10.6cm3)
11:13:27.973 : <Slic3r> Slic3r installed in a loclized path. Using an 8.3 path: "C:\PROGRA~1\REPETI~1\Slic3r\"
11:13:30.321 : N49 M105*26
11:13:33.380 : N50 M105*18
11:13:36.408 : N51 M190 S60*106
11:14:47.556 : N52 M105*16
11:14:47.566 : N53 M117 ETE 1h 31m 09s*10
11:14:47.586 : N54 M104 S214*83
11:14:47.606 : N55 G28*35
11:14:52.917 : N56 M117 ETE 1h 31m 09s*15
11:14:52.949 : N57 M105*21
11:14:52.964 : N58 G1 Z5 F5000*57
11:14:52.980 : N59 M117 ETE 1h 31m 09s*0
11:14:52.995 : N60 M109 S214*89
11:16:59.110 : N61 M105*16
11:16:59.125 : N62 M117 ETE 1h 31m 09s*8
11:16:59.141 : N63 G21*47
11:16:59.156 : N64 G90*34
11:16:59.172 : N65 M117 ETE 1h 31m 09s*15
11:16:59.203 : N66 M82*41
11:16:59.219 : N67 G92 E0*118
11:16:59.234 : N68 G92 E0*121
11:16:59.250 : N69 G1 Z0.3 F6000*32
11:16:59.266 : N70 G1 E-2.00000 F2400.00000*5
11:16:59.281 : N71 G92 E0*113
11:16:59.297 : N72 G1 X98.204 Y85.428 F6000*120
11:16:59.344 : N73 G1 E2.00000 F2400.00000*43
11:16:59.359 : N74 G1 F600*75
11:16:59.375 : Printing layer 1 of 325


  • G-Code syntax is the same, just that host adds the checksum it sends while server sends it, but does not display it.

    In server check set temperature. If it is never 250 and as you said it goes back to 215 which is also the set temperature this is no server issue. It is just a result of your PID settings for the extruder in firmware. Overshoot is quite normal, just 35°C is quite much. But if you have a strong extruder this can in deed happen. Check in temperatures the curve and output power. There you also see if temperature was higher set at a time. My guess is that you have a high power extruder and it heats still quickly in 215°C range so it overshoots so much. Increase control range or add more damping or lower P factor to give it less power in that area and reduce overshoot.

    This may also vary depending on the start temperature. If you come from < 50°C it will normally more overshoot then when you switch from 200 to 215.
  • the great thing about the PID settings (stock from day one) is the extruder temp is rock solid.  On the control panel for the printer you can prepare the hotend, and when doing so the temp only overshoots initially by 1 degree then falls back to the set temp and never fluctuates.

    If the PID was set incorrectly then why doesn't the host cause the over shoot too?  That is the puzzling part.  Using the Geeetech printing software also doesn't have any overshoot.  
  • As said, firmware controls heating and is responsible for overshoot. So as long as same commands get send same thing should happen.

    Have you tried just sending 
    M104 S214
    and see what happens? If it behaves differently you are sending some additional commands that cause it, but I do not see any command that might cause it. After all M109 even blocks until target is reached so all following commands are not executed. So only if you had send PID changing commands before that would be an explanation. Hence the rest after connecting just setting temperature and see in graph what exactly happens.
Sign In or Register to comment.