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 Upgrading to 3.x is on my list. I didn't know it had calls with parameters. And thanks for the insight into the specifics about the command's "deprecation". It appears to be working nicely for my purposes right now.

Thanks! This is great stuff! I'm really enjoying it.

@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

@ryanp Check the reliability of the wiring from your BLTouch. I found 2 only occasionally intermittent wiring problems that caused me no end of problems. The intermittent nature of the problems had me confused for a very long time. What clued me in was that for a while, the probe started failing to probe at one corner of the bed, every time. That said to me it was the wiring being moved. Sure enough, that was the big problem.

@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

@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 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.

@diamondback Yes, arrays as parameters will be wonderful. I've written enough mini-compilers to know how hard the implementation of arrays will be though.

For arbitrary letters, I wonder if it might be useful to establish some kind of convention for how to do common things like bed area. Say, use ABCD and dereference parameters into variables at the beginning of the macro:

var XMin = param.A
var XMax = param.B
var YMin = param.C
var YMax = param.D

This has the disadvantage that if we're used to this usage those letters wouldn't be available for concepts that begin with them. But I don't know how to predict that. An alternative would be for X, Y & Z to be maximums and M, N and O. This choice has the disadvantage of using letters which can't be used in custom G-code or M-code commands, but starting with "M" is easily remembered as "Minimum". Or maybe, A, B and C would be better.

Or, maybe:

var XMax = floor(param.X / 1000)
var XMin = param.X - var.XMax * 1000
var YMax = floor(param.Y / 1000)
var YMin = param.Y - var.YMax * 1000

is a little more obscure but only uses X and Y. The call would look like:

M98 P"MacroFile" X{var.XMin + var.XMax * 1000} Y{var.YMin + var.YMax * 1000)

Or, maybe in preparation for retrofitting when array parameters become available, use variable names X0, X1, Y0 and Y1 (will array subscripts be zero based or 1 based?)

I'm open to anything that makes sense to the most people.

@donstauffer I did think of a way to "cheat": Multiply the Max value by 1,000 and add them together. But that's not all that much more readable than arbitrary letters. When arrays become available, if they can be passed as macro parameters, that might be somewhat better, although again, you'd have to know the "magic numbers" for what subscripts mean what. In either case you could define a variable inside the macro and assign to it, this giving a good name to each at the beginning of the macro. But overall, none of this is particularly syntactically "sugary."

This is a style question, but the answer may involve a feature I'm unaware of.

If I want to call a macro with a pair of coordinates, I can do something like:

M98 P"MacroFile" X{var.XCoord} Y{var.YCoord}

Then in the macro, I just access them using param.X and param.Y.

If I have ranges of coordinates, as in defining a bed area, I'm not aware of any way except choosing arbitrary letters:

M98 P"MacroFile" X{var.XMin} A{var.XMax} Y{var.YMin} B{var.YMax}

I could concatenate min and max as strings with a colon between them, but I know of no way to separate them again inside the macro.

What's the best way to handle this?

@adrian52 I didn't even know there WAS heater compensation for the cooling fan. How do you control it?

My Simplify3D 4.1.2 profile, working with dual extruders on a Railcore running a Duet 2 WiFi.

The scripts use RRF 3.3 features. They also use some of my macros, which I put in the second link. In the Starting Script, you'll want to change var ExtruderCount = 1 to var ExtruderCount = 2 to use both extruders. I recommend in many cases using a Prime Pillar, at least up to the the height where the last tool change happens. The tool change script uses the Prime Pillar to catch ooze during the change.

Let me know if you discover any bugs or improvements.

https://drive.google.com/file/d/0B6D7F182ZnZbRmppRWRDeVR6dVE/view?usp=sharing&resourcekey=0-cfeny5SjHnYvMEtxg9Eh2w

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

@dc42 Unfortunately, adding a daemon.g file with a loop didn't fix it for me. I have a music macro called from my S3D ending script. If I run the macro while no job is running it works fine. But almost always, at the end of a print, the third note doesn't sound. Not a big deal, but I don't know why it does this.

@fcwilt Wow, I put 3.4 when I meant 3.3. I have no experience with 3.4. But 3.3 is great!

@phaedrux I was looking for confirmation that that's what 401% is supposed to mean. I'm sure it's not actually extruding 4 times the filament. But to figure out what's wrong with the sensor, I need to interpret that number correctly. I was also expressing surprise that, if I AM interpreting it correctly, it would be reporting MORE filament use rather than less (which I'd expect from simple slipping). If I'm understanding the M591 results correctly.

@gtaman I noticed the same thing.

@t3p3tony I was only doing M118, which usually shows on the web interface.