-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] (STM32 UUID Never Replaces Default UUID) #26698
Comments
Please give https://github.com/ellensp/Marlin/tree/stm32-uuid a try You can see what I changed here bugfix-2.1.x...ellensp:Marlin:stm32-uuid Sadly I cannot test on real hardware, don't have a OPULO_LUMEN though I would like to change that... But I did make it work under the marlin simulator, so it is 3/4 tested. If this works as you think it should ill turn this in a pr for further scrutiny |
oh cool @ellensp i love how you did that!! I'll see if I can test on real hardware today and report back with results. thank you so much! |
@ellensp Just tested this across a couple LumenPnP REV04 motherboards, works perfectly! Maybe adding a commented out |
With a PR created to address the issue we can close this one. Thanks for the report! |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Did you test the latest
bugfix-2.1.x
code?Yes, and the problem still exists.
Bug Description
Hey there!
I believe I found a bug with how M115 handles reporting the machine's UUID when trying to pull an STM32's UUID from the chip itself, not from configuration.
This feature was added about a year ago (and starts here in the M115.cpp file). The intention with the feature was to replace Marlin's config-defined UUID with the one found in the STM32 itself if 1) the
HAS_STM32_UID
flag is set in the board's pins file, and 2) theMACHINE_UUID
is not already defined.However, due to this #ifndef in
langauge.h
, that second condition never happens because we're always setting aMACHINE_UUID
. I was able to get this feature to work by simply commenting out this#ifndef
, but I'm assuming it's there for a reason!I'd love to patch this myself, I'm just curious about how y'all think it's best to fix before submitting a PR. I had two thoughts:
&& !defined(MACHINE_UUID)
) for using the STM32 UUID and just printing out a second UUID and renaming that serial print line "STM32 UUID" or something so it doesn't step on the toes of the existing UUID logic, but I start getting bugs with theprint_hex_byte()
function not being defined. I like this approach because a user-defined UUID doesn't get removed if the STM32 UUID is enabled.MACHINE_UUID
to equalDEFAULT_MACHINE_UUID
ifHAS_STM32_UID
is not defined as well.Would love to know what y'all think would be the best approach! Once I know what makes sense, let me know and I'll file a PR. I understand this is not super widely available hardware, so I'm happy to run any tests on my hardware and validate a fix.
Bug Timeline
Not sure, might have been from feature introduction.
Expected behavior
I expected that
M115
would report the STM32 UUID instead of the Default UUID when theHAS_STM32_UID
flag is set in the board's pins file, and thatMACHINE_UUID
is not set in the configuration file.Actual behavior
Instead, it reports the Default UUID value:
cede2a2f-41a2-4748-9b12-c55c62f367ff
.Steps to Reproduce
OPULO_LUMEN_REV4
with#define HAS_STM32_UID
in the pins file, and#define MACHINE_UUID "00000000-0000-0000-0000-000000000000"
commented out in Configuration.h. Flash onto LumenPnP REV04 motherboard (or any other STM32 board with the same chipset).M115
to Marlin.Version of Marlin Firmware
bugfix-2.1.x
Printer model
Opulo LumenPnP v3.1
Electronics
Stock LumenPnP REV04 Motherboard
LCD/Controller
None
Other add-ons
None
Bed Leveling
None
Your Slicer
None
Host Software
None
Don't forget to include
Configuration.h
andConfiguration_adv.h
.Additional information & file uploads
Archive.zip
The text was updated successfully, but these errors were encountered: