Posts made by docbobo

Is this compatible with the latest beta?

@wilriker said in PanelDueFirmware 3.2-RC3 released:

So, I tried but unfortunately (or luckily) I cannot reproduce your issue with M300 not playing on PanelDue. I tried playing various tunes from various sources (USB, HTTP, Panel itself) in in all cases sounds were played as expected.

Can you provide me with an example? Also I am running RRF 3.2-beta2 now. Please check if that makes a difference.

Will do. However, won’t be able to do this before the end of week.

Just noticed the following in my DSF output:

[error] Failed to merge JSON: {"key":"","flags":"d99fn","result":{"boards":[{"mcuTemp":{},"vIn":{}}],"fans":[{"actualValue":0,"requestedValue":0,"rpm":-1},{"actualValue":1.00,"requestedValue":1.00,"rpm":-1}],"heat":{"heaters":[{"active":0,"current":61.0,"standby":0,"state":"off"},{"active":0,"current":84.5,"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":205,"state":"idle"},{"feedRate":50.0,"lineNumber":151,"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":{"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,"laserPwm":null,"requestedSpeed":0,"topSpeed
   System.Text.Json.JsonReaderException: Expected end of string, but instead reached end of data. LineNumber: 0 | BytePositionInLine: 1280.
   at System.Text.Json.ThrowHelper.ThrowJsonReaderException(Utf8JsonReader& json, ExceptionResource resource, Byte nextByte, ReadOnlySpan`1 bytes)
   at System.Text.Json.Utf8JsonReader.ConsumeString()
   at System.Text.Json.Utf8JsonReader.ConsumePropertyName()
   at System.Text.Json.Utf8JsonReader.ConsumeNextToken(Byte marker)
   at System.Text.Json.Utf8JsonReader.ConsumeNextTokenOrRollback(Byte marker)
   at System.Text.Json.Utf8JsonReader.ReadSingleSegment()
   at System.Text.Json.Utf8JsonReader.Read()
   at System.Text.Json.JsonDocument.Parse(ReadOnlySpan`1 utf8JsonSpan, Utf8JsonReader reader, MetadataDb& database, StackRowStack& stack)
   at System.Text.Json.JsonDocument.Parse(ReadOnlyMemory`1 utf8Json, JsonReaderOptions readerOptions, Byte[] extraRentedBytes)
   at System.Text.Json.JsonDocument.Parse(ReadOnlyMemory`1 utf8Json, JsonDocumentOptions options)
   at DuetControlServer.Model.Updater.Run() in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/Model/Updater.cs:line 100

I also have that on startup for some other keys, e.g. "inputs" and "move". But the one above is reoccurring. It stop when the PanelDue's screensaver is on.

Some more system info:

M115
FIRMWARE_NAME: RepRapFirmware for LPC176x based Boards FIRMWARE_VERSION: 3.2-beta1_2 ELECTRONICS: LPC176x FIRMWARE_DATE: 2020-09-15b1

Board: biquskr_1.4 (LPCSBC)
DSF Version: 3.2.0-beta1+1

@wilriker no, it’s not waking up the panel. It was mostly black, just the numbers for x, y, and z were appearing.

@wilriker Let me know if there's anything I can do.

BTW, when running mesh compensation, I noticed that coordinates for X Y Z were updating the screen, even though it was in sleep mode. Doesn't seem to happen while printing.

@BoA Well, the documentation seems to say

Play beep sound, use to notify events like the end of printing. If an LCD device is attached to RepRapFirmware, a sound is played via the add-on touch screen control panel. Else the web interface will play a beep sound.

I just set up my 5i with an BTT SKR 1.4 Turbo using 3.2-RC3 together with all the other betas (DWC, DSF, FW).

At least for me, M300 doesn't result in any sound coming out of the PanelDue, even though it does beep when I am pressing some of the buttons.

Am I missing anything there?

In that context: what would be the right way to cancel a print from within start.g?

I am running RRF 3.2 beta 1 on a BTT SKR 1.4 Turbo with SBC
DSF Version 3.2.0-beta1+1
DWC Version 3.2.0-beta1+2

This problem also seems to be present in RRF 3.1.1 on SBC.

Here's the GCode I am testing with:

T0
M0

Based on documentation, I would've expected that stop.g is called afterwards, which seems to be happening in standalone mode (according to @jay_s_uk).

Instead, what's being called is cancel.g

I am running RR3 3.2 beta 1 on a BTT SKR 1.4 Turbo with SBC
DSF Version 3.2.0-beta1+1
DWC Version 3.2.0-beta1+2

I was just trying out some filament change during print, and according to documentation, M600 should execute pause.g if no filament-change.g is present. In my case though, just the extruder stopped moving. It did not execute the pause.g code.
Copying pause.g to filament-change.g resulted in the correct behavior in that regard, but it certainly doesn't match the documentation.

Here's my M122

=== Diagnostics ===
RepRapFirmware for LPC176x based Boards (biquskr_1.4) version 3.2-beta1_2 running on LPC176x at 120Mhz
Used output buffers: 1 of 16 (12 max)
=== RTOS ===
Static ram: 4704
Dynamic Memory (RTOS Heap 5): 1960 free, 1936 never used
Exception stack ram used: 448
Never used ram: 60
Tasks: HEAT(blocked,338) MAIN(running,326) IDLE(ready,20)
Owned mutexes:
=== Platform ===
Last reset 02:19:16 ago, cause: [power up]
Last software reset at 2020-09-30 20:19, reason: User, LinuxInterface spinning, available RAM 268, slot 2
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0440f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 0x020
Supply voltage: under voltage events: 0
Driver 0: position 13616,  standstill, SG min/max 130/130, error r/w 0/0, ifcnt 87, cnt r/w 506/0, timeout 0, failedOp 0xff
Driver 1: position 9670,  standstill, SG min/max 158/158, error r/w 0/0, ifcnt 87, cnt r/w 506/0, timeout 0, failedOp 0xff
Driver 2: position 22080,  standstill, SG min/max 40/40, error r/w 0/0, ifcnt 74, cnt r/w 505/0, timeout 0, failedOp 0xff
Driver 3: position 0,  standstill, SG min/max 2/2, error r/w 0/0, ifcnt 50, cnt r/w 505/0, timeout 0, failedOp 0xff
Driver 4: position 0,  standstill, SG min/max 14/14, error r/w 0/0, ifcnt 74, cnt r/w 505/0, timeout 0, failedOp 0xff
Driver 5: position 0
Driver 6: position 0
Date/time: 2020-10-01 12:25:05
Slowest loop: 3.93ms; fastest: 0.31ms
Step timer: target 3636317556 count 4051167559 delta -414850003 late 0
USBSerial connected 1
ADC not ready 0 ADC error threshold 10 ADC Init 1
Ints: 5646; Calls 7528; fast: 2uS; slow 12uS adj 63 bad 0 big delta 0
PWM Channels
state 0 next 40614 on 55770 off 64230 pin 2.5
state 1 next 40614 on 52380 off 67620 pin 2.7
Delta 40614 Start 0 End 2
=== Move ===
Hiccups: 0, FreeDm: 100, MinFreeDm: 100, MaxWait: 0ms
Bed compensation in use: mesh, comp offset 0.000
=== DDARing ===
Scheduled moves: 595, completed moves: 595, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0, chamberHeaters = -1
Heater 0 is on, I-accum = 0.5
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is ready with "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue* is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon* is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Filament sensors ===
Extruder 0 sensor: ok
=== SBC interface ===
State: 0, failed transfers: 0
Last transfer: 14ms ago
RX/TX seq numbers: 24229/4160
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0-beta1+1
Code buffer space: 2048
Configured SPI speed: 8000000 Hz
Full transfers per second: 29.74

Same problem for me with M600: filament-change.g is executed and the extruder is moved to the desired position. When resuming the print, the extruder us moved back to its original position and nothing happens.

Then, after a while, I get a "Finished Printing" notification.

Just checked - that even produces the same error when pasted into the GCode command box at the top of DWC.

You are right, it seems to be slightly more complicated than that. Even though I cannot upload my gcode file here - upload always fails with an error (?) - I was able to reduce the problem to exactly one line:

M84 XYE; disable motors

A gcode file that just contains this line will produce the error. Adding a whitespace in front of the semicolon seems to fix this problem, btw.

$ dpkg --list | grep Duet
ii  duetcontrolserver                    3.2.0-beta1+1                       armhf        Control server application for Duet 3 series
ii  duetruntime                          3.2.0-beta1+1                       armhf        .NET Core runtime libraries for the Duet software framework
ii  duetsd                               1.0.7                               all          Virtual SD card directory for the Duet software framework
ii  duetsoftwareframework                3.2.0-beta1+1                       armhf        Meta package for the full Duet software framework
ii  duetwebcontrol                       3.2.0-beta1+2                       all          Official web interface for Duet electronics
ii  duetwebserver                        3.2.0-beta1                         armhf        Optional web server for Duet 3 series

I just started my journey with RRF on a SKR 1.4 Turbo. Today, I switched from an ESP based connection over to the SBC integration. However, uploading some gcode that had worked earlier today, I received the following error:

Failed to get file info for CaribouSKR_PETG_calicat_calico_0.2000mm.gcode
Operation failed (Reason: CodeParserException in GetFileInfo: Failed to parse major M-code number (otors))

It seems that the parsed had some issues with the very last gcode in the file, which reads

M84 XYE

However, the same gcode worked in the files when uploaded via ESP.