I wrote some GCode to calibrate pressure advance. I wasn't satisfied with how uncertain I was in reading the other ones I found. They usually try various PA values as a sort of gradient, which sounds fine until you have other artifacts confusing the issue. It also requires some effort to convert the measured height into a k value in many cases.

But what most lacked entirely is a "normal" reference adjacent to each test value. I produced this reference by first laying down some lines at a very slow, steady speed, then putting the test lines right next to it. The picture doesn't quite show how much easier this is to read; I think I succeeded in what I was trying to do. Once removed from the bed, you can try various lighting, including back lighting.

Features:

Only 2 layers, so it doesn't take long.
Raft, so it's not sensitive to initial nozzle height.
Controlled by variables set at the beginning of the code.
PA test values separated by configurable space, so you can read just by counting bands.
Configurable number of lines in each band.
Configurable for machines with multiple tools.
Configurable speeds, temperatures, retraction, layer height & width, bed position, and of course, k values for PA.

Pictured is eSun Fire Engine Red PETG on an E3DV6 (my secondary hot end) at 243°, k values from 0.05 (bottom) to 0.25 (top), increasing 0.01 each band. The bottom of each band is 4 lines at 1,200mm/min. The top of each band is 4 lines of 35mm on each side at 1,200mm/min sandwiching 70mm at 6,000mm/min in the center.
In my experience you can use something like this to find the general value, then do another print with fewer bands and more lines per band to confirm the best k value. My best band on this is the 8th from the bottom, so I'm using k=0.12.

This code uses RFF 3.x meta-commands, so it's for Duet hardware. Further, RFF 3.3 and earlier have a bug which doesn't end the lifetime of local variables when a job ends or gets canceled, so you have to do an M999, an emergency stop, or cycle the power between attempts. This will be fixed in RFF 3.4, which has been in beta for several weeks, so it should be out soon.

Please consider this "copylefted".

;	set variables

var StartX = 50
var StartY = 50
var LinesPerTest = 4
var LinesBetweenTests = 4

var TempBed = 74
var TempTool = 243

var ToolNum = 1
var Width = 0.48
var Height = 0.25
var Retract = 1
var Prime = 7.9	;	Before Raft

var PALow = 0.05
var PAHigh = 0.25
var PAIncrement = 0.01

var SpeedRaft = 2000
var SpeedSlow = 1200
var SpeedFast = 6000
var SpeedTravelXY = 9000
var SpeedTravelZ = 1200
var SpeedRetract = 4500

;	Calculated and Utility Variables

var TestCount = 1 + floor((var.PAHigh - var.PALow) / var.PAIncrement + 0.5)
var FilFactor = var.Width * var.Height / (pi * 1.75 * 1.75 / 4)
var PA = var.PALow - var.PAIncrement
var Dist = 0

;	PREPARE

;M42 P1 S1	;	Lights Bright

T{var.ToolNum}
M82	;	Extruder Absolute Mode

;	Heat Bed and set Hot Ends to Standby

M400
M117 "Heat"

M140 S{var.TempBed}				;	set Bed Temp

M568 P{var.ToolNum} S{var.TempTool} A2	;	set Tool Temp
M116 H{var.ToolNum + 1} S1			;	Wait for temp

G4 S12					;	Delay to Allow for Overshoot
M116 H{var.ToolNum + 1} S1		;	Wait for Recovery

M116 H0 S1					;	Wait for Bed

M400
M117 "Home"

G28

;	BEGIN RAFT

M400
M117 "Raft"

;	Go to StartX + Width, StartY

G90	;	Absolute

G92 E0
G0 E{-var.Retract} F{var.SpeedRetract}

G1 X{var.StartX + var.Width} Y{var.StartY} F{var.SpeedTravelXY}
G1 Z{var.Height} F{var.SpeedTravelZ}

G91	;	Relative

;	Prime

G0 E{var.Prime} F{var.SpeedRetract}
G92 E0

var RaftLineCount = floor((floor(139 / var.Width) - 1) / 3) + 1
set var.Dist = (2 * var.TestCount * var.LinesPerTest + var.LinesBetweenTests * (var.TestCount - 1)) * var.Width

while iterations < var.RaftLineCount
	
	;	Draw Raft Line
	
	G0 Y{var.Dist} E{abs(var.Dist) * var.FilFactor} F{var.SpeedRaft}
	G92 E0
	
	;	Break here if last time

	if iterations + 1 >= var.RaftLineCount
		break

	;	Move Over

	G0 X{3 * var.Width} E{3 * var.Width * var.FilFactor} F{var.SpeedRaft}
	G92 E0

	set var.Dist = -var.Dist

G0 E{-var.Retract} F{var.SpeedRetract}	;	Retract

;	BEGIN TEST PATTERN

M400
M117 "Test Pattern"

;	Go to StartX, StartY

G90	;	Absolute

G1 Z{2 * var.Height} F{var.SpeedTravelZ}
G1 X{var.StartX} Y{var.StartY} F{var.SpeedTravelXY}

G91	;	Relative

while iterations < var.TestCount

	;	set PA

	set var.PA = var.PA + var.PAIncrement
	M572 D{var.ToolNum} S{var.PA}
	echo "PA=",{var.PA}
	
	;	Draw Reference Lines

	while iterations < var.LinesPerTest

		G0 E0 F{var.SpeedRetract}		;	Unretract
		G0 X140 F{var.SpeedSlow} E{140 * var.FilFactor}

		G92 E0
		G0 E{-var.Retract} F{var.SpeedRetract}	;	Retract

		G1 Y{var.Width} F{var.SpeedTravelXY}
		G1 X-140 F{var.SpeedTravelXY}

	;	Draw Test Lines

	while iterations < var.LinesPerTest
	
		G0 E0 F{var.SpeedRetract}		;	Unretract

		G0 X35 F{var.SpeedSlow} E{35 * var.FilFactor}
		G0 X70 F{var.SpeedFast} E{105 * var.FilFactor}
		G0 X35 F{var.SpeedSlow} E{140 * var.FilFactor}

		G92 E0
		G0 E{-var.Retract} F{var.SpeedRetract}	;	Retract

		G1 Y{var.Width} F{var.SpeedTravelXY}
		G1 X-140 F{var.SpeedTravelXY}

	;	Move to start of next comparison

	G1 Y{var.LinesBetweenTests * var.Width} F{var.SpeedTravelXY}

;	Finish up

M400
M117 "Done"

G1 Z10 F{var.SpeedTravelZ}

G90					;	Absolute

G1 X10 Y280 F{var.SpeedTravelXY}

G0 E0	 F{var.SpeedRetract}		;	Unretract

@phaedrux The macro creates a few hundred short macros which support a system I developed to control printer settings on a feature level (solid fill, infill, supports, etc.) rather than just a layer level. So, you can set your outer perimeter to use a different fan setting than solid fill, for example.

@dc42 My testing in error. exists() works fine.

@fcwilt I don't really have a theory. But I'm running out of moving parts to replace. So I'm frustrated and uncertain.

@dc42 Perfect, thanks! This worked:

Private Const CENTER_DOT_CHAR As String = "·"

Public Sub Test()
Dim sFilename As String
sFilename = "C:\Users\Don\3D Printing\Software\Slicing\FeatureSettings\TestDot"
Dim fsT As Object
Set fsT = CreateObject("ADODB.Stream")
fsT.Type = 2 'Specify stream type - we want To save text/string data.
fsT.Charset = "utf-8" 'Specify charset For the source text data.
fsT.Open 'Open the stream And write binary data To the object
fsT.WriteText ";special characters: " & String(10, CENTER_DOT_CHAR)
fsT.SaveToFile sFilename, 2 'Save binary data To disk

End Sub

@dc42

Macro "Caller":
var X = 3
M98 P"/macros/Test/Callee"

Macro "Callee":
echo "X="^{var.X}

Result of running Caller:
Error: in file macro line 1 column 17: meta command: unknown variable 'X'

(This is fine with me. As expected.)

@oliof My belts are most definitely not overtensioned. When I loosened them to do the Air Print tensioning, they didn't bounce at all so I stopped and just left them there. I used to have them at about 50Hz, but now they're much looser.

@phaedrux Macro:

https://drive.google.com/file/d/1xkiiMbsnKcUBRHepfGuDxpLkeH_PS8OA/view?usp=sharing

@gloomyandy C++ has something like Pascal has, in that you can create local constructs within a function, and the function becomes the enclosing scope and so is accessible. It's been too long and I don't remember the details.

@fcwilt I see. It wasn't clear to me what an "axis" was in terms of exrtruders. That's good! I can set them individually. I'm happy.

@carlosr I think you have to have the bed reasonably level first. I do:

G28
G32 ; usually a few times
G29

@o_lampe That's my best guess as well, that it would affect the G0 speed even though it's only a retraction. But I was hoping for a certain answer.

@peirof Yes, you have to have firmware 3.x installed. All you need to do is copy the code to a file (I suggest a .gcode extension) and edit the values to the right of the equals sign. So for example, if you use an extrusion width of 0.44 instead of my 0.48, just change var Width = 0.48 to var Width = 0.44.

StartX & StartY set the front left corner's position on your bed. LinesPerTest controls the Y height of each band so you can make it larger (more lines) to see it better; be aware that the bands have double this many lines in them, because there are this many reference lines, and then this many test lines PALow and PAHigh are the starting and ending pressure advance k values to test, and PAIncrement is the amount to change the k value for each band as it moves back (up in the picture). Together these 3 variables control the Y height of the bands. LinesBetweenTests controls the blank space between the bands.

It's up to you to make sure the combination of lines, spaces between bands, and number of bands created by PALow, PAHigh and PAIncrement don't run out of bed space if they start at (StartX, StartY). Each line is "Width" wide (in the Y direction). So the way I have it set up, the print will be 21 bands (PA 0.05 to 0.25 by 0.01 increments) and each of those 21 bands will be 8 lines (4 reference and 4 test), for a total of 168 lines of bands. Between the bands will be a total of 20 spaces of 4 lines, for a total of 80 lines of space. The grand total is 248 lines, each of which is 0.48mm wide, for a total Y height of about 119mm. So my print went from Y=50 to Y = 169.

The lines are 140mm long (in the X direction). So my print went from X=50 to X=190.

TempBed sets your bed temperature and TempTool sets your hot end temperature. ToolNum would be 0 for most people; I was using my secondary hot end. Height is your layer height. Retract is retraction distance; Prime is how much to prime the hot end with filament before starting to print the raft.

The speeds are probably OK as they are; they're in mm/min. The idea is to have a much faster SpeedFast than SpeedSlow, and compare the results to the reference lines in the band, which print at SpeedSlow. You can set the retraction speed, but for this, you're probably OK leaving it alone.

Once the file looks good just upload and print it just as you would with a file your slicer produced. Alternatively, you can upload it as is without printing it and then edit it in the web interface, then print it.

Does that help?

Consider the following code:

M220 S100
G92 E0
G0 E-0.95 F4500

M220 S50
G92 E0
G0 E-0.95 F4500

Will the second retraction be half as fast or the same speed? That is, does M220 apply to extruder speed by itself, as in a retraction?

It's logical that it would, but it would seem to have more utility if it doesn't. If retraction is carefully tuned (and you're not using firmware retraction), then slowing down the feed rate would screw it up, possibly badly.

But the documentation doesn't make it clear. I'm guessing that means it DOES affect it. I guess that means using firmware retraction would be better.

I wrote some GCode to calibrate pressure advance. I wasn't satisfied with how uncertain I was in reading the other ones I found. They usually try various PA values as a sort of gradient, which sounds fine until you have other artifacts confusing the issue. It also requires some effort to convert the measured height into a k value in many cases.

But what most lacked entirely is a "normal" reference adjacent to each test value. I produced this reference by first laying down some lines at a very slow, steady speed, then putting the test lines right next to it. The picture doesn't quite show how much easier this is to read; I think I succeeded in what I was trying to do. Once removed from the bed, you can try various lighting, including back lighting.

Features:

Only 2 layers, so it doesn't take long.
Raft, so it's not sensitive to initial nozzle height.
Controlled by variables set at the beginning of the code.
PA test values separated by configurable space, so you can read just by counting bands.
Configurable number of lines in each band.
Configurable for machines with multiple tools.
Configurable speeds, temperatures, retraction, layer height & width, bed position, and of course, k values for PA.

Pictured is eSun Fire Engine Red PETG on an E3DV6 (my secondary hot end) at 243°, k values from 0.05 (bottom) to 0.25 (top), increasing 0.01 each band. The bottom of each band is 4 lines at 1,200mm/min. The top of each band is 4 lines of 35mm on each side at 1,200mm/min sandwiching 70mm at 6,000mm/min in the center.
In my experience you can use something like this to find the general value, then do another print with fewer bands and more lines per band to confirm the best k value. My best band on this is the 8th from the bottom, so I'm using k=0.12.

This code uses RFF 3.x meta-commands, so it's for Duet hardware. Further, RFF 3.3 and earlier have a bug which doesn't end the lifetime of local variables when a job ends or gets canceled, so you have to do an M999, an emergency stop, or cycle the power between attempts. This will be fixed in RFF 3.4, which has been in beta for several weeks, so it should be out soon.

Please consider this "copylefted".

;	set variables

var StartX = 50
var StartY = 50
var LinesPerTest = 4
var LinesBetweenTests = 4

var TempBed = 74
var TempTool = 243

var ToolNum = 1
var Width = 0.48
var Height = 0.25
var Retract = 1
var Prime = 7.9	;	Before Raft

var PALow = 0.05
var PAHigh = 0.25
var PAIncrement = 0.01

var SpeedRaft = 2000
var SpeedSlow = 1200
var SpeedFast = 6000
var SpeedTravelXY = 9000
var SpeedTravelZ = 1200
var SpeedRetract = 4500

;	Calculated and Utility Variables

var TestCount = 1 + floor((var.PAHigh - var.PALow) / var.PAIncrement + 0.5)
var FilFactor = var.Width * var.Height / (pi * 1.75 * 1.75 / 4)
var PA = var.PALow - var.PAIncrement
var Dist = 0

;	PREPARE

;M42 P1 S1	;	Lights Bright

T{var.ToolNum}
M82	;	Extruder Absolute Mode

;	Heat Bed and set Hot Ends to Standby

M400
M117 "Heat"

M140 S{var.TempBed}				;	set Bed Temp

M568 P{var.ToolNum} S{var.TempTool} A2	;	set Tool Temp
M116 H{var.ToolNum + 1} S1			;	Wait for temp

G4 S12					;	Delay to Allow for Overshoot
M116 H{var.ToolNum + 1} S1		;	Wait for Recovery

M116 H0 S1					;	Wait for Bed

M400
M117 "Home"

G28

;	BEGIN RAFT

M400
M117 "Raft"

;	Go to StartX + Width, StartY

G90	;	Absolute

G92 E0
G0 E{-var.Retract} F{var.SpeedRetract}

G1 X{var.StartX + var.Width} Y{var.StartY} F{var.SpeedTravelXY}
G1 Z{var.Height} F{var.SpeedTravelZ}

G91	;	Relative

;	Prime

G0 E{var.Prime} F{var.SpeedRetract}
G92 E0

var RaftLineCount = floor((floor(139 / var.Width) - 1) / 3) + 1
set var.Dist = (2 * var.TestCount * var.LinesPerTest + var.LinesBetweenTests * (var.TestCount - 1)) * var.Width

while iterations < var.RaftLineCount
	
	;	Draw Raft Line
	
	G0 Y{var.Dist} E{abs(var.Dist) * var.FilFactor} F{var.SpeedRaft}
	G92 E0
	
	;	Break here if last time

	if iterations + 1 >= var.RaftLineCount
		break

	;	Move Over

	G0 X{3 * var.Width} E{3 * var.Width * var.FilFactor} F{var.SpeedRaft}
	G92 E0

	set var.Dist = -var.Dist

G0 E{-var.Retract} F{var.SpeedRetract}	;	Retract

;	BEGIN TEST PATTERN

M400
M117 "Test Pattern"

;	Go to StartX, StartY

G90	;	Absolute

G1 Z{2 * var.Height} F{var.SpeedTravelZ}
G1 X{var.StartX} Y{var.StartY} F{var.SpeedTravelXY}

G91	;	Relative

while iterations < var.TestCount

	;	set PA

	set var.PA = var.PA + var.PAIncrement
	M572 D{var.ToolNum} S{var.PA}
	echo "PA=",{var.PA}
	
	;	Draw Reference Lines

	while iterations < var.LinesPerTest

		G0 E0 F{var.SpeedRetract}		;	Unretract
		G0 X140 F{var.SpeedSlow} E{140 * var.FilFactor}

		G92 E0
		G0 E{-var.Retract} F{var.SpeedRetract}	;	Retract

		G1 Y{var.Width} F{var.SpeedTravelXY}
		G1 X-140 F{var.SpeedTravelXY}

	;	Draw Test Lines

	while iterations < var.LinesPerTest
	
		G0 E0 F{var.SpeedRetract}		;	Unretract

		G0 X35 F{var.SpeedSlow} E{35 * var.FilFactor}
		G0 X70 F{var.SpeedFast} E{105 * var.FilFactor}
		G0 X35 F{var.SpeedSlow} E{140 * var.FilFactor}

		G92 E0
		G0 E{-var.Retract} F{var.SpeedRetract}	;	Retract

		G1 Y{var.Width} F{var.SpeedTravelXY}
		G1 X-140 F{var.SpeedTravelXY}

	;	Move to start of next comparison

	G1 Y{var.LinesBetweenTests * var.Width} F{var.SpeedTravelXY}

;	Finish up

M400
M117 "Done"

G1 Z10 F{var.SpeedTravelZ}

G90					;	Absolute

G1 X10 Y280 F{var.SpeedTravelXY}

G0 E0	 F{var.SpeedRetract}		;	Unretract

@generisi I suspect not, because the function takes a variable name (no quotes) as an argument, not a string. I could imagine it being useful, though.

@fcwilt I actually don't especially like how big M291 messages are. M117 is almost what I want. It seems to respect things you're in the process of doing on the PanelDue, and it shows both on the PanelDue and on the web interface. But I don't have the ability to make it appear in the console log (there's probably a way to do that with another command), and the messages boxes often don't hang around long enough (not that I want to have to clear them manually, but it varies, and sometimes it's a only few seconds). The display of layers includes the layer number and Z coordinate, and that can show on the PanelDue (which I think doesn't show the layer number, at least on most screens) and the web interface (which I think shows both on most screens but not all).

But most often I display messages during the startup script, before a skirt starts printing. Those aren't layer numbers or heights. The info varies, but mostly tells you what it's currently doing.

It seems like every message option has some of the features I want but none has them all. Any that interferes with babystepping is no good. Any that doesn't show on the PanelDue doesn't quite do it. Any that doesn't always show on the web interface isn't that great. And not logging to the web interface console doesn't keep a record after the message disappears. Maybe I'm missing something or being picky. It's not a huge big deal, but I gather the only options are M117, M118 and M291.

I'm not that fond of my CR-10s Marlin, but it does have a dedicated message line at the bottom that's very good (though short). A message stays there until cleared in code and doesn't interrupt anything in order to display. Something equivalent plus logging so I can look through past messages would be ideal. That's the kind of thing.

@fcwilt To keep track of what layer I'm on.

@fcwilt Using them?

@fcwilt Mostly layer counts after things have started.