Pressure advance tuning with conditional G-code
-
@schmart ok thanks. its obviously dependent on both the syntax used and the other lines.
-
The forum highlighting problem is long standing
https://forum.duet3d.com/post/225020
.
Sometimes you need yo try a few different language formats to get one that works.
Try python, bash, Java, json, pascal etc -
Hi. I test this today but I become with the duet3 6c Board and tool board 1lc in sbc Modus a error.
What can I Do?
I have test it with .g and .gcode and as MacroWith macro I become a another error Code
-
I wanted to try the code as well, and it doesn't seem to work as expected. The nozzle and bed heat up, and then the heater is turned off again as it starts printing it seems.
-
@heartleander81 As far as I know, the conditional G-code works in a macro only, not in a .gcode file.
The second problem I suspect is a copy error. Conditional G-code is indentation sensitive; with indented text (consistently using either spaces or tabs) you essentially define the sections that run conditionally or in a loop.
In other errors I spot that the word line in
purge_line_flow_ratio
was somehow replaced with the line numbers 139 and 141 the variable is used on, so perhaps something's going wrong in the process of copying the text from the forum post into the macro editor.I've just copied the code from the first post again in my editor (VS Code) and performed a difference/diff/compare with the code in my actual printer to verify that the code in this post is sound. There's no differences that explain what I'm seeing on your end
-
@izeman I'm missing text like 'Axes to be homed' in the console, so I'm assuming you had to modify the code for the topology of your printer.
Can you verify that the code still contains the
T{var.tool_number}
andM568 P{var.tool_number} S{var.print_temperature} R{var.standby_temperature} A1
statements? This selects the current tool, respectively sets the active and standby temperatures and requests to go to the standby temperature.If that's still in there, according to the documentation, the
M568 A2
on line 131 should use the current tool (which should be selected withT{var.tool_number}
) and thereforeM568
should not require theP
parameter, but you can try if changing the codeM568 A2
(originally on line 131) toM568 P{var.tool_number} A2
helps mitigate the error. -
@schmart hi.
When I write a echo for purge_line_flow_ratio become I the error on line 88 not in line 139 and line 141.
I have check it on vs code to and notepad ++ ther looks All good but doun't work -
Via privat chat @Heartleander81 and I tried to solve his problem.
He is using a D3 with SBC. I am using a D3M+ standalone. I sent him my macro and he tried to simulatet it. He got this error:
GetFileInfo: Cannot convert Z parameter to float (value {var.layer_height})
We both are running 3.4 B5. Could this be a DSF Problem?
@oozeBot i know you have some printer running D3 with SBC. Can you try to simulate it?
Best
-
I have copy second time the Code from first comment.
I have the error with the line 139 and 141 but the test run now.
-
@pcr Can you please send me the full G-code file?
-
@chrishamm here ya goPA.g
-
Here is the console output. This was tested on a 6HC with attached SBC running 3.4b5.
After simulation:
M37 P"0:/gcodes/1636019653286-pa.g" Error: Operation failed (Reason: ArgumentException in SimpleCode: Cannot convert Z parameter to float (value {var.layer_height}))
After upload:
Failed to get file info for 1636019653286-pa.g Operation failed (Reason: ArgumentException in GetFileInfo: Cannot convert Z parameter to float (value {var.layer_height}))
-
Am I correct that the SBC scans the file and since it does not find a clear layer height, the error is there? Is only a guess, since without sbc the error is apparently not there
The test run now at my printer with the 2 error line 139 and 141. Nice work.
-
@heartleander81 said in Pressure advance tuning with conditional G-code:
Am I correct that the SBC scans the file and since it does not find a clear layer height, the error is there? Is only a guess, since without sbc the error is apparently not there
Well, it does indeed seem the handling is different compared to running the G-code on a standalone board. Please run the following macro, first with
M37
and then withM98
. Make sure you've homed the Z-axis yourself, and/or adjust the macro to suit your printer.var z = 25.0 G1 Z{var.z} F600
I think that if this small snippet fails, we should follow up with one of the developers.
I've also run the code posted by @PCR on my printer as well, with
M37
,M32
andM98
. The only thing that was noticeably different, were some printer-specific adjustments he made, and lines ending with \x0A\x0A (LFLF) characters, while mine uses \x0D\x0A (CRLF). So this code should run fine.The test run now at my printer with the 2 error line 139 and 141. Nice work.
So you're still seeing the weird 'purge_139_flow_ratio' and 'purge_141_flow_ratio' errors? These kind of errors are triggered when a variable is not defined. I can't explain the cause of that. But it seems that the word 'line' in the variable name
purge_line_flow_ratio
gets substituted with the named constant called 'line' in the firmware part that prepares macro error messages. That also shouldn't happen.I can't reproduce this with my firmware build, and I haven't yet tested with an older firmware. Can you check what the following macro yields?
G1 X{var.a_line_liner} F600
On my printer this results in the following expected error message. It doesn't say unknown variable 'a_1_liner' or unknown variable 'a_1_1r' or something like that:
Furthermore, can you run the macro(s) without the SBC (don't know if that's possible with your setup) and/or share what
M122
returns? -
@heartleander81 About variables and this script running on a SBC, the documentation does still state that "These are supported in RRF 3.3 running in standalone mode". I'm not sure if this still applies, but it might explain your problems.
-
@izeman said in Pressure advance tuning with conditional G-code:
I wanted to try the code as well, and it doesn't seem to work as expected. The nozzle and bed heat up, and then the heater is turned off again as it starts printing it seems.
I came across this fix in the release notes for RepRapFirmware 3.4.0beta3:
M568 did not allow the P parameter to be omitted
So that explains that!
-
@schmart said in Pressure advance tuning with conditional G-code:
@izeman I'm missing text like 'Axes to be homed' in the console, so I'm assuming you had to modify the code for the topology of your printer.
Yes. Thanks. I inserted my G32 & G29 S1. All axes are homed.
And I now just have to correct the M568 command, as I'm running 3.3 still. And then we'll see -
That come when I make a macro with: G1 X{var.a_line_liner} F600.
My M122
=== Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.4.0beta5 (2021-10-12 13:53:56) running on Duet 3 MB6HC v1.01 or later (SBC mode) Board ID: 08DJM-9P63L-DJ3T8-6J1DA-3SD6P-KV4H9 Used output buffers: 1 of 40 (14 max) === RTOS === Static ram: 151104 Dynamic ram: 66408 of which 240 recycled Never used RAM 132920, free system stack 200 words Tasks: SBC(resourceWait:,0.6%,518) HEAT(notifyWait,0.0%,321) Move(notifyWait,0.0%,351) CanReceiv(notifyWait,0.0%,772) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,339) TMC(notifyWait,8.2%,92) MAIN(running,91.0%,921) IDLE(ready,0.2%,30), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:09:14 ago, cause: software Last software reset at 2021-11-05 11:27, reason: User, GCodes spinning, available RAM 127336, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0043c000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 Step timer max interval 134 MCU temperature: min 30.8, current 32.7, max 43.3 Supply voltage: min 25.1, current 25.2, max 25.2, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0 Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0 Driver 0: pos 0, standstill, SG min/max 0/0, reads 8042, writes 14 timeouts 0 Driver 1: pos 0, standstill, SG min/max 0/0, reads 8041, writes 15 timeouts 0 Driver 2: pos 0, standstill, SG min/max 0/0, reads 8041, writes 15 timeouts 0 Driver 3: pos 0, standstill, SG min/max 0/0, reads 8042, writes 14 timeouts 0 Driver 4: pos 0, standstill, SG min/max 0/0, reads 8042, writes 14 timeouts 0 Driver 5: pos 0, standstill, SG min/max 0/0, reads 8045, writes 11 timeouts 0 Date/time: 2021-11-05 11:37:02 Slowest loop: 24.87ms; fastest: 0.04ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 6 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP* is doing "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 === CAN === Messages queued 4978, received 11016, lost 0, longest wait 2ms for reply type 6049, peak Tx sync delay 5611, free buffers 49 (min 48), ts 2772/2771/0 Tx timeouts 0,0,0,0,0,0 === SBC interface === State: 4, failed transfers: 0, checksum errors: 0 Last transfer: 2ms ago RX/TX seq numbers: 21916/21916 SPI underruns 0, overruns 0 Disconnects: 0, timeouts: 0, IAP RAM available 0x2b7dc Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.4-b5 Code buffer space: 4096 Configured SPI speed: 8000000Hz Full transfers per second: 39.68, max wait times: 45.1ms/18.9ms Codes per second: 0.15 Maximum length of RX/TX data transfers: 3040/832
-
Hi,
thank you for your incredible job... Could you tell me, what the latest version is?
TY, Pierre
-
@medicusdkfz still the first one. Which is working perfectly here