@red-sand-robot said in Servo Wiring: @dc42 It is a micro servo, 9g weight, 1.5-1.7kg/cm (4.8V-6V) stall torque. Commonly referred to as a 9G servo. I haven't conducted any tests with a micro servo. It's quite likely that it doesn't need any extra capacitance at all; but if it does, 100uF should be more than adequate. The recommendation of 220uF was based on tests I did using a MG996R servo, weight about 58g. I have some 12.5g servos now (HS-70MG) so I'll test a pre-1.04 board with one of those too.

@moczikgabor said in SSR failsafe: Limiting the power of the bed heater so that it could not reach unsafe temperatures would defeat the purpose of the high power bed: heating up fast. The bed heater on my delta heats to 100C in just a few minutes, and tops out at 200C at full power - within the rating of the silicone heater. There are no plastic parts in contact with the bed. I don't consider that reducing heating time by perhaps 2 minutes is worth sacrificing passive safety for. If you are trying to make your printer fireproof and suitable for unattended operation, then IMO it needs to be inside a fireproof enclosure, with a smoke/heat detector to determine if there is fire or excessive temperature inside the enclosure. If you have that, then I agree with you that it should use a double pole contactor to disconnect the mains when fire is detected.

Please upgrade your firmware to version 2.02, which will provide better diagnostics. Please verify that you have continuity from the Duet motor headers right through to your motors. With power off but motors connected, use your multimeter to measure the resistance between the two pins at one end of the X motor connector, by touching the probes on the motor connector spills on the underside of the Duet. It should read a few ohms, the resistance of one motor phase. Then check the resistance between the two pins at the other end of the X motor connector. Likewise you should get a few ohms resistance between. There should be on continuity between any pair of pins on the X motor connector that are not next to each other, or between the two middle pins.

@haggan90 If those screws are constrained at the top, try taking the upper mount off. The linear guides should be contstraining any XY movement, not the screws. So if you allow the top of the screws to "float" it will ensure that there are no binding issues.

ok in the c Code i have not looked i think it will help me a bit, what i havent found for now is how i get the information when z.b M300: Play beep sound or when M291 is executed with rr_reply i will nothing receive when i execute this two comands

As you can see from the documentation: https://duet3d.dozuki.com/Wiki/Gcode#Section_M25_Pause_SD_print M25 is not for initiating a pause from within a print file or macro. Use M226 instead: https://duet3d.dozuki.com/Wiki/Gcode#Section_M226_Gcode_Initiated_Pause

@singhm29 apologies I just reread your initial post and see your thermistor is working but you are disconnecting it to test. As others have said when it's disconnected the heater that it is associated with should display "fault" in DWC. If that happens it is working as intended.

@siblues you can check to see if it's a driver by swapping the motors plugged into a working axis with the not working one.drivers can get blown when wiring develops intermittent faults in a single phase.

@red-sand-robot fantastic looking design. It's worth mentioning that the mechanism you are using is itself inspired by the e3d toolchanger mechanism. Can't wait to see the completed machine.

Problem solved, I forgot to reset the Z height.

@bugsysiegals said in Duet Maestro Upgrade - Calibrations Cube Issue: Where do I find pressure advance settings, in Cura or Duet? you add it to your config. also a misconfigured thermistor can cause more filament to ooze.

@hbrownell said in RRF Configurator questions...: I am running a 16 tooth pulley for the belt, so the number that I get says 100 Steps pM, is that right? yes

Thanks, I suspect it's the fact I didn't set any M915 values. I'll also give your code a go.

In the picture you posted, if the bed is moving in toward you, then isn't the nozzle moving in +Y direction relative to the bed/part, correct? Assuming since the bed moves then the nozzle is not moving in Y direction. A G1 Y200 should move the bed towards you on most standard bed-moving printers (prusa i3 style, etc). If this is the case then you need to change your motor direction (M569), endstop direction, and homing macro files. But I could be looking at the picture wrong.

@dc42 said in Current of pins on expansion header?: You should have no problem driving a SSR from the pins on the expansion bus. The heater outputs are active low, so connect the SSR control terminals between the chosen heater output pin and +3.3V. I went to the data sheets of a typical Crydom and Schneider SSR and they have input current specs of 5 to 12mA depending on the device. That seems like a lot when some of the µC pins are rated for 2mA.

No, that's not what I want. It would be nice if the G4 would only apply to one command and would not stop the entire printer. or another possibility is to execute a command for a certain time or after a certain time. in my case the lighting of the lighting with M42 ... but I take note that this is not possible at the moment. Thank you

Many thanks @dc42. I will practice using the file resurrection and also look forward to seeing this feature emerge in the future.

@phaedrux Like mentioning to add in "M280 Px S150" if running on 3.3V for added safety, maybe mention adding a pullup resistor between Z-probe in and 3.3V on the Z-probe connector. Just generally make it more readable. I don't know how many times i read it back and twards before getting it (might be because i'm not a native English speaker to ofc.) But it could be made much easier to read for a newb.

1: Ah ok, haven't got any so i have to order anyways 2: Yeah i know, but bu the 0.5mm difference that comes up between probing points that have 20mm between each other ain't true. As you say it might be something structural with the printer (haven't upgraded to MGN's yet). Still i have a feeling that the BLTouch reads somewhat inconsistent at sometimes to, it has to probe one spot 3-4 times before it's happy.

@gnydick said in Any g-code in stop.g causes heaters to turn off: @jv43 What's really strange logic is that cancel.g is preferred. I don't have a cancel.g. I had an empty stop.g. The heaters didn't turn off from a cancel. Then when I added code to the stop.g, it did turn off the heaters. Either way, there was no cancel.g, so why did adding code to the stop.g cause the heaters to turn off when in both cases, there was no cancel.g. Just feels not so intuitive. Please test that again. That's not what should happen, and I can't think of any type of firmware bug that would cause that. If there is no stop.g or cancel.g file, then the heaters should be turned off by the firmware. Except if you terminate it using DWC and it sends the H1 parameter on the M0 command. [I didn't agree with the introduction of the H1 parameter, and I am minded to remove it.]