We have found the GT2 belts that are commonly used (including by us) on deltas from small to ~1.2m large work well. They are fibreglass core AFAIK and have no appreciable stretch. The bend radius has no issues in 20T pulleys that we use.

What I don't know is how well they scale to larger printers where stretch may be more pronounced.

See https://duet3d.com/wiki/Connecting_a_Z_probe.

Yet another two examples. I just created g-code with 50 millisecond segments (F1200, 1mm movements), so pauses (or step signals with shorter interval) going exactly every 50 ms, easy to find in analyzer logs:

All three motors paused at 7.420+ s position
Pause for X step, premature step for Y and Z at 7.520+ s position

Pause for X and Y, premature step for Z at 7.670+ s position, also steps are skewed at 7.770+ s position

See https://duet3d.com/wiki/Configuring_RepRapFirmware_for_a_Cartesian_printer#User-defined_macro_files.

@dc42:

See https://duet3d.com/wiki/Configuring_RepRapFirmware_for_a_Delta_printer#Homing_file, or read the comments in the sample homedelta.g file that I provide.

That F parameter is actually what I was thinking of when I said I didn't really want to increase the motor speed. However, its been many months since I last read that and had forgotten about the "300" values. I bet that's my issue. I'll double check that tonight. It's probably doing exactly what its been told to do. My Z height is somewhere around 335mm now…

@dc42:

Are you certain that it was reading config.g correctly? The only hardware fault I can think of that would change the behaviour in the ways you describe would be a failure to read and process config.g, perhaps because of a hardware fault in the SD card interface.

How can I know for sure? The controller board that I'm using now is running off the same SD card that I was using on the board that doesn't work. Because the new board hadn't been fired up in many months, all I did was upload all the latest .bin files and it works as expected. Is there some way I can test if the SD card interface is working as expected? FYI, my controller board is totally enclosed and the SD card wasn't touched at the time that it stopped working.

Thank you!

I ended up loading the new beta firmware out of order, and promptly lost contact with the board. Reloading through the card wasn't working, and eventually wasn't responding to Repetier Host to even try that route.

I was waiting on Atmel for access to this file as well. The webmaster replied this morning after I reported the issue. She stated that they are having problems with myAtmel and asked what file I was trying to download, but then never replied after that point.

With this, I can at least boot a windows partition and get the Duet back online.

I think I would reach max 110 if I put the electronics with the screen on top, less otherwise.
Thanks. Once I start wiring … the fun will start (hoping the duet will work 🙂 )

There is build instructions on github
https://github.com/dc42/RepRapFirmware/blob/dev/BuildInstructions.txt
But it uses Eclipse to compile

See "Makerbot mechanical endstop" at https://duet3d.com/wiki/Connecting_endstop_switches. The red wire is pin 1 and goes to +3.3V, the black wire goes to GND, and the green wire goes to STP.

Have a look here:
http://reprap.org/wiki/G-code#M584:_Set_drive_mapping

It turns out - and hence my OP question - that one of my Titan extruders was in fact skipping. I thought at first the motor wasn't strong enough .. or that there was a clog in the nozzle - or that .. well.. 1/2 a dozen other reasons I was checking.

As it was .. I just didn't have the current set correctly. It was set at 400mA (it probably came from a copy/paste doing the config) .. and it really should have been 850mA

Once I made that adjustment - so far, it's been working great.

Thanks for everyone's input and help.

@DjDemonD:

My understanding is that it microsoft's clumsy attempt to muscle into the 3D arena. I am sure the format has much to commend it but for the time being its just an annoyance having to use microsoft's 3D object builder to convert these back to .stls.

I believe that's a highly inaccurate and unfair way to describe the situation. It's my understanding that 3MF was developed by a consortium of companies with an interest in evolving the current state of 3D printing file formats. Microsoft chose to include it in Windows 10. They didn't develop it. If you check the membership list of the consortium you'll see there are many big name players involved.

To answer the OP's initial question, you can find list of places where 3MF has been adopted here.

@T3P3Tony:

I have fixed the issue as far as I can test, took the opportunity to upgrade the forum software as well. please let me kow if its working for you.

Works for me now. Thanks!

HAs anybody a step file of a diamond hot end mount (kossel better) since mine just broke at the first moment (by hand even)

Yes sounds like your pause file raises the Z height by 5mm but the resume one is not lowering it again. have a look here:

https://duet3d.com/wiki/Configuring_RepRapFirmware_for_a_Cartesian_printer#Pause.2C_resume_and_cancel_files

I am not familiar with S3D layer change scripts, but if that script causes those commands to be inserted in the gcode file at the start of the appropriate layers, then that should work.

@T3P3Tony:

Hi Ian

You can do what you describe using one more thermistor input.

As the DuetWifi reports the CPU temperature there is an aspiration to make this a temperature channel that can be used for fan control.

Ah… Ok. Makes sense.

Pressure advance adds a term to the extruder drive position that is proportional to the extrusion speed. This helps to make the extrusion rate from the nozzle more accurately match what the gcode commands during acceleration and deceleration. You control it using the M572 command.

I tried reslicing the model from the slic3r file with S3D and now the Web Interface correctly display 0.18 for the first layer. And it seems that it is also correct, the nozzle does not scape on the bed… So it seems it is a problem with slic3r?