Firmware update woes. Duet3

Demi

@chrishamm
Thanks for the help everyone.

"A SD card must NOT be present in the Duet 3 when connecting a Raspberry Pi to it"
It is not, Im using the same card for both the board and the pi, and bouncing back and forth.

"RRF 3.01-RC7 is incompatible to the latest stable DSF release. You have to stick with 3.0 until the next stable version is out"
Okay, if I am understanding correctly, the GPIO control method cant be used at this time with the newest firmware. No biggie for me, the intent is to run the board through USB control from a pi running Repitier as a front panel. I was just doing basic setup with the pi in this config.

"Firmware updates generally do not need to be installed manually. This is done automatically when the system components (packages) of the DuetPi OS are updated"

How is this accomplished? Do I need to SSH into the pi and update, or do I need to flash a new OS to the SD card for the pi? The only reason I went down this road was I was having issues with deployprobe.g not being called for M401 and related. These Duet3s are being used in a production facility, and Im the guy that got picked to implement them, so I really do appreciate how quickly you all have jumped in to help me. Im at pucker factor 5.5.

Danal

@Demi said in Firmware update woes. Duet3:

@chrishamm
Thanks for the help everyone.

"A SD card must NOT be present in the Duet 3 when connecting a Raspberry Pi to it"
It is not, Im using the same card for both the board and the pi, and bouncing back and forth.

Good.

"RRF 3.01-RC7 is incompatible to the latest stable DSF release. You have to stick with 3.0 until the next stable version is out"
Okay, if I am understanding correctly, the GPIO control method cant be used at this time with the newest firmware.

If I understand your statement correctly... no... "the GPIO method" is available at every release, if DSF and the firmware match. Longer answer: Tthe firmware (on the Duet board itself) and the DSF (DuetSoftwareFramework) on the Pi must be at release levels that are compatible with each other. We know that you have RC7 on the firmware. We don't know, at this moment, what DSF you have.

Further complicating this answer: There is a "stable" release path on the install servers, and an "unstable". I don't know which one you chose back at the time you built the SD card. If you used the "out of the box" card, you are on "stable".

To finish this thought: We MAY need to bossa one more time. After that, everything will keep itself in sync.

No biggie for me, the intent is to run the board through USB control from a pi running Repitier as a front panel. I was just doing basic setup with the pi in this config.

This may be a unique requirement of your production environment, but... generally everybody in Duet land recommends against this. It un-does most of the advanced function of the Duet (web, onboard files, onboard monitoring), and leaves you with an expensive board that is forced to be dumb.

Anyway, not all that relevant to the learning curve here...

"Firmware updates generally do not need to be installed manually. This is done automatically when the system components (packages) of the DuetPi OS are updated"

How is this accomplished? Do I need to SSH into the pi and update,

Correct. ssh into Pi, then sequence is always:

sudo apt update
sudo apt upgrade

(or, if for some reason you don't want the Pi to upgrade itself 'sudo apt upgrade duetsoftwareframework')

These Duet3s are being used in a production facility, and Im the guy that got picked to implement them, so I really do appreciate how quickly you all have jumped in to help me. Im at pucker factor 5.5.

We will get you going.

A Former User

@Demi said in Firmware update woes. Duet3:

"Firmware updates generally do not need to be installed manually. This is done automatically when the system components (packages) of the DuetPi OS are updated"
How is this accomplished?

It does depend on the DuetSoftwareFramework (or probably specifically duetcontrollserver) already working; if you have an incompatible firmware on the Duet apt update will not update the firmware.

Specifically apt update will also update the package RepRapFirmware, and as part of its script it will ask the Duet board to run the update just like you would run M997 S1 from a console - but if the board isn't connected or otherwise unable to communicate with the running version of DSF the update will not succeed, and as far as I know it will not retry - but once communication is sorted you can run M997 S1 as it will read the firmware file that was part of the RepRapFirmware update.

Demi

@Danal said in Firmware update woes. Duet3:

We know that you have RC7 on the firmware. We don't know, at this moment, what DSF you have.

Ohhhh. Headslap. Alright standby, working on it now. Yeah I know the front panel deal is weird. Its a long and strange story, but we have some printers that were purchased that already have front panels that underperformed in their shipped state, and a safety requirement that they can be controlled physically. Ill update the pi and report back in 5.

Demi

Before:


pi@duet3:~ $ sudo apt list duetcontrolserver -a
Listing... Done
duetcontrolserver/stable,now 1.2.4.0 armhf [installed,automatic]
duetcontrolserver/stable 1.2.3.0 armhf
duetcontrolserver/stable 1.2.2.1 armhf
duetcontrolserver/stable 1.1.0.5 armhf
duetcontrolserver/stable 1.0.4.1 armhf
duetcontrolserver/stable 1.0.3.1 armhf

After
sudo apt-get update
sudo apt-get upgrade:


pi@duet3:~ $ sudo apt list duetcontrolserver -a
Listing... Done
duetcontrolserver/stable,now 1.2.4.0 armhf [installed,automatic]
duetcontrolserver/stable 1.2.3.0 armhf
duetcontrolserver/stable 1.2.2.1 armhf
duetcontrolserver/stable 1.1.0.5 armhf
duetcontrolserver/stable 1.0.4.1 armhf
duetcontrolserver/stable 1.0.3.1 armhf

Its...the same? DCS error persists. Restarting.

Danal

Thanks @bearer, very good clarification!

A Former User

@Demi said in Firmware update woes. Duet3:

Its...the same?

need to switch to the unstable packge list.

edit:

#comment out stable list
sudo sed -i '/ stable/s/^/#/g' /etc/apt/sources.list.d/duet3d.list
#add unstable list
echo "deb https://pkg.duet3d.com/ unstable armv7" | sudo tee /etc/apt/sources.list.d/duet3d-unstable.list

Danal

Yep, or regress the firmware on bossa. I believe forward is better, I'm going to give him instructions for that.

Demi

You guys are awesome. Im a babe in the woods over here, and thank you Danal for anticipating that I didnt know how to switch to the unstable package list. Lol. I sure didnt.
Trying it now.

Danal

Yeah, you probably found it on the Wiki, here is a cut paste, you can just run these exactly as shown:

wget -q https://pkg.duet3d.com/duet3d.gpg
wget -q https://pkg.duet3d.com/duet3d-unstable.list
sudo mv duet3d.gpg /etc/apt/trusted.gpg.d/
sudo mv duet3d-unstable.list /etc/apt/sources.list.d/duet3d-unstable.list
sudo chown root:root /etc/apt/trusted.gpg.d/duet3d.gpg
sudo chown root:root /etc/apt/sources.list.d/duet3d-unstable.list

AFTER those run, one more time:

sudo apt update
sudo apt upgrade duetsoftwareframework

Danal

Once all that finishes, Duet Web should suddenly work.

A reset should not be required... but... if things still won't connect, first action is power cycle. That sequence above is pretty solid.

Demi

Oh, whoops. I may have jumped the gun. I ran with Bearers instructions, followed with an update/upgrade. Now returning:

pi@duet3:~ $ sudo apt list duetcontrolserver -a
Listing... Done
duetcontrolserver/unstable,now 1.3.2 armhf [installed,automatic]
duetcontrolserver/unstable 1.3.1 armhf
duetcontrolserver/unstable 1.3.0 armhf
duetcontrolserver/unstable 1.2.5.0 armhf
duetcontrolserver/unstable 1.2.4.0 armhf
duetcontrolserver/unstable 1.2.3.1 armhf
duetcontrolserver/unstable 1.2.3.0 armhf
duetcontrolserver/unstable 1.2.2.1 armhf
duetcontrolserver/unstable 1.2.2.0 armhf
duetcontrolserver/unstable 1.2.1.0 armhf
duetcontrolserver/unstable 1.2.0.0 armhf
duetcontrolserver/unstable 1.1.0.5 armhf
duetcontrolserver/unstable 1.1.0.4 armhf
duetcontrolserver/unstable 1.1.0.3 armhf
duetcontrolserver/unstable 1.1.0.2 armhf
duetcontrolserver/unstable 1.1.0.1 armhf
duetcontrolserver/unstable 1.1.0.0 armhf
duetcontrolserver/unstable 1.0.4.1 armhf
duetcontrolserver/unstable 1.0.4.0 armhf
duetcontrolserver/unstable 1.0.3.5 armhf
duetcontrolserver/unstable 1.0.3.3 armhf
duetcontrolserver/unstable 1.0.3.2 armhf

Restarting.

Danal

Our instructions looked different but did the same things. Your status looks GOOD

A Former User

@Danal said in Firmware update woes. Duet3:

but did the same things

almost; but chrishammn never confirmed or denied if stable and unstable list should co-exist after not too long ago asking someone to remove the stable list.

Danal

Once everything is back up, just for fun, try this from the Pi ssh session

echo "m115" | sudo /opt/dsf/bin/CodeConsole

Mine returns:

FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.01-RC7 ELECTRONICS: Duet 3 MB6HC v0.6 or 1.0 FIRMWARE
_DATE: 2020-04-14b3

and the fact that it returns anything indicates the Pi and the Duet are connected.

Danal

@bearer said in Firmware update woes. Duet3:

@Danal said in Firmware update woes. Duet3:

but did the same things

almost; but chrishammn never confirmed or denied if stable and unstable list should co-exist after not too long ago asking someone to remove the stable list.

Ah, very interesting. Should we update the documentation in the "getting started"?

A Former User

@Danal said in Firmware update woes. Duet3:

Should we update the documentation in the "getting started"?

i re-read it after his comment, and i guess it could be interpreted as either or, and the rest of us missed that. (but i suspect english is not the native language for me nor the author of the text so ymmw). however adding the key in both scenarios would indicate one or the other. if the text were to be changed replacing all the key stuff with wget -qO - https://pkg.duet3d.com/duet3d.gpg | sudo apt-key add - would probably be worth while as well.

clarifying if it is an issue and making the instructions clearer would probably be a good thing in any case.

Danal

@bearer said in Firmware update woes. Duet3:

but i suspect english is not the native language for me nor the author of the text so ymmw)

I joke, and I repeat JOKE, that I am not a native English speaker.

I was born in a small town in TX, and the grain of truth behind that joke is that I really did take some tutoring at a point long after college, in my mid-career, so that I could speak accent-less, grammatically correct, English when I need to in business situations. It did seem to unlock some advancement that was lagging a bit.

But what REALLY cured my TX accent, and made me sound neutral american, was living in the Greater London Area (New Barnet) for about a year.

Demi

It works!!! Good LORD. Im sure glad you were all here to help me, I would have never gotten there but I still have the ethernet issue.

So, I pull the card out of the Pi. Put it in the Duet3, plug in the ethernet. It doesnt join the network. I plug in USB and connect via Pronterface.

Connecting...
Printer is now online.
>>>M122
SENDING:M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.01-RC7 running on Duet 3 MB6HC v0.6 or 1.0
Board ID: 08DJM-956L2-G43S4-6J9DD-3SJ6M-TB6AG
Used output buffers: 4 of 40 (4 max)
=== RTOS ===
Static ram: 154580
Dynamic ram: 161588 of which 24 recycled
Exception stack ram used: 308
Never used ram: 76716
Tasks: NETWORK(ready,2084) HEAT(blocked,1196) CanReceiv(suspended,3824) CanSender(suspended,1484) CanClock(blocked,1432) TMC(blocked,216) MAIN(running,4540) IDLE(ready,80)
Owned mutexes:
=== Platform ===
Last reset 00:05:00 ago, cause: power up
Last software reset at 2020-04-16 10:52, reason: User, spinning module GCodes, available RAM 76640 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04432000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d
Error status: 0
[ERROR] Error status: 0

Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 33.9, current 42.7, max 42.7
Supply voltage: min 24.2, current 24.3, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.3, under voltage events: 0
Driver 0: standstill, reads 24921, writes 14 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 24922, writes 14 timeouts 0, SG min/max 0/0
Driver 2: standstill, reads 24923, writes 14 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 24923, writes 14 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 24927, writes 11 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 24927, writes 11 timeouts 0, SG min/max 0/0
Date/time: 1970-01-01 00:00:00
Slowest loop: 1.95ms; fastest: 0.15ms
=== 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 = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 1 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 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
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 1.95ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 0 of 8
- Ethernet -
State: disabled
Error counts: 0 0 0 0 0
[ERROR] Error counts: 0 0 0 0 0

Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 1201, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 93602ms ago
RX/TX seq numbers: 0/1
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0

Ethernet disconnected seems like the key entry here.
Send:

M552 S1

And BAM, everything works! If I restart I have to reconnected and do it all over again to get ethernet (stand alone) working. I tried putting the M552 S1 in config.g but it doesnt enable ethernet.

Danal

If you run with the card in the Duet, you will need the ether plugged into the duet, and the enable command.

I'd actually run with the card in the Pi, and the ethernet physically plugged into the Pi. That should just "come up and work". Default is DHCP, there are tons of Pi tutorials around on how to make it static, if you wish. EDIT: Also, if you want unique hostnames for the printers, change it on the Pi. Again, lots of Pi examples out there.

And/or, you could forgo the ether completely, and run WiFi on the Pi. This is a Pi only option (the board does not have wifi). In your environment, I'm sort of thinking you will stick to ether.