RepRapFirmware 2.02RC4 released

dc42

I've just released this at https://github.com/dc42/RepRapFirmware/releases/tag/2.02RC4. See the upgrade notes at https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md for full details.

deckingman

David,

I'm not sure if this is the best thread to report back on but there have been a few threads started by myself and others with seeming boot up and /or I2C errors, so I'll put my feedback here.

I've updated to this 2.0.2RC4 release and DWC 1.22.5 as recommended in the release notes.

I don't see any sign of the Duex5 heater LEDs flashing now (someone had problems with lights connected to heater channels flashing).

I do still get a short "double blip" of the hot end fan when booting but it's much much shorter and the overall boot up time seems to be faster.

I still get DWC disconnecting if I edit config.g then restart. It takes about 5 to 10 seconds or so for DWC to re-establish a connection. This isn't a huge issue though. Maybe it's something to do with my PC (Win 10 i7) or Browser (Firefox) or network (wired gigabit ) but I can't think what. It's a trivial thing so I'm not too bothered about it.

Too early to say if I have any I2C errors as these were very intermittent.

HTH

fcwilt

@deckingman said in RepRapFirmware 2.02RC4 released:

I still get DWC disconnecting if I edit config.g then restart. It takes about 5 to 10 seconds or so for DWC to re-establish a connection.

Seems to me this is to be expected since the firmware is re-booting.

Has there ever been a time when a restart didn't close the connection to DWC?

Thanks.

Frederick

deckingman

@fcwilt said in RepRapFirmware 2.02RC4 released:

@deckingman said in RepRapFirmware 2.02RC4 released:

I still get DWC disconnecting if I edit config.g then restart. It takes about 5 to 10 seconds or so for DWC to re-establish a connection.

Seems to me this is to be expected since the firmware is re-booting.

Has there ever been a time when a restart didn't close the connection to DWC?

Thanks.

Frederick

The connection gets lost after the firmware re-boots and in another thread that I started, people told me that 10 seconds or so was an inordinately long time for the connection to re-establish. I'm not too bothered about it but others have told me that the behaviour is abnormal, hence the reason I mentioned it.

dc42

@deckingman said in RepRapFirmware 2.02RC4 released:

The connection gets lost after the firmware re-boots and in another thread that I started, people told me that 10 seconds or so was an inordinately long time for the connection to re-establish. I'm not too bothered about it but others have told me that the behaviour is abnormal, hence the reason I mentioned it.

Are you using a static IP address, or DHCP? If you are using DHCP then the reconnect time will depend in part on how quickly your router allocates an IP address to the Duet.

Also, I don't know how long DWC waits between connection attempts. It must obviously be long enough to allow the previous attempt to time out.

deckingman

@dc42 It's static. We've been through all this in other threads but it's a minor irritation so don't worry about it. I only mentioned because I was trying to point out any behaviours that are changed or unchanged.

Veti

my 12864 now initializes correctly
thank dc42

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.