RepRapFirmware 2.02RC4 released

[incogizmo]

This post is deleted!

[incogizmo]

@dc42 & @Veti ahhh awesome thanks guys so I was doing something wrong

So I understand, on a button to launch a menu the file name is to be in both the A and L value? Or A"#0" preferably.

Easily fixed! I'll update all my menus and switch back to rc4 thanks again for all your help

[dc42]

@incogizmo said in RepRapFirmware 2.02RC4 released:

So I understand, on a button to launch a menu the file name is to be in both the A and L value?

Having looked into it some more, I can see that the person who implemented my specification misread my intentions, and my supposed fix in 2.02RC4 has not helped. For now put "#0" in the A parameter and the menu filename in the F parameter. Don't start the menu name with letter G, M or T. This is a temporary workaround, and I will fix it properly in the 2.02 release.

[GizmotronX5000]

I'll likely update today!

(This is a test post against the spam filter. I was getting automatically flagged last week.)

[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.