DSF 1.3.1 (unstable) released

gtj0

The default SpiFrequency in /opt/dsf/conf/config.json changed from 2000000 (2MHz) to 8000000 (8MHz) with the recent release. Try changing it back to 2000000 and see what happens. Experiment to see what the fastest speed you can reliably run at.

chrishamm

@tobias_munich Sorry to hear you are having problems. Can you check for error messages when DCS disconnected? Can you share the output of M122?

@gruen Please do what @gtj0 said.

gtj0

@chrishamm Do you want me to open github issues for the print time and model issues I mentioned above?

mikedahlgren

@chrishamm Shared elsewhere but here is the results of "sudo journalctl -u duetcontrolserver -en 100 --no-pager"

Apr 06 18:02:00 duet3 DuetControlServer[13291]: Duet Control Server v1.3.1
Apr 06 18:02:00 duet3 DuetControlServer[13291]: Written by Christian Hammacher for Duet3D
Apr 06 18:02:00 duet3 DuetControlServer[13291]: Licensed under the terms of the GNU Public License Version 3
Apr 06 18:02:01 duet3 DuetControlServer[13291]: [info] Settings loaded
Apr 06 18:02:01 duet3 DuetControlServer[13291]: [info] Environment initialized
Apr 06 18:02:01 duet3 DuetControlServer[13291]: [warn] RepRapFirmware got a bad header checksum
Apr 06 18:02:01 duet3 DuetControlServer[13291]: [info] Connection to Duet established
Apr 06 18:02:01 duet3 DuetControlServer[13291]: [info] IPC socket created at /var/run/dsf/dcs.sock
Apr 06 18:02:01 duet3 DuetControlServer[13291]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux
Apr 06 18:02:02 duet3 DuetControlServer[13291]: [fatal] Abnormal program termination
Apr 06 18:02:02 duet3 DuetControlServer[13291]: [fatal] Update task faulted
Apr 06 18:02:02 duet3 DuetControlServer[13291]: System.ArgumentException: Requested value 'fault' was not found.
Apr 06 18:02:02 duet3 DuetControlServer[13291]: at System.Enum.TryParseByName(RuntimeType enumType, String originalValueString, ReadOnlySpan1 value, Boolean ignoreCase, Boolean throwOnFailure, UInt64& result) Apr 06 18:02:02 duet3 DuetControlServer[13291]: at System.Enum.TryParseInt32Enum(RuntimeType enumType, String originalValueString, ReadOnlySpan1 value, Int32 minInclusive, Int32 maxInclusive, Boolean ignoreCase, Boolean throwOnFailure, TypeCode type, Int32& result)
Apr 06 18:02:02 duet3 DuetControlServer[13291]: at System.Enum.TryParse(Type enumType, String value, Boolean ignoreCase, Boolean throwOnFailure, Object& result)
Apr 06 18:02:02 duet3 DuetControlServer[13291]: at System.Enum.Parse(Type enumType, String value, Boolean ignoreCase)
Apr 06 18:02:02 duet3 DuetControlServer[13291]: at DuetAPI.Utility.JsonLowerCaseStringEnumConverter.JsonLowerCaseStringEnumConverterInner1.Read(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Utility/JsonLowerCaseStringEnumConverter.cs:line 62 Apr 06 18:02:02 duet3 DuetControlServer[13291]: at System.Text.Json.JsonPropertyInfoNullable2.OnRead(ReadStack& state, Utf8JsonReader& reader)
Apr 06 18:02:02 duet3 DuetControlServer[13291]: at System.Text.Json.JsonPropertyInfo.Read(JsonTokenType tokenType, ReadStack& state, Utf8JsonReader& reader)
Apr 06 18:02:02 duet3 DuetControlServer[13291]: at System.Text.Json.JsonSerializer.ReadCore(JsonSerializerOptions options, Utf8JsonReader& reader, ReadStack& readStack)
Apr 06 18:02:02 duet3 DuetControlServer[13291]: at System.Text.Json.JsonSerializer.ReadCore(Type returnType, JsonSerializerOptions options, Utf8JsonReader& reader)
Apr 06 18:02:02 duet3 DuetControlServer[13291]: at System.Text.Json.JsonSerializer.Deserialize(String json, Type returnType, JsonSerializerOptions options)
Apr 06 18:02:02 duet3 DuetControlServer[13291]: at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 282
Apr 06 18:02:02 duet3 DuetControlServer[13291]: 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 06 18:02:02 duet3 DuetControlServer[13291]: at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 264
Apr 06 18:02:02 duet3 DuetControlServer[13291]: at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 248
Apr 06 18:02:02 duet3 DuetControlServer[13291]: at DuetAPI.Machine.MachineModel.UpdateFromFirmwareModel(String key, JsonElement jsonElement) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/MachineModel.cs:line 134
Apr 06 18:02:02 duet3 DuetControlServer[13291]: at DuetControlServer.Model.Updater.Run() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/Model/Updater.cs:line 140
Apr 06 18:02:02 duet3 DuetControlServer[13291]: [fatal] Update task faulted

chrishamm

@mikedahlgren Thanks, I've got a fix ready and will release it later this week. Until then the only way to get DCS back working is to reset the Duet 3 using the push button and to wait a moment.

@gtj0 You're right about the printing time and Simplify3D, I'm looking into it. As for the diffs it's all looking good and appears like what DWC would expect, but it's odd that you are seeing the tool temperatures being transmitted over and over again even though nothing has changed. I just tried to reproduce it and I could do this, so I'll fix it as well. Thanks for letting me know!

PS: It's actually Simplify3D that tried to be smart, they're now printing hour instead of hours so my regex doesn't work any more. I'll update it.

mikedahlgren

@chrishamm Thanks you!

gtj0

@chrishamm Can you also comment on the other model oddities like the "fans" object showing in an update but with all empty values. It's kinda confusing because some of the things the RRF model considers "live" show up on every update but others which are also "live" don't.

chrishamm

@gtj0 The whole purpose of the patch-mode subscription is to reflect changes. So it is intended to transmit empty objects if none of the properties of a list item have changed, else you would not be able to tell when the size of a list has changed (e.g. because you decided to delete a tool or something else). Well, in your case you shouldn't be seeing any empty or null items either and it's related to the bug I'm about to fix, so don't worry about it.

PS: Here the new regex for S3D that should work, feel free to give it a try:

Build time: ((?<h>\d+) hour(s)?\s*)?((?<m>\d+) minute(s)?\s*)?((?<s>(\d+) second(s)?))?

gtj0

@chrishamm Cool! I'll give the regex a try.

gtj0

@gtj0 said in DSF 1.3.1 (unstable) released:

@chrishamm Cool! I'll give the regex a try.

AHHHHH. The fact that all those <> etc characters need to be escaped in config.json is really annoying. I'll wait for you to update the default file in the repo.

gtj0

(Possibly) New issue with messages.
If I execute G32 directly, I get the Leadscrew adjustments made: 0.005 0.040 -0.000, points used 3, (mean, deviation) before (0.014, 0.017) after (0.000, 0.000) message back. If I execute G32 from a macro, I don't.

For the good case, I see 2 messages in the DCS log...

DuetControlServer[4316]: [debug] Completed G30 P2 X230 Y-222 Z-99999 S3 ; probe near a leadscrew and calibrate 3 motors => Leadscrew adjustments made: 0.005 0.040 -0.000, points used 3, (mean, deviation) before (0.014, 0.017) after (0.000, 0.000)
DuetControlServer[4316]: Leadscrew adjustments made: 0.005 0.040 -0.000, points used 3, (mean, deviation) before (0.014, 0.017) after (0.000, 0.000)

When run from a macro I only see...

DuetControlServer[4316]: [debug] Completed G30 P2 X230 Y-222 Z-99999 S3 ; probe near a leadscrew and calibrate 3 motors => Leadscrew adjustments made: 0.005 0.040 -0.000, points used 3, (mean, deviation) before (0.014, 0.017) after (0.000, 0.000)

gtj0

@dc42 @chrishamm Not sure of this is a DSF or RRF issue but the model reported by the DSF always has the extrusion factor at "1" and M221 doesn't seem to affect it. Not sure if the M221 isn't working or if the value reported in the model is incorrect.

dc42

@gtj0 said in DSF 1.3.1 (unstable) released:

@dc42 @chrishamm Not sure of this is a DSF or RRF issue but the model reported by the DSF always has the extrusion factor at "1" and M221 doesn't seem to affect it. Not sure if the M221 isn't working or if the value reported in the model is incorrect.

It works for me, in standalone mode (read command/response pairs from bottom to top as usual):

07/04/2020, 07:59:43 	m563 p0
Tool 0 - drives: 0; heaters (active/standby temps): 1 (0.0/0.0); xmap: X; ymap: Y; fans: 0; status: selected
07/04/2020, 07:59:22 	m409 k"move.extruders[].factor"
{"key":"move.extruders[].factor","flags":"","result":[1.2,1.0]}
07/04/2020, 07:59:17 	m221
Extrusion factor(s) for current tool: 120.0%
07/04/2020, 07:59:14 	m221 s120
07/04/2020, 07:59:07 	t0
07/04/2020, 07:58:59 	m221 s120
Error: M221: No tool selected
07/04/2020, 07:58:42 	m409 k"move.extruders[].factor"
{"key":"move.extruders[].factor","flags":"","result":[1.0,1.0]}

gtj0

@dc42 Yeah you're right. I keep forgetting I can do M409 to get the values from RRF.

@chrishamm It does appear to be a DSF model update issue. M409 reports the correct value but the DSF model does not.

chrishamm

@gtj0 Thanks for the report about the extrusion factor, it will be fixed in the next RRF version. I'm afraid I cannot reproduce the G32 output issue though, I can call macros from macro files and the correct output is shown on DWC as expected.

gtj0

@chrishamm ~~OK. I'll have to look how I'm grabbing messages from the model updates.~~

Actually I tried with the DWC and had the same result. I'll check again.

gtj0

@chrishamm Using DSF 1.3.1 and DWC 2.1.1, If I click "True Bed Levelling (G32)" then when it completes, I get the message with the corrections. If I run a macro from the DWC that either runs G32 or calls M98 P"/sys/bed.g", I do NOT get the message with the corrections and there's no indication from the DCS that it sent the message.

gtj0

@chrishamm Here's the full DCS output from executing the "PrepPrinter.g" macro from the DWC.
No message was displayed.

dcs.txt

chrishamm

@gtj0 Thank you, the log explains why you see no output. I am working on a fix.

ChrisP

@chrishamm, not sure if you're aware of this one - there seems to be an issue with sensors that fault crashing DCS.

I'm experimenting with using multiple beds for a project and was trying to define a second bed to emulate another system that is setup and runnning already (using RC5 and 1.2.5.0). However, on 1.3.1, the moment the heater/sensor is mapped as a bed, DCS dies - log attached.

The system I already have running (not here) does actually have the additional bed attached, whereas this one doesn't at the moment. As a result, there is a sensor fault and I think this is possibly where the bug lies. Unfortunately, I can't find a spare sensor right now to test whether the bug just relates to a sensor fault, however, I don't believe this shold cause a complete crash anyway.

Here's the code that can induce the error for me:

M308 S2 P"temp1" Y"thermistor" T100000 A"Bed2"	; configure sensor 0 as thermistor on pin temp1
M950 H2 C"out2" T2				; create bed heater output on out2 and map it to sensor 2
M143 H2 S80					; set temperature limit for heater 0 to 80C
M307 H2 A81.5 C541.8 D1.3 S1.00 V0.0 B0		; bed heater tuning values
M140 P1 H2 S0 R0				; map heated bed to heater 0
M144 P1						; put bed into standby

And while you can proabaly easily recreate this, here's the log: Sensor fault.txt