What is the problem?
One of my plugin users is experiencing an unknown command error with BedLevelVisualizer, and I can't seem to reproduce this. See here. My plugin just grabs the commands to send from settings and splits it on "\n" and sends to the printer using OctoPrint.control.sendGcode as seen in this function. Seems to only happen after first powering on the printer. Is this a firmware/communication issue?
What did you already try to solve it?
Tried stripping out extraneous blank commands being sent to printer from the split array.
Additional information about your setup
See the issues post here
So... what's the T after the G29 command? That one is new to me.
What if you don't have UBL?
I send an M115 to my printer via OctoPrint's Terminal tab:
My Marlin appears to be 1.1.0+ so in theory, it could have UBL. Curious, I send a G29 T and it's making noise in there. It's not doing a 3-point but a standard 9-point leveling routine.
Pretty sure that UBL has to be activated and then that condition saved. There are two camps on this of course: pro-UBL and i-will-stab-your-eyes-out-if-you-change-my-printer's-leveling.
G29 T in the latest Marlin branches are for displaying the topography report in theory. The plugin works with all different types of leveling options, you don't have to have UBL for the plugin to work. You set the GCODE yourself in settings, so whatever you use to generate auto-bed leveling, have at it, but in order for the plugin to graph it has to be able to get a report back from the firmware. The most recent version of the plugin changes it up a little to not require a Data Collector Flag to be entered and instead uses a built in custom GCODE command @BEDLEVELVISUALIZER to instruct the plugin to start collecting data. So if you add that just prior to whatever command you use to report the topography it should work.
Based on some investigation, it seems this issue is more than likely firmware related with the user.
I'd say... have them do an M115 and verify that it's at least 1.1.0+