RepRapFirmware 3.01-RC1 released

dc42

Fixed in latest commit.

SpoonUnit

I've just migrated from 2.04 to 3.01 (via 3.0). I must admit, I didn't stop at 3.0 to check everything was working. Anyway, after a few hiccoughs, I have almost everything working from a control perspective. All tools are registered and reporting the correct temp, all axes can be homed, tools can be heated, bed can be heated. Pretty happy with this, I moved to run my first job, which starts with mesh bed leveling, and that's where I encountered the first issue. Once G29 was issued, the head moved much slower than expected to the first point, but then held there. I looked at DWC to find it waiting for manual bed leveling. It wanted me to raise the bed up to the head. Not wanting to do this for 40 points, I quickly realised there's no way to abort this process from DWC once it begins. You can click OK, but you probably can't get to the emergency stop button before the next point, so you're just trapped. Even booting DWC up on a second browser instance resulted in the dialog popping up which I couldn't cancel. So first issue - could ideally do with a way of cancelling manual bed leveling.

However, I can't really see what's wrong with the setup. My starting point is the setup I have for Duet 2, but adjusted based on @dc42 post on the e3d forum.

M558 P8 C"zstop" H3 F360 I0 T35000 	; Set Z probe type to switch, the axes for which it is used and the dive height + speeds
G31 P200 X0 Y0 Z0	 				; Set Z probe trigger value, offset and trigger height
M557 X10:290 Y20:180 S40 			; Define mesh grid

The only difference is my mesh definition as I'm not ready to switch to having 0,0 in the center of my bed. As far as I can see, there's no other setup for the automated mesh bed leveling, so I'm not sure what I'm missing here? I trigger the bed measurement with a simple G29, which doesn't seem to have been altered for RRF3 (https://duet3d.dozuki.com/Wiki/Gcode#Section_G29_Mesh_bed_probe). Perhaps I need to specify S0 even though that should be the default?

The second issue I have relates to the setup of a thermistor to measure the bed temperature. While the heating plate itself has an inbuilt temperature report, the physical bed itself takes some time longer to reach working temperature. To measure this, I've mounted a thermistor against the bed itself, and plugged that into duex.e5temp. The only way I could figure out how to use this to hold processing in Duet 2 was to define this as a chamber, and then use M191 P0 S65 to cause processing to wait for the bed to report a sufficient temperature to continue. In Duet 2, I defined this like this:

M305 S"P0" P6 R4700 T100000 B4388 			
M141 H6 P0

Even with no actual heater assigned to the chamber, the chamber would appear in DWC and I could use M191. I kinda knew this was a hack, but now I need a similar hack for Duet 3 as I don't have a heater for this chamber. So far, I've just (ab)used duex.e3heat to act as the ghost heater, which then means I have no heater for tool 3.

M308 S6 P"duex.e5temp" Y"thermistor" A"T0" T100000 B4725 C7.06e-8 	; Set thermistor
M950 H6 C"duex.e3heat" T6					; Bed heater
M141 P0 H6

This looks like it'll work, but I wonder if there's a better way?

SpoonUnit

OK. Have made a bit of progress. It seems that I'm struggling as I'm using the same tool (a microswitch) for both a Z endstop and a Z probe. By executing commands from config.g individually, I can see that once this executes:

M574 Z1 S1 P"zstop"   ; Z min active high endstop switch

this then fails

M558 P8 C"zstop" H3 F360 I0 T35000

I can't quite fathom whether this should or shouldn't be the case from the docs.

"Note, if your Z probe is connected to the Z endstop input, in RRF 3.0 on Duet 2 boards only (not in RRF 3.01 and later, and not in RRF 3.0 on Duet 3), that input is by default pre-assigned to be used by the Z endstop, so you must free it up first."

If I read it right, this whole statement doesn't apply as this is RRF 3.01, albeit an RC, not final release. So does this mean I shouldn't need to free it up? I find that if I do free it up, the the M558 command will work, and I can then execute G29 which then works properly. At this stage then, it feels like my homing statement will need to clear the pin and define M574, and my levelling process will need to clear the pin and define M558. Is this the intended final outcome or am I missing a simple alternative?

gtj0

@dc42 said in RepRapFirmware 3.01-RC1 released:

Fixed in latest commit.

Thanks!

gtj0

@dc42 said in RepRapFirmware 3.01-RC1 released:

Confirmed, it doesn't work on Duet 3. This is because Duet 3 has separate code to provide a fast response to loss of 12V power in order to protect the drivers, which preempts that code I added. I will fix it in the next build.

@dc42 said in RepRapFirmware 3.01-RC1 released:

Fixed in latest commit.

Confirmed fixed, thanks.

dc42

@SpoonUnit said in RepRapFirmware 3.01-RC1 released:

OK. Have made a bit of progress. It seems that I'm struggling as I'm using the same tool (a microswitch) for both a Z endstop and a Z probe. By executing commands from config.g individually, I can see that once this executes:
M574 Z1 S1 P"zstop"   ; Z min active high endstop switch
this then fails
M558 P8 C"zstop" H3 F360 I0 T35000
I can't quite fathom whether this should or shouldn't be the case from the docs.

"Note, if your Z probe is connected to the Z endstop input, in RRF 3.0 on Duet 2 boards only (not in RRF 3.01 and later, and not in RRF 3.0 on Duet 3), that input is by default pre-assigned to be used by the Z endstop, so you must free it up first."

If I read it right, this whole statement doesn't apply as this is RRF 3.01, albeit an RC, not final release. So does this mean I shouldn't need to free it up? I find that if I do free it up, the the M558 command will work, and I can then execute G29 which then works properly. At this stage then, it feels like my homing statement will need to clear the pin and define M574, and my levelling process will need to clear the pin and define M558. Is this the intended final outcome or am I missing a simple alternative?

You don't need a Z endstop if you have a Z probe. Delete your Z endstop in config.g and use just the Z probe. Make sure that your homing files use a G30 command to home Z, not a G1 H2 Z move.

gtj0

@dc42 I'm not sure if this is a new problem or an old one....

If the X or Y axes are homed then you turn the ATX power off, if you issue a G1 H1 against X or Y, the axis gets marked as homed even though the power is still off. If you then issue a G1 X5 H0, for instance, you get the "Attempt to move motors..." message but the position reports that X has moved 5mm.

dc42

@gtj0 said in RepRapFirmware 3.01-RC1 released:

If the X or Y axes are homed then you turn the ATX power off, if you issue a G1 H1 against X or Y, the axis gets marked as homed even though the power is still off.

That should happen if and only if the X or Y (as appropriate) endstop switch is triggered when you send that command. I agree that it would be better just to reject the command.

gtj0

@dc42 said in RepRapFirmware 3.01-RC1 released:

@gtj0 said in RepRapFirmware 3.01-RC1 released:

If the X or Y axes are homed then you turn the ATX power off, if you issue a G1 H1 against X or Y, the axis gets marked as homed even though the power is still off.

That should happen if and only if the X or Y (as appropriate) endstop switch is triggered when you send that command. I agree that it would be better just to reject the command.

No worries. Not a big issue.

gtj0

Heh, just as I said that... I just turned ATX on and tried to do a homeall and got ...

Push(): stack overflow
Error: Homing failed

Had to reset but here's an M122 before the reset.

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 version 3.01-RC1+1 running on Duet 3 MB6HC
Board ID: 08DGM-9T66A-G63SJ-6J9F4-3SD6S-1U03B
Used output buffers: 1 of 40 (8 max)
=== RTOS ===
Static ram: 153808
Dynamic ram: 160628 of which 24 recycled
Exception stack ram used: 520
Never used ram: 78236
Tasks: NETWORK(ready,1972) HEAT(blocked,1200) CanReceiv(suspended,3820) CanSender(suspended,1436) CanClock(blocked,1436) TMC(blocked,76) MAIN(running,4964) IDLE(ready,80)
Owned mutexes:
=== Platform ===
Last reset 06:06:38 ago, cause: software
Last software reset at 2020-02-09 17:47, reason: User, spinning module LinuxInterface, available RAM 78896 bytes (slot 0)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04432000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 28.5, current 31.5, max 34.8
Supply voltage: min 0.1, current 25.3, max 25.7, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 0.2, current 12.2, max 12.2, under voltage events: 3
Driver 0: standstill, reads 18529, writes 64 timeouts 0, SG min/max 0/239
Driver 1: standstill, reads 18529, writes 64 timeouts 0, SG min/max 0/225
Driver 2: standstill, reads 18547, writes 47 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 18534, writes 60 timeouts 0, SG min/max 0/201
Driver 4: standstill, reads 18535, writes 60 timeouts 0, SG min/max 0/212
Driver 5: standstill, reads 18535, writes 60 timeouts 0, SG min/max 0/205
Date/time: 2020-02-10 14:05:56
Slowest loop: 9.48ms; fastest: 0.04ms
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 372, MaxWait: 14364857ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 47, completed moves: 47, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -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 0 0 0 0 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is assembling a command in state(s) 0
daemon* is idle in state(s) 0
queue is idle in state(s) 0
lcd is idle in state(s) 0
spi is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 1.34ms; 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: 0
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 88003, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 16ms ago
RX/TX seq numbers: 24365/36759
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v1.2.4.0
Code buffer space: 4096
Configured SPI speed: 2000000 Hz
Full transfers per second: 34.39

TC

Not sure if this has already been reported. When I set an offset for a tool and then switch between selected and unselected state the X/Y coordinates are ajusted correctly in DWC. But the behavior of the displayed Z coordinate is strange. Sometimes it is not changing at all, sometimes it changes when a move is executed. Nevertheless just the displayed value seams to be wrong. The offset is taken into account as it should be.

gtj0

@TC said in RepRapFirmware 3.01-RC1 released:

Not sure if this has already been reported. When I set an offset for a tool and then switch between selected and unselected state the X/Y coordinates are ajusted correctly in DWC. But the behavior of the displayed Z coordinate is strange. Sometimes it is not changing at all, sometimes it changes when a move is executed. Nevertheless just the displayed value seams to be wrong. The offset is taken into account as it should be.

By any chance, does the change in value correspond to the correction applied by the heightmap?

kir09Bes

We've used the RepRapFirmware 3.01-RC1 on Duet 2 for Five Bar Parallel SCARA configuration. It produces some sort of jerking when passes through 0 of thetaR (see the picture in https://duet3d.dozuki.com/Guide/Five+Bar+Parallel+SCARA/24?lang=en). Could you suggest how to eliminate the jerking?

TC

@gtj0 good idea, but I am not using any height map yet. Also wouldn't the heightmap just apply an offset to the coordinate in both cases? The strange thing is that it is sometimes not changing at all when selecting the tool.

SpoonUnit

@dc42 said in RepRapFirmware 3.01-RC1 released:

You don't need a Z endstop if you have a Z probe. Delete your Z endstop in config.g and use just the Z probe. Make sure that your homing files use a G30 command to home Z, not a G1 H2 Z move.

Thanks. That's much simpler.

Any thoughts on the chamber issue? Can I just allocate any random pin to the heater or will there be a check on whether it can actually perform as a heater?

spllg

unsure if this is related to 3.01-rc1but i feel, it might:

tried to configure my ed3 v6 as

M308 S1 P"temp1" Y"thermistor" B4725 C7.06e-8

which resulted in a displayed temperature of -273.1C.

M308 S1 P"temp1" Y"thermistor"

seems to result in a temperature reading which is ~20C too high around 200C - at least i'm unable to print pla at temperature < 215 because it would not flow.

what should i do?

dc42

@spllg said in RepRapFirmware 3.01-RC1 released:

unsure if this is related to 3.01-rc1but i feel, it might:

tried to configure my ed3 v6 as

M308 S1 P"temp1" Y"thermistor" B4725 C7.06e-8

which resulted in a displayed temperature of -273.1C.

M308 S1 P"temp1" Y"thermistor"

seems to result in a temperature reading which is ~20C too high around 200C - at least i'm unable to print pla at temperature < 215 because it would not flow.

what should i do?

After sending that first command, send M308 S1 to see whether it reports the correct parameters.

dc42

@SpoonUnit said in RepRapFirmware 3.01-RC1 released:

Any thoughts on the chamber issue? Can I just allocate any random pin to the heater or will there be a check on whether it can actually perform as a heater?

I can't remember whether you can use any pin or it has to be PWM-capable. But your alternative is to use conditional GCode. Don't create a dummy heater, just a sensor. Then loop until the sensor temperature is high enough, e.g. within 5C of the temperature you have set for the bed heater (if your sensors agree that closely).

Sotidii

Items "t" do not work.

SpoonUnit

@dc42 said in RepRapFirmware 3.01-RC1 released:

But your alternative is to use conditional GCode.

OK. Definitely interested in trying that, though the benefit of the chamber definition is lost (i.e. I can see the sensor temp displayed clearly in DWC - but maybe there's another way to add the sensor to the UI?).

Here's what I tried:

echo "starting"
while true
	if heat.sensors[6].lastReading < 30
		echo heat.sensors[6].lastReading
		break
echo "bed temp reached"

I tried this as a macro and a gcode file, and neither work. In fact, I think adding the additional echo within the if body and then running the job caused DWC to go into an infinite-reboot-loop. If this isn't the right way to test code, is there an alternative?

I realise the logic is upside down by the way. I've been flipping the >/< while testing.

Just to confirm this is the right sensor to test:
alt text