Posts made by synfinatic

Looks like v1.04+ support up to 30V for the Z Probe In. What about for versions < 1.04?

Just a quick followup. Was able to RMA both boards and finally found the time to install them and test again. Made sure to use the latest stable releases for both firmware and DWC. All my problems seem to have been resolved.

Thanks to everyone for their help!

Thanks David. I'll reach out to Tim.

So I rewired the ground for the Duet/Duex5 to be per the instructions. The 20AWG wire was IMHO a bit too thin so I spliced the ground together. Basically, the two boards are connected via a single 13AWG wire and then I soldered in another 13AWG wire to connect to the power supply at a single point. I measured the resistance between the 3 connectors to verify a good connection and added some strain relief.

TL;DR: It follows the same pattern. Was able to home a couple of times and run the mesh bed scan via the PanelDue without problems, but I couldn't even get to homing the Y axis the first time without tripping the 20sec delay using DWC.

Any other suggestions/ideas?

@dc42 So I do have those, but they're too small for a single 13AWG wire I've been using for power, let alone two of them, so I used my own. The next smallest size wire I know I have is 20. Might have some 18 lurking around. What size wire is acceptable/is it designed for?

@elmoret You're right. I miss-read the docs. What is the proper way? With the ferrules, I can't daisy-chain the grounds can I? Am I supposed to splice the wires together (solder & heat shrink?). Smaller wires and run two wires into the same ferrule?

@dc42 Connections are solid. Using ferrules on the Duet/Deux5 side and spade connectors on the power supply end. Wire is 13AWG silicone wire. Here's the wiring:

So been playing with the printer most of the day. In general this combo seems to work better, but I'm not at the point of it being fixed. From a fresh power cycle, homing via the PanelDue works most of the time, but not always. Executing more complicated actions like gantry/Z leveling (auto level) and mesh leveling sometimes works, sometimes doesn't. Haven't been able to complete a full leveling cycle yet without things starting to start showing the 20sec delay between moves I've mentioned earlier.

Haven't gotten things reliable enough to start tuning the extruder or even trying to attempt a print.

Honestly, the fact that sometimes it works and sometimes it doesn't, even though the config/macros don't change seems to indicate some kind of firmware/hardware issue. I've re-flashed the firmware probably half a dozen times now, so maybe it's hardware? Not sure what else to do other then to RMA the board unless someone has a better idea?

So trying that combo, and power cycled the printer (no USB connection) to start from a baseline.

From DWC:
First "home all" went perfectly
Second "home all" started fine... X & Y homed normally. Then things started to slow down after the first Z touch off
Third "home all" and there's a ~20 sec delay before each movement, starting immediately from pressing the button in DWC.

Tried home all from the paneldue immediately after the 3rd and it had the same problem.

Rebooted printer again.

From PanelDue:
Ran "home all" 3 times, all behaved correctly

Tried home all from DWC immediately after the 3rd paneldue test and it worked correctly three times in a row.

Then did a bunch of x/y/z moves via DWC. Not only did they move in the correct direction, but they were quick & responsive.

So it seems that as long as I do the homing first via the PanelDue then things are ok. But initial homing via DWC == problems.

Update: edited my config.g (reduced Z travel max) and reloaded. Then tried to re-home via the PanelDue which was immediately buggy. So it really really wants to start off from a hard reset.

Is DWC 1.21 compatible with the latest beta firmware?

Edit: release notes seem to indicate it is if I'm not using a password? Gonna give that a try. Still would love to understand why I'm seeing these delays with the stable release and nobody else running a Duet on the Voron2 is. Of course, it's a pretty small sample size right now.

I've been talking to a few other people with the same printer using the same config. Nobody has seen anything like this. They were thinking I had a bad board.

Ran M122 again, just for comparison:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01beta2(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-95BLL-N6PSS-6JKD0-3S46K-9JSBL
Used output buffers: 1 of 20 (12 max)
=== RTOS ===
Static ram: 28484
Dynamic ram: 95808 of which 0 recycled
Exception stack ram used: 508
Never used ram: 6272
Tasks: NETWORK(ready,400) HEAT(blocked,1248) MAIN(running,3648)
Owned mutexes:
=== Platform ===
Last reset 00:31:18 ago, cause: power up
Last software reset at 2018-07-14 19:28, reason: User, spinning module GCodes, available RAM 6272 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 39.1, current 43.4, max 44.0
Supply voltage: min 24.1, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/204
Driver 1: standstill, SG min/max 0/1011
Driver 2: standstill, SG min/max 0/0
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max 0/250
Driver 6: standstill, SG min/max 0/258
Driver 7: standstill, SG min/max 0/206
Driver 8: standstill, SG min/max 0/253
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 2018-07-14 20:33:41
Slowest loop: 197.57ms; fastest: 2.97ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 236, MaxWait: 828444ms, Underruns: 0, 0
Scheduled moves: 70, completed moves: 70
Bed compensation in use: none
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: 3 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 ready with "M408 S0 R1" 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 ===
Slowest loop: 169.65ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state: 5
=== Expansion ===
DueX I2C errors 6830

@phaedrux It was fine under 2.0 and is fine under 2.01.beta2 via the PanelDue. Only has issues under 2.01beta2 via the DWC.

BTW, thanks for the help. Feel like we made some progress. Hopefully someone else can provide some ideas.

@phaedrux Nope. Just finished wiring and slowly bringing the printer to life. Was acting so wonky I haven't even gotten to the gantry leveling step or even tried the extruder.

Honestly, until upgrading to beta2 I was pretty much convinced my board was bad and I needed to RMA it with Filastruder. But b2 seems like an improvement (at least it seems more consistent) so not sure anymore

Back to beta2 firmware and DWC.

Behaving the same as I described before with this version. The only additional info I can provide is I notice when doing a moves, they're not just running at angles, but reversed on the selected axis. Basically -100 Y causes the head to move +50Y and -50X. Same pattern for X moves. The head position values in the upper right corner of the DWC update correctly based on the physical movement of the head.

Yeah, I uploaded the b2 DWC zip file via the UI after upgrading the firmware.

So I downgraded back to the release version and moving via the web (after homing via paneldue) only moves in a single axis at a time, but there's about a 5sec delay before executing the move. No delay with the paneldue.

I also tried re-homing via DWC, and it's slooooowwwwww again.

I have been testing via the webUI. I've upgraded the firmware and webcontrol files to the latest beta. Started the full homing (via web) and X & Y seemed to work fine. But it never dropped the gantry to home Z and then gave up. The console has the error:

Error: Z probe was not triggered during probing move

Which is accurate.

Rebooted the whole printer and started homing via the PanelDue. That worked perfectly. Moved it around in X, Y, Z, no problems. Re-homed a few more times (still using the PanelDue) and it worked great.

So then started using the WebUI again. Did a full home- worked fine. Tried moving in X and it moved in X and Y. Went back to the PanelDue and verified that DOES NOT happen when moving via the PanelDue. Did more moves via the webUI and seems like any X or Y moves diagonally in both X and Y. If I didn't know better I'd say my CoreXY printer was setup wrong, but this is only happening via the webui.

Update: I should mention that it doesn't move in X and Y when homing X or Y. It only does that during moves post-homing.

I should mention it's not just homing. That's just the obvious example. Manual moves after a successful homing also tend to have random ~20sec delays before execution. The first few times it happened I thought it didn't register the click and I'd click the button again... so the commands would end up getting queued up and execute over time.

Here's a zip file (forums won't let me upload zip files) of the entire contents of my sd card: https://synfin.net/misc/duet-config.zip

0_1531615356465_center_xyz.g
0_1531615163805_config.g
0_1531615217517_homeall.g
3_1531615425548_zhop_up.g
2_1531615425546_probe_zm.g
1_1531615425546_probe_y.g
0_1531615425546_probe_x.g

Here's the M122 after trying to home all axis (which took about 3min). Not sure if it normally takes a few seconds to spit out it's answer, but probably took at least 5sec for me.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-95BLL-N6PSS-6JKD0-3S46K-9JSBL
Used output buffers: 1 of 20 (8 max)
=== RTOS ===
Static ram: 28380
Dynamic ram: 95596 of which 0 recycled
Exception stack ram used: 508
Never used ram: 6588
Task NETWORK ready, free stack 324
Task HEAT blocked, free stack 1256
Task MAIN running, free stack 3656
=== Platform ===
Last reset 00:11:21 ago, cause: power up
Last software reset at 2018-07-14 13:14, reason: User, spinning module GCodes, available RAM 6244 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, 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 31.9, current 43.3, max 43.5
Supply voltage: min 0.0, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/205
Driver 1: standstill, SG min/max 0/167
Driver 2: standstill, SG min/max 0/0
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max 0/230
Driver 6: standstill, SG min/max 0/221
Driver 7: standstill, SG min/max 0/173
Driver 8: standstill, SG min/max 0/177
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 2018-07-14 17:47:34
Slowest loop: 224.26ms; fastest: 3.03ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 236, MaxWait: 722287760ms, Underruns: 0, 2
Scheduled moves: 19, completed moves: 19
Bed compensation in use: none
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: 3 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 ready with "M122" 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 ===
Slowest loop: 228.12ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state: 5
=== Expansion ===
DueX I2C errors 30269
ok

Oh, realized I should include the version info (M115):

FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 2.0(RTOS) ELECTRONICS: Duet Ethernet 1.02 or later FIRMWARE_DATE: 2018-06-05b3

Also, I should mention that I've noticed sometimes various commands over the USB connection seem to have a delay. Ie: something like M115 might take a few seconds before it returns the firmware version.