DSF 1.3.1 (unstable) released
-
@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)?))?
-
@chrishamm Cool! I'll give the regex a try.
-
@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. -
(Possibly) New issue with messages.
If I execute G32 directly, I get theLeadscrew 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)
-
@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.
-
@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]}
-
@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.
-
@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.
-
@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.
-
@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.
-
@chrishamm Here's the full DCS output from executing the "PrepPrinter.g" macro from the DWC.
No message was displayed. -
@gtj0 Thank you, the log explains why you see no output. I am working on a fix.
-
@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
-
This MAY be related to a behavior I've observed but cannot completely and cleanly reproduce enough to report. My best phrasing at this point:
If a homing sequence does not complete, a D3+Pi hangs in a way that requires a power cycle. M999 or emergency stop on the DWC does not totally clear it.
-
@chrishamm ...continuation from PM...
Testing your latest commits...
Things appear to be worse. When I execute the PrepPrinter macro from the DWC, the macro starts and the DWC shows a spinner next to the macro entry but no messages are ever shown and the spinner entry doesn't clear when the macro finishes. In this state you can't click the macro entry any more. I've attached the dcs log again below.
BTW, If I just click the "True Bed Levelling (G32)" button I still don't get the completion message. I was getting it earlier.
Another oddity... If I refresh the DWC, it displays the last message that was sent by the DCS even if it was 20 minutes ago.
;PrepPrinter.g M561 G29 S2 G32 G32 G29 S1
; bed.g G1 Z5 F3600 G30 P0 X-235 Y-222 Z-99999 ; probe near a leadscrew G30 P1 X2 Y235 Z-99999 ; probe near a leadscrew G30 P2 X230 Y-222 Z-99999 S3 ; probe near a leadscrew and calibrate 3 motors
-
Hmmm. Lots of other things not working. DSF not accepting commands after a few minutes, pause/resume/cancel not working, etc. Have to revert.
-
@gtj0 Thanks for testing, I'll do some more tests later when I get back home.
PS were you on the latest RRF from github when you tested?
-
@chrishamm said in DSF 1.3.1 (unstable) released:
@gtj0 Thanks for testing, I'll do some more tests later when I get back home.
PS were you on the latest RRF from github when you tested?
Yes. Last commit:
commit b1a1ef35db873ce8ae84a20de90d096c79e8d108 (upstream/v3.01-dev, v3.01-dev) Author: David Crocker <dcrocker@eschertech.com> Date: Tue Apr 7 16:38:01 2020 +0100 Made the heater fault mnessage more concise
-
@chrishamm Any progress? The current dev branch DCS just hangs when you try to run a macro.
-
@gtj0 Yes I've got macros working well now - I cannot provoke any problems with the latest dev version from GitHub. If you wish to give it a try, rebuild RRF without this commit: https://github.com/dc42/RepRapFirmware/commit/8d38be149db0e18dba6e9f5f6f554cf1c6d87156 If you run into problems, please report them on GitHub or send me a PM - this thread is only for DSF v1.3.1.
dc42 and I are working on another object model change and I'm hoping to release DSF 1.3.2 along with DWC 2.1.2 when that is done.