I may have fixed this already. I noticed in the log the SPI buffer warning. I increased the SPI buffer in raspbian to 8192 and now it seems to be working. But, my config must be totally broken in this version as I can't seem to power on my PSU anymore due to no PS_ON port defined. Off I go down the rabbit hole. 
edit: config fixed by changing M80 to M80 C"pson"
I have a Duet 3 6HC & Raspberry Pi 4 SBC on my E3D Tool Changer
I ran an apt upgrade for duetsoftwareframework and after completion, web control just loops between connected/disconnected. Using advice I found in another thread, I opened a terminal on the SBC and ran sudo journalctl -u duetcontrolserver -ef
It seems DCS hits an exception and crashes resulting in a start/stop loop. Here's the log terminal output:
Feb 17 21:21:35 duet3 systemd[1]: Starting Duet Control Server...
Feb 17 21:21:36 duet3 DuetControlServer[11398]: Duet Control Server v3.4.6
Feb 17 21:21:36 duet3 DuetControlServer[11398]: Written by Christian Hammacher for Duet3D
Feb 17 21:21:36 duet3 DuetControlServer[11398]: Licensed under the terms of the GNU Public License Version 3
Feb 17 21:21:36 duet3 DuetControlServer[11398]: [info] Settings loaded
Feb 17 21:21:37 duet3 DuetControlServer[11398]: [info] Environment initialized
Feb 17 21:21:37 duet3 DuetControlServer[11398]: [warn] Kernel SPI buffer size is smaller than RepRapFirmware buffer size (4096 configured vs 8192 required)
Feb 17 21:21:37 duet3 DuetControlServer[11398]: [info] Connection to Duet established
Feb 17 21:21:37 duet3 DuetControlServer[11398]: [info] IPC socket created at /run/dsf/dcs.sock
Feb 17 21:21:37 duet3 systemd[1]: Started Duet Control Server.
Feb 17 21:21:38 duet3 DuetControlServer[11398]: [fatal] Abnormal program termination
Feb 17 21:21:38 duet3 DuetControlServer[11398]: [fatal] SPI task faulted
Feb 17 21:21:38 duet3 DuetControlServer[11398]: System.IO.IOException: Error 90 performing SPI data transfer.
Feb 17 21:21:38 duet3 DuetControlServer[11398]: at LinuxApi.SpiDevice.Transfer(Byte* writeBufferPtr, Byte* readBufferPtr, Int32 buffersLength) in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/LinuxApi/SpiDevice.cs:line 141
Feb 17 21:21:38 duet3 DuetControlServer[11398]: at LinuxApi.SpiDevice.TransferFullDuplex(ReadOnlySpan`1 writeBuffer, Span`1 readBuffer) in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/LinuxApi/SpiDevice.cs:line 121
Feb 17 21:21:38 duet3 DuetControlServer[11398]: at DuetControlServer.SPI.DataTransfer.ExchangeData() in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 1573
Feb 17 21:21:38 duet3 DuetControlServer[11398]: at DuetControlServer.SPI.DataTransfer.PerformFullTransfer(Boolean connecting) in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 233
Feb 17 21:21:38 duet3 DuetControlServer[11398]: at DuetControlServer.SPI.Interface.Run() in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/DuetControlServer/SPI/Interface.cs:line 904
Feb 17 21:21:38 duet3 DuetControlServer[11398]: at DuetControlServer.Utility.PriorityThreadRunner.<>c__DisplayClass0_0.<Start>b__0() in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/DuetControlServer/Utility/PriorityThreadRunner.cs:line 25
Feb 17 21:21:38 duet3 DuetControlServer[11398]: [fatal] SPI task faulted
Feb 17 21:21:38 duet3 DuetControlServer[11398]: System.IO.IOException: Error 90 performing SPI data transfer.
Feb 17 21:21:38 duet3 DuetControlServer[11398]: at LinuxApi.SpiDevice.Transfer(Byte* writeBufferPtr, Byte* readBufferPtr, Int32 buffersLength) in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/LinuxApi/SpiDevice.cs:line 141
Feb 17 21:21:38 duet3 DuetControlServer[11398]: at LinuxApi.SpiDevice.TransferFullDuplex(ReadOnlySpan`1 writeBuffer, Span`1 readBuffer) in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/LinuxApi/SpiDevice.cs:line 121
Feb 17 21:21:38 duet3 DuetControlServer[11398]: at DuetControlServer.SPI.DataTransfer.ExchangeData() in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 1573
Feb 17 21:21:38 duet3 DuetControlServer[11398]: at DuetControlServer.SPI.DataTransfer.PerformFullTransfer(Boolean connecting) in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 233
Feb 17 21:21:38 duet3 DuetControlServer[11398]: at DuetControlServer.SPI.Interface.Run() in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/DuetControlServer/SPI/Interface.cs:line 904
Feb 17 21:21:38 duet3 DuetControlServer[11398]: at DuetControlServer.Utility.PriorityThreadRunner.<>c__DisplayClass0_0.<Start>b__0() in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/DuetControlServer/Utility/PriorityThreadRunner.cs:line 25
Feb 17 21:21:38 duet3 DuetControlServer[11398]: [info] Application has shut down
Feb 17 21:21:38 duet3 systemd[1]: duetcontrolserver.service: Main process exited, code=exited, status=70/SOFTWARE
Feb 17 21:21:38 duet3 systemd[1]: duetcontrolserver.service: Failed with result 'exit-code'.
Feb 17 21:21:39 duet3 systemd[1]: duetcontrolserver.service: Service RestartSec=100ms expired, scheduling restart.
Feb 17 21:21:39 duet3 systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 231.
Feb 17 21:21:39 duet3 systemd[1]: Stopped Duet Control Server.
Here's my config.g: config.g
I'm not sure where to go from here. Any help is appreciated.
I seen this exact effect with an old mk42 clone. Even on PID it would do it a little. It just seemed to have very slow response either from the heater or the thermistor, I'm not sure. I did several tests with it, and when I printed with the bed heat off, the z wobble effect disappeared entirely. Swapped the bed after that and never had the problem again.
I use an SBC with an E3D toolchanger. Comes in handy when doing tool offset calibration with TAMV. I can see where most users wouldn't need it, though.
@bearer said in Fusion 360 FFF Slicer: G2/G3 Generation Now in Preview:
slightly OT
Effective October 1, 2020, functionality in Fusion 360 for personal use will be limited, and you’ll no longer have access to the following:
Probing, 3 + 2-axis milling (tool orientation), multi-axis milling, rapid moves, automatic tool changes
Multi-sheets, smart templates, output options for drawings (print only).
Download options from public share links
Cloud rendering
Export options including F3Z, DWG, DXF, IGES, SAT, and STEP
Simulation and generative design
Unlimited active and editable Fusion 360 documents (10 doc limit).
Fusion 360 extensions
Wow, can't even export to STEP. I guess it might be the beginning of goodbye to Fusion 360 for me.
@dc42 I'm an idiot. You literally said that above and I somehow read past it. My apologies.
Adding a short (10ms) pause using G4 prior to the second sensor reading seemed to fix it.
@dc42 Is it possible to read a sensor value twice within a single macro? For example, check the state of a switch at the beginning of tpre, then again at the end after the move out? When I do this (just by echoing to console) it outputs the state the switch was in when the macro started (or whenever the sensor was first read in the macro) for both instances despite the switch being pressed at the beginning and unpressed at the end. Aside from that it seems to work as expected if i'm only reading the sensor once.
@kuhnikuehnast said in Help with strange diagonal banding on Ultibots D300VS+ ?!:
@wwmotorsports said in Help with strange diagonal banding on Ultibots D300VS+ ?!:
@JoergS5 : that's definitely a possibility, but I have tried two different brand new E3D steppers (compact and pancake) and had the exact same defect so I doubt that's my issue in this case.
@kuhnikuehnast : what kind of extruder are you running?
It is a zesty nimble. Really strange! Has anyone an idea how this is possible?
Diagonal banding seemed like a common problem with the Nimble back when I was using it. I could never fully get rid of it on mine, and that's why I no longer use it. There was a fairly large thread in the Zesty forums discussing it and people were trying many things to fix it, but I never found a definitive fix. Maybe that's changed since then (mid-late 2017), but with as much time as I spent with it, i'm not confident in it.
I'd put my vote in for an ESP8266 as well. I have some pushbuttons with RGB led's in them and I use an ESP8266 to control the color of the buttons by polling the Duet for status. Works great.
You're the man, David. We are lucky to have someone like you who is so involved in interacting and helping out the community while at the same time being the main developer. Thank you!
edit: didn't realize the last person bumped up an old thread...whoops. Either case, the sentiment remains.