Duet2 Wifi+Duex5 and SBC
-
@taconite What I meant was a command-line shell, i.e. login via SSH or in case you have keyboard and screen connected to the RPi open a shell there (in UI look for Terminal or Shell). Basically the location where you also ran
systemctl status ...
orjournalctl
. -
@wilriker said in Duet2 Wifi+Duex5 and SBC:
@taconite What I meant was a command-line shell, i.e. login via SSH or in case you have keyboard and screen connected to the RPi open a shell there (in UI look for Terminal or Shell). Basically the location where you also ran
systemctl status ...
orjournalctl
.I guess we had a misunderstanding. I understood you that the command line needs to be in SSH or on the pi command itself. I was wondering about the command that I should issue To phrase it differently I don't know which command I should run.
pi@duet3:~ $ systemctl status duetcontrolserver.service -l debug Unit debug.service could not be found. â duetcontrolserver.service - Duet Control Server Loaded: loaded (/lib/systemd/system/duetcontrolserver.service; enabled; vendo Active: activating (start) since Thu 2021-02-11 20:28:52 CET; 1s ago Main PID: 1596 (DuetControlServ) Tasks: 9 (limit: 2062) CGroup: /system.slice/duetcontrolserver.service ââ1596 /opt/dsf/bin/DuetControlServer Feb 11 20:28:52 duet3 systemd[1]: Starting Duet Control Server... Feb 11 20:28:53 duet3 DuetControlServer[1596]: Duet Control Server v3.2.0 Feb 11 20:28:53 duet3 DuetControlServer[1596]: Written by Christian Hammacher fo Feb 11 20:28:53 duet3 DuetControlServer[1596]: Licensed under the terms of the G lines 1-13/13 (END)...skipping... Unit debug.service could not be found. â duetcontrolserver.service - Duet Control Server Loaded: loaded (/lib/systemd/system/duetcontrolserver.service; enabled; vendor preset: enabled) Active: activating (start) since Thu 2021-02-11 20:28:52 CET; 1s ago Main PID: 1596 (DuetControlServ) Tasks: 9 (limit: 2062) CGroup: /system.slice/duetcontrolserver.service ââ1596 /opt/dsf/bin/DuetControlServer Feb 11 20:28:52 duet3 systemd[1]: Starting Duet Control Server... Feb 11 20:28:53 duet3 DuetControlServer[1596]: Duet Control Server v3.2.0 Feb 11 20:28:53 duet3 DuetControlServer[1596]: Written by Christian Hammacher for Duet3D Feb 11 20:28:53 duet3 DuetControlServer[1596]: Licensed under the terms of the GNU Public License Version 3 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ lines 1-13/13 (END)
pi@duet3:~ $ journalctl -xeu duetcontrolserver.service -l debug Failed to add match 'debug': Das Argument ist ungĂźltig pi@duet3:~ $ journalctl -xeu -l debug duetcontrolserver.service Failed to add match 'debug': Das Argument ist ungĂźltig pi@duet3:~ $ journalctl -l debug duetcontrolserver.service Failed to add match 'debug': Das Argument ist ungĂźltig pi@duet3:~ $ journalctl -l duetcontrolserver.service Failed to add match 'duetcontrolserver.service': Das Argument ist ungĂźltig pi@duet3:~ $
-
@taconite Sorry, I haven't been clear. So a more step-by-step instruction set.
First make sure to stop the duetcontrolserver service:sudo systemctl stop duetcontrolserver
then run DuetControlServer manually with debug logging enabled:
sudo su - dsf -c "/opt/dsf/bin/DuetControlServer -l debug"
This will output everything directly to the console with logging in debug level.
-
This is the output
pi@duet3:~ $ sudo systemctl stop duetcontrolserver pi@duet3:~ $ sudo su - dsf -c "/opt/dsf/bin/DuetControlServer -l debug" This account is currently not available. pi@duet3:~ $
-
-
@wilriker said in Duet2 Wifi+Duex5 and SBC:
sudo /opt/dsf/bin/DuetControlServer -l debug
pi@duet3:~ $ sudo systemctl stop duetcontrolserver pi@duet3:~ $ sudo /opt/dsf/bin/DuetControlServer -l debug Duet Control Server v3.2.0 Written by Christian Hammacher for Duet3D Licensed under the terms of the GNU Public License Version 3 [info] Settings loaded [info] Environment initialized [fatal] Could not connect to Duet (Board is not available (no header)) [debug] System.OperationCanceledException: Board is not available (no header) at DuetControlServer.SPI.DataTransfer.ExchangeHeader() in /home/christian/Due t3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 1170 at DuetControlServer.SPI.DataTransfer.PerformFullTransfer(Boolean connecting) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataT ransfer.cs:line 162 at DuetControlServer.SPI.DataTransfer.Init() in /home/christian/Duet3D/DuetSo ftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 104 at DuetControlServer.Program.Main(String[] args) in /home/christian/Duet3D/Du etSoftwareFramework/src/DuetControlServer/Program.cs:line 113
again "no header" but I checked the wiring multiple times. Maybe there is something wrong with the small pcb (btw. I already checked for lifted pads and measured the connections)
-
@taconite I never tested how good it works with the Wifi Module still present. In theory that should work but I only ever tested with a Duet 2 Ethernet with Ethernet module removed. So it's possible that there is an issue with that.
-
@taconite said in Duet2 Wifi+Duex5 and SBC:
(https://forum.duet3d.com/topic/17203/duet-2-ethernet-and-sbc)
mh okay I thought I read in this topic ((https://forum.duet3d.com/topic/17203/duet-2-ethernet-and-sbc)) that s.o. made it work with the wifi module still present. BTW the LED of the wifi module is not flashing and I installed the duet wifi server fw that came with 3.2 before I moved to the SBC duet FW
-
@taconite Yes, I think another user got it working with Wifi module still installed. And also for D2SBC build the pin that enables Wifi module is explicitly held low on start-up such that the module does not start but still it being present could lead to signal detrimination.
Anyway, looking again at what you posted above, it says that there is no header. This at least means that the transfer ready pin is working correctly now. You said you have checked the wiring multiple times but please check again that did not mix-up MISO and MOSI - and in doubt try switching them on the RPi GPIO header.
-
okay seems like a little progress! Wiring was fine but I decided to replace the "little" board.
I get a connection but it seems unstable
and now I get something:[debug] Connection to Linux established! [warn] Restarting transfer because a bad header response was received (0xffffff01) [debug] Updated key limits [warn] Restarting transfer because a bad data response was received (0x0000006c) [warn] Restarting transfer because a bad data response was received (0x00000022) [warn] Bad data CRC32 (expected 0xd6ae08fc, got 0x0400dced) [debug] Requesting update of key boards, seq 0 -> 0 [warn] Restarting transfer because a bad data response was received (0x0000006c) [debug] Updated key boards [debug] Requesting update of key fans, seq 0 -> 0 [debug] Updated key fans [warn] Restarting transfer because a bad header response was received (0xffffff01) [debug] Requesting update of key heat, seq 0 -> 0 [warn] Restarting transfer because a bad header response was received (0xffffff01) [warn] Restarting transfer because a bad header response was received (0x000000fe) [debug] Updated key heat [debug] Requesting update of key inputs, seq 0 -> 0 [warn] Restarting transfer because a bad data response was received (0x00000200) [debug] Connection to Linux established! [warn] Restarting transfer because a bad data response was received (0xffffff6f) [debug] Updated key limits [warn] Restarting transfer because a bad data response was received (0x00000400) [warn] Restarting transfer because a bad header response was received (0xffffff01) [debug] Connection to Linux established! [warn] Restarting transfer because a bad header response was received (0xffffff01) [warn] Restarting transfer because a bad header response was received (0x000000fe) [warn] Restarting transfer because a bad header response was received (0x000000fe) [warn] Restarting transfer because a bad header response was received (0x000000fe) [warn] Restarting transfer because a bad header response was received (0x000000fe) [warn] Restarting transfer because a bad header response was received (0x10f001fe) [warn] Restarting transfer because a bad header response was received (0xffffff01) [warn] Restarting transfer because a bad header response was received (0x000000fe) [warn] Restarting transfer because a bad header response was received (0x000000fe) [warn] Restarting transfer because a bad header response was received (0x000000fe) [warn] Restarting transfer because a bad header response was received (0x000000fe) [warn] Restarting transfer because a bad header response was received (0x000000fe) [warn] Restarting transfer because a bad header response was received (0x00000140) [warn] Bad data CRC32 (expected 0x6b118bf2, got 0x9427c9a1) [warn] Restarting transfer because a bad data response was received (0xffffff65) [debug] Connection to Linux established! [warn] Restarting transfer because a bad data response was received (0x00001000) [warn] Bad header CRC32 (expected 0xffffffff, got 0x1523f9ff) [warn] Note: RepRapFirmware didn't receive valid data either (code 0x0004005f) [warn] Restarting transfer because the number of maximum retries has been exceeded [debug] Connection to Linux established! [debug] Updated key limits [warn] Bad data CRC32 (expected 0x59fc6687, got 0x0af43244) [warn] Bad data CRC32 (expected 0x59fc6687, got 0xa820c52f) [warn] Bad data CRC32 (expected 0x59fc6687, got 0xfad539a4) [warn] Restarting transfer because the number of maximum retries has been exceeded [warn] Restarting transfer because a bad data response was received (0x00200020) [debug] Connection to Linux established!
-
@wilriker Is there something I can do to stabilize the connection?
-
@taconite You could try reducing SPI frequency in /opt/dsf/conf/config.json
-
@wilriker it is already lowered to 2MHz
-
@taconite Try going down (half frequency in each step) to see if you can find a speed at which it still works - if any.
-
@wilriker Lowered the SPI to 500000 Hz still no stable connection. Could it be that the RapsberryPi power supply is undersized?
The Pi is getting fairly hot.
The transfer ready pin is reading 3,3V (saw that in another thread) -
@taconite which RPi are you using? Apart from very early versions of DSF your Pi is supposed to eventually die from boredom not from burnout. What I mean is that DSF even while printing is fairly nice on resources.
Also unless you connect power drawing USB devices the RPi does not need mich power.If you can't get a stable connection at 500kHz, my experience was that there still is something wrong with wiring. From your description and images everything looks fine but obviously it's not.
-
@taconite Du you still have the ground connection between RPi and Duet PSU? I can see it on the initial setup but not in the later setup with the short ribbon cable. This connection is vital for a stable communication.
-
So far - Thank you for your time and effort @wilriker I really appreciate it!!
I am using the RPi 3B+. I am just sometimes (by sometimes I mean I tried both with or without devices, startet with and then disconnected or started without and then connected) connecting a USB Mouse and keyboard but it seems to make no difference.
I removed the connection because bearer (seems like he is not a part of the community anymore) that there is a connection between the sbc the board and the PowerSupply via the duet.
I added another ground connection. Now I get
[debug] Connection to Linux established! [warn] Restarting transfer because a bad data response was received (0xffffff6f) [debug] Updated key limits [debug] Requesting update of key boards, seq 0 -> 0 [debug] Updated key boards [debug] Requesting update of key fans, seq 0 -> 0 [debug] Updated key fans [debug] Requesting update of key heat, seq 0 -> 0 [debug] Updated key heat [debug] Requesting update of key inputs, seq 0 -> 0 [warn] Bad data CRC32 (expected 0xc1080bd3, got 0x1c82d85c) [warn] Bad data CRC32 (expected 0xc1080bd3, got 0xe22206da) [debug] Updated key inputs [debug] Requesting update of key job, seq 0 -> 22 [debug] Updated key job [debug] Requesting update of key move, seq 0 -> 34 [debug] Updated key move [debug] Requesting update of key network, seq 0 -> 2 [debug] Updated key network [debug] Requesting update of key sensors, seq 0 -> 0 [debug] Updated key sensors [debug] Requesting update of key spindles, seq 0 -> 0 [debug] Updated key spindles [debug] Requesting update of key state, seq 0 -> 0 [warn] Bad data CRC32 (expected 0x93b784ac, got 0xaa5a56ed) [debug] Updated key state [debug] Requesting update of key tools, seq 0 -> 0 [debug] Updated key tools [warn] Bad data CRC32 (expected 0xd34f675f, got 0x61c25a1a) [warn] Bad data CRC32 (expected 0x7fc40204, got 0xb18115a5) [warn] Bad data CRC32 (expected 0xda9ff4a3, got 0x21a0745f) [warn] Bad data CRC32 (expected 0xda9ff4a3, got 0x9a65823f) [warn] Bad data CRC32 (expected 0x35e61450, got 0x25ba3ca7) [warn] Bad data CRC32 (expected 0x35e61450, got 0xa286412b) [warn] Bad data CRC32 (expected 0x35e61450, got 0x1835cde6) [warn] Restarting transfer because the number of maximum retries has been exceeded [warn] Restarting transfer because a bad header response was received (0xffffff01) [debug] Connection to Linux established! [debug] Updated key limits [debug] Requesting update of key boards, seq 0 -> 0 [debug] Updated key boards [debug] Requesting update of key fans, seq 0 -> 0 [debug] Updated key fans [debug] Requesting update of key heat, seq 0 -> 0 [debug] Updated key heat [debug] Requesting update of key inputs, seq 0 -> 0 [debug] Updated key inputs [debug] Requesting update of key job, seq 0 -> 23 [warn] Bad data CRC32 (expected 0x06345c63, got 0x71e5899b) [debug] Updated key job [debug] Requesting update of key move, seq 0 -> 34 [warn] Bad data CRC32 (expected 0x3b75061d, got 0x2d9ac0a1) ^C[warn] Received SIGINT, shutting down... [debug] IPC task terminated [debug] SPI task terminated [debug] Periodic updater task terminated [debug] Job task terminated [debug] Update task terminated [debug] Stopping plugins and saving their execution state [info] Application has shut down
I will redo the wiring and start from a white piece of paper (the first time I redone the wiring I startet from a white piece of paper aswell)
-
@taconite Which version of DSF are you using? The 3.2.2 version contains a change to the way that DSF waits for the transfer ready signal that makes it a little more resistant to noise on that pin. Probably not a total fix, but it may help.
I'm following this thread with interest as a number of users of the LPC/STM32 port of RRF have also had issues with noise on the link between the control board and the rPi. On those boards noise on the transfer ready pin can cause a lot of problems as it can trigger a transfer when RRF is not really ready.
-
@taconite said in Duet2 Wifi+Duex5 and SBC:
I removed the connection because bearer (seems like he is not a part of the community anymore) that there is a connection between the sbc the board and the PowerSupply via the duet.
In theory there is via the common ground from VIN -> 5V -> 3.3V but I found on my setup that I cannot get stable communication without an additional direct connection from RPi GND to Duet PSU GND.
Also just as an idea: all my wiring is 0.34mm².And yes, bearer unfortunately left this community.