RRF 3.01-RC10, DWC 2.1.5 and DSF 2.1.1 released
-
I've changed the M140 (and M141) headings and text in the GCodes wiki page, and changed "created" to "assigned" in the upgrade notes. I hope this will help make it clearer.
-
based on our discussion here i have updated g-code M140 documentation with the note and sample error.
personally I read release notes and could not figure out what to do with M140...perhaps we should rename M140 from "Set Bed Temperature (Fast) " to
"Configure Bed Heater or Set Bed Temperature (Fast)"any thoughts?
-
@c310 said in RRF 3.01-R10, DWC 2.1.5 and DSF 2.1.1 released:
based on our discussion here i have updated g-code M140 documentation with the note and sample error.
personally I read release notes and could not figure out what to do with M140...perhaps we should rename M140 from "Set Bed Temperature (Fast) " to
"Configure Bed Heater or Set Bed Temperature (Fast)"any thoughts?
I've already done that.
-
@dc42 said in RRF 3.01-R10, DWC 2.1.5 and DSF 2.1.1 released:
If you tell me what you didn't find clear, I will try to improve the text.
Sorry to butt in on this but I do believe that I can see how the confusion arises. Looking at the wiki for gcode M950 it reads thus:
"M950 is used to create heaters, fans and GPIO ports and to assign pins to them. Each M950 command assigns a pin or pins to a single device. So every M950 command must have exactly one of the H, F, J, P or S parameters."
....and then in the examples it shows
"M950 H1 C"out1" Q100 T1 ; create heater 1"
So I can see how users might be forgiven for thinking that the M950 H0 command is all that is required to create a bed heater.
Perhaps the notes about M950 should include the need to use M140 H0 as well? Might that clarify things?
-
I'm all set now, I directly installed the "DuetMaestroAP.bin file onto the SD Card and then uploaded the update.
M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 Maestro FIRMWARE_VERSION: 3.01-RC10 ELECTRONICS: Duet Maestro 1.0 FIRMWARE_DATE: 2020-04-25b3Thanks for all the support here.
-
Install went fine, very smooth, including firmware load of B0. It also appears to operate, although I have not yet done a full print.
WOW the update of B1, etc, messages got MUCH CLEANER. I realize that 3HC boards are still on RC7... but I just thought I'd check, and the "Please wait, updating" style messages are GREAT.
It seems that DWC "Emergency Stop" hangs and never comes back. If I can derive info, I will start a linked thread.
-
first short print (2 hours) done, everything working awesome
-
A Noctua Fan that I use to cool the CPU / drivers etc has now become an 'ON/OFF' fan, it used to work fine between the 40 / 45 Deg limits set.
It now is either at 100% or nothing, it comes on at the low end i.e. 40, this used to work just fine so I won't accept that this is a gcode issue unless M950 has changed but not yet been documented.
Up until the update this morning the fan has been fine (although I have skipped a couple of RC versions).
I am now getting
'inconsistent Z' when trying to home Z.
Cancel print results in a 'attempt to extrude with no tool selected' error.
NOTHING has been changed mechanically - was all tickety boo before the update.
Has anyone developed a 'Test plan' that can be executed against new RC's - many people can execute on different hardware and report result - just a thought.
-
Problem with DCS crashing ungracefully (usually on startup) - DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1
-
Bug report: G32 messages work from console, not from DWC.
https://forum.duet3d.com/topic/15894/g32-messages-not-returning-to-console-rrf-3-01-rc10
-
very basic Q to ask - shouldn't the Duet3 boot from the same SD card used by the Pi ?
Because mine doesn't, doesn't make any attempt to get an IP address when hardwired.
-
@Garfield said in RRF 3.01-R10, DWC 2.1.5 and DSF 2.1.1 released:
very basic Q to ask - shouldn't the Duet3 boot from the same SD card used by the Pi ?
Because mine doesn't, doesn't make any attempt to get an IP address when hardwired.
Other than the M55x network commands, it should work. Make sure they're not commented out when in standalone mode.
-
Don't have any M55x commands - have never had any ...
-
@Garfield I think you'd need at least M552 S1 to enable networking. It should get a DHCP address. You should then be able to reach the printer via the name set in M550 P. Http://printername
-
Gone from bad to worse ... can't even boot the DWC in the Pi now .... Pi boots OK ... sytemctl status reports DWC is running but can't access it.
-
@Garfield I thought you were trying to go standalone to get around the DCS issue, no?
-
@Garfield said in RRF 3.01-R10, DWC 2.1.5 and DSF 2.1.1 released:
very basic Q to ask - shouldn't the Duet3 boot from the same SD card used by the Pi ?
Because mine doesn't, doesn't make any attempt to get an IP address when hardwired.
it won't unless you copy the config from /opt/dsf/sd/sys to /boot/sys before removing it from the Pi. (moving the config to /boot/sys/config.g and symlinking it back to /opt/dsf/sd/sys/config.g would be an interesting exercise though (and adding M552 S1))
i.e. duet can only read the first fat32 partition, raspbian uses it for /boot and the duet is unable to read the config file the pi normally uses.
-
I was trying to boot stand alone - couldn't - put it into the Pi and although DWC reports running it can't be accessed, I can access SSH.
Never been a Linux fan ..... never will be until it ceases to a 19th century OS accessible only to those prepared to waste days on a basic config (I am not one of those - I have a life)
-
@bearer said in RRF 3.01-R10, DWC 2.1.5 and DSF 2.1.1 released:
@Garfield said in RRF 3.01-R10, DWC 2.1.5 and DSF 2.1.1 released:
very basic Q to ask - shouldn't the Duet3 boot from the same SD card used by the Pi ?
Because mine doesn't, doesn't make any attempt to get an IP address when hardwired.
it won't unless you copy the config from /opt/dsf/sd/sys to /boot/sys before removing it from the Pi. (moving the config to /boot/sys/config.g and symlinking it back to /opt/dsf/sd/sys/config.g would be an interesting exercise though (and adding M552 S1))
i.e. duet can only read the first fat32 partition, raspbian uses it for /boot and the duet is unable to read the config file the pi normally uses.
Can't symlink in that case but yeah, I keep forgetting about people running their SBC from an SD card since I run from SSD. When I need to go standalone, I just copy the /opt/dsf/sd/ directory contents to a freshly formatted SD card.
-
@gtj0 said in RRF 3.01-R10, DWC 2.1.5 and DSF 2.1.1 released:
Can't symlink in that case
not if you move the config to the /boot parition and link from the ext4 parition?
(i cant test in a duet3, but think it should work)pi@rpix:/opt/dsf/sd/sys $ ls config.g pi@rpix:/opt/dsf/sd/sys $ sudo mkdir /boot/sys pi@rpix:/opt/dsf/sd/sys $ echo M552 S1 | tee cat - >>config.g pi@rpix:/opt/dsf/sd/sys $ sudo mv config.g /boot/sys mv: failed to preserve ownership for '/boot/sys/config.g': Operation not permitted pi@rpix:/opt/dsf/sd/sys $ ln -s /boot/sys/config.g pi@rpix:/opt/dsf/sd/sys $ ls -l total 1460 lrwxrwxrwx 1 pi pi 14 Apr 26 22:44 config.g -> /boot/sys/config.g pi@rpix:/opt/dsf/sd/sys $ echo M552 S1 | sudo tee -a config.g pi@rpix:/opt/dsf/sd/sys $ cat config.g ; Duet 3 Configuration File ; It is recommended to replace the contents of this file with a preset from https://configtool.reprapfirmware.org M550 P"Duet 3" ; set machine label M552 S1(although i suspect doing the whole sys, gcode, macro folders might be more convenient.. and throwing in the stand alone dwc not as a link)
