Posts made by Dakine

Discourse works well. I think it's important to add that theming is important regardless of the solution selected. Beyond just good looks, it can really help with ease of use as well.

Really glad to hear this is being considered.

This might be a bit off the wall, but since the majority of the posts here seem to be questions / users seeking help, would a stack exchange-esque option make sense? Then the OP could select an answer that solved their issue, people could up vote helpful comments, and have sub-threads built in to responses instead of intertwining with the rest of the conversation. I think this really makes the information and effort put into a thread more future proof and easy to mine for future users/searchers.

@dc42:

Is it a Duet WiFi or Duet Ethernet?

Sorry David, I didn't see you had replied. It is a Duet Wifi. I'm running 1.20 (2017-12-23).

I can also confirm it is not the new ironing setting that's causing any issues. This has happened on all three of my prints since I posted, two of which don't have ironing on. The machine is basically frozen while this occurs, I have to do an emergency stop (the normal M0 stop does nothing) and wait for it to boot back up before moving my print head away from my print.

It's definitely hitting the end code - I see the extruder retract but after that, it hangs. The next line in my end code is

G1 Z+5 E-5 X-20 Y-20 F9000 ;move Z up a bit and retract filament even more

Any ideas?

Thanks again.

Hi dc42, I expect this will happen again, anything I can do to capture more information on the problem? I should have run an m122, now that I think about it.

So, this is odd and scary. I've just completed my 6th or 7th print with the Duet, using the same slicer (Cura) and same start/end gcode.

I just wrapped up a 9h print and I was monitoring the printer because it was getting close to done. I watched the print head move to a corner of the print and just stop. It sat there for a few seconds while I fumbled with the bed and pulled it out of the way. It had started melting a hole into the print, but thankfully it doesn't impact it much.

I took a screen shot of the web interface next.

I highlighted a few things.

• The Duet was reporting 95.6% completion.

• Both heaters had beed turned off.

• The total layers was reporting 21. It was actually 154, with a last, 155th layer for ironing, which had been completed. (Cura counts ironing as a layer apparently)

• The filament usage was WAY off. Or it was accurate and the expected usage was way off.

About 4 minutes after I took the screen shot, the printer homed X and Y, and raised the Z by 5mm as the end G-Code tells it to.

This happened once before, though I didn't see it happened and was scratching my head about it. I printed a small calibration cube and came back to see it stuck to the hot end, off the print bed by about 5mm with the X and Y homed.

My gut is telling me ironing has something to do with this, but all of my prints have been ironed on the top layer for a week or so now.

Here's my end GCode from Cura, I think it's clear this was hit because the heaters were off. Not sure where it went wrong.

M104 S0 ;extruder heater off
M140 S0 ;heated bed heater off (if you have it)
G91 ;relative positioning
G1 E-1 F300  ;retract the filament a bit before lifting the nozzle, to release some of the pressure
G1 Z+5 E-5 X-20 Y-20 F9000 ;move Z up a bit and retract filament even more
G28 X0 Y0 ;move X/Y to min endstops, so the head is out of the way
M84 ;steppers off
G90 ;absolute positioning

Not sure I can help with the problem, but for me at least, I can't see your picture.

Hmm. I think I've somehow worked through this. It looks like my steps/mm micro-stepping commands were off by quite a bit. I've adjusted those and it looks like things are working out now, although I'm sure it's not dialed in just yet.

I think removing the errant G92 commands helped as well. I'm not certain why the configurator put them in.

Fortunately I've discovered several more issues after trying to print again, so at least I won't be bored tonight!

Thanks for the help dc42.

Ok, then it sounds like I don't need that command since the homing switch is hit below the bed surface. This happens because the glass surface doesn't extend to the XYZ home corner, plus the nozzle compresses the bed spring a little when homing Z. Not Ideal, but I can't print my Z-Limit adjuster until the printer prints again.

That being the case, if the switch is hit ~5mm below the bed surface, shouldn't the ~5mm mesh grid compensation account for that?

It looks like I have a G92 Z2.5. If my understanding is correct, this would tell the printer that the current Z position is actually 2.5mm, not 0mm. When adjusting for the mesh it would only lift up by about 2.5mm instead of 5mm, correct? That would seem like it could be part of my issue if that's the case.

I commented the G92out of the homez.g and homeall.g, and re-ran the mesh compensation just to be safe. It's still digging into the bed however.

; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool on Sun Feb 18 2018 21:28:00 GMT-1000 (HST)
G91               ; relative positioning
;G1 Z5 F6000       ; lift Z relative to current position
G1 S1 Z-185 F1800 ; move Z down until the switch triggers
G92 Z2.5          ; set Z position to trigger height

; Uncomment the following lines to lift Z after probing
G91              ; relative positioning
G1 Z5 F100       ; lift Z relative to current position
G90              ; absolute positioning

Awesome! Did you find specs for the 7i online or did you measure it up yourself?

Hi dc42,

Yeah, I agree, they need to be smaller than that. However I'm not able to adjust the Z endstop any higher without being higher than the bed can go, due to some damage to the printer. The first thing I plan to print is an adjustable Z-limit: https://www.thingiverse.com/thing:1008176. But for now, this is what I'm stuck with. Can the mesh compensation not handle a 5mm offset? the maximum difference between heights is only .9mm, admittedly still too much, but seems like it's well within operating capacity.

All three axes are homed. My Z is set to 120, and my acceleration is set to 100. These are actually a bit lower than they were on the Melzi board previously I believe.

Again, I was able to print one test damn near perfectly. But the mesh just isn't loading any more, or is loading inconsistently and I'm getting a string of bad luck.

Hello,

I just completed wiring up my new Duet Wifi to my Maker Select V2. After some effort I was able to get a simple test print to print properly, using the mesh grid compensation. I do not have a Z probe, and so manually ran the mesh using a sheet of paper. This was after several attempts to get it to use MGC, and it not working. I have no real idea what changed, other than "third time's the charm."

I haven't been able to get mesh compensation to work since. Running M122 produces the below, which says mesh compensation is in use. However, it clearly is not, as the hot end grinds into my glass bed immediately after homing. I've tried adding G29 S1 to my start g-code, but no joy. I've included my start gcode (from Cura), as well as my heightmap.csv.

I'm sure I'm missing something simple.

Thanks for any help!

GCode

G21 ;metric values
G90 ;absolute positioning
M83 ;set extruder to absolute mode
G29 S1 ;Load Height Map
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z15.0 F9000 ;move the extruder up 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F9000
;Put printing message on LCD screen
M117 Printing...

heightmap.csv

RepRapFirmware height map file v2, mean error 5.600, deviation 0.216
xmin,xmax,ymin,ymax,radius,xspacing,yspacing,xnum,ynum
25.00,175.00,25.00,175.00,-1.00,75.00,75.00,3,3
  5.600,  5.400,  5.100
  5.700,  5.600,  5.600
  5.800,  5.800,  5.800

M122 Diagnostics

M122
=== Diagnostics ===
Used output buffers: 3 of 32 (14 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.20 running on Duet WiFi 1.0
Board ID: 08DGM-95BLL-N65TJ-6J1D6-3S86M-90XVM
Static ram used: 15448
Dynamic ram used: 98920
Recycled dynamic ram: 320
Stack ram used: 1392 current, 4400 maximum
Never used ram: 11984
Last reset 00:02:37 ago, cause: power up
Last software reset at 2018-02-19 23:40, reason: User, spinning module GCodes, available RAM 7944 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 33.8, current 34.2, max 34.4
Supply voltage: min 12.3, current 12.3, max 12.5, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2018-02-21 15:21:03
Cache data hit count 601693000
Slowest main loop (seconds): 0.156814; fastest: 0.000110
=== Move ===
MaxReps: 0, StepErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 1 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 state is running
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.20
WiFi MAC address 2c:3a:e8:0b:28:97
WiFi Vcc 3.38, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 16552
WiFi IP address 192.168.0.123
WiFi signal strength -40dBm, reconnections 0, sleep mode modem
HTTP sessions: 1 of 8
Socket states: 2 0 0 0 0 0 0 0
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)

@Neotko:

@KeeganB:

You can use Pronterface, no problem. Even if you have lower case characters you just need to lead them with a single quote (apostrophe) and it will not convert them to uppercase…

PassWORD would be: P'a's'sWORD

This really works? I would love that to be added to the wiki if so. But like others said I also did use pronterface and the macro instructions of the wiki to set the password. Was quite painless

Yep, it does. It gives confusing output:

M587 S"M'y N'e't'w'o'r'k" P"P'a's's"
SENDING:M587 S"M'Y 'N'E'T'W'O'R'K" P"P'A'S'S"

But if you send command M587 only, it reports back a properly cased wifi network name. I assume the password is cased properly as well, but I Can't confirm, because my wifi network is hidden because come on it's 2018.

Need to install some Beta firmware I guess to be able to connect to a hidden network. Yikes.

For anyone else who finds this via Google, the way to determine your port on a Mac is :

1. Open Terminal (cmd+space, type terminal, hit enter)

2. Type 'ls /dev/tty.*' without the single quotes obviously. Hit enter.

3. You should see a not too large list of ports that are in use. Mine looked like:
   /dev/tty.Bluetooth-Incoming-Port /dev/tty.SOC
   /dev/tty.MALS /dev/tty.usbmodem1442345

4. You're probably looking for one like /dev/tty.usbmodem1442345, but it will have a different number. If you have multiple ports that look like possibilities, just try them in pronterface.

Good Luck!

These instructions are atrocious. Step one says skip this step if you aren't using Windows, then the rest of the instructions are all windows based anyways. I hope Duet3D can update the documentation some.

Will, did you ever get it working on your mac?

StefanC, How were you able to determine the right port?

Thanks!

This is ridiculously awesome. Thanks for sharing.

@dc42:

The two wires belonging to one phase must be at one end of the 4-pin connector that plugs into the Duet, and the two wires belonging to the other phase at the other end.

Thanks! Excited to get back to this tonight.

@dc42:

See https://duet3d.dozuki.com/Wiki/Choosing_and_connecting_stepper_motors?revisionid=HEAD#Section_Identifying_the_stepper_motor_phases.

Thank you for the link - I think I know which wires belong to the same phase, but that doesn't confirm which spot on the board they should be plugged into. Or maybe I'm just being overly cautious. If two wires are the same phase, do they get plugged into the same numbered slots? e.g. 1a and 1b? Does it matter which wire goes to a/b? or does the same phase pair go to 1a and 2a?

Also, to further my understanding, do the names of the pins indicate anything I should be aware of? The + and - on the melzi board were fairly obvious, I think, but I don't want to assume "a" means "-" on the duet.

@darookee:

If nothing has changed in the wiring to the v2.1 they are pin compatible, except the E-stepper, as it does not has a propper connector. For my Wanhao i3 (Maker Select rebrand I think?) I just plugged the steppers in and they work.

Unfortunately, that's not the case for me. The connectors don't fit the Duet Wifi board. I'm going to have to wire up the included connectors, or shave off the "guides" on the printer connectors to make them fit. It would probably just be better to do it right.

Good to know that they are generally pin compatible, however, as the connectors don't line up I don't know if the 1- -> 1b, 1+ -> 1a, or if the 2- ->1b, 2+ ->1a, etc. Or if it even matters.

By the way, thank you for your write up on this process. Much appreciated.

I'm attempting to wire up my newly received Duet Wifi to my Maker Select. The Melzi board had the stepper motor wires labeled in order 1-, 1+, 2+, 2-. The Duet Wifi has 1b, 1a, 2a, 2b. I was hoping to confirm that in this case 1- -> 1b, 1+ -> 1a, etc. Is that the case? If not, what would be the best way to determine the proper wiring? Can I attempt to test a stepper motor without causing damage for wiring it wrong?

Thanks!