it also depends on what you mean by not particularly fast. the maestro supports stealthchop2 which can make your printer nearly silent at low speeds.

@dc42 / community unfortunately I am still having issues with this. Tool changes occur with movements in the physical X axis direction and Z direction and are very crash prone as the difference in z offsets increases. Can anybody share a solution to what I'm sure is a silly mistake somewhere on my part? Anybody able to share working IDEX configs with larger Z offsets between XUVW carriage tools?

I had similar issues (and I’ve seen others here) and it was the thermistor settings. I don’t know if the online configuration was set wrong or it was “operator error” in each case but it had me chasing my tail. Perhaps if you post details of your config and thermistor type someone can rule this out.

It wasn't readily apparent from the SeeMeCNC site, but I found it here: https://github.com/seemecnc/RostockMaxV3.2/tree/master/SD Thanks for your assistance.

@dc42 said in Duet 3 demo at TCT: It will be a smart tool board, handling at least an extruder motor, heater, temperature sensor, 2 fans and a Z probe. What about support material? Add either an additional servo header or a stepper heater and temp sensor, maybe up the amperage allowed on the fan headers (or generic pwm headers) for larger builds so that pwm header could allow for small brushed motors to be controlled by that same circuit board? I have some ideas lingering that might expand the machine capabilities of the duet3.

After refresh browser page nothing changed and still not work. I think wifi module works, and problem in main firmware. After reset printer with command M999 start works normal. I'm connect via USB and that result 0_1555732305691_rs.txt

@vlad said in incorrect print time estimates (S3D), layer count etc: As a side note, I am sure you have never said "nsufferable twat" any man in person. Right? What a brave man Couch braveman with virtual big balls. I'm not one to stand down to the likes of you. If you behaved in person the way you've behaved here I'd have said exactly the same thing to your face. If there's anyone acting tough behind a keyboard here, it's you. I get that you have high expectations, but your inability to communicate with others in a cordial tone is doing you no favours. I and many others have tried to help you and you've shared very little good will in return.

Ah so it's just the heatsink portion then. Makes sense.

I bet you could ask Proto pasta directly and probably get a response.

Another vote for ! given I'm used to it's meaning.

@bearcattd said in Duet webcam: @frank26080115 I think I am close...which board do I choose in Arduino? the ESP32 board file added 40-50 new boards. Thanks! M5Stack-Core-ESP32 works for me, there's no clear instructions on this so I guessed it, since M5Stack is the seller.

It sounds like you are having the same issue I was having. I have a fairly long bowden tube and couldn't see any change in my pressure advance settings. It turned out the problem was I wasn't going far enough into the pressure advance values. I wound up needing to go up to 1.485 to get the improvement I was looking for. To save time, I used a script-driven pressure advance object like this one: https://www.thingiverse.com/thing:3442071 It uses post processing to increase the pressure advance for every Z layer so you can test a large range of values in just one print - whichever layer looks best you just measure height with a caliper to figure out the pressure advance value you need.

@nikker said in Test print with modified gcode causes disconnect of DWC: Let me know if there is any other information I can provide. Firmware versions and the results of a M122 would be useful. Can you tell if the raspberry pi still has a connection? It's definitely a more complicated setup than expected but should still work. Can you test with a direct ethernet connection just to remove that from the equation? You could use M302 to allow cold extrudes which would stop the error. I'm not sure if it's related or not, but it could be worth eliminating. https://duet3d.dozuki.com/Wiki/Gcode#Section_M302_Allow_cold_extrudes

Bit late to the party here but here are a couple other factors that can affect the printed part sizing. Backlash in axis. Backlash due to loose belts, excessively compliant mechanics, etc can present as oval holes if one axis suffers from significant backlash and the other does not. This is pretty easy to check. If you have a dial indicator you can use that to take two measurements at the same axis position, approaching the measurement point from opposite directions for each reading. If you don't have a dial you can print a large and small part to see if the error is an absolute value or scales with part size. Absolute error would indicate something mechanical like backlash rather than a material setting / steps/mm issue. Another easy backlash check is to look at the first layer of the part. IF the diagonal fill lines appear to be in sets of two (two lines close together, a small gap, then another two lines close together) this indicates excessive backlash in an axis. Material shrink. Plastics will always shrink a little bit while cooling. For a PLA I print with a lot I see shrink rates around 0.5%, around 0.1mm over 20mm (for my printer and material). Extrusion factor can't correct for this error and it's also not really a positioning error as my axes move very accurately. It's possible to scale x/y steps but I prefer to keep the positioning steps correct and scale up my part in the slicer in XY by my shrink rate. Z tends to be pretty stable and not need scaling for shrink in my experience.

Do the steppers start to work again if you disconnect the endstops? Also can you confirm the endstop wiring and switch component you use? I know some of the makerbot style ones have 3 wires and a LED if I recall correctly. It's weird that one would work but the other don't... Date will always show up as 1970-01-01 unless you change it every boot. Duet has no real time clock so it can't keep track of the time if turned off. On boot it resets to 0 unix time (Jan 1 1970)

@nhof said in Z-Max End stop? Printer ignoring it?: he second line M574 Z1 S2 we are actually asking for the Z probe to trigger when the Z reaches min limit. Not what we really want to set up for the subsequent G1 move. I imagine something like M574 Z2 S1 might serve you better, double check the home sensor state using M119 (or thru DWC) to ensure you have the proper S value Awesome, I will take a look at these! The G1 syntax specifically could be the issue I was seeing.

It looks like the machine_zendstop.g file just has one G92 command in it (which resets the Z position to the given value). The only time it is called is during the z homing routine. The script would be called using M98 like so: M98 Pmachine_zendstop.g You might be able to try that in the console manually to see if you get errors. IF the file is still messed up you could just take the G92 command from it and put it into homez.g instead.

thank you very much . I am gonna check the bed , maybe I can try to buy another one , it is simple 4mm glass , so not a big deal and I still can use as a spare. Also I 'll check the road if bended. Do you think I can exclude Y carriage as the cause ? Mesh leveling works better after I am switched from Marlin to Klipper , i like this firmware very much and gave at this " old" 8 bit ramps based printer a big pimp

FTP is a much quicker way to do it over the network, but you can right click and download files and multiple selections of files.