Duet 3 SBC DCS has stopped
-
@CaLviNx said in Duet 3 SBC DCS has stopped:
@Phaedrux said in Duet 3 SBC DCS has stopped
How bout you save us all some time and just exit the thread please.
What why? Don't you don't like the fact that I pointed out the problem days ago, a problem that has been proven to be true, just because you don't like the fact its still a fact none the less.
You seem to have mistaken my use of the word please as a request.
-
@Phaedrux said in Duet 3 SBC DCS has stopped:
@CaLviNx said in Duet 3 SBC DCS has stopped:
@Phaedrux said in Duet 3 SBC DCS has stopped
How bout you save us all some time and just exit the thread please.
What why? Don't you don't like the fact that I pointed out the problem days ago, a problem that has been proven to be true, just because you don't like the fact its still a fact none the less.
You seem to have mistaken my use of the word please as a request.
Excuse me? Is that a threat
-
@CaLviNx I'm trying to figure this out and some people are trying to help. you posted you swapped to standalone and i acknowledged the error went away but it didn't solve the problem. The point was to troubleshoot the firmware on the RPI because other members were trying to help with that.
If you want to argue do it on someone else's post.
-
@dhusolo said in Duet 3 SBC DCS has stopped:
@CaLviNx I'm trying to figure this out and some people are trying to help. you posted you swapped to standalone and i acknowledged the error went away but it didn't solve the problem. The point was to troubleshoot the firmware on the RPI because other members were trying to help with that.
If you want to argue do it on someone else's post.
I'm not arguing with you. The gentleman in question thinks that just because he is a certain position that means he can dictate things I was trying to assist you days ago, I pointed out that there is a provable issue running the duet-3 in conjunction with an sbc, again that's a fact. The gentleman doesn't seems to like the fact of that fault (where ever it lies) being pointed out
-
@CaLviNx said in Duet 3 SBC DCS has stopped:
The gentleman doesn't seems to like the fact of that fault (where ever it lies) being pointed out
Not at all. It's your attitude that I take issue with. If you don't have anything helpful to add to a troubleshooting thread, you are welcome to stop posting to it.
-
@Phaedrux said in Duet 3 SBC DCS has stopped:
@CaLviNx said in Duet 3 SBC DCS has stopped:
The gentleman doesn't seems to like the fact of that fault (where ever it lies) being pointed out
Not at all. It's your attitude that I take issue with. If you don't have anything helpful to add to a troubleshooting thread, you are welcome to stop posting to it.
I don't really care what you think of my attitude. I have already added the most helpful solution (you just don't like it) and that is to use the duet in standalone mode until such a time as that the provable issue is recognised and a solution to the problem is found
-
@CaLviNx again that's not a solution that's a work around
-
@dhusolo said in Duet 3 SBC DCS has stopped:
@CaLviNx again that's not a solution that's a work around
Anything that gets you printing is a solution
-
@CaLviNx said in Duet 3 SBC DCS has stopped:
Ihave already added the most helpful solution (you just don't like it)
I haven't said a thing about your solution. Yes you're correct it works in standalone. Great. We'd like to do some more testing to see what's going on in SBC mode with the new beta. If that disinterests you, find another thread.
-
@dhusolo
Did you downgrade the firmware on the duet 3 manually to 3.1.1 before downgrading the software on the Pi?
The connection between the two was changed significantly at beta 2 and a board running beta 2 or 3 can't connect to a lower version of DSF and vice versa. -
@jay_s_uk I can't remember 100% because I did a few different things in standalone and SBC. I think I used the erase jumpers and powered on the board.
-
It would be good if we could get beta 3 on there and see if it's working at all. It sounded like you lost communication between the duet and pi entirely when you tried to update to beta 3. Is that right?
-
@Phaedrux Correct. Just making sure I'm doing it right, Is there a different way to erase the firmware on the board besides the erase jumpers or would even using a different SD card do the trick?
-
Well you normally don't need to erase the firmware, but yes the jumper is the way to do that. Once erased you will need to use usb to flash a firmware again.
A different SD card won't help since the firmware is flashed to the board itself. The firmware bin file on the sd card is just there for storage during in place flashing.
What version is flashed to the duet right now?
What version is the Pi running?If you're completely back on 3.1.1 right now, are you on the unstable branch for apt-update? How did you originally try to update to the beta?
-
@Phaedrux I think I got it back to 3.1.1.
What's the command to verify version info including DWS and DWC?
-
From the gcode console send M122 and post the results please.
Additionally send M122 "DSF"
-
I haven't loaded my config file but I flashed Duet3Firmware_MB6HC.bin through Bossa. It looks like it's communicating with the RPI again.
M122
m122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (SBC mode) Board ID: 08DJM-956L2-G43S8-6J9D0-3S46T-9U2LF Used output buffers: 1 of 40 (10 max) === RTOS === Static ram: 154604 Dynamic ram: 161360 of which 20 recycled Exception stack ram used: 236 Never used ram: 76996 Tasks: NETWORK(ready,1980) HEAT(blocked,1452) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1436) TMC(suspended,252) MAIN(running,5184) IDLE(ready,76) Owned mutexes: === Platform === Last reset 00:09:59 ago, cause: power up Last software reset at 2020-11-05 20:48, reason: User, spinning module LinuxInterface, available RAM 74612 bytes (slot 3) Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN Error status: 0 MCU temperature: min 15.0, current 25.8, max 25.9 Supply voltage: min 0.2, current 0.3, max 0.3, under voltage events: 0, over voltage events: 0, power good: no 12V rail voltage: min 0.1, current 0.1, max 0.2, under voltage events: 0 Driver 0: ok, reads 0, writes 0 timeouts 0, SG min/max 0/0 Driver 1: ok, reads 0, writes 0 timeouts 0, SG min/max 0/0 Driver 2: ok, reads 0, writes 0 timeouts 0, SG min/max 0/0 Driver 3: ok, reads 0, writes 0 timeouts 0, SG min/max 0/0 Driver 4: ok, reads 0, writes 0 timeouts 0, SG min/max 0/0 Driver 5: ok, reads 0, writes 0 timeouts 0, SG min/max 0/0 Date/time: 2020-11-08 14:26:06 Slowest loop: 2.36ms; fastest: 0.13ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === Heat === Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP* is ready with "M122" 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 SBC is idle in state(s) 0 Daemon* is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 1.03ms; fastest: 0.01ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions HTTP sessions: 0 of 8 - Ethernet - State: disabled Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === CAN === Messages sent 0, longest wait 0ms for type 0 === Linux interface === State: 0, failed transfers: 0 Last transfer: 12ms ago RX/TX seq numbers: 19460/19461 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.1.1 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 5.64M122 DSF
m122 DSF === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (SBC mode) Board ID: 08DJM-956L2-G43S8-6J9D0-3S46T-9U2LF Used output buffers: 1 of 40 (12 max) === RTOS === Static ram: 154604 Dynamic ram: 161360 of which 20 recycled Exception stack ram used: 236 Never used ram: 76996 Tasks: NETWORK(ready,1980) HEAT(blocked,1452) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1436) TMC(suspended,252) MAIN(running,4512) IDLE(ready,76) Owned mutexes: === Platform === Last reset 00:12:41 ago, cause: power up Last software reset at 2020-11-05 20:48, reason: User, spinning module LinuxInterface, available RAM 74612 bytes (slot 3) Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN Error status: 0 MCU temperature: min 25.6, current 25.8, max 26.0 Supply voltage: min 0.3, current 0.3, max 0.3, under voltage events: 0, over voltage events: 0, power good: no 12V rail voltage: min 0.1, current 0.2, max 0.2, under voltage events: 0 Driver 0: ok, reads 0, writes 0 timeouts 0, SG min/max not available Driver 1: ok, reads 0, writes 0 timeouts 0, SG min/max not available Driver 2: ok, reads 0, writes 0 timeouts 0, SG min/max not available Driver 3: ok, reads 0, writes 0 timeouts 0, SG min/max not available Driver 4: ok, reads 0, writes 0 timeouts 0, SG min/max not available Driver 5: ok, reads 0, writes 0 timeouts 0, SG min/max not available Date/time: 2020-11-08 14:28:49 Slowest loop: 1.97ms; fastest: 0.13ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === Heat === Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP* is ready with "M122 D0 S0 F0" 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 SBC is idle in state(s) 0 Daemon* is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 1.03ms; fastest: 0.01ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions HTTP sessions: 0 of 8 - Ethernet - State: disabled Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === CAN === Messages sent 0, longest wait 0ms for type 0 === Linux interface === State: 0, failed transfers: 0 Last transfer: 12ms ago RX/TX seq numbers: 24793/24794 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.1.1 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 32.80 -
@dhusolo said in Duet 3 SBC DCS has stopped:
M122 DSF
I think the quotes around DSF are required. I'll admit I haven't used that command yet.
-
m122 "DSF" === Duet Control Server === Duet Control Server v3.1.1 Daemon: Finishing macro daemon.g, started by system > Next stack level Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 32.83 -
@dhusolo said in Duet 3 SBC DCS has stopped:
=== Duet Control Server === Duet Control Server v3.1.1
Regardless, I think you're on 3.1.1 across the board now.
