I will update the post later with config files

I am running a Bowden direct drive extruder and my results might surprise some people but I can attest these settings work very very well.

So Gecko have you changed your slicer settings as well? I do not have a part cooling blower and have successfully completed several benches like this one with PLA: https://www.thingiverse.com/thing:1619976 and 3dbenchy…. I do not have any stringing, oozing or blobbing like when I started.

Warning, I need to tame some of these back as some of them cause my printer to bang around depending on what is being printed but the prints come out amazing

M566 X9000 Y9000 Z12 E9000 ; Set maximum instantaneous speed changes (mm/min)
M203 X12000 Y12000 Z375 E12000 ; Set maximum speeds (mm/min)
M201 X9000 Y9000 Z150 E6000 ; Set accelerations (mm/s^2)
M906 X850 Y950 Z950 E950 I30 ; Set motor currents (mA) and motor idle factor in per cent
M572 D0 S0.1

My Slicer is simplify3D and the bridging in it sucks, most overhangs in these models never get bridge mode enabled but I was still able to get amazing results none the less.

Slicer settings:

62mm/s print speed
115mm/s retraction speed
1.85mm retraction
0z hop
Outline direction: Outside in
Outline overlap: 10% (too much overlap on a well tuned printer will cause bulging like you see I found 10% to be ideal for well tuned estep and filament temp)
Only retract when crossing open spaces is unchecked
force retraction between layers is checked
perform retraction during wipe movement is checked

You might also try (if you have S3d) putting a negative number in extra restart distance if you find blobbing just after a retraction such as -0.02… this will keep less filament from being primed after the retraction. (personally I do not like to solve issues with the slicer and would hunt down the issue causing what you are facing but if all else fails try this setting.

My kids ran off with my benches but the results with snappy XY and snappy extruder completely eliminated any stringing and successfully connected non bridge parameter outlines (S3D bug, they should be treated as bridges) and it did so without the assistance of cooling and a 205c temp on PLA.

Now I just need to find the best jerk settings so my printer does not sound like its banging with every movement of the axis.... I am finding fast moves are the best way, it makes for ultra sooth quality prints with no defects but I need to find the sweet spot for jerk settings to make it maintain the quality that the high speed is giving

Well to me its not duplicating functionality…. Simplify3D already supports this on printers that have built in wifi printing.

To me i find it more of a pain to save sliced file, open browser tab upload file oopse first layer failed rinse repeat when instead i could just push the print button from Simplify3D. that and its far easier to send prints to multiple printers from simplify3d then to repeat this process for each printer.

The web panel serves a great purpose for managing the controller/firmware but for prints especially with many machines using simplify3d is just quicker.

Would be nice if this was a dropdown option in the web interface instead of having to write macros…. there should be a whole section dedicated to tuning and tweaking the printer but can be hidden via a checkbox so kids are not messing with the settings

Possibly add Riemann logging ability… this way a farm of printers can send these streams to a remote system for logging and monitoring with dashboard alerts and metrics etc.

Riemann is an agentless monitoring system that would work perfectly for something like this and is recommended by and supported by Docker:
https://blog.docker.com/2016/03/realtime-cluster-monitoring-docker-swarm-riemann/

Why Riemann in particular?
There are a variety of reasons to use Riemann. Here are a few of the most obvious.
Riemann’s push-based model lets you detect problems and verify that fixes are working in near real-time.
Traditional monitoring systems such as Nagios usually work with a poll-based model: They wake up periodically (say, every 5 minutes), run a series of health checks to verify that everything in the system is in the desired state (e.g. your services are up), and report the results to you via e-mail or another method. Riemann requires that services send their own events, and consequently outages or network partitions can be detected as soon as the events stop flowing. Likewise, we can collect and process events of any type, opening the doors to proactively providing value through monitoring instead of simply fighting fires.
Riemann’s stream processing allows for powerful transformations of incoming data.
For instance, even if an exception is logged 1000 times in an hour, Riemann can roll up all exceptions of that type into just a few e-mails with information about how many times the exception occured. This helps combat alarm fatigue. Another example- Riemann makes measuring metrics in percentiles quite trivial. This allows to gain true insight into the operations of our systems without having important information masked behind aggregations such as averages.
Riemann is easy to get data into or out of, allowing interesting use cases such as storing event data for analysis later on.
Clients for Riemann can send events using a thin protocol buffers layer over TCP or UDP. Riemann can emit events and metrics from its index into a variety of backends including Graphite, InfluxDB, Librato, and more. Riemann also has built-in support for notification via SMS, e-mail, Slack, etc.
Riemann’s architectural model is simple, preventing the potentially ironic situation of having monitoring software that is difficult to operate and/or failing often.
Riemann is designed from the ground up to be straightforward to operate and reason about. While this has some tradeoffs (for instance, it makes it impossible to distribute a single Riemann instance safely), in practice Riemann’s philosophy is largely that imperfect information right now is better than perfect information which never arrives. If the Riemann server crashes, usually a simple restart will remedy the problem; no finicky reconciling of distributed state needs to occur.
Likewise, the push-based model helps to alleviate the “who monitors the monitoring software” question (i.e. how do we detect when our monitoring itself has issues). We can simply set up a few Riemann servers and forward events to the downstream servers. If the upstream server goes down, the downstream servers will notice this and alert you. Especially running Docker across clouds, this could be particularly valuable.
It’s rather fast.
From the landing page: “Throughput depends on what your streams do with events, but a stock Riemann config on commodity x86 hardware can handle millions of events per second at sub-ms latencies, with 99ths around 5ms. Riemann is fully parallel and leverages Clojure and JVM concurrency primitives throughout.”

@briangilbert:

@whitewolf

Could you give link to the polycarbonate you bought from Amazon please?

I have another thread on here called "polycarbonate no bed heat success", there is links and a lot more info in that thread.

This doesnt answer your question but you should check out clearpath SDSK servos it will save you a bunch of headache and yes they are compatible with the Duet or any other board for that matter

You wont gain anything going above 32 for your extruder

Yes by giving the surface a dull sanded appearance the IR sensor picks it up

probably not considering its easy to accomplish that with a browsers tabbing feature thats already implemented by default though it does require switching between tabs. A Dashboard could be designed but would most likely be best served from a RPI or web server.

You can easily test that, both the old version and new version are installed in different folders so you can switch back easily

@dc42:

If we did implement a start.g file, it would have to be executed before starting the file to be printed. Whereas operations such as bed probing are usually better done after the printer is up to temperature.

Please do, its not needed in all situations for the bed to be up to temp.

One question though, on the XYZ Davinci series before the slicer gcode the head is parked off to the side then the bed temp rises and the hotend temp rises then the head moves onto the bed then a prime and wipe down the edge of the bed.

Are they reading the temps from the gcode ahead of time to accomplish this? and no this wasnt in my slicer start script it was part of the firmware

I dont see why the engine enamel wouldnt work, just go in very thin coats to be sure an even reflective surface

@raykholo:

While I understand the possible appeal Whitewolf describes, I think it is dangerous for the machine to do anything it is not explicitly commanded to do. The M98 in the start gCode in Slicer strikes a nice balance, because if a new user uses premade slicing profiles from the manufacturer, this can have the M98 line in it, but if a more advanced user wants to use their own slicer settings, they can have complete control and not have the machine perform additional unexpected actions.

I underdstand what you are saying but the problem with that logic is it depends on a kit being added to every slicer.

Advanced users can simply modify the start.g file if the start sequence does not perform as they wish.

All of the XYZ davinci printers home all axes, move the head off to the side of the printable area and then heat and prime the nozzle then do a wipe down the edge of the bed before beginning any of the slicers gcode and of a kit developer wants to do any number of such things they should be able to.

Advanced users are just that and have the ability to modify the printer to perform anyway they want to. they dont need a slicer to do so and we are not talking about a firmware that needs to be compiled … it is a single file they can modify or hit the delete button

A kit developer can control the pause routine or the tool change routine through the firmware files or the slicers gcode scripts so it doesnt make much sense to say no to start routine unless you remove the ability for all... just like the advanced users can delete or modify any of the other available routines pause, resume, homeall etc