Upload/Print stall & heated bed not heating bugs?

[tonyphoang-zz]

I noticed two bugs that I've come across.

1. When I load the .gcode file to Octoprint and press Upload/Print, the system will stall. But if I load the .gcode file, press Upload, select Hot End temperature, then finally press the Print button it will print just fine.
2. Using Makerbot to export the .gcode file, I noticed that if I select heated bed, the printer will not heat the bed.

[markwal]

The GPX plugin defaults to reprap flavor gcode which Makerware can't produce. You need to switch it to MakerBot in settings. That is probably why the heatbed thing happens because MakerWare sends M109 to set the heatbed temp. Though to be honest I haven't tried printing anything from Makerware. I'll attempt something tomorrow and see if I can reproduce your issue. It'd be helpful for you to upload a sample gcode that shows your issue (the smaller the better) somewhere (Google Drive, DropBox, etc.) and put a link to it here.

[tonyphoang-zz]

When I change it to Makerbot for gcode flavor, the load/print works but the heated bed still does not work. Also live hot end reading is disabled during heating using this method.

In the old method - the method listed on post #1, it would show me live hot end readings.

What would you recommend for slicing? I've been reading there's cura integration but have never used cura before.

[markwal]

Strange. On MakerBot for gcode flavor I get hotend and heat bed readings and they both heat. It would be helpful for you to attach some gcode so I can look.

I almost always use slic3r on my pc. It even has octoprint integration so I can upload with a button in slic3r.

I have MakerWare, RepG, Cura and Slic3r all installed and working though.

[tonyphoang-zz]

[tonyphoang-zz]

Which .log file would you like to see?

Right now I have my machine type set to replicator 2 (default)

I wonder since my printer is a ctc 3d printer which uses sailfish that it won't work.

[markwal]

Aha. That's it. You want to set it to replicator 1 dual. It's a normal confusion, all of the makerbot clones are basically replicator 1 clones, but people get confused because most have gone to metal bodies, but the guts are all rep 1 flavor.

I meant the .gcode source that you were uploading not so much a log.

[tonyphoang-zz]

Download this image to your desktop, change ending to .gcode

You were correct that I selected the wrong machine type. Now it displays hot end and bed temperatures correct. The extruder seems to slam against a wall when I initialize a load/print then seems to work fine. Any clue as to why it does that?

[tonyphoang-zz]

The slamming against the wall could be attributed to this?

[tonyphoang-zz]

[tonyphoang-zz]

Update: It appears to only slam against the wall when it initially starts the first print. Additional prints do not cause this issue.

[markwal]

The position on the gcode viewer is because the OctoPrint default is origin in the lower left. There's a checkbox to have it be in the center makerbot style. It's on the printer profile settings page.

My guess on the slam is that gpx is confused about where your print head is when it is computing the first move. Perhaps jogging with the control panel causes this confusion since it uses relative mode. Any difference if you haven't jogged and/or you've homed before starting to print?

[markwal]

Hmmm... your first move is to home x and y so that doesn't seem to explain it. I'm not sure what is going on there. But since you say first print perhaps it is any print after jogging? You should turn on serial.log in OctoPrint settings so you'll have one if it happens again.

[tonyphoang-zz]

I'll give that a try after my current print job is done. Also checking the center view port/reloading on model in the gcode viewer does nothing

[markwal]

No not that center. That just puts the model at the center of your screen.

Settings->Printer Profiles->Edit (pencil icon)->Origin choose Center from the dropdown

[tonyphoang-zz]

I changed the center and rebooted the pi. Next I tried to print a new file and it didn't slam against the wall. I think that was what was causing the slam

Now when the printer initializes for the first print, it centers itself in the center of the platform then goes to home.

[tonyphoang-zz]

It appears as if everything is working properly.

One minor aesthetic issue is that after a print is done, the front LCD screen states: print is finished. When you load another print job, LCD does not clear so I can't see the progress of the print job of the second print. Manually pressing the M button clears the screen and shows the current stats.

[tonyphoang-zz]

Update on the slamming:

Looks like I spoke too soon, it slams the new printer head for additional prints.

[markwal]

OK, I need more information. Which direction is it going when it slams? At what point in the print does it do that? Before or after the homing? Now are you saying that it doesn't do it on the first print, but it does it on subsequent prints? Does it only happen after you use the buttons on the control tab?

[tonyphoang-zz]

It slaps it towards the bottom when the extruder is traveling to the bottom left. It does it at the very beginning. It doesn't do it on the first print but only on prints after that. I don't press any buttons.

[markwal]

By bottom you mean toward the front of the printer?

Facing the printer: home position is back right. It goes there (homing) and then travels to the front left and hits the front of the printer? If so, then is it the G1 X-112 Y-73 Z150 F3300.0 (move to waiting position) of your starting gcode that hits the front?

If your printer has a 150mm deep bed and the offsets are set correctly (Y offset around 70 something in sailfish) then that move should end up a little beyond the front left corner of the bed and 150mm above it.

Also, if it is that move, it should have the same slap every time including when you print from x3g off of the sd card.

[tonyphoang-zz]

yeah botton represents towards the front of the printer.

my printer is 225x145x150

Should I set the printer's setting to x: 225 Y: 145 z: 150 origin: center

[markwal]

That won't help the slapping problem though. It'll just draw the gcode viewer dimensions properly.

If it's that Y move that's causing the problem and it's just a tad too far for you y axis you need to convince MakerWare not to go that far. I thought there was a way to edit your print box dimensions in MakerWare, but I can't find it now that I updated to 3.7.

145mm should be the same as a MakerBot Replicator 1 though and that move while it is 158mm from the home position should fit since your bot has space around the bed right? There must be something we're missing here.

It is the move after it goes home and then it's on its way to the front left and the bed to the bottom when it slaps, right?

[markwal]

I think I spotted it.

[tonyphoang-zz]

Interesting thing is that when I hit home after canceling a print, it will go to the top right but will hit the wall about 2 inches from the top right and try and grind against the wall.

[markwal]

MakerWare doesn't put a switch to absolute positioning in the start gcode. Maybe the bot is still in relative mode? Although now that I type it I think there would be different symptoms of that.

You could put a G90 in OctoPrint's start gcode setting.

[tonyphoang-zz]

Something like this?

[markwal]

Home should run until it hits your end stop switch. Maybe your endstop switch isn't in the right position or it isn't working?

What happens when you choose home axes from the LCD menu?

You can test the switch by tapping it with something on the way. Don't pinch your fingers.

[tonyphoang-zz]

I tried shoving the extruder manually back to home when it grinds and it stopped.

[markwal]

Yes, your gcode settings look right. I'd get rid of the M106 though. Do you have a print cooling fan? (Not an extruder heatsink fan, something aimed at the print bed controlled by the printer.) If so, you should use M126.

[tonyphoang-zz]

My PLA printing cooling fan is always turned on so I don't have it electronically controlled

[markwal]

Ah. Then you can get rid of that M106 all together. The reason I recommend that is that it is ambiguous in this context. Reprap and OctoPrint define it as turn off PLA cooling fan. Makerbot defines it as disable extruder heatsink fan and you don't want to do that.

[tonyphoang-zz]

Interesting that when I press cancel then home, it grinds

[tonyphoang-zz]

It turns out that on the LCD, it doesn't cancel the print job. Because while it's in that state, when I try to manually control the extruder after canceling, I can hear the stepper motors grinding (without hitting a wall)

[markwal]

I've got a repro. Hang on. I've got a bug here on the left over state between print jobs.

[tonyphoang-zz]

I'd be glad to test out your plugin and any other updates in the future as I am interested in remotely controlling my x3g printer

[tonyphoang-zz]

I noticed a behavior when it would try to print a second job.

It would moves to a random location (close to top right) and I can hear grinding (does not hit a wall) then it would go to the bottom left and grind against the wall.

I think when it tries to go home, it gets lost and does not reach the stopper.

[markwal]

I thought I had a repro, but I didn't. My z shim had come loose enough to miss the z end stop but still wedge in a way that made the z grind but not make it home. But I just put the shim back in place and I can do two prints in a row no problem. :-(

[tonyphoang-zz]

Nothing is loose on mine. What printer do you have and does it run sail fish?

[markwal]

I have a FlashForge Creator Pro running Sailfish 7.7

[tonyphoang-zz]

It has to be a setting that's off then.I'll send you screen shots of all my settings tomorrow

[tonyphoang-zz]

I think the grinding issue for the second print for me is that it doesn't return to home right away. Any quick fixes you can think of? I thought the gcode specified that it needed to go to home

[markwal]

Yes, your gcode sends the carriage home at the start. You could try sending that command in the terminal window and observe the printer. Home X&Y: G162 X Y F2000 The MakerWare gcode has this for the waiting position: G1 X-112 Y-73 Z150 F3300.0 But you might want to just skip the Z while you’re experimenting since you’re having trouble with Y. You might want to try a lower value for Y and see if it stops short. Or what the hey, see if the printer can find the center:

G90
G1 X0 Y0 Z10

I added that Z10 just to make sure the bed is out of the way, but not move it all the way to the bottom like the makerware code. The G90 means go absolute

[markwal]

In this whole thing have you only been printing with the right extruder?

[tonyphoang-zz]

correct, I've only printed with the right

[markwal]

Shoot. That kills another theory. There's an implicit move to switch to the other extruder. I was thinking maybe at the beginning of the next you're getting an extruder offsets worth of grinding. My guess at this point is that homing on Y isn't working for some reason. Does the light on the switch board come on when you push the Y endstop?

[tonyphoang-zz]

Changing monitoring state from 'Offline' to 'Opening serial port' Connected to: <GPX.gpxprinter.GpxPrinter instance at 0x14cf558>, starting monitor Changing monitoring state from 'Opening serial port' to 'Connecting' Recv: start Recv: Makerbot v7.2echo: gcode to x3g translation by GPX Recv: SD card ok Changing monitoring state from 'Connecting' to 'Operational' Send: M110 Send: M110 Recv: ok Recv: ok Send: M20 Recv: ok Recv: Begin file list Recv: abs20mm.x3g Recv: 3dsetup Recv: 3D Printer Manual.docx Recv: PLA.x3g Recv: PLA20MM.x3g Recv: pi.x3g Recv: Spulenspacer_37mm-2.x3g Recv: Dual_Traffic_Cone.x3g Recv: SPIRAL-04.x3g Recv: rhino1-1.x3g Recv: RPICase_mount-2.x3g Recv: deleteme.x3g Recv: End file list Send: M105 Recv: ok T0:24 /0 T1:24 /0 B:39 /0 Send: M105 Recv: ok T0:23 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:23 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:24 /0 B:39 /0 Send: M105 Recv: ok T0:23 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:23 /0 T1:24 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:23 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:24 /0 B:39 /0 Send: M105 Recv: ok T0:23 /0 T1:24 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:24 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:24 /0 B:39 /0 Send: M105 Recv: ok T0:23 /0 T1:24 /0 B:39 /0 Send: M105 Recv: ok T0:23 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:23 /0 T1:23 /0 B:39 /0 Send: G90 Recv: ok Send: M105 Recv: ok T0:24 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:23 /0 B:39 /0 Send: G1 X0 Y0 Z10 Recv: ok Send: M105 Recv: ok T0:23 /0 T1:23 /0 B:39 /0 Send: G1 X0 Y0 Z10 Recv: ok Send: M105 Recv: ok T0:24 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:24 /0 B:39 /0 Send: M105 Recv: ok T0:23 /0 T1:24 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:23 /0 B:39 /0 Send: M105 Recv: ok T0:24 /0 T1:23 /0 B:39 /0

[tonyphoang-zz]

It's off center when I ran G90 G1 X0 Y0 Z10

[tonyphoang-zz]

Here are my settings

[markwal]

Looks a lot like mine. I invert the Z jog controls because it's more intuitive to think of moving the bed up and down rather than the head up and down since in our bots its the bed that moves. I also change the jog speeds in OctoPrint's printer profile to match the home feedrates (reduce to 2500mm/min from 6000mm/min) since it is fast enough for jogging and doesn't jerk around as much.

Now that I think about it, you should probably home it in the sequence to find out if 0,0 is where you want it:

G90
G162 X Y F2000
G161 Z F900
M132 X Y Z
G1 X0 Y0 Z10

That sequence means: absolute mode, home X Y to maximum, home z to minimum, recall stored home offsets, and finally move to the center of the bed and 10mm away from it. I'm not sure why, but it looks like the makerbot start gcode stomps on that M132 with a G92. But I'm a noob so what do I know? So you might want to try it the way MakerBot has it too and compare:

G90
G162 X Y F2000
G161 Z F900
M132 X Y Z
G92 X152 Y75
G1 X0 Y0 Z10

Another thing to do here is to print a 20mm calibration cube directly from the sd card x3g and print one from octoprint using gcode and compare the result in terms of bed position and dimensions. Maybe there's something off in the gpx conversion to steps.

[tonyphoang-zz]

Maybe I could run

G91 G28 X0 Y0

after the run is complete to zero the location?