Capturing accelerometer data on individual printers has been a huge boon for quantifying the effect that changes to a machine can have on how it’s mechanically behaving, but I’ve noticed some issues with the way the calibrate_shaper script presents the data that can be confusing for users.
The fundamental issue is that the Y axis is scaled relative to the data in a particular capture. This makes it difficult to compare plots run-to-run and can be misleading, suggesting problems that aren’t actually there.
An obvious example of this would be a case where the user makes a change that reduces peak resonance. Say the machine starts with, e.g., a clear primary peak at 45Hz with a magnitude of 8k with a smaller peak at 120Hz / 2K. If a change is made to the machine that reduces that primary peak to 4K, the relative scaling can make it appear that there’s suddenly been a huge increase in resonance at the higher frequencies even though nothing changed there. Helping out a user that was pulling their hair out going down the rabbit hole with this type of scenario is what prompted me to take a look at this.
The other issue is that the Y axis is scaled based on a unitless value presented in scientific notation. This means that plots not only change relative scale, but can shift by an order of magnitude. While the scaling is presented at the top left of the plot, it’s extremely easy to overlook and I’d wager that most users have never noticed it at all.
I ran plots on a sample data set with a couple of small changes to demonstrate this here.
The unit magnitude is addressed simply by changing:
ax.ticklabel_format(axis='y', style='scientific', scilimits=(0,0))
To style='plain'
.
I don’t see very much downside to doing this beyond the plots becoming slightly wider. This helps prevent silent unit shifts from providing a misleading picture of how the machine is behaving. This seems like an obvious improvement to me.
Normalizing the Y axis was similarly done in a quick and dirty manner – to be clear, I do not think this is the correct approach for the general case script but was done here to visually demonstrate the issue. In this case, I normalized Y scaling to 1e5 by adding the line ax.set_ylim(0,100000)
.
This one’s a tougher nut to crack since overall resonance can vary so much between printers/axes, so a one size fits all approach won’t work. Setting the scaling to 1e5 works for the data set here, but on a printer with less resonance, would crunch the graph to the point of being indecipherable.
My initial thought is that a script parameter that allows the user to specify a normalization scale might work, i.e., the user could tell the script to normalize to 1e4, 1e5, etc based on their printer, but I’m not 100% sure whether that’s the best approach.
At any rate, this is something I’ve seen trip people up a number of times and being able to generate normalized plots would certainly add value to the accelerometer as a tool. I thought I’d put this out there to see what thoughts folks have on how this could best be done.