RepRapFirmware 3.01-RC6 released

ChrisP

@bearer said in RepRapFirmware 3.01-RC6 released:

@ChrisP said in RepRapFirmware 3.01-RC6 released:

this is how I always debug 0.6 and Duet 2s

easy to loose sight of the trees in the forrest i guess

timeout 1 cat /dev/ttyACM0 & echo -e "\nM122" > /dev/ttyACM0

should get you the M122 from serial as a one line copy/paste if you should need it (as opposed to installing the less than user friendly console based serial terminals available for the pi)

100%
Yeh, I've got Termite on a Windows PC, so I can avoid conole based serial terminals

@chrishamm said in RepRapFirmware 3.01-RC6 released:

Thanks but this M122 output doesn't show anything unusual either. Btw, you can keep a log session going when you start a print by running sudo journalctl -u duetcontrolserver -f. This way, all the events from DCS are sent to your console window.
Cool!

The print has now got past where it did last time, annoyingly.
If it is was just the PanelDue causing the issue this time, is it any use to you if I plug it back in to force crashes and post the logs, or not? Or do we just accept that eh PannelDUe is currently dead for this release?

edit: I've noticed that the Layer Chart remains blank during printing...?

droftarts

@chrishamm @dc42 see https://forum.duet3d.com/post/143464 earlier in thread. Says layer time is still wrong. Saw it was supposed to be fixed in 3.01-RC6 release notes. Any suggestions?

@Marco-Bona The only thing I can think of is to clear browser cache?

Ian

chrishamm

I've just released DWC 2.1.1 (see https://forum.duet3d.com/topic/15342/duet-web-control-2-1-1-released) and DSF 1.3.1 (see https://forum.duet3d.com/topic/15343/dsf-1-3-1-unstable-released). Please use the corresponding threads for DWC and DSF-related support and this one only for issues involving the firmware.

dc42

@droftarts said in RepRapFirmware 3.01-RC6 released:

@chrishamm @dc42 see https://forum.duet3d.com/post/143464 earlier in thread. Says layer time is still wrong. Saw it was supposed to be fixed in 3.01-RC6 release notes. Any suggestions?

@Marco-Bona The only thing I can think of is to clear browser cache?

Ian

The issue I thought we were talking about is this one https://forum.duet3d.com/post/142804 whereby the firmware behaves as if the first layer (and the whole print) started when the printer was powered up. I believe that is fixed. Is there another issue with layer times?

wilriker

For everyone having unexplainable problems using SBC ( @chas2706 might fall under that) AND using my Exec On MCode tool please see: https://forum.duet3d.com/post/143593

ChrisP

Im assuming this is a firmware related issue rather that a DSF issue, but I'm not sure.

I've noticed that on powerup, the printer clearly isn't parsing filaments.csv properly as it forgets what filament is loaded. The csv file is there and has the correct information, but the web interface shows no filament is loaded and M701 returns "No filament loaded in the selected tool".

I'm currently running 3.01-RC6 with DSF 1.3.1

edit: loading filament sitll fails to show it on the web interface, but M701 reports correctly

gruen

I have upgrade from a fresh raspberry image to RC6. Now I would print, upload works then
Failed to connect to duet3.
DCS is not startet.

Apr 05 12:29:59 Duet3 DuetControlServer[2388]: Duet Control Server v1.3.1
Apr 05 12:29:59 Duet3 DuetControlServer[2388]: Written by Christian Hammacher for Duet3D
Apr 05 12:29:59 Duet3 DuetControlServer[2388]: Licensed under the terms of the GNU Public License Version 3
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [info] Settings loaded
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [info] Environment initialized
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [warn] Bad data checksum (expected 0x31c7, got 0xe55f)
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [warn] Bad data checksum (expected 0x31c7, got 0xe55f)
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [warn] Bad data checksum (expected 0x31c7, got 0xe55f)
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [warn] Restarting transfer because the number of maximum retries has been exceeded
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [error] Duet is not available
Apr 05 12:30:00 Duet3 systemd[1]: duetcontrolserver.service: Succeeded.
Apr 05 12:30:06 Duet3 systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart.
Apr 05 12:30:06 Duet3 systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 75.
Apr 05 12:30:06 Duet3 systemd[1]: Stopped Duet Control Server.
Apr 05 12:30:06 Duet3 systemd[1]: Started Duet Control Server.
Apr 05 12:30:06 Duet3 DuetControlServer[2405]: Duet Control Server v1.3.1
Apr 05 12:30:06 Duet3 DuetControlServer[2405]: Written by Christian Hammacher for Duet3D
Apr 05 12:30:06 Duet3 DuetControlServer[2405]: Licensed under the terms of the GNU Public License Version 3
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [info] Settings loaded
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [info] Environment initialized
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [warn] Bad data checksum (expected 0x31c7, got 0xe55f)
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [warn] Bad data checksum (expected 0x31c7, got 0xe55f)
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [warn] Bad data checksum (expected 0x31c7, got 0xe55f)
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [warn] Restarting transfer because the number of maximum retries has been exceeded
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [error] Duet is not available
Apr 05 12:30:07 Duet3 systemd[1]: duetcontrolserver.service: Succeeded.
Apr 05 12:30:13 Duet3 systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart.
Apr 05 12:30:13 Duet3 systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 76.
Apr 05 12:30:13 Duet3 systemd[1]: Stopped Duet Control Server.
Apr 05 12:30:13 Duet3 systemd[1]: Started Duet Control Server.
Apr 05 12:30:13 Duet3 DuetControlServer[2418]: Duet Control Server v1.3.1
Apr 05 12:30:13 Duet3 DuetControlServer[2418]: Written by Christian Hammacher for Duet3D
Apr 05 12:30:13 Duet3 DuetControlServer[2418]: Licensed under the terms of the GNU Public License Version 3

Power cycle doesn't work!

chas2706

@wilriker said in RepRapFirmware 3.01-RC6 released:

For everyone having unexplainable problems using SBC ( @chas2706 might fall under that) AND using my Exec On MCode tool please see: https://forum.duet3d.com/post/143593

Thanks for the info.
I use your Exec On MCode so I definitely fall into that category.

gruen

I'm back on RC5.

gtj0

If you're having issues with connections between the DSF and the Duet3, check this out...
https://forum.duet3d.com/post/143792

gruen

I'm waiting for RC7.

dc42

@gruen said in RepRapFirmware 3.01-RC6 released:

I'm waiting for RC7.

There are no plans for a RRF 3.01-RC7 release, because there are no known bugs in 3.01-RC6 known yet other than the limitations described in the whatsnew-rrf3 file.

tobias_munich

RC6 works for me in standalone mode and is stable.
SBC mode is still unstable.
think the reason is still the current version of the duet framework.

jmjcoke

I have tried, sudo service duetcontrolserver restart and I still have Drive is unmounted. Any help on how I can goto RC5 from here, I cannot seem to get duetframework to anything but 1.3.1.

tobias_munich

@jmjcoke the problem is not RC6, it’s the Duetframework.
if you run RC6 in stand-alone mode you shoudnt have issues.

SpoonUnit

Successfully setup and printed with RC6. Only issue is that my kill switch isn't working. It's setup with this, to invoke trigger2.g:

M581 P"duex.e2stop" S1 T2 C0

Trigger 2 is working if I invoke with M98, and M999 (the only command in the trigger) also does it's job. I've tried all 4 permutations of the command that seem to make sense:

M581 P"duex.e2stop" S1 T2 C0
M581 P"duex.e2stop" S0 T2 C0
M581 P"!duex.e2stop" S1 T2 C0
M581 P"!duex.e2stop" S0 T2 C0

None of them result in activation of the trigger when the button is pressed.

The command executes fine from the console, and worked as intended with RC1. I can't see any reference in the notes for each release between RC1 and RC6 for this, but could have missed something.

Is there a way to simply report on the state of a given pin?

This output doesn't give me confidence it's been made available, but I never needed to investigate to this depth previously, so I'm not sure what the output in RC1 was:

M409 K"sensors.endstops" F"v"

{"key":"sensors.endstops","flags":"v","result":[{"triggered":false,"type":"inputPin"},{"triggered":false,"type":"inputPin"},null,{"triggered":false,"type":"motorStallAny"}]}

I'm not sure where else in the object model to look. Could this be it?

M409 K"inputs[5]" F"v"

{"key":"inputs[5]","flags":"v","result":{"axesRelative":false,"compatibility":"RepRapFirmware","distanceUnit":"mm","drivesRelative":false,"feedRate":50.0,"inMacro":false,"lineNumber":0,"name":"Trigger","stackDepth":0,"state":"idle","volumetric":false}}

If so, I don't see any key there for the value.

Any help appreciated.

deckingman

@SpoonUnit Something did change with M581. I'm on a phone right now so not easy for me to say exactly what. IIRC you need to add an M950 with a (I think) J parameter.

dc42

@SpoonUnit, read the upgrade notes for 3.01-RC2, or https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M581_RepRapFirmware_3_01RC2_and_later.

SpoonUnit

Thanks.

This was the end result of the conversion, which now works.

; buttons
;RRF 3.01 RC1
;M581 P"duex.e2stop" S1 T2 C0

;RRF 3.01 RC6
M950 J1 C"duex.e2stop" ; Define Input J1 for pin duex.e2stop
M581 P1 T2 C0 S1 ; Connect Input J1 (P1) to trigger 2 (T2) always (C0) for inactive to active (S1 - also default)

One source of confusion was that M950 J1 alone reports this, regardless of whether the button is pressed or not:

M950 J1
Pin duex.e2stop, active: true

I guess this is reporting that the pin is active in the model, and not that the pin state is open. Where in the object model will J1 sit once defined? It doesn't seem to be in inputs or sensors.

Also spotted on the M950 example:

M950 J1 C"!^e3stop" ; Input 1 uses e0Stop pin, inverted, pullup enabled

Should this not read that Input 1 uses e3stop, instead of e0stop?

chrishamm

@ChrisP Thanks for reporting this, I'll try to reproduce and fix it.