Thanks, looks good, possibly reading a little high but I can see the blurb on why that might be.

Yeah will see if we have any and send you some in the next package.

Thank you. I was able to solve this by reuploading firmware through USB seems like it get corrupted somehow. My machine working now though I’m not exactly sure what caused it in the first place.

One short update here, may be a info that could go into the wiki also.

I use the switched +5 V power ot the ATX PSU to power the Duet and for switching on the duet I need to
keep the PS_ON lead from the ATX PSU grounded manually for ~3 seconds, after the blue LED near the wifi module
flashes a bit brighter and goes off.
Than the duet PS_ON pin goes to GND and I can release my mechanical push button.

Note : I decided to go this way, because I do not want all the electronics to consume power without any purpose.
I have (currently) no plan/need to switch the printer on remotely without being there to watch the print start.

Interesting note, thanks.

Thanks DC 42, it started to make much more sense when I got a hold of the right wiring diagram. Somehow I was looking at one that was for the proto-V2 in which had things reversed. Yikes! Thanks for the help!

Werner

Cool, it's sold! 🙂

@dc42:

When you say the Duet is invisible, do you mean that it doesn't show up in Device Manager when you connect it via USB? It normally shows up under Ports.

Yes, it does not show up in Device Manager, I expanded the whole tree and it's nowhere to be seen.

@dc42:

When you power the Duet from USB, you should get two red and one green LED lit on the edge of the board with the USB connector. Does this happen? If the green LED is not lit than this usually means that you have your endstop switches wired to the wrong pins.

No, there's no green LED. In that case, I'll try without endstops plugged in to see if this resolves the issue.

Thanks for the quick reply!

No, it looks like the drivers you are using have all that onboard

there was a bug in DWC 1.13RC1 IIRC upgrade to the full 1.13 and also FW 1.17dev? Whatever the latest is 7 IIRC make sure you do the FW first followed by the WiFi server then the DWC

@Guyaros:

Hi Ron,

I'm also using Cobra metal extruder.

Try these settings:
M906 X1000 Y1000 Z800 E1000 ; Set motor currents (mA)
M201 X800 Y800 Z15 E300 ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z500 E2400 ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E120 ; Minimum speeds mm/minute

Thanks for the setting, my problem was wiring, most steppers I use it is a simple wire to wire ,however this stepper required a specific order. Once I figured it out it worked fine.
For us newbies it is nice to be able to find help

Ok guys, be prepared to chuckle.

When I removed the build plate to have a look at the thermistor I noticed that the color of the wiring (white teflon insulation) was different than the wiring I had going to the bed temp thermistor slot (black vinyl). Hmm.

Coincidentally, the previous "Z Stop" switch wiring was white teflon coated, while the wiring I cut at the Z stop switch to splice in a new piece of good wire was black vinyl.

I put a new two-pin connector on the white teflon wire, plugged it into the bed temp sensor socket, and now it all just works.

Coincidence? I think not. 🙂

I don't know how I managed to mislabel the wiring as I pulled it off the old Melzi board, but somehow I did.

I have one remaining issue that I know of (at least until I try to plug in the PanelDue and 7" screen), but I'll post that in a separate thread.

Ok, I got everything connected up. It wasn't without its hiccups, but I worked through them. Somehow, magically, the wiring between my Z stop switch and the DuetWifi board went bad. I tested this with a multimeter and proved that it was the wires running from the printer in the main bundle of wiring. I spliced in a new length of wires between the Z stop switch and the board and now it works fine.

I'm left with a single issue: I'm getting an error message from the bed heater. I've tried both orientations of the pins for the bed temp sensor, and the behavior is the same either way (I don't know enough about the temp sensor to know if there's a polarity or not.

I'll post that in another thread so that it gets new eyes.

Yeah, jumper is correct and I get the correct voltage on LEDA. A new panel is on the way from Filastruder and so it should be fully functional again shortly.

You can use bossac.exe from the Tools folder of my github repo under Windows 10. I need to update the instructions, or else build a new version of bossa.

In fact active low enables are the default, so you shouldn't need to use M569 to change the polarity. The drives will get enabled when they are first commanded to move. Sending M1 or M18 or M84 disables them.

To expand on what Tony has said, if your normal homing position is the minimum of all the axes (i.eX=0, Y=0 and Z=0) then connect your min end stops to the 3 connectors on the duet. If you use M208 to set your axes maxima, then once the machine has been homed, it won't go beyond those limits so the max end stops aren't needed. If you want, you can connect all the max end stops in series and wire them to a spare Estop, then use M581 to define that as an emergency stop interrupt. In theory that would prevent the machine from crashing beyond the maxima if it were instructed to do so before the axes had been homed. Be aware though, that until David gets around to changing it, interrupts don't work during a macro and that if you use DWC to move the axes, such moves are treated as macros. So, if you instructed the machine to move beyond it's maximum limits through DWC, and the machine had not been previously homed, then the maximum end stops would still be ignored and it would crash. Therefore, best practice is to always home the machine as soon as you turn it on, and better still, lower the motor currents in your homing file and put them back up when homing is completed. HTH

To clarify, I only used the X axis motor, I know it works and is wired up to a 4 pin connector. I hadn't yet wired the Y-axis to a connector so I used the X-axis motor. The motors are not the issue, this much I know.

How about another parameter on the M305 line to add a Channel name to the Heater and this get read by DWC and PanelDue at boot time?

Not sure how easy or difficult this would be just a thought?

You don't need to change anything in the config file to use an SSR to control the bed.