Multiple compile errors

[rongoodman303]

Bug Description

Configuring for LK5 Pro.

1) In the support LKx Pro branch, in the default/example configuration.h, line 150, #define SERIAL_PORT 0 generates a compile error. Changing the 0 to -1 or 1 also generates compile errors. Changing it to 2 compiles OK, but may not be a good value. Need better comments on how to properly set serial ports for these printers and their screens, and appropriate default values in configuration.h for this project.

2) On my LK5 Pro, and probably other machines with the same Longer Kit board, the X, Y and Z drivers are TMC2208, not A4988. You may want to make appropriate changes in the Stepper Drivers section. There may be other Marlin and Gcode features available for the TMC2208 drivers, but that is not critical for now.

3) Using the configuration.h in this bug report, review my configuration changes for LK5, serial port, stepper drivers, etc., and attempt to compile. Note multiple compile errors associated with lgtdwlcd.cpp, as seen in the jpg file attached.

My Configurations

Required: Please include a ZIP file containing your Configuration.h a RGConfigs.zip and Configuration_adv.h files.

Steps to Reproduce

1. Configure for LK5 Pro and leave all serial port defaults as they are in the branch's default configuration.h
2. Compile and observe errors.

Expected behavior: Should compile clean

Actual behavior: Multiple compile errors.

Additional Information

See attached jpg of compile errors after I fixed everything I had any control over in the configuration files.

[LONGER3D]

the screenshot image above shows the target device is STM32F103 for LKx series rather than mege2560 fro LKx Pro series. so please checkout the git branch you download. below is the link for LKxPro branch. https://github.com/LONGER3D/Marlin2.0-lgt

[NeutronKEKS]

@rongoodman303 Do you have a solution? Have the same problem.

[rongoodman303]

LONGER3D: That is exactly the branch I downloaded. I changed only the one parameter in Configuration.h for LK5_PRO. In lines 102/103, changed to:

// #define LK4_PRO

define LK5_PRO

After that, in the PIO edtor, the correct bopard for LK5_PRO is highlighted, indicating that it was properly selected:

#define MOTHERBOARD BOARD_LONGER_LGT_KIT_V1       // motherboard for LKxPro and LK5

And also properly highlighted:

elif ENABLED(LK5_PRO)

define CUSTOM_MACHINE_NAME "Longer3D LK5 Pro"

The ABM screen:

Then used AutoBuild Marlin to compile, and got the errors I reported. Platform IO gives me no other option for the build than STM32F103.

After the build attempt, looking at some of the auto generated files: and:

So it looks like, despite what the ABM screen says, it did select the correct motherboard and environment based on how Configuration.h was setup, and the failure to do a clean build is something else going on in the Marlin environment, with some kind of configuration file that I have no control over, that is wrong, because I did not change anything else but the lines that select LK5_PRO.

[rongoodman303]

I figured out how to get the correct build environment to display and compile in Autobuild Marlin. Apparently it picks its information up from the first occurrence of a #define MOTHERBOARD that is not a comment. And it uses that information to pick Board, Pins, Architecture and Environment values for the build. This makes it a critical bug.

However, by simply switching out the #ifany logic for picking a motherboard to have the BOARD_LONGER_LGT_KIT_V1 printers listed first, it picked the correct info to display and build with, and compiled with no errors.

So the permanent fix in Configuration.h, where motherboard is selected, is to make the user pick one instead of using logic to do so, and provide comments as to how to do that. :

Replace lines 181-187 with the following:

// Choose the name from boards.h that matches your setup and uncomment that board name line // For LK1_PRO, LK4_PRO, LK5_PRO, LK5 uncomment following:

define MOTHERBOARD BOARD_LONGER_LGT_KIT_V1 // motherboard for LKxPro and LK5

// For U20, U30, U20_PLUS, CUBE2, LK1, LK1_PLUS, LK2, LK4, uncomment following //#define MOTHERBOARD BOARD_LONGER3D_LK // motherboard for LKx(except for LK5), CUBE2

By the same logic, the #Ifdef logic for selecting a CUSTOM_MACHINE_NAME confuses Autobuild Marlin and it always displays Alfawise U20, the first uncommented line is is looking for, despite the surrounding logic. This is not as serious a problem as the motherboard situation, because the proper custom machine name is displayed when/where it should be. But it is still confusing to the user/developer working on the configurations.

[NeutronKEKS]

Thanks that helped. But when I define the TMC drivers the printer won't work. It gets stuck in some sort of loop. With the A4988 it works.

[rongoodman303]

I and others have reported this and similar issues to the MarlinFirmware/AutobuildMarlin folks, and they are going to look at getting ABM to work smarter and properly with logical selections for MOTHERBOARD and CUSTOM_MACHINE_NAME so these kinds of Configuration.h files with logical selections for those critical keywords will work as intended. Until then, the workaround I posted in my earlier comment is the only way to get it to work as intended.

See: https://github.com/MarlinFirmware/AutoBuildMarlin/issues/51

[DanielJMorel]

It is 04/08/23 and I still am not able to download a good build from any of the Longer LK5 Pro downloads from any of the Github Repositories. I have tried several over the past week and none create a clean build. You would think that after all this time, Longer would get their act together and post a clean Marlin version for their machines. This is ridiculous. All I want to do is enable the stepper drivers that came stock on the LONGER_LGT_KIT_V1 so that I can enable Linear Advance and Input Shaping. I even purchased an SKR 1.4 Turbo with TMC2209 stepper drivers which compiles cleanly however I can't get the LCD Touchscreen to work. Very Frustrating!!! I have seen several post in my searches where others are experiencing similar issues. Even the examples provided with the Latest Marlin release do not compile cleanly. Does anyone test these or are they just posted without any testing? Regarding the touchscreen: why would the example files for Longer LK5 pro call out #define CR10_STOCKDISPLAY (which doesn't work) when there is //#define LONGER_LK_TFT28 commented out under Graphical TFT's? Also, this is for a smaller touchscreen. Where is the one for the Longer LK5? should be one for a 4.3" touchscreen. Any help on getting this to work would be greatly appreciated.

[jelly-belly]

I'm able to compile the official and the Longer copies of Marlin 2 without error and flash them successfully, but once flashed, the screen just reboots every 5 seconds, and I can't establish a serial connection to the board. Thanks to your post, Daniel, I was able to just get my printer operational again by leaving everything at default on the Longer version, including the wrong stepper driver. I'm no expert (the sum of my experience was playing with an UNO years ago) and I could be off track, but from looking at the only available motherboard diagram, and all the pins.h files, the defined pins often don't seem to even correspond to the 2560's pins. The pins_LONGER3D_LKx_PRO.h has the correct pins, including for the display, but it's not even in Longer's LK5 Marlin zip, it's in the official Marlin in the RAMPS folder. For example, the filament runout is connected to A13 on the board, pins_LONGER3D_LK.h defines it as PC0/pin15, pins_LONGER3D_LKx_PRO.h calls it pin 2. The 2560 datasheet lists PC0 as A8, and A13 as PC5. Like I said, I'm in over my head, as apparently leaving the Longer configuration.h as-is works. At stock, this printer makes beautiful prints, and can go fairly fast, but it's pretty disappointing not to be able to pay around customizing it. I guess when I order the SKR I'll have to order a display too. This is my first printer, but the first thing I came to realize is that the touchscreen display severely limits your ability to interact with Marlin, something no reviews ever mentioned, so it's no great loss if it has to go.