Extruder temp set to value that can't be found in the config

[jamesd512 0]

I am trying to use Cura for the first time so I can try out the support roof stuff.  I have a CTC Bizer which is running Sailfish 7.6 and Cura 4.7.  I'm using Octoprint with the GPX plugin to run the print.

 

I have some gcode for a test object which contains an M109 S42 T0, but I cannot find where it's coming from in the config.  I believe it's to set the extruder T0 to 42 degrees and wait.  Can't find any setting carrying that value in my config.

 

Another problem is Octoprint / GPX are not set up right yet I don't think, as the printer tries to set the bed temperature to 42 deg on receiving the Gcode

 

Here is the top of the Gcode

 

;FLAVOR:Makerbot
;TIME:1496
;MINX:-33.916
;MINY:-9.326
;MINZ:0.3
;MAXX:33.916
;MAXY:9.732
;MAXZ:37.8
;Generated with Cura_SteamEngine 4.7.0
T0
M190 S60
M104 S220
M104 T1 S175
M104 S220
M116
M104 T1 S175
M116
M82 ;absolute extrusion mode

G92 E0
M136 (enable build progress)
M73 P0
G162 X Y F2000(home XY axes maximum)
G161 Z F900(home Z axis minimum)
G92 X0 Y0 Z-5 A0 B0 (set Z to -5)
G1 Z0.0 F900(move Z to '0')
G161 Z F100(home Z axis minimum)
M132 X Y Z A B (Recall stored home offsets for XYZAB axis)
G92 X152 Y75 Z0 A0 B0
G1 X-112 Y-73 Z150 F3300.0 (move to waiting position)
G130 X20 Y20 A20 B20 (Lower stepper Vrefs while heating)
M109 S42 T0

 

 

[jamesd512 0]

Does anyone know of a suitable preset profile for a Replicator 1 dual clone?  Both the Wanhao 4s and the Makerbot profile are fixed at 1 extruder.

 

Or maybe someone knows how to turn on more verbose logging for Cura so I can see where it's getting the value and setting from.

 

Could anyone suggest their favourite 3d printing forum so I can open more lines of enquiry?

 

Many thanks

[GregValiant 1,112]

This is my favorite forum.  It's a knowledgeable, adult crowd (other than the occasional juvenile delinquent).

 

I looked at your Gcode snippet and thought I'd take a pass.  There are some codes in there that I'm not familiar with at all.  In fact the entire second paragraph looks like Greek to me.

 

I do see that the slicer has your machine configured with "Center "0"" is that correct?

 

Edited October 5, 2020 by GregValiant

[jamesd512 0]

Yes the Replicator 1 dual family (wanhao, flashforge, monoprice, ctc) from what I can work out share this center origin.  I can work out what the gcode is doing line by line using this reference: https://reprap.org/wiki/G-code  

 

But ultimately it's Cura generating it based on some limited settings provided by me against the custom FFF printer option (setting just print dimensions, center origin mainly)

 

I found a profile for a Flashforge Creator Pro, which I understand is compatible and have got something printing.  But it's on the right edge of the build plate and going slightly off the end. 

 

I tried updating the onboard values for home offsets, which made no difference to the item position on the build plate.  Also, this profile outputs .3mf instead of .gcode by default, which is mysterious because this is not defined anywhere in the profile.  Anyway, I was able to use the export function to get the .gcode version

[GregValiant 1,112]

It's got you jumping through hoops.

If it is printing on the right edge then it was likely sliced for a machine with the "0" in the left front corner.  I suppose after the print you could try setting your home offsets differently.  If your machine is 200 wide then you could set the X offset to +90 and the Y offset to +90.  That would move the relative 0 to 10mm in from the left front corner X and Y.

 

Looking at the Gcode snippet in the first post again, I would read between the lines a bit and say that it was going to start out with extruder T1 at 175° and T0 was set to a really low standby temp.  There was no waiting for the cooldown so the remaining gcode would run while it was cooling.  That 175 is a low start temp for extruder 2 as well.

[jamesd512 0]

It was 100% configured to print to center origin.  I know it wasn't using the eprom/firmware offset params, because I checked and double checked with Makerbot Desktop and changes made no difference.  Also the profile I was using had 0,0,0 offsets in cura.  

 

But  I've had some success starting from scratch and piecing together a new profile for the CTC Bizer.  It now prints single extruder stuff just fine, so I'm pretty confident I'll be all set soon.   A little move offset tuning and it will be ok.  I'll share the goods here once everything is looking good. 

 

It's outputting gcode now.  The printing on the left issue is gone, but we're still not centred, so in due course I'll look to tweak the offsets in the profile, hopefully that will do it.

 

When I do a dual extruder print, around about the time the first tool head change is reached, it still goes wrong.  This time the print head randomly gets spooked and tries to leave the printer stage left, so I need to be poised over the power button when testing.  I have the Octoprint console logs, hard to see the command that would have caused the head to move hundreds of mm left suddenly.   See the log below.

 

So I need to debug the gcode.  It strikes me that gcode debugging tools are out there but nothing emerged for me that could do some key things well:

 

• Annotate the file with a human readable comment describing each gcode line.  This is available through humanize-gcode, but it doesn't support Makerbot flavour.  Not a big issue, but also easy to fix
• Enable line by line execution.  Possible insertion of m71 commands, requiring an OK press
• Transform the gcode to remove all the temp and extrusion stuff so dry run is possible -save a lot of time
• Try out the emergency stop button plugin for Octoprint - not sure if it will avert print head crashes, but this seems to be the main peril when trying to debug new profiles.  I've had every conceivable form of head crash now and it's getting old having my hand around the back on the power switch

All the above can be done quite easily by pre-processing the gcode with a script.  But also open to being told not to bother and guided to understand how to debug gcode well via other means.

 

 

Send: N1537 G0 F600 X1.311 Y-9.76 Z0.6*13
Recv: ok
Send: N1538 G0 F3600 X9.219 Y-2*70
Recv: ok
Send: N1539 G0 X9.463 Y-.699*5
Recv: ok
Send: N1540 G0 X8.754 Y-.113*8
Recv: ok
Send: N1541 G0 X0.00 Y0.00*25
Recv: ok
Send: N1542 G1 F1200 E-2.46557*30
Recv: ok
Send: N1543 G1 F600 Z1.6*24
Recv: ok
Send: N1544 G92 E0*115
Recv: ok
Send: N1545 M135 T0*85
Recv: ok
Send: N1546 G92 E0*113
Recv: ok
Send: N1547 M104 S190*90
Recv: ok
Send: N1548 M116*29
Recv:  T:170 /190 B:60 /60 T0:170 /190 T1:210 /185 @:0 B@:0
Recv:  T:170 /190 B:60 /60 T0:170 /190 T1:210 /185 @:0 B@:0
Recv:  T:172 /190 B:60 /60 T0:172 /190 T1:210 /185 @:0 B@:0
Recv:  T:173 /190 B:60 /60 T0:173 /190 T1:210 /185 @:0 B@:0
Recv:  T:174 /190 B:60 /60 T0:174 /190 T1:210 /185 @:0 B@:0
Unexpected error while reading serial port, please consult octoprint.log for details: OSError: '[Errno 5] Input/output error' @ comm.py:_readline:2916
Changing monitoring state from "Printing" to "Offline (Error: OSError: '[Errno 5] Input/output error' @ comm.py:_readline:2916)"
Connection closed, closing down monitor

 

[jamesd512 0]

If anyone's wondering why I'm bothering when Makerbot Desktop works fine, it's because I really like to get support interfaces working as it will save quite a bit of cost.

 

Also I really like Cura the best, it's awesome.

[jamesd512 0]

Made some progress, just updating here in case it helps anyone else.  It surprises me with all the Replicator clones out there that it was so hard to switch to Cura.  I guess folks are happy with Makerbot desktop.

 

M71 works great.  Shows a message and waits for a press of the M (OK) button.

 

I adapted humanize-gcode to work better for debugging, have an extra feature

 

--debug_start_line n  : Add in M71 (<gcode description>) before every line from the line specified

 

This way I could enable this for 10 lines prior to where the printer was doing funny things, and isolate the line that was causing the funny move.  The terminal in Octoprint shows line numbers, but because of buffering I guess, the lines are not synced with what the printer is doing, so this helped me.

 

In this case it was M135 T1, switching to the second tool head, which was sending the print head out of bounds to the left.  So looking at the Sailfish resources, the firmware toolhead offsets get applied at this point.  Using Makerbot Desktop, I could see that there was a crazy value in the first offset field, 33000 steps.  I set that to zero to test it, then tuned it to be aligned with the other nozzle.  Don't bother with ReplicatorG to update onboard settings, it doesn't work.

 

It wasn't necessary to add the dry run feature to humanize-gcode, because there is a great plugin for this for Octoprint.  I didn't bother with the emergency stop, because only interrupting power can halt a gcode move which is underway.

 

I guess for the Replicator clones out there, the little hidden reset button at the back is the best bet.

 

If anyone else needs to debug gcode on a Makerbot flavour machine, let me know and I'll either send a pull request or fork humanize-gcode.  Thinking of doing that because it only supports Marlin and Smoothie flavours at the moment, and I can see how to add support for Makerbot flavour.

[jamesd512 0]

Anyone who has a Mightyboard bot, Replicator 1, CTC Bizer, Flashforge creator pro, Wanhao Duplicator 4S and others.  you can struggle with Sailfish or you can use Marlin.

 

I am surprised how well buried this information is that since 2.0, Marlin supports nearly everything out there with it's hardward abstraction layer making it possible.  It was still a struggle to get a working Marlin 2.0 on my Bizer, but well well worth it.

 

Feels like a new machine.

 

Anyone who finds there way here wanting to breathe new life into an old machine just ask and I will tell what to do, what code changes I needed to do, and what issues you might face.

Edited October 21, 2020 by jamesd512