RepRapFirmware 3.01-RC1 released
-
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
-
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.
-
@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?
-
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?
-
@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.
-
@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?
-
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?
-
@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.
-
@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).
-
Items "t" do not work.
-
@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:
-
I think what's happening is that the loop is taking up all the processor time. I'll fix this in RC2. Meanwhile, try putting a 1 second delay (G4 P1000 command) in the loop body.
-
Is there an update for the expansion board as well?
-
@jay_s_uk said in RepRapFirmware 3.01-RC1 released:
Is there an update for the expansion board as well?
Try the one at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. You might need to use the copy of RRF there too.
-
@dc42 said in RepRapFirmware 3.01-RC1 released:
try putting a 1 second delay
Yep. Sorted. Thanks!. I did wonder whether it was just going to get stuck that way. So, the second pause does fix it, and perhaps that's sensible anyway. You're in control about how much to wait between cycles. I guess if you're going to fix it at some value, that value could be set by another GCODE before entering the loop perhaps.
The short piece of code does generate an interesting result on the progress bar
-
Actually, now I'm a bit confused ...
This was where I (stupidly) put the pause ...
while true if heat.sensors[6].lastReading > 30 G4 P1000 break
But it worked anyway (?), so it paused even without the sensor having the right value.
Also PrusaSlicer isn't terribly excited about the GCODE ..
!!!!! Failed to process the custom G-code template start_gcode
Parsing error at line 18.
if heat.sensors[6].lastReading > 65 -
It seems Slic3r uses [] to denote variables, so if they're found, it immediately tried to process and then fails. I wonder if an alternate form can be made available along the lines of:
heat.sensors.6.lastReading
This then doesn't trip the error. For now I can post process to just put the [] back in.
-
@SpoonUnit said in RepRapFirmware 3.01-RC1 released:
Also PrusaSlicer isn't terribly excited about the GCODE ..
why not use the macros provided by RRF to do start/stop stuff?
-
@dc42
send M308 S1 P"temp1" Y"thermistor" B4725 C7.06E-8
send M308 S1response is
Sensor 1 type Thermistor using pin temp1, reading -273.1, last error: sensor open circuit, T:100000.0 B:4725.0 C:7.06e+0 R:2200.0 L:0 H:0
and the tool fan starts spinning - it should start @50C
-
@spllg said in RepRapFirmware 3.01-RC1 released:
@dc42
send M308 S1 P"temp1" Y"thermistor" B4725 C7.06E-8
send M308 S1response is
Sensor 1 type Thermistor using pin temp1, reading -273.1, last error: sensor open circuit, T:100000.0 B:4725.0 C:7.06e+0 R:2200.0 L:0 H:0
and the tool fan starts spinning - it should start @50C
There's your answer, the firmware can't detect the thermistor. Maybe a bad crimp connection?