Best posts made by OBELIKS

Eh, I needed to fetch a beer from the storage. So I hopped in to the "workshop"
Anet steppers are 37,8mm long and Wantai real length is 46,8mm.
And the beer is imperial IPA with 10% alcohol. And it is brilliant.

Added, thanks.

@digitalvision Thanks.
Now can someone explain my stupid ass how to output the result to a file?

When talking about humidity you need to be careful, relative humidity (expressed in %) tells you how saturated air is.
So at 25°C air can have 20g of water per kg of air and that is 100% humidity. If you raise temperature to 65°C, air can take up to 204g, so that means relative humidity when you have 20g/kg is 32%
So at "normal" conditions ant 25°C/50%rh you have 10g/kg and when you heat it up to 65°C you still have 10g/kg, so relative humidity is 6%
But I think that temperature also plays in drying, it always helps if you get molecules moving faster.

I once found these somewhere, and from what I tested they work. You basically set temperature as high as possible before glass transition.
PLA - 4h@45°C
ABS - 2h@60°C
PETG - 2h@65°C
NYLON - 12h@70°C
PVA - 4h@45°C
TPU/TPE - 4h@50°C
ASA - 4h@60°C
PP - 6h@55°C
Dessicant - 6h@65°C

Edit: Missing temperature

Good news, I have the same result. And I think I know what is the problem. Try disabling Print Infill Before Walls. When it was printing walls I could hear it dragging against the infill and I can feel it. With Slic3r that prints walls before the infill by default I never had this issue.

I have a problem I have not noticed before. It was always present, but I did not print circles except for the M3 holes. So I did not notice.
Anyway, if it not seen from the video, on the big circle printer keeps speeding and slowing. It is choppy.
And the weird thing is, there is a pattern in the circles. I get 3, 4, 5, 2, 5, 4 lines.
My config is here (fresh), I also attached the gcode file

Here is a octagon, so I could test straight lines, as you can see it works perfectly. Ignore the ugly print.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01beta2(RTOS) running on Duet WiFi 1.02 or later
Board ID: 08DGM-956GU-DJMSN-6J9F4-3SD6M-1VR3G
Used output buffers: 3 of 20 (16 max)
=== RTOS ===
Static ram: 28484
Dynamic ram: 96032 of which 0 recycled
Exception stack ram used: 420
Never used ram: 6136
Tasks: NETWORK(ready,328) HEAT(blocked,1248) MAIN(running,3616)
Owned mutexes:
=== Platform ===
Last reset 00:41:35 ago, cause: software
Last software reset at 2018-07-16 21:09, reason: User, spinning module GCodes, available RAM 6208 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 42.9, current 43.2, max 44.2
Supply voltage: min 12.4, current 12.6, max 12.8, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/383
Driver 1: standstill, SG min/max 0/458
Driver 2: standstill, SG min/max 0/652
Driver 3: standstill, SG min/max 0/524
Driver 4: standstill, SG min/max not available
Date/time: 2018-07-16 21:51:26
Slowest loop: 101.17ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 150, MaxWait: 0ms, Underruns: 695, 1
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.5
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 172.91ms; fastest: 0.08ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
- WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.21
WiFi MAC address 5c:cf:7f:76:5f:98
WiFi Vcc 3.33, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 15296
WiFi IP address 192.168.1.119
WiFi signal strength -38dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Expansion ===

Test gcode: https://www.dropbox.com/s/hfvgd5zj1sb30em/Cylinder test.gcode?dl=0
Stl: https://www.dropbox.com/s/hkadyoitr26z2r4/Cylinder test.stl?dl=0

Video: https://photos.app.goo.gl/1CxSx4eu7rzz3dxa8

0_1531770199343_config.g

I think you are overthinking it. Do you have multiple beds?
If not, default setting in S3D is OK, it will output M140 S70 to set bed temperature to 70°C, and that works with Duet

If you need more help from me just say. I can print more tests. Just prepare them for PETG.

@Munce31 If you are using the script @jens55 posted, you can add

print("M117 %.3f" % pressure_advance)

after

print("M572 D0 S%.3f" % pressure_advance)

M900 command is located under filament settings, custom gcode. It is used to set linear advance factor. Delete it or comment it out.

@grizewald I checked the STEP file from the Mosquito documentation and it measured at 1,95 mm
I also measured it from a picture where it is 1,97 mm (see below). Ignore the IN, it just says MADE IN U.S.A., scale is in mm

@oliof said in Pressure Advance seems to not be working.:

Supermerill's Slic3r++ fork includes looping seam hiding as well, but I haven't tried it yet (the latest build crashes at launch and I haven't tried to figure out why).

He has a fix on the releases page. "You have to remove creality.ini and basic.ini from resources/profiles because they have duplicate lines."
I also need to try it.

Latest FF (beta) 64bit on WIN10 and I have no problems

I have seen it before. But they did give a new roll and asked for the old one to check what happened.

I don't know if the real problem was already discovered and fixed, but here is the "official" reply from one of the developers (Vojtech Bubnik):

There are multiple effects in play, therefore some of your prints may show a different effect than the prints from the others. Ideally we would compare apples to apples, we would work with Slic3r's 3MF files that contain all the modifiers and parameters, so we can keep track of most of the variables in play.

First, the Slic3r's logic to extend the solid infill is there to anchor the solid top infill into the sparse infill. The logic is sound, but it has its drawbacks as you guys found out, it consumes material , it adds to the print time, and currently it is not configurable in Slic3r. Cura and S3D just do not extend the infill, thus you may see gaps at the bottom of your boxes as you already have found out as well. In the future versions of Slic3r, we may make the extension into the solid infill configurable.

In addition, Slic3r applies perimeter-infill overlap to close some of the gaps between the solid infill and inner perimeters, which it may have a negative effect on the accuracy of the outer wall. You may try to decrease the overlap number with the risk of getting some gaps in solid infill, the config parameter is available to you.

Then there is sometimes an effect of thin walls being extruded with just perimeters with no infill, and it may happen, that the wall thickness is not an integer multiple of the extrusion width (this is again a bit complicated by the fact, that Slic3r calculates the wall width as the tangent width giving the "corrugated iron sheet" surface of printed vertical walls, you will find a "recommended object thin wall thickness" hint at the Print Settings -> Layers and perimeters page for a given integer number of perimeters), so Slic3r will produce some overlap of the inner most perimeters to fill in the space completely, if the "Detect thin walls" feature is disabled. If you enable the "Detect thin walls", then Slic3r will fill in the remainder inside the inner most perimeter with a single line. Unfortunately the "Detect thin walls" feature currently may produce some unwanted single line extrusions at sharp protrusions of a model, therefore we have it disabled by default in our profiles. In the future, we will split the "Detect thin walls" to "Thin walls inside / Thin walls inside and outside" the way it has been done recently in S3D. By the way, S3D's recent implementation most likely copied from the initial gap fill algorithm implemented some 3 years ago in the original Slic3r, as it manifests the same behavior including the negative artifacts (read bugs).

Lastly, it is the physics as others noted. Plastics, if extruded first from pellets into a filament, and then from filament into a very thin rectangular extrusion, will behave neither as a liquid, nor as a solid. The stretching of the plastic will align the long molecular chains of the polymer, introducing internal stresses to the extrusion. This internal stress will pull the extrusion together if not cooled quickly enough. Indeed, as many of you found out, in a cool basement the effects are more pronounced, also on my MK2 the 3D Benchy has the line more pronounced at the side away from the cooling fan.

So, it is "just" physics, and it will be very difficult to compensate for the internal stresses and cooling effects of the filament IMHO, one of the reasons being the viscoelastic behavior of the molten plastics, and the dependence of the plastic behavior on its composition, temperature, hydrolisis of the polymer molecular chains if the filament is not 100% dry (polyesters - PLA & PET are sensitive to hydrolisis, hydrolised filament contains shorter polymer chains, thus being less viscous), effectivity of the cooling, reflections of the cooling air from the already printed objects etc.

If I am not too lazy I might prepare something for those that want GUI

At first I think I will leave excludes alone. For that I am definitely too lazy.

If Manuel agrees naturally.

@obeliks nevermind, it's back

I have 2.4A motors, so 22AWG?

Just FYI, GUI works! I finally had the time to check.
So I marked it as released.

Next plan is to implement the exclusions and maybe a bit more feedback while it is working.

This should be it:
https://github.com/T3P3/Duet/blob/master/Duet2/SD Card Contents/SD Card Contents.zip