tekkydave

Are the wheels just on one side of the v-slot. Mine are on both (3-wheeled) so stop it moving in either X or Y. 

I wouldn't rely on the screws to constrain the movement, just move it up & down.

Will the XY frame be constrained in the X-Y plane purely by the wheels in the 4 corners? If so you may get binding issues with the screws unless the XY frame is free to float on them.

I had issues with my D-Bot when I had wheels in all 4 corners and 3 screws. I eventually removed the wheels at the front as the rear wheels were providing sufficient constraint in the X-Y plane. The screws were then purely moving the bed up/down and keeping it in the same plane.

Maybe I have misunderstood your design.

I got it from Makers Hut on ebay they have GT2 6mm up to 1524mm. I used a 1350mm for mine.

The same seller does longer lengths - even 1000mm.

This is the one. I bought 3.

Recommend getting single-start screws for resolution. Also stops any back-driving causing bed to sag. Also recommend using 3 screws to give a stable z axis.

Great research. When I started using PETG I had lots of issues with stringing. This was using a direct extruder too so not a Bowden issue. I found that tuning slicer parameters to minimise retractions got rid of almost all stringing. I found the best infill pattern was concentric as it drastically reduces the number of retractions followed by a move. I stopped using honeycomb when I had my Prusa. It would almost shake itself to bits unless going very slow.

1 hour ago, Gina said:

Now I have the bones of the machine assembled I've been thinking about the possibility of boxing it in to provide a fume cabinet and also to enable a heated enclosure to help when printing ABS and any other type of filament that benefits from keeping warm.  The external dimensions of the frame are 720mm x 610mm, with the motors on the XY frame sticking out back and front.  In view of this I think one of the shorter sides would be best for the door.  It probably isn't necessary to have more than one side transparent (the door) and make the other sides from lengths of timber and plywood.  I plan to include a webcam somewhere to provide remote viewing of the printing process.

Here is a good tutorial on using a Raspberry Pi and MotionEyeOS to control a webcam and integrate it into the Duet web interface.

It describes using a Pi Zero which I tested and it's adequate with a Raspi cam and takes up littlemspace.

I plan to use a Pi3 so I can attach multiple cameras. E.g. one watching the bed, one on the spool. Only one will be visible via the Duet but the Pi has its own web interface for monitoring all the attached cameras.

It sounds sensible to me to remove as much weight as possible from the moving bits

Are you printing with a brim? I tend to have a 5 to 8mm brim on everything these days - stops any curling.

Are you talking hotend or bed thermistor?

I was having difficulty trying to get an accurate hotend temperature with the old style heater blocks so I got a new style one with the thermistor cartridge.

Most of the silicon heater thermistors are the Marlin type 75. In Duet terms this gives:

M305 P0 T100000 B3950 C0 R4700

Duet uses the thermistor parameters (beta etc) directly whereas Marlin uses a table which has been pre-generated from the same parameters.

When you get a fault sometimes there is more info on the Gcode Console page.

Hover the mouse over the boxes and it explains what to use them for. I have mine in the Printer Settings.

The only thing I can suggest is restarting the router and Duet. I had similar issues at the start but it has been pretty stable since (touches wood).

Looking a LOT better

Read this - the relavent bit is the section "Inherent config changes needed for all Cura users using Duet:"

https://betrue3d.dk/using-duet-with-cura-and-diamond-hotend-and-firmware-retract/

Maybe Slic3r has the correct output format set by default. The version of cura your Repetier Host is using is quite old now. Latest version is 2.8 I think (numbering scheme was changed - I think 15.xx became V1).

Comparing your gcode & mine I can see you are missing a

G90 ;absolute positioning

somewhere.

Your extruder is being given absolute coordinates to go to but it is treating them as relative hence the over-extrusion. Either add one in your start g-code or set the output format to Marlin in Slicer (might be listed as 'Reprap').

20 minutes ago, Gina said:

Here's a screenshot of slic3r - can you see anything wrong?

Your settings are all set to 'default' have you adjusted them to suit the printer & filament?

I think it's to do with absolute/relative extruder movement. Check you have your start gcode setup correctly in slicer. You should be able to select the right output format in slicer too.

Maybe try Slic3r standalone.

Had a look at the gcode. First layer is at 8mm/s, rest at 12mm/s. It seems to spend a long time doing infill between the inner & outer walls - maybe thats when it slows down. Maybe try a model without a narrow wall e.g a cube.

Config looks ok. I'll have a look at gcode.

Very weird. Can you post your config.g as it stands now. The gcode file of the printed object would be useful too. I'll have a look and see if I can spot anything.

I have a gcode simulator on my tablet I can run it through to see if that is where the problem is.

What does the preview look like in the slicer program. If possible use a stand-alone slicer to see this.