RepRapFirmware 3.01-RC6 released

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.

dc42

@SpoonUnit said in RepRapFirmware 3.01-RC6 released:

;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

As you have not inverted the input, it should report 'active: true' when the input is high and false when it is low (i.e. shorted to ground).

Where in the object model will J1 sit once defined? It doesn't seem to be in inputs or sensors.

It should already be in sensors.inputs[1].

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?

Thanks, I've corrected the example.

dc42

I've just tested exactly that configuration: M950 J1 C"duex.e2stop". M950 J1 always reports "active: false" which is incorrect. I will fix this in RC7. M409 K"sensors.inputs" reports it correctly.

SpoonUnit

@dc42 Strange I get active:true, regardless of whether the button is pressed or not, whereas you get false. Good to know what you intended for it.

echo sensors.inputs[1].value

Reports true, where I expect it to report false. Regardless, the button is performing its intended function now.