Closed MadScienzzz closed 2 years ago
Send: BEDLEVELVISUALIZER
It seems the @ is getting stripped off the command somehow. Do you happen to have the creality cloud plugin installed?
I also don't trust and can't really support creality firmware. It's the bane of the 3d printing world. I recommend upgrading or using InsanityAutomation's Marlin fork/precompiled binaries.
Send: BEDLEVELVISUALIZER
It seems the @ is getting stripped off the command somehow. Do you happen to have the creality cloud plugin installed?
Not sure what that is - I compiled the firmware from GitHub and using VS. It was working fine up until today. I last used the printer on Monday and there were no changes made to cause this, but something obviously has.
I checked to see if there were any conflicting plugins (I hadn't added anything in since it was working) but disabled most of them anyway.
Okay, just looked at Creality Cloud - definitely do not have that installed! I saw someone else literally within the last couple of hours had a similar issue resolved by removing that.
I'll have a look at those binaries, but I'm not sure why this has happened as nothing has really changed....
Not sure what could have caused this either, I haven't released a new version since January. , One thing that does stand out a bit is the order of commands as copied above from terminal tab. It looks like homing is happening after the BEDLEVELVISUALIZER flag is being sent, which would cause problems. It needs to occur right before the G29 command, the way it's configured in the plugin. To truly debug, enable OctoPrint's serial logging in the serial connection settings and run through the process. Then share your serial.log file from the logging section of OctoPrint. Also, check octoprint.log for any errors as well.
Couple of things that you might want to try. Remove the T
from the G29 command, and you potentially might want to enable the option to remove row labels based on your G29 response. Just can't remember if I'm detecting that internally or not.
Would make a single change at a time and test with serial logging enabled and we can get a better picture of what's happening.
Not sure what could have caused this either, I haven't released a new version since January. , One thing that does stand out a bit is the order of commands as copied above from terminal tab. It looks like homing is happening after the BEDLEVELVISUALIZER flag is being sent, which would cause problems. It needs to occur right before the G29 command, the way it's configured in the plugin. To truly debug, enable OctoPrint's serial logging in the serial connection settings and run through the process. Then share your serial.log file from the logging section of OctoPrint. Also, check octoprint.log for any errors as well.
Couple of things that you might want to try. Remove the
T
from the G29 command, and you potentially might want to enable the option to remove row labels based on your G29 response. Just can't remember if I'm detecting that internally or not.Would make a single change at a time and test with serial logging enabled and we can get a better picture of what's happening.
Thank you very much for your reply and advice. I'm going to implement your suggestions shortly and will report back with findings. If still not working, I'll enable serial debug and paste results here also.
Also having this issue. Putting "@BEDLEVELVISUALIZER" into terminal manually I get ..
Send: BEDLEVELVISUALIZER Recv: echo:Unknown command: "BEDLEVELVISUALIZER" Recv: ok
After functioning fine for months, my non-creality marlin E3P began having the issues described above after a couple of weeks of inactivity. The issues seem to be tied to the GCODE MACROS plugin, and the Visualizer plugin now works fine for me with the GCode plugin disabled.
According to this issue there should be no conflict with GCODE Macros version 1.1.1+.
https://github.com/cp2004/OctoPrint-GCodeMacros/issues/3
I do see there was an update to that plugin 6 days ago though, so maybe there could be a regression @cp2004?
I've reported the bug on that plugin's repo and where I think the issue is occurring.
Ah - you all beat me to it!
I created a whole new server instance on anothe sdcard (in case my os was broken) and went through the plugins and found it to be that one! I must have enabled it and not looked at bedvis for a while after!
Many thanks for identifying this! I'm up and running with my favourite plugin again!
GCODE Macros has been patched now on the main branch, but a release hasn't been put out. Going ahead and closing since we know what the cause is.
Master is basically my development branch there, but I will try and get it out this evening.
Should now be fixed with 1.2.0 of the GCode Macros plugin.
thank you for these posts, this was my problem
Describe the bug Bed mesh does not complete - Sits at "Please wait, retrieving current mesh."
This was working fine for me, up until a few days ago. I don't think anything was changed in that time....
Expected behavior Complete bed mesh - with chart displayed
Debug Log [2022-07-07 21:17:22,677] DEBUG: Canceling mesh collection per user request [2022-07-07 21:17:22,678] DEBUG: Mesh data collected prior to cancel: [2022-07-07 21:17:22,678] DEBUG: [] [2022-07-07 21:17:22,678] DEBUG: Mesh data after clearing: [2022-07-07 21:17:22,678] DEBUG: []
Screenshots
Firmware and Version Marlin 2.0.9.3
Bed level output: [...] Send: BEDLEVELVISUALIZER Send: M140 S60 Recv: echo:Unknown command: "BEDLEVELVISUALIZER" Recv: ok Recv: ok Send: M117 Homing all axes Recv: ok Send: G28 [...] Recv: ok Send: M420 S0 Recv: echo:Bed Leveling OFF Recv: echo:Fade Height 10.00 Recv: ok Send: M117 Heating the bed Recv: ok Send: M190 S60 [...] Recv: ok Send: M300 S1000 P500 Recv: ok Send: M117 Creating the bed mesh levels Recv: ok Send: M155 S30 Recv: ok Send: BEDLEVELVISUALIZER Send: G29 T Recv: echo:Unknown command: "BEDLEVELVISUALIZER" Recv: ok Send: M155 S3 [...] Recv: Bilinear Leveling Grid: Recv: 0 1 2 3 Recv: 0 +0.283 +0.156 +0.184 +0.361 Recv: 1 +0.227 +0.132 +0.121 +0.252 Recv: 2 +0.212 +0.144 +0.090 +0.221 Recv: 3 +0.345 +0.215 +0.136 +0.261 Recv: [...] Recv: ok Recv: ok Send: M140 S0 Recv: ok Send: M500 Recv: echo:Settings Stored (649 bytes; crc 11493) Recv: ok Send: M300 S440 P200 Recv: ok Send: M300 S660 P250
Output from M115: Send: M115 Recv: FIRMWARE_NAME:Marlin 2.0.9.3 (Jun 20 2022 23:26:53) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:Ender-5 Pro 4.2.7 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff Recv: Cap:SERIAL_XON_XOFF:0 Recv: Cap:BINARY_FILE_TRANSFER:0 Recv: Cap:EEPROM:1 Recv: Cap:VOLUMETRIC:1 Recv: Cap:AUTOREPORT_POS:0 Recv: Cap:AUTOREPORT_TEMP:1 Recv: Cap:PROGRESS:0 Recv: Cap:PRINT_JOB:1 Recv: Cap:AUTOLEVEL:1 Recv: Cap:RUNOUT:1 Recv: Cap:Z_PROBE:1 Recv: Cap:LEVELING_DATA:1 Recv: Cap:BUILD_PERCENT:0 Recv: Cap:SOFTWARE_POWER:0 Recv: Cap:TOGGLE_LIGHTS:0 Recv: Cap:CASE_LIGHT_BRIGHTNESS:0 Recv: Cap:EMERGENCY_PARSER:0 Recv: Cap:HOST_ACTION_COMMANDS:1 Recv: Cap:PROMPT_SUPPORT:0 Recv: Cap:SDCARD:1 Recv: Cap:REPEAT:0 Recv: Cap:SD_WRITE:1 Recv: Cap:AUTOREPORT_SD_STATUS:0 Recv: Cap:LONG_FILENAME:0 Recv: Cap:EXTENDED_M20:0 Recv: Cap:THERMAL_PROTECTION:1 Recv: Cap:MOTION_MODES:0 Recv: Cap:ARCS:1 Recv: Cap:BABYSTEPPING:1 Recv: Cap:CHAMBER_TEMPERATURE:0 Recv: Cap:COOLER_TEMPERATURE:0 Recv: Cap:MEATPACK:0 Recv: Cap:CONFIG_EXPORT:0 Recv: ok Send: M155 S2 Recv: ok [...]