RepRapFirmware 2.02RC4 released

[smoki3]

@dc42 Hi,

i noticed that M1 is calling "ause.g" instead of "pause.g". I think its a typo.

Running RC4

[dc42]

@smoki3 said in RepRapFirmware 2.02RC4 released:

@dc42 Hi,

i noticed that M1 is calling "ause.g" instead of "pause.g". I think its a typo.

Running RC4

Are you sure? M1 should call sleep.g.

[fcwilt]

@dc42 said in RepRapFirmware 2.02RC4 released:

Are you sure? M1 should call sleep.g.

M1 does do that - verified.

If something is calling "ause.g" perhaps the P parameter was left off?

Frederick

[dc42]

@fcwilt, what is your evidence that M1 is calling "ause.g"? Do you have a sleep.g file on your system?

[fcwilt]

@dc42 said in RepRapFirmware 2.02RC4 released:

@fcwilt, what is your evidence that M1 is calling "ause.g"? Do you have a sleep.g file on your system?

I verified that M1 calls "sleep.g".

BUT I speculated that perhaps something (not M1) was executing a command "M98 pause.g", with the P parameter left off by mistake, thus yielding a call to "ause.g".

Frederick

[smoki3]

@dc42 I get the message "ause.g" cant not found on my paneldue.

But maybe I found the issue. In my sleep.g It calls M98 pause.g instead of M98 Ppause.g

[dc42]

I don't see that message when I send M1 from PanelDue on my delta.

Do you have a sleep.g file, and if so, what is in it?

[Phaedrux]

Updated firmware, DWC, and PanelDue to latest. Re did bed leveling routine and a mesh grid. Went smoothly. Ran a 15 hour print no issues.

[dc42]

@phaedrux said in RepRapFirmware 2.02RC4 released:

Updated firmware, DWC, and PanelDue to latest. Re did bed leveling routine and a mesh grid. Went smoothly. Ran a 15 hour print no issues.

Thanks for the feedback!

[frafa]

Hello

Same problem on 2.02RC4 for me
https://forum.duet3d.com/topic/7316/firmware-2-02-release-candidate-3-now-available/70

[dc42]

@frafa said in RepRapFirmware 2.02RC4 released:

Hello

Same problem on 2.02RC4 for me
https://forum.duet3d.com/topic/7316/firmware-2-02-release-candidate-3-now-available/70

I'm sorry, I remember reading that post but somehow it didn't get added to my list of issues to investigate.

I've just reproduced that problem on my own SCARA by changing the homing file not to use the Z endstop. In my case, the reason is that I have a G1 XY move to position the arm just before the G30 move, and the firmware isn't allowing that move because the Z axis is not homed.

I will fix this in the 2.02 release. Meanwhile, a possible workaround is to use a G1 S2 XY move to set the arm positions to specified angles, instead of commanding a specified XY position.

[frafa]

Hi David,

Homing ok if i add:

;Home Z ir-probe
G91 ; Add test ...
G1 S2 X1 Y-1 ; Add test ...
G90 ; absolute movement
G30 ; Single Z-Probe

But test move after homing return error ...

17:26:48
G28
17:25:46
M120
G91
G1 Y10 F6000
M121
Error: G1/G2/G3: intermediate position outside machine limits

[dc42]

I've implemented a fix in the source code, which will be included in 2.02RC5. Thanks for your patience.

[frafa]

Thank you
No problems David 1.21RC3 works perfectly in the meantime

[insertnamehere]

Previously I've been using M226 to pause prints by editing it into the gcode. I've just tried that on RC4 and although it paused, it also locked up and I was unable to continue the print. A power off was the only way to reset.

M600 was doing the same thing in RC3.

Anybody else experiencing this?

[dc42]

We had a report of this one or two RC versions ago, but I was unable to reproduce it. I'll test it again. Please post your pause.g file here.

[garyd9]

With RC4, DWC is still often reporting an incorrect current layer. In the attached/linked gcode file, there are 70 layers. DWC is reporting that layer 2 of 70 is currently being printed for many layers (I'm currently printing the 6th layer and it's still showing 2 of 70.)

Slicer is cura 3.6.0 and adaptive layers is turned OFF. The "LAYER:xx" comments in the gcode file are correct.

In the attached image, you can see Z is at 1.01 which corresponds to the 6th layer in the file, but DWC still thinks it's on layer 2 of 70 (search for "LAYER:5" in the gcode file (Cura layer numbers start with 0 in the gcode file.))

gcode file: (google drive link) https://drive.google.com/open?id=1O-v-Pu1YvzgWd29iQmxBT9_bVLOqXol-

[dc42]

@garyd9 said in RepRapFirmware 2.02RC4 released:

With RC4, DWC is still often reporting an incorrect current layer. In the attached/linked gcode file, there are 70 layers. DWC is reporting that layer 2 of 70 is currently being printed for many layers (I'm currently printing the 6th layer and it's still showing 2 of 70.)

I think this line, just before the "end of prime line" comment, is confusing the firmware:

G1 X34.441 Y-145.764 Z4.2 E0 F9000

Because it contains both XY movement and extrusion, the firmware classifies it as a printing move, and it therefore thinks that you have completed the print up to Z=4.2. It is waiting for an extruding move at a greater Z height before it counts another layer.

[Martin1454]

@dc42 Im trying to update my bed.g to support the latest release.

I use 3 independent lead screws, and your IR probe.

My old bed.g file was:

; bed.g
; called to perform automatic bed compensation via G32
;
; generated by RepRapFirmware Configuration Tool on Tue Jul 31 2018 15:05:50 GMT+0200 (Centraleuropæisk sommertid)
M561 ; clear any bed transform
G28 Z;
G29 S2; Clear bed height map 
; Probe the bed at 3 points
G30  P0 X0 Y160 Z-9999 ; Front Right
G30  P1 X320 Y47 Z-9999 ; Front Left
G30  P2 X320 Y280 Z-9999 S3 ; Center Rear

I can now see that a tool have to be selected, but do I also have to use 1 of the S-* parameters? If so, how?

[dc42]

I can't think of any reason why you would need to change the bed.g file for the latest release. You should not need to have a tool selected. You do need to have homed X and Y as well as Z, so you might want to change the G28 Z command to just G28.

BTW, M561 and G29 S2 do the same thing.