RRF M669 Kinematics Issue

Phaedrux

Have you tried with just M669 K5?

DougJones

@Phaedrux
~~That seems to have loaded the config file without issue. But there is no way that the kinematics are setup correctly, right?~~

My mistake, I did not apply the config file. When I did, the WIFI dropped and the DUet locked up again.

for reference it is not a corexyu

it is exactly this:

alt text

Phaedrux

That's quite strange. Can you try something more pedestrian like M669 K1 for a plain corexy? Don't move anything obviously, I just want to know if it causes the same problem.

DougJones

@Phaedrux

Yes, same problem is confirmed.

I feel like I've tried every possible combination. Anytime the M669 command is in the config file, the unit seems to lockup with no wifi.

I have to pull the SD card, insert it into the laptop. Comment out that one line and DWC loads and I get a blue light on the wifi module.

If i go into the config file edit it to uncomment the M669 line. The blue light on the wifi module drops and I cannot access the duet.

dc42

@DougJones I confirm that there is a bug that is causing the Duet to reset. I am investigating it.

dc42

@DougJones this problem is that on this line:

M669 K5 X1:0:0:0 Y-1:1:0:1 Z0:0:1:0 U0:0:0:1 : set custom Kinematics

you have used ':' instead of ';' to introduce the comment. A bug in the RRF handling of some M669 errors is causing the Duet to reset instead of displaying an error message. I will fix the error handling in RRF 3.5 and 3.4.6.

DougJones

@dc42

Great. I will try this later today. My eyes must be getting bad....I've stared at that one line for several hours and not noticed.

-Doug

DougJones

@dc42

Okay, great that fixed the issue with the config file. Now, onto the second problem.

The Duet keeps disconnecting about once per minute. It shows from M122 as

WiFi Vcc 3.40, reset reason Turned on by main processor

My wifi signal is very good as I installed an access point directly next to the machine. Its the same access point that ran the machine previously in the old house. Its a TP-Link Deco, so I don't have a lot of options for channels and whatnot. I've been through all the other posts about this issue and have yet to find a solution.

WiFi signal strength -34dBm, mode 802.11n, reconnections 0, sleep mode modem

It seems pretty consistant every minute or two the DWC disconnects

2/13/2023, 11:51:11 AM	Connection established
2/13/2023, 11:51:09 AM	Connection interrupted, attempting to reconnect...
HTTP request timed out
2/13/2023, 11:48:38 AM	Connection established
2/13/2023, 11:48:37 AM	Connection interrupted, attempting to reconnect...
HTTP request timed out

I did not have this problem on firmware 2.02. But like I say, the machine has been idle for 18 months and that was way back on firmware 2.02 and now I am on 3.4.5

Results from M122:

2/13/2023, 11:47:25 AM	m122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.5 (2022-11-30 19:36:12) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-917DA-G4MSD-6J9D8-3S86P-K8UMA
Used output buffers: 1 of 26 (16 max)
=== RTOS ===
Static ram: 23836
Dynamic ram: 76588 of which 960 recycled
Never used RAM 10696, free system stack 184 words
Tasks: NETWORK(notifyWait,16.9%,242) HEAT(notifyWait,0.0%,317) Move(notifyWait,0.0%,363) DUEX(notifyWait,0.0%,24) MAIN(running,82.5%,438) IDLE(ready,0.6%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:02:33 ago, cause: power up
Last software reset time unknown, reason: TerminateCalled, GCodes spinning, available RAM 38792, slot 0
Software reset code 0x0183 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0400f000 BFAR 0xe000ed38 SP 0x20001f40 Task MAIN Freestk 516 ok
Stack: 0000002b 0045f57b 00000000 2000ce38 20002310 0045f9a7 00000000 0045f2fd 20001f90 0041da03 20001fe0 00000000 2000ce38 00000000 200021dc 00000001 00000000 00463f2b 20001fe0 00000000 2000ce38 00463f2b 0047d670 2000ce38 0041da01 200021dc ffffffff
Error status: 0x00
Step timer max interval 0
MCU temperature: min 16.5, current 23.6, max 23.9
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
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a
Driver 1: standstill, SG min n/a
Driver 2: standstill, SG min n/a
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min n/a
Driver 5: standstill, SG min n/a
Driver 6: standstill, SG min n/a
Driver 7: standstill, SG min n/a
Driver 8: standstill, SG min n/a
Driver 9: standstill, SG min n/a
Driver 10: 
Driver 11: 
Date/time: 2023-02-13 11:47:24
Cache data hit count 4294967295
Slowest loop: 22.02ms; fastest: 0.18ms
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 7.1ms, write time 16.9ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters 7 -1 -1 -1, ordering errs 0
Heater 7 is on, I-accum = 0.0
=== 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 1, 0.39 reads/min
=== Network ===
Slowest loop: 37.34ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
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.27
WiFi MAC address ec:fa:bc:2d:e2:de
WiFi Vcc 3.40, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 25848
WiFi IP address 192.168.68.152
WiFi signal strength -34dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

Phaedrux

@DougJones Can you verify that your DWC version is also 3.4.5?

You can also try reflashing everything by uploading the full release zip file to the system tab in DWC.

https://github.com/Duet3D/RepRapFirmware/releases/download/3.4.5/Duet2and3Firmware-3.4.5.zip

DougJones

@Phaedrux
Yes. DWC is 3.4.5

DougJones

@Phaedrux

Yes, everything is re-flashed now and same response

update: I just spent 2 hours getting another AP setup with its own SSID and trying to connect the Duet to that, only to realize that its a 5GHz only AP. I cannot seem to catch a break here. I liked this idea of having a "3D printer only" wireless network to keep it from "hopping" AP nodes on my mesh network. And I has this really nice TP-Link Pharos AP that allowed me complete control to select channels/frequences, etc.

Off to FB marketplace to see if I can get a cheap AP/Router to test with.

Phaedrux

For what it's worth I have a very old 2.4ghz router that provides a network for the printers and it's been going strong for years. There have been a few other reports of mesh routers not playing nice.

@DougJones said in RRF M669 Kinematics Issue:

only to realize that its a 5GHz only AP

I didn't realize there was such a thing. I thought they were all combo units.

dc42

@DougJones it's probably not relevant to this issue, but running RRF 3.5beta2 with your config.g file I see these startup errors reported:

Error in start-up file macro line 32: Driver 7 does not support x4 microstepping with interpolation
Driver 8 does not support x4 microstepping with interpolation
Driver 9 does not support x4 microstepping with interpolation

These relate to the M350 line. You could avoid them by using two separate M350 lines, one for Z (with I0) and one for the other axes. But is there a reason why you are running Z with just x4 microstepping instead of the usual x16 ?

This board is also running WiFi firmware 1.27 and my WiFi is also a TPLink Deco mesh. The connection is stable. An app on my smartphone indicates that the mesh system is using channel 4.

DougJones

@dc42

Okay, I have a new AP installed in the garage with the printer. Its a TP-Link Pharos with b/g/n @ 2.4 GHz. The printer now has its own SSID and its isolated from the DECO system. I'm at about 30 minutes with no disconnections. I am running channel 6 with WPA2-psk with AES and 0 db of antenna boost. This Pharos unit lets me control everything through its web interface.

For reference: I had a TP-Link DECO M5 system for years and it ran great. When we bought the new house a couple of months ago, I upgrade to the Newest, fastest DECOs that support wifi 6E (its an XE 75). The system works great, but this isn't the first device on 2.4Ghz that I have found a little flaky.

wifi section from M122:

= WiFi =
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 2
WiFi firmware version 1.27
WiFi MAC address ec:fa:bc:2d:e2:de
WiFi Vcc 3.40, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 23824
WiFi IP address 192.168.68.152
WiFi signal strength -36dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

Regarding the M350 line:

I'm not sure why i am not using x16. I feel like there was a reason for this years ago when Initially set this up. I think that I might have been worried about the weight of the z-axis. At the time, I had 2 ballscrews connecting an aluminum plate x axis. I think I might have been concerned about the drop off in holding torque for x16 microstepping (maybe wrongly, but I think that was the reason).

Now my setup is 4 independent z-axis motors each controlling a ballscrew to do mesh leveling and remove some of the twist in the heated bed. That system works great.

If its okay, I might leave this alone for now, but I can test moving to x16 once I have everything moving again.

M350 X16 Y16 Z4 U16 E16:16 I1                  				; configure microstepping with interpolation

I think you are suggesting that I should do this:

M350 X16 Y16 U16 E16:16 I1                  				; configure microstepping with interpolation
M350 Z4 I0

Update: Well.....she is up and printing again..... Thanks for all the help. WIFI is infinitely more stable now. I'll do a few test prints, dial everything in real good and then I'll have a look at the z axis x16 settings