RepRapFirmware 2.02RC4 released

[incogizmo]

Ive updated to RC4 today and the 79, 179 and 279 values are now working as expected on the 12864 display.
Thanks dc

I have noticed a few other oddities with the 12864 display however.

The speedfactor is display appears to be multiplied by 100. Using M220 S80 will produce an output of 8000
This is the line I am using the display spped factor:
value R51 C50 F0 D0 W25 N500

Another thing I have noted is loading menus now does not function. I recieve an error stating File "menu", File cannot be found.
The line I am using is:
button R51 C72 F0 T"Get Started »" A"menu" L"e_main"

If I create a file called menu it will be loaded when trying to select any button that is a reference to a menu.

For now I have reverted to RC3 and all functionality has returned.

[Veti]

@incogizmo

change the A"menu" to A"e_menu"

[dc42]

@incogizmo said in RepRapFirmware 2.02RC4 released:

button R51 C72 F0 T"Get Started »" A"menu" L"e_main"

That line should have been:

button R51 C72 F0 T"Get Started »" A"#0" L"e_main"

but due to a bug that is now fixed, you had to use "menu" instead of "#0". However, @Veti's suggestion is simpler.

I will check out the display of the speed factor.

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