RepRapFirmware 3.01-RC6 released
-
@ChrisP said in RepRapFirmware 3.01-RC6 released:
drive is unmounted
by the sound of it its unable to load the config.g so that could explain why nothing else works.
could you also try doing
ls -l /opt/dsf/sd
andls -l /opt/dsf/sd/sys
in an ssh shell to see what permissions you have?edit: or did the power cycle solve it?
-
@elliott-griffiths it’s frustrating.
After setting it up from scratch.
Means... downloading the current image, and setup a new sd...
still issues.
Stand-alone with SD, no problem.But the SBC version.
After starting with the new image the sbc connects to the duet. So far so good.
DWC is able to acces the virtual SD with all folders.
But after uploading the config.g to the sys folder and rebooting,
the system has problems to access to the virtual SD with a lot of error messages .
It’s not able to read and access any folder of the virtual SDIt’s so frustrating
-
@bearer said in RepRapFirmware 3.01-RC6 released:
@ChrisP said in RepRapFirmware 3.01-RC6 released:
drive is unmounted
by the sound of it its unable to load the config.g so that could explain why nothing else works.
could you also try doing
ls -l /opt/dsf/sd
andls -l /opt/dsf/sd/sys
in an ssh shell to see what permissions you have?Thanks for picking this up, but that is not the porblem at this point. I've only seen that error once immediately after update and after power cycle, that hasn't happened again.
Everything now seems to load and I can see all the files on the interface, however, it's still not booting properly. After a reinstall, I'm still getting a persistant "busy" state and no the tools show the bed, but not the extruder, temperature chart still sows both. Pressing emergency stop now seems to work, but then nothing is listed in the tools and it still sits being "Busy" - see image.
-
@tobias_munich said in RepRapFirmware 3.01-RC6 released:
But after uploading the config.g to the sys folder and rebooting,
care to share the file and/or try a empty file?
-
@bearer I tried a lot of ways ....
And after all the tests I made it seems it’s a problem with the virtual SD. -
But after uploading the config.g to the sys folder and rebooting,
the system has problems to access to the virtual SDAnd after all the tests I made it seems it’s a problem with the virtual SD.
no doubt about it, just curious if its the content or presence of the config.g file that makes a difference; as it seemed it did make a difference from your earlier post.
-
I'd also be interested to see what (if any) errors you have in the log for the DCS service:
sudo journalctl -u duetcontrolserver.service
Because I get a massive log full of this repeating. So I guress it's to do with my laser filament monitor in this case.
Apr 03 22:20:52 starttex DuetControlServer[359]: [error] Failed to merge JSON: {"key":"","flags":"d99fn","result":{"boards":[{"mcuTemp":{"current":47.2},"v12":{"current":11.3},"vIn":{"current":12.0}}],"fans":[{"actualValue":0,"requestedValue":1.00,"rpm":0},{"actualValue":0,"requestedValue":0,"rpm":-1}],"heat":{"heaters":[{"active":50.0,"current":20.5,"standby":0,"state":"standby"},{"active":200.0,"current":23.0,"standby":0,"state":"off"}]},"inputs":[{"feedRate":50.0,"lineNumber":0,"state":"idle"},{"feedRate":50.0,"lineNumber":0,"state":"idle"},{"feedRate":50.0,"lineNumber":0,"state":"idle"},{"feedRate":50.0,"lineNumber":0,"state":"idle"},{"feedRate":50.0,"lineNumber":2450,"state":"idle"},{"feedRate":50.0,"lineNumber":0,"state":"idle"},{"feedRate":50.0,"lineNumber":0,"state":"idle"},{"feedRate":50.0,"lineNumber":0,"state":"idle"},{"feedRate":50.0,"lineNumber":0,"state":"idle"},{"feedRate":50.0,"lineNumber":0,"state":"idle"},{"feedRate":50.0,"lineNumber":0,"state":"idle"}],"job":{"build":null,"duration":null,"filePosition":0,"layerTime":null,"timesLeft":{"filament":null,"file":null,"layer":null}},"move":{"axes":[{"homed":false,"machinePosition":0,"userPosition":0},{"homed":false,"machinePosition":0,"userPosition":0},{"homed":false,"machinePosition":0,"userPosition":0}],"currentMove":{"acceleration":0,"deceleration":0,"requestedSpeed":0,"topSpeed":0},"extruders":[{"position":0,"rawPosition":0}],"speedFactor":1.0},"sensors":{"analog":[{"lastReading":20.5},{"lastReading":23.0}],"endstops":[{"triggered":false},{"triggered":false},{"triggered":true}],"filamentMonitors":[{"filamentPresent":null}],"inputs":[{"value":null},{"value":true}],"probes":[{"value":[1000]}]},"seqs":{"boards":0,"directories":0,"fans":4,"heat":7,"inputs":1,"job":0,"move":13,"network":3,"reply":0,"sensors":2,"spindles":0,"state":0,"tools":5,"volumes":0},"spindles":[{"current":0},{"current":0}],"state":{"atxPower":null,"currentTool":-1,"laserPwm":null,"nextTool":-1,"previousTool":-1,"status":"idle","upTime":779},"tools":[{"active":[200.0],"standby":[0],"state":"off"}]}} Apr 03 22:20:52 starttex DuetControlServer[359]: System.Text.Json.JsonException: Failed to deserialize property [FilamentMonitor].FilamentPresent (type Boolean) from JSON null Apr 03 22:20:52 starttex DuetControlServer[359]: ---> System.Text.Json.JsonException: The JSON value could not be converted to System.Boolean. Path: $ | LineNumber: 0 | BytePositionInLine: 4. Apr 03 22:20:52 starttex DuetControlServer[359]: ---> System.InvalidOperationException: Cannot get the value of a token type 'Null' as a boolean. Apr 03 22:20:52 starttex DuetControlServer[359]: at System.Text.Json.Utf8JsonReader.GetBoolean() Apr 03 22:20:52 starttex DuetControlServer[359]: at System.Text.Json.Serialization.Converters.JsonConverterBoolean.Read(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options) Apr 03 22:20:52 starttex DuetControlServer[359]: at System.Text.Json.JsonPropertyInfoNotNullable`4.OnRead(ReadStack& state, Utf8JsonReader& reader) Apr 03 22:20:52 starttex DuetControlServer[359]: at System.Text.Json.JsonPropertyInfo.Read(JsonTokenType tokenType, ReadStack& state, Utf8JsonReader& reader) Apr 03 22:20:52 starttex DuetControlServer[359]: at System.Text.Json.JsonSerializer.HandleNull(Utf8JsonReader& reader, ReadStack& state) Apr 03 22:20:52 starttex DuetControlServer[359]: at System.Text.Json.JsonSerializer.ReadCore(JsonSerializerOptions options, Utf8JsonReader& reader, ReadStack& readStack) Apr 03 22:20:52 starttex DuetControlServer[359]: --- End of inner exception stack trace --- Apr 03 22:20:52 starttex DuetControlServer[359]: at System.Text.Json.ThrowHelper.ReThrowWithPath(ReadStack& readStack, Utf8JsonReader& reader, Exception ex) Apr 03 22:20:52 starttex DuetControlServer[359]: at System.Text.Json.JsonSerializer.ReadCore(JsonSerializerOptions options, Utf8JsonReader& reader, ReadStack& readStack) Apr 03 22:20:52 starttex DuetControlServer[359]: at System.Text.Json.JsonSerializer.ReadCore(Type returnType, JsonSerializerOptions options, Utf8JsonReader& reader) Apr 03 22:20:52 starttex DuetControlServer[359]: at System.Text.Json.JsonSerializer.Deserialize(String json, Type returnType, JsonSerializerOptions options) Apr 03 22:20:52 starttex DuetControlServer[359]: at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 282 Apr 03 22:20:52 starttex DuetControlServer[359]: --- End of inner exception stack trace --- Apr 03 22:20:52 starttex DuetControlServer[359]: at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 287 Apr 03 22:20:52 starttex DuetControlServer[359]: at DuetAPI.Machine.ModelCollectionHelper.UpdateFromJson(IList list, Type itemType, JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelCollection.cs:line 227 Apr 03 22:20:52 starttex DuetControlServer[359]: at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 264 Apr 03 22:20:52 starttex DuetControlServer[359]: at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 248 Apr 03 22:20:52 starttex DuetControlServer[359]: at DuetAPI.Machine.MachineModel.UpdateFromFirmwareModel(String key, JsonElement jsonElement) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/MachineModel.cs:line 134 Apr 03 22:20:52 starttex DuetControlServer[359]: at DuetControlServer.Model.Updater.Run() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/Model/Updater.cs:line 140
Edit: and sure enough, commenting out my filament monitor in the config.g and everything (except for the filament monitor) is working again. Think this is one for @chrishamm .
-
@ChrisP said in RepRapFirmware 3.01-RC6 released:
Did power cycling fix that issue for you? It did for me. MInd you, even when that works, the printer is still unusable
How can you say that power cycling fixed it for you if the printer is still unusable?
-
@chas2706
Because power cycling fixed that issue (ie. the drive mounted and read file and config etc), but after rebooting it hit a different bug (mentioned in my post above) that still rendered the printer unusable at that point. -
Ok that's an improvement but for me power cycling, resetting or re-installing made no difference.
I've had to revert to RRF3.01RC3 but now running on the wrong version of DWC because there is no indication anywhere how we SBC users can download a specific version of DWC. -
This has learnt me a big lesson. Always, always, always make a current back up before you download a "new release"! My latest back up was from a few previous releases.
-
edit: NOPE, that was not a good idea.
maybe this works better, specifying all the packages to fulfill dependencies for duetsoftwareframework=1.2.5.0
grep duet3d -r /etc/apt | grep unstable && sudo apt install duetcontrolserver=1.2.5.0 duetsd=1.0.5 duettools=1.2.5.0 duetwebserver=1.2.3.1 duetwebcontrol=2.0.7-1 reprapfirmware=1.2.5.0-1 duetruntime=1.2.5.0 duetsoftwareframework=1.2.5.0 || echo Please swtich to unstable list.
edit changed to fail if not on unstable list.
Also according to chrishamm switching to instead of adding the unstable list may be the way to go
#comment out stable list sudo sed -i '/ stable/s/^/#/g' /etc/apt/sources.list.d/duet3d.list #add unstable list echo "deb https://pkg.duet3d.com/ unstable armv7" | sudo tee /etc/apt/sources.list.d/duet3d-unstable.list
-
@chas2706 said in RepRapFirmware 3.01-RC6 released:
Ok that's an improvement but for me power cycling, resetting or re-installing made no difference.
I've had to revert to RRF3.01RC3 but now running on the wrong version of DWC because there is no indication anywhere how we SBC users can download a specific version of DWC.As @bearer pointa out, rolling back isn't tricky. Tbh, theres a reason that it's a beta firmware, so it should be obvious that backups are wise when trying a new "upgrade".
I'd still be interested to know the output of you logs for the DCS service.
-
the start of the log is probably more relevant than the end of it.
-
@ChrisP said in RepRapFirmware 3.01-RC6 released:
As @bearer pointa out, rolling back isn't tricky. Tbh, theres a reason that it's a beta firmware, so it should be obvious that backups are wise when trying a new "upgrade".
I understand the meaning of beta firmware but if you have Duet3 with SBC and dare to "upgrade" there is no guarantee that if upon failure an older backup will work.
I now have this problem running RRF3.01.RC3 from a backup:So now I will be spending numerous hours starting afresh!
-
@chas2706 said in RepRapFirmware 3.01-RC6 released:
there is no guarantee that if upon failure an older backup will work.
that would imply your backup isn't covering your needs. simply shutting down the pi and cloning or imaging the SD card would take care of all but the RRF firmware on the Duet which can be flashed after restoring an old SD card. (caveat if they changed the iap binary)
-
@chas2706
You really shouldn't need to start afresh. Even if you do, as long as you have a copy of the sys & macros folders it should take longer to burn a new raspbian image than it does to get that fresh Linux install to a working printer. I can't remember it taking more than about 15 mins following the guide on the wiki.You'll be back up and running in no time
-
@Marco-Bona said in RepRapFirmware 3.01-RC6 released:
1_ I continue to have the problem with the correct visualization of the Layers (yesterday @droftarts said it would be solved with the new build)
Strange, because this is mentioned specifically in the notes;
Bug fixes:
When printing a file, the first layer time was reported incorrectly, and when the print completed the total print time reported was incorrectHave you updated the firmware AND the DWC?
Ian
-
@chas2706 said in RepRapFirmware 3.01-RC6 released:
So now I will be spending numerous hours starting afresh!
see my edited post https://forum.duet3d.com/post/143326
-
@chas2706 said in RepRapFirmware 3.01-RC6 released:
because there is no indication anywhere how we SBC users can download a specific version of DWC.
apt allows specification of a version after the thing you are installing.
sudo apt install duetsoftwareframework=1.2.4.0
This, plus a few more commands below, gives you total control over the duet installation on the Pi. You can force it into a good (or bad!) state.
You may want to do 'uninstall' in certain circumstances, or use the --reinstall flag (which forces a complete install even if apt thinks that version is already installed) Examples:
sudo apt uninstall duetsoftwareframework
sudo apt install duetsoftwareframework --reinstall
You can list all available versions via:
sudo apt list -a duetsoftwareframework Listing... Done duetsoftwareframework/unstable,now 1.3.0 armhf [installed] duetsoftwareframework/unstable 1.2.5.0 armhf duetsoftwareframework/unstable,stable 1.2.4.0 armhf duetsoftwareframework/unstable 1.2.3.1 armhf duetsoftwareframework/unstable,stable 1.2.3.0 armhf duetsoftwareframework/unstable,stable 1.2.2.1 armhf duetsoftwareframework/unstable 1.2.2.0 armhf duetsoftwareframework/unstable 1.2.1.0 armhf duetsoftwareframework/unstable 1.2.0.0 armhf duetsoftwareframework/unstable,stable 1.1.0.5 armhf duetsoftwareframework/unstable 1.1.0.4 armhf duetsoftwareframework/unstable 1.1.0.3 armhf duetsoftwareframework/unstable 1.1.0.2 armhf duetsoftwareframework/unstable 1.1.0.1 armhf duetsoftwareframework/unstable 1.1.0.0 armhf duetsoftwareframework/unstable,stable 1.0.4.1 armhf duetsoftwareframework/unstable 1.0.4.0 armhf duetsoftwareframework/unstable 1.0.3.5 armhf duetsoftwareframework/unstable 1.0.3.3 armhf duetsoftwareframework/unstable 1.0.3.2 armhf duetsoftwareframework/stable 1.0.3.1 armhf
Generally, when doing a simple install, apt will deal properly with dependencies. During uninstalls and reinstalls in often does not. You can list all dependencies via:
apt-cache depends duetsoftwareframework duetsoftwareframework Depends: duetcontrolserver Depends: duetsd Depends: duettools Depends: duetwebserver Depends: duetwebcontrol Depends: reprapfirmware Depends: reprapfirmware