Vivedino Troodon Board (non-working w/RRF >=3.1).
-
This is a thread I promised @Phaedrux a while back about the vivedino troodon control board which is a Duet2 derivate: It combines a Duet2Wifi and Duex on a single PCB, with seven steppers (so the equivalent of a Duet2Wifi+Duex2). It has a couple subtle differences to the Duet2Wifi board: A weird locking adapter for the Vivedino PanelDue clone (which I do not on), exposed direct stepper control pins, Plug-In drivers in BigFoot format, and likely some other issues.
This board identifies as a Duet+Duex boards when you run M115:
M115 FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.3 ELECTRONICS: Duet WiFi 1.02 or later + DueX5 FIRMWARE_DATE: 2021-06-15 21:45:03
M122 complains about drivers 2, 4, and 9, but those are not on the board and are disabled in the config (see below).
=== Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3 (2021-06-15 21:44:54) runnin g on Duet WiFi 1.02 or later + DueX5 Board ID: 0JD0M-9P6M2-NW4SD-6J9D8-3S86Q-9APHL Used output buffers: 1 of 24 (13 max) === RTOS === Static ram: 23876 Dynamic ram: 79464 of which 0 recycled Never used RAM 11076, free system stack 184 words Tasks: NETWORK(ready,3.9%,227) HEAT(delaying,0.0%,346) Move(notifyWait,0.1%,364) DUEX(notifyWait,0.0%,24) MAIN(running,90.9%,441) IDLE(ready,5.1%,29), total 100 .0% Owned mutexes: USB(MAIN) === Platform === Last reset 00:00:14 ago, cause: software Last software reset at 2021-10-05 18:04, reason: User, GCodes spinning, availabl e RAM 11076, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Step timer max interval 0 MCU temperature: min 29.8, current 30.3, max 30.7 Supply voltage: min 24.1, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0 , gc cycles 0 Driver 0: position 0, standstill, SG min/max not available Driver 1: position 0, standstill, SG min/max not available Driver 2: position 0, temperature-shutdown! short-to-ground, standstill, SG min/ max not available Driver 3: position 0, standstill, SG min/max not available Driver 4: position 0, temperature-shutdown! short-to-ground, standstill, SG min/ max not available Driver 5: position 0, standstill, SG min/max not available Driver 6: position 0, standstill, SG min/max not available Driver 7: position 0, standstill, SG min/max not available Driver 8: position 0, standstill, SG min/max not available Driver 9: position 0, temperature-shutdown! short-to-ground, standstill, SG min/ max not available Driver 10: position 0 Driver 11: position 0 Date/time: 2021-10-05 18:04:49 Cache data hit count 1047507163 Slowest loop: 1.75ms; fastest: 0.70ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 1.5ms, write time 0.0ms, max retries 0 === Move === DMs created 83, maxWait 0ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Under runs [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Under runs [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 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 USB is ready with "M122" in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === DueX === Read count 1, 4.11 reads/min === Network === Slowest loop: 29.96ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 - WiFi - Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.26 WiFi MAC address 3c:61:05:e6:f7:3b WiFi Vcc 3.38, reset reason Turned on by main processor WiFi flash size 4194304, free heap 24240 WiFi IP address 192.168.86.39 WiFi signal strength -58dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0 ok
As a reference configuration, I used the Ender 3 configuration from the Config Tool, and added 3 lines to disable the nonexisting steppers to get rid of errors about them. Here is config.g:
; Configuration file for Duet WiFi (firmware version 3.3) ; executed by the firmware on start-up ; ; generated by RepRapFirmware Configuration Tool v3.3.3 on Tue Oct 05 2021 16:07:09 GMT+0200 (Mitteleuropäische Sommerzeit) ; General preferences G90 ; send absolute coordinates... M83 ; ...but relative extruder moves M550 P"Vivedino" ; set printer name M918 P1 E4 F2000000 ; configure direct-connect display ; Network M552 S1 ; enable network M586 P0 S1 ; enable HTTP M586 P1 S0 ; disable FTP M586 P2 S0 ; disable Telnet ; Drives M569 P0 S0 ; physical drive 0 goes backwards M569 P1 S0 ; physical drive 1 goes backwards M569 P2 S1 ; physical drive 2 goes forwards M569 P3 S0 ; physical drive 3 goes backwards M584 X0 Y1 Z2 E3 ; set drive mapping M350 X16 Y16 Z16 E16 I1 ; configure microstepping with interpolation M92 X80.00 Y80.00 Z400.00 E93.00 ; set steps per mm M566 X1200.00 Y1200.00 Z24.00 E300.00 ; set maximum instantaneous speed changes (mm/min) M203 X9000.00 Y9000.00 Z180.00 E6000.00 ; set maximum speeds (mm/min) M201 X500.00 Y500.00 Z100.00 E5000.00 ; set accelerations (mm/s^2) M906 X800 Y800 Z800 E1000 I50 ; set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout ; Axis Limits M208 X0 Y0 Z0 S1 ; set axis minima M208 X235 Y235 Z260 S0 ; set axis maxima ; Endstops M574 X1 S1 P"xstop" ; configure active-high endstop for low end on X via pin xstop M574 Y1 S1 P"ystop" ; configure active-high endstop for low end on Y via pin ystop M574 Z1 S1 P"zstop" ; configure active-high endstop for low end on Z via pin zstop ; Z-Probe M558 P0 H5 F120 T6000 ; disable Z probe but set dive height, probe speed and travel speed M557 X15:215 Y15:195 S20 ; define mesh grid ; Heaters M308 S0 P"bedtemp" Y"thermistor" T100000 B4092 ; configure sensor 0 as thermistor on pin bedtemp M950 H0 C"bedheat" T0 ; create bed heater output on bedheat and map it to sensor 0 M307 H0 B1 S1.00 ; enable bang-bang mode for the bed heater and set PWM limit M140 H0 ; map heated bed to heater 0 M143 H0 S150 ; set temperature limit for heater 0 to 150C M308 S1 P"e0temp" Y"thermistor" T100000 B4092 ; configure sensor 1 as thermistor on pin e0temp M950 H1 C"e0heat" T1 ; create nozzle heater output on e0heat and map it to sensor 1 M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit M143 H1 S275 ; set temperature limit for heater 1 to 275C ; Fans M950 F0 C"fan0" Q500 ; create fan 0 on pin fan0 and set its frequency M106 P0 S0 H-1 ; set fan 0 value. Thermostatic control is turned off M950 F1 C"fan1" Q500 ; create fan 1 on pin fan1 and set its frequency M106 P1 S1 H1 T45 ; set fan 1 value. Thermostatic control is turned on M950 F2 C"fan2" Q500 ; create fan 2 on pin fan2 and set its frequency M106 P2 S1 H1:0 T45 ; set fan 2 value. Thermostatic control is turned on ; Tools M563 P0 D0 H1 F0 ; define tool 0 G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C ; Custom settings are not defined ; Disable nonexisting stepper drivers M569 P2 R-1 M569 P4 R-1 M569 P9 R-1
It accepts and runs Duet2Wifi firmware and RRF2.x and 3.0 run fine on the board. With 3.1 and above (tested with 3.1.0 which you aren't supposed to be using, 3.1.1, and 3.3), the board still boots up fine but triggers "motor phase may be disconnected" as soon as you command a move:
G0 H2 X100 F300 Warning: motor phase A may be disconnected reported by driver(s) 0 Warning: motor phase B may be disconnected reported by driver(s) 0 Warning: motor phase A may be disconnected reported by driver(s) 0 Warning: motor phase B may be disconnected reported by driver(s) 0 Warning: motor phase A may be disconnected reported by driver(s) 0 Warning: motor phase B may be disconnected reported by driver(s) 0 Warning: motor phase A may be disconnected reported by driver(s) 0 Warning: motor phase B may be disconnected reported by driver(s) 0 Warning: motor phase A may be disconnected reported by driver(s) 0 Warning: motor phase B may be disconnected reported by driver(s) 0
Here are some shots of the board in my "test bench" setup.
(Yes, the OHL license and attribution is missing on the silk screen. I have reached out to Formbot3D asking for the design files for this board, will follow up about the silk screen next.)
-
@oliof What drivers are on the bigfoot modules? How are the drivers mapped to the duet numbering scheme (is 0 theone on the left looking at your top view picture?)? Because looking at the pictures it seems that drive 0 is disconnected, so the error message may be correct?
-
@gloomyandy They're TMC2660. I connected the stepper to the port labelled X and tried moving the X stepper. And, just to repeat -- everything works as expected with RRF2.x and 3.0 with no changes to the wiring.
The error message is definitely not correct.
(for clarity: The stepper connectors are labelled E0 X Y E2 E3 E4 E5, this can also be seen on the back).
-
@oliof are the 2.05 and 3.0 builds you are using ones supplied by them or ones supplied by duet?
-
@jay_s_uk they're the genuine Duet3D builds. Formbot3D doesn't provide their own builds.
-
-
@oliof Can you check the m122 output while you are getting the warning to see if the driver status shows a similar message. Was it the same config.g file for both 3.0 and 3.x (x>=1)?
-
@gloomyandy yes, the same config.g as posted above. I will do some more testing tomorrow.
-
Here are some photos of the bigfoot stepper modules, the last one with an overlay of the 2660 pinout courtesy of Chase Daigle.
-
@gloomyandy here's an M122 after an attempted X move:
M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3 (2021-06-15 21:44:54) running on Duet WiFi 1.02 or later + DueX5 Board ID: 0JD0M-9P6M2-NW4SD-6J9D8-3S86Q-9APHL Used output buffers: 3 of 24 (24 max) === RTOS === Static ram: 23876 Dynamic ram: 79464 of which 0 recycled Never used RAM 11076, free system stack 150 words Tasks: NETWORK(ready,6.6%,249) HEAT(delaying,0.0%,342) Move(notifyWait,0.1%,323) DUEX(notifyWait,0.0%,24) MAIN(running,93.3%,415) IDLE(ready,0.0%,29), total 100.0% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 00:02:48 ago, cause: power up Last software reset at 2021-10-05 18:04, reason: User, GCodes spinning, available RAM 11076, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x04 Step timer max interval 0 MCU temperature: min 25.0, current 25.8, max 25.9 Supply voltage: min 24.2, current 24.4, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0 Driver 0: position 800, standstill, SG min/max not available Driver 1: position 0, standstill, SG min/max not available Driver 2: position 0, temperature-shutdown! short-to-ground, standstill, SG min/max not available Driver 3: position 0, standstill, SG min/max not available Driver 4: position 0, temperature-shutdown! short-to-ground, standstill, SG min/max not available Driver 5: position 0, standstill, SG min/max not available Driver 6: position 0, standstill, SG min/max not available Driver 7: position 0, standstill, SG min/max not available Driver 8: position 0, standstill, SG min/max not available Driver 9: position 0, temperature-shutdown! short-to-ground, standstill, SG min/max not available Driver 10: position 0 Driver 11: position 0 Date/time: 2021-10-06 07:19:47 Cache data hit count 4294967295 Slowest loop: 4.21ms; fastest: 0.70ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 0.4ms, write time 0.0ms, max retries 0 === Move === DMs created 83, maxWait 145255ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 2, completed moves 2, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 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 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === DueX === Read count 0, 0.00 reads/min === Network === Slowest loop: 199.91ms; fastest: 0.08ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 - WiFi - Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 2 WiFi firmware version 1.26 WiFi MAC address 3c:61:05:e6:f7:3b WiFi Vcc 3.38, reset reason Turned on by main processor WiFi flash size 4194304, free heap 19488 WiFi IP address 192.168.86.39 WiFi signal strength -56dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 4 0 0 0 0 0 0
It bears noting that I by now twice did an accidental
G0 H2 X1 F300
before aG0 H2 X10 F300
-- and on the X1 move nothing happened; neither a move nor a motor phase error. -
@oliof I can't say anything about the FW-issues, but i compared the 2660 PCB with the original Duet2. I noticed, there are far more "vias" on the Duet around the 4 output tracks (A1-B2) and the tracks are much wider. The Duet also has more vias below the chip to transfer heat to the PCB backside.
Could you post a picture of an empty driver-socket? I'm missing a big capacitor on the driver to stabilize VMot. -
@oliof Are you still getting an error saying:
"motor phase A may be disconnected reported by driver(s) 0"
If you are can you run m122 when that error is being reported. I would expect the motor status to report:
"open-load-A"
or something similar. In your original post it looked like it was reporting the error over and over once it happened was that the case or was it reporting it only when you did a move? -
@oliof is it because it identifies as Duet+DueX5, rather than Duet+DueX2, so it’s not disabling the extra non-existent drivers? How did it identify on old FW versions? There’s definitely a hardware difference between the real boards. See https://duet3d.dozuki.com/Wiki/Duex2_and_Duex5_Features#Section_Using_a_DueX5_with_External_drivers
I’d guess you’d have to look at the Troodon schematic next to the DueX schematic to work out what’s different.
Ian
-
@droftarts it doesn't include the Drivers 2, 4 and 9, which are Z, E1 and E6 so it really is a duet+duex5 rather than a duet+duex2
-
@gloomyandy yes and the M122 is from when I got the error. And yes, it does repeat reporting the error.
-
@o_lampe .
Yes, the cooling setup is different, but please remember: The hardware is proven to work, it worked fine with RRF until 3.0 and it continues to work well with either older RRF versions or Klipper. The design may not be ideal, but it's solid and functional.
-
@droftarts it always identifies as a Duet+DuetX5, and as you can see in my config.g, the missing drivers are disabled so they don't report an error. I have not heard back from Formbot3D but if I am not mistaken there's a weeklong holiday so I picked an unfortunate time to expect a speedy answer.
-
@o_lampe @droftarts one of the easiest discernible differences is that SG_TEST is not connected, i.e. stallguard pin is floating. Since people elsewhere were theorizing the floating stallguard may be a problem, I bridged SG_TEST to the neighboring GND pin (which I confirmed to be going on the GND rail with a multimeter, I also checked my solder attempt and it's got continuity from SG_TEST to VNegative).
Unfortunately no change.
-
To make it clear @gloomyandy: While I get the phase mismatch error in the console, the driver does not report open load state in M122. That is what you were looking for?
-
@oliof I was expecting to see it in the m122 output, but there is a lot of "filtering" going on for this condition (motor, current, step speed, must be reported constantly over time), so it's hard to be sure. I've had a good luck at the changes since V3.0 and I can't see anything obvious that would result in what you are seeing.