Observations and notes from installation
-
I just received my pre-production (white) Duet WiFi board. After doing some reading about commissioning the board, it was time to get the thing fired up.
Going through the documentation from this website, I set out to start talking to the board. I went to https://github.com/dc42/RepRapFirmware/tree/dev/Driver to download the drivers.
One thing that didn't work for me at first (by following the documentation to the letter), was that Win7 automatically wanted to append a .txt to the duet.inf file. Once I set it to show hidden file extensions, I was able to delete the .txt from the filename. I tried opening the duet.inf file and even selecting "install" from the right click menu but I was greeted by a message saying something like "drivers cannot be installed in this manner". So, I figured I'd just plug the USB into my laptop and see what happens. It said it didn't install the drivers properly, so I went to the windows device manager and found Duet in the device list. Clicked update driver and browsed to the folder I had the .inf and .cat file. It installed as would be expected and I was on my way.
Configuration of the WiFi worked very well, and as described in the documentation.
I then started to modify the Kossel Mini config file included on the SD card. I changed things to better match the settings for my Rostock Max V2 mechanics.
And that's as far as I got before I had to get back to work.
Hopefully more playing with it tonight.
Cheers!
-
Same issue with the driver on Windows 7. I had to open Device Manager and navigate to the folder to install the driver.
-
A further update…
Last night, I got the end stops, steppers and FSR/JohnSL board hooked up. After a few iterations, I finally got the end stops working properly. I reverted to the mechanical limit switches on the Rostock Max V2, in lieu of the hall effect sensors because I need to get ones that work at 3.3V.
After swapping the pins around on the limit switches (which I probably didn't need to do), I finally was able to get homing to work. Then set out to work on the bed.g auto-calibration file, which I also got to work.
The motion is nice and smooth and it is noticeably quieter than the RAMBO stepper drivers.
One thing I noticed was that sometimes (maybe 50% of the time), after modifying the config file from the web interface and hitting "Apply" and answering "YES" to the Reboot Duet pop up, the three delta steppers would go crazy for about one second. Some sort of glitch that made the motors move.
Is this a bug in the firmware, web server or something in my config file?
The fact that it doesn't always happen makes me think it isn't in the config file.This happened on both v1.13 and 1.13b, if that helps.
-
A further update…
One thing I noticed was that sometimes (maybe 50% of the time), after modifying the config file from the web interface and hitting "Apply" and answering "YES" to the Reboot Duet pop up, the three delta steppers would go crazy for about one second. Some sort of glitch that made the motors move.
Is this a bug in the firmware, web server or something in my config file?
The fact that it doesn't always happen makes me think it isn't in the config file.I haven't see this happen on my delta, however it would make sense to disable all drives and heaters before a software reset. So I have just changed the code to do this, and it will be in the next release.
-
I was just thinking about my issues with connecting my mechanical end stops…
The end stops were originally wired up as directed by the Rostock Assembly guide (outer pins of the end stop itself), which is normally closed. I then connected the pins of the connectors that plug into the Duet between the 3.3V and SIG. When I tried to home the axes, the carriages all went downwards. I tried changing the M574 S parameter to S0 (active low), which still didn't fix it.
I then switched the pins on the on the end stops themselves to one end and middle pin, which swapped them from NC to NO. Upon homing this time, the motors moved the right direction but all of them crashed into the top and kept trying to move. So, the end stops weren't being recognized.
Then, I tried to swap the pins on the other end at the connectors on the Duet WiFi. I connected them to pins 1 and 3 (GND and SIG). I don't remember exactly, but I'm pretty sure the motors went down again upon homing. So I changed the S parameter in the M574 line in config and voila! All was well in the world. I ended up with normally open switches connected between GND and SIG and M574 X2 Y2 Z2 S0.
So essentially, I ended up trying most of the possible permutations:
NO and NC for the mechanical end stops
GND/SIG and 3.3V with SIG on the Duet WiFi pins
S1 and S0 in the M574 config fileNC switches with GND/SIG and S1 should have worked, shouldn't it?
NC switches with 3.3V/SIG and S0 should have worked, shouldn't it? This was the second thing I tried, but it didn't work.
NO switches with 3.3V/SIG and S1 should have worked, shouldn't it?
NO switches with GND/SIG and S0 did work.This was late at night, so my memory might be faulty. The moral of the story is that I think at least two (maybe four) of the options I tried should have worked, but only one did. I'm thinking that when the S1 or S0 option is set, the appropriate pull up or pull down GPIO configuration in the firmware might not be set in one or more of the cases. It's also entirely possible that I don't understand the pull up/pull down and floating pin requirements to make all of it work.
-
There is a section in the Duet WiFi beta documentation on this forum about upgrading from RAMPS. Even if you were using some other electronics before, you may find it helpful. Normal practice for a delta with a Duet is to use normally closed endstop switches (the outer pins of the microswitches) connected to the outer two pins of each endstop connector on the Duet, and M574 X2 Y2 Z2 S1 in config.g.
-
Just curious - how come the pins are GND - 3.3v - SIG? If SIG is pulled high as it seems to be, why not do 3.3v - GND - SIG so that a normal 2-pin connector can be used?
Similar question on the Z-probe connector - why is the MOD pin in the middle, why not 3.3v/GND/OUT/MOD, so the 3 pins needed for the IR sensor match up?
-
Just curious - how come the pins are GND - 3.3v - SIG? If SIG is pulled high as it seems to be, why not do 3.3v - GND - SIG so that a normal 2-pin connector can be used?
Because if you do that, people plug the 2-pin connector on to the wrong pins and short +3.3V to ground. Lots of people blow up Arduino voltage regulators that way, because RAMPS uses that pinout.
Similar question on the Z-probe connector - why is the MOD pin in the middle, why not 3.3v/GND/OUT/MOD, so the 3 pins needed for the IR sensor match up?
Tony can probably answer that one.
-
Just curious - how come the pins are GND - 3.3v - SIG? If SIG is pulled high as it seems to be, why not do 3.3v - GND - SIG so that a normal 2-pin connector can be used?
Because if you do that, people plug the 2-pin connector on to the wrong pins and short +3.3V to ground. Lots of people blow up Arduino voltage regulators that way, because RAMPS uses that pinout.
Why not overload protect the 3.3v bus, since that would address both this issue and any other causes of shorts?
I'm not sure what power topology is used on the Duet Wifi, but I think the 0.8.5 used a TC2117 regulator with overtemperature shutdown?
-
Just curious - how come the pins are GND - 3.3v - SIG? If SIG is pulled high as it seems to be, why not do 3.3v - GND - SIG so that a normal 2-pin connector can be used?
Because if you do that, people plug the 2-pin connector on to the wrong pins and short +3.3V to ground. Lots of people blow up Arduino voltage regulators that way, because RAMPS uses that pinout.
Similar question on the Z-probe connector - why is the MOD pin in the middle, why not 3.3v/GND/OUT/MOD, so the 3 pins needed for the IR sensor match up?
Tony can probably answer that one.
From memory it was the original RepRapPro IR sensor that went into the 0.6 and has migrated through… starting to get lost in the mists of time though.
-
Just curious - how come the pins are GND - 3.3v - SIG? If SIG is pulled high as it seems to be, why not do 3.3v - GND - SIG so that a normal 2-pin connector can be used?
Because if you do that, people plug the 2-pin connector on to the wrong pins and short +3.3V to ground. Lots of people blow up Arduino voltage regulators that way, because RAMPS uses that pinout.
Why not overload protect the 3.3v bus, since that would address both this issue and any other causes of shorts?
I'm not sure what power topology is used on the Duet Wifi, but I think the 0.8.5 used a TC2117 regulator with overtemperature shutdown?
The 3.3V power rail is indeed overload protected. But there is still an advantage to having fewer support requests, by making it immaterial which way round the 3-pin connector is mated, in the common case of a user with microswitch endstops. Although we use polarised Molex connectors on the Duet series, many users plug unpolarised Dupont connectors onto them.
I've been in this business long enough to know that if users can plug connectors in the wrong way round or into the wrong socket, then many of them will. When that happens, I want to (a ) protected the components from damage, and (b) where feasible, make it work anyway.
-
Fair enough, thanks for the explanation.
