3D Printer yet?

[xrunner]

I have to admit... I WAS hoping for the thing to just work, as the DIGGRO is already configured for serial control. I tried every baudrate available in the menu and swapping TX & RX in case it was labeled wrong but no joy; it wouldn't even finish booting then. 

I'll have to see if I can find any documentation; it appears the FW has been revised as it is dated April 2020. I'm pretty sure the 6-Pin header is AVR-ICSP; I'm hoping the 8-pin is most of the pins for EXP-1 but that will probably require tracing out to the CPU.

I had to muck around with serial port settings in FW before my touch screen would communicate (the default settings would not work). I'm talking about Marlin FW for the BTT SKR Mini. Here's my serial settings for what it's worth -

/**
 * Select the serial port on the board to use for communication with the host.
 * This allows the connection of wireless adapters (for instance) to non-default port pins.
 * Serial port -1 is the USB emulated serial port, if available.
 * Note: The first serial port (-1 or 0) will always be used by the Arduino bootloader.
 *
 * :[-1, 0, 1, 2, 3, 4, 5, 6, 7]
 */
#define SERIAL_PORT -1

/**
 * Select a secondary serial port on the board to use for communication with the host.
 * :[-1, 0, 1, 2, 3, 4, 5, 6, 7]
 */
#define SERIAL_PORT_2 2

/**
 * This setting determines the communication speed of the printer.
 *
 * 250000 works in most cases, but you might try a lower speed if
 * you commonly experience drop-outs during host printing.
 * You may try up to 1000000 to speed up SD file transfer.
 *
 * :[2400, 9600, 19200, 38400, 57600, 115200, 250000, 500000, 1000000]
 */
#define BAUDRATE 115200

[mnementh]

Yeah, remember that this port is already configured in Marlin; I unplugged the original TS and swapped the pins around to match the BTT serial input. Should be the only thing that needs configuring is baudrate; but I see lots of posts from people head-scratching because no matter what they do, they keep getting "No Printer Connected!" on the screen.

My guess is that there must be something it expects to see in the datastream... or maybe just the refresh rate... and it's not happy.

mnem

[xrunner]

Yeah, remember that this port is already configured in Marlin ...

Yes, but what port number? Mine had to be port 2 before it would work. 

[mnementh]

...Right now waiting on another roll of filament from Amazon to start on one for t'other end; by my calculations I have like 36 grams left and that just ain't gonna cut it.

Filament arrived, but it's not a perfect match to what I've been using. That was black-black and high-gloss; this is a little brownish and semi-gloss or satin. The brand I've been using was sold out, so I bought a 1Kg roll of FlashForge branded filament cuz it was on sale. Toeplate #2 is printing, so we'll see how it matches up tomorrow morning, I guess...

Toeplate for other end was done printing when I woke up this morning; holding them together side by side, you can see a slight difference in color but at the other end of the board it's indistinguishable.

Here's hoping the boi steps up & puts it to good use. Or bad use.

mnem
 

[mnementh]

Yeah, remember that this port is already configured in Marlin ...

Yes, but what port number? Mine had to be port 2 before it would work. 

This same port already works with the Diggro TS. That tells me that this isn't a reserved port in Marlin, and that the port should be properly configured for serial, no matter what device is connected to it. Unless one or the other of these uses some non-standard protocol or handshaking, which of course is very possible.

mnem
 

[mnementh]

Oklay... I think I get it.

After reading the manual: https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/?action=dlattach;attach=1119474

it appears that this control panel works in 3 different modes: (1) 128x64 Emulation Mode, (2) Ender 3 SWD mode, and (C) Serial Mode.

Apparently, the FW will auto-switch (depending on what is present) or manually switch between 128x64 emulation mode and the other two; however, Serial mode vs CReality SWD mode each have their own firmware.

Trying to figure out which FW is on this thing right now... 

mnem
 

[xrunner]

Trying to figure out which FW is on this thing right now... 

Just download and install the latest FW, there's nothing you need to figure out. 

They upgrade the FW all the time, heck I've updated mine (the TFT35 V3.0_E.26) probably 15 times since I've had it. In fact they just put up one with some changes since a few days ago. Your screen is included in the .zip file as well as all the others, like mine.

https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware

Just put the TFT .bin file for your board, the TFT directory for your board (it contains the bmp and font files), and the config.ini on an SD card and upgrade. That's all there is to it.

[mnementh]

I was beating my head against GitHUB for a few... couldn't get the TFT folders to save. Finally gave up and downloaded the entire Git as a ZIP. It's late; I'll look into it some more tomorrow.

mnem
 

[xrunner]

Just updated the screen FW again this morning. Like I said, they make changes to it all the time, which I suppose is better than them not caring any more.

This time I noticed an error that has appeared during the upgrade process for several upgrade cycles, regarding some mis-match of a .bmp file, has also been fixed.

The only things I change in the config.ini file are these - however there are other things you could play around with. Remember - nothing can go wrong, 

#### Auto Save Load Leveling Data
# The TFT will auto-detect if Auto Bed Level is available.
# Enable this will send "M500" after "G29" to store leveling value
# and send "M420 S1" to enable leveling state after startup
# Options: [enable: 1, disable: 0]
auto_load_leveling:0

^^^ I changed it to 0

#### Persistent temperature info
# show persistent temperature info on all menu screens
# Options: [enable: 1, disable: 0]
persistent_info:1

^^^ I changed it to 1

#### Default Marlin Mode Background & Font Color Options
# Options: [ WHITE: 0,  BLACK: 1,  RED: 2,  GREEN: 3,      BLUE: 4,       CYAN: 5,  MAGENTA: 6,    YELLOW: 7,
#           ORANGE: 8, PURPLE: 9, LIME: 10, BROWN: 11, DARKBLUE: 12, DARKGREEN: 13,    GRAY: 14, DARKGRAY: 15]
# Or set the color(RGB888 format) hex value directly(start with “0x”).
# Such as: 0xFF0000 : Red, 0x00FF00 : Green, 0x0000FF : Blue
marlin_bg_color:1
marlin_fn_color:7

^^^ I changed it to 7

[mnementh]

Yup; I just updated to the version released yesterday.

Still no joy, even after trying all the available baudrate settings one at a time and resetting the panel each time. While I was doing that, I realized it should not be a surprise; this thing has to be set up as serial comms. If it were set up for SWD, there shouldn't be a baud rate setting. 

There must be something else; either that, or the Serial port I'm using is actually a pair of multi-I/O pins and this thing requires a hardware RS-232 port. That might explain why yours needs to be on a specific serial port.

I'm going to take the deep-dive on the config.ini that I saw posted in the GitHUB. in a minute. Or three. Well, after I have some breakfast & coffeee in me.

mnem

[mnementh]

Ugggh. The "deep-dive" on the gitHUB was just filehandling instructions for config.ini; not any kind of in-depth study of the various settings. As usual with Marlin, I'll have to scroll through the whole effing thing and parse it as I'm reading.

This is going to be at least 2 coffees worth... 

mnem

[xrunner]

Ugggh. The "deep-dive" on the gitHUB was just filehandling instructions for config.ini; not any kind of in-depth study of the various settings. As usual with Marlin, I'll have to scroll through the whole effing thing and parse it as I'm reading.

This is going to be at least 2 coffees worth... 

Man you should be thrilled - you can't buy fun like you're about to have. 

[mnementh]

oi.

#--------------------------------------------------------------------
# Supported Marlin Firmware Version
#--------------------------------------------------------------------
#  Minimum Marlin Firmware Version: 2.0.5.4
#  Distribution date: 2020-05-12
#  Source: https://github.com/MarlinFirmware/Marlin/releases
#

#  Note: Ensure that following options are enabled in Marlin firmware
#
#  M115_GEOMETRY_REPORT (in Configuration_adv.h)
#  M114_DETAIL  (in Configuration_adv.h)
#  REPORT_FAN_CHANGE (in Configuration_adv.h)
#  EMERGENCY_PARSER (in Configuration_adv.h)
#  SERIAL_FLOAT_PRECISION 4 (in Configuration_adv.h)
#  HOST_ACTION_COMMANDS  (in Configuration_adv.h)
#
# For printing from onboard SD
#
#  SDSUPPORT (in Configuration.h)
#  AUTO_REPORT_TEMPERATURES (in Configuration_adv.h)
#  AUTO_REPORT_SD_STATUS (in Configuration_adv.h)
#  LONG_FILENAME_HOST_SUPPORT (in Configuration_adv.h)
#  SDCARD_CONNECTION ONBOARD (in Configuration_adv.h)#

#--------------------------------------------------------------------
# General Settings
#--------------------------------------------------------------------

Welp, that didn't take long. Evidently there is something this thing expects to see from the serial comms that is only supported in Marlin 2.x.x. I'm still running the default FW
(with a few toggles switched on), which is based on Marlin 1.1.9.

Yeah.... not gonna eff with this anymore until I have the wiring for EXP-1 & EXP-2 figured out and I can at least run the thing in 128x64 emulation mode. That was the primary reason for having this stoopit thing in the first place. Don't really care if the TS works at all; it was just a novelty. The novelty of which... has worn off.

mnem
 

[mnementh]

Ugggh. The "deep-dive" on the gitHUB was just filehandling instructions for config.ini; not any kind of in-depth study of the various settings. As usual with Marlin, I'll have to scroll through the whole effing thing and parse it as I'm reading.

This is going to be at least 2 coffees worth... 

Man you should be thrilled - you can't buy fun like you're about to have. 

 

Uh-huh... and of course, now I'm thinking aboot going through and making sure all those "required items" are toggled on... just to see what it does.

mnem

[xrunner]

Welp, that didn't take long. Evidently there is something this thing expects to see from the serial comms that is only supported in Marlin 2.x.x. I'm still running the default FW
(with a few toggles switched on), which is based on Marlin 1.1.9.

You need two serial ports - Marlin 1.1.x only supports one. That's why I was asking you what your second serial port was set to ...

[Zucca]

I am blown away...
schematics, manual, top and bottom layer everything is super well documented and available here

BIGTREETECH finally someone in china is swimming upstream!

Well I take it back.... the relay board V1.2 is funny....   
fully story here, warning 

https://github.com/bigtreetech/BIGTREETECH-Relay-V1.2/issues/7#issuecomment-735447011

BTW, I want to sell my TFT touch... after one week of using it I do not like it and I miss my marlin, which is more useful to get the job done.
My personal opinion.....

[mnementh]

Welp, that didn't take long. Evidently there is something this thing expects to see from the serial comms that is only supported in Marlin 2.x.x. I'm still running the default FW
(with a few toggles switched on), which is based on Marlin 1.1.9.

You need two serial ports - Marlin 1.1.x only supports one. That's why I was asking you what your second serial port was set to ...

Ahhh... now I see what you were getting at. I didn't see any reference to such anywhere in any of the documentation or install vids/articles I found.

I think "need" is a bit excessive. Obvi, Longer/DIGGRO figured out how to do it with 1.1.9.

I tried enabling what looked like the correct equivalents in Configuration_adv.h; still no joy. I've reverted now & packed the TFT 2.4 away; I have a couple other higher priority projects right now.

mnem
 

[mnementh]

I am blown away...   schematics, manual, top and bottom layer everything is super well documented and available here   BIGTREETECH finally someone in China is swimming upstream!   

Well I take it back.... the relay board V1.2 is funny....      fully story here, warning     https://github.com/bigtreetech/BIGTREETECH-Relay-V1.2/issues/7#issuecomment-735447011

BTW, I want to sell my TFT touch... after one week of using it I do not like it and I miss my Marlin, which is more useful to get the job done. My personal opinion.....

Hmmm... I guess I don't get why, unless you just want some of the money back; your controller has the EXP-1/EXP-2 ports, right? So either mode is dead-easy; switchable right from the panel...

re: the relay board... I certainly wouldn't bother with hot air just to remove a single SOIC-8; just a 4mm chisel-tip tinned a little heavy. Much less chance of damaging surrounding bits, especially fracture-prone MMLCCs. 

mnem
 

[xrunner]

BTW, I want to sell my TFT touch... after one week of using it I do not like it and I miss my marlin, which is more useful to get the job done.
My personal opinion.....

I didn't like it at first but now I use it all the time. The only function I can't get to in the touch screen is the mesh levelling, but I just switch to the Marlin menu to do it if needed.

BTW Zucca, all I have to do to get to the Marlin menu is hold down the rotary knob for a few seconds - it clicks a few times - then two icons appear. One is for the touch screen mode and the other goes into the original Marlin menu. Do the same to return.

Does yours not have that capability? 

[CatalinaWOW]

Question?  Is mesh leveling convenient, but potentially harmful to print quality?

Here is my reasoning.  With manual leveling you are lining the bed up with the movement axes of the machine.  During printing the z-axis need only increment, making any backlash in this axis moot.  With mesh leveling the machine finds the best fit plane to the measured points and tries to construct the model perpendicular to that plane.  If the best fit plane is not perpendicular to the movement axes then z-axis travel up and down will be required,  possibly making backlash an issue.

For those using mesh leveling there might not be any observable problems if there is effectively no backlash, or if the table is actually perpendicular to the z-axis.  Has anyone noticed any cases where mesh bed leveling did have a negative effect on print outcome?

[Zucca]

For those using mesh leveling there might not be any observable problems if there is effectively no backlash, or if the table is actually perpendicular to the z-axis.  Has anyone noticed any cases where mesh bed leveling did have a negative effect on print outcome?

I am pretty new in this 3DP circus, so here only my 2 cents based on my little experience.
Marlin is pretty much tested by a big army of people, very very common FW for a 3D printer. If mesh leveling would have been  the cause of a negative effect, me and you will be not the first to notice it.
I trust every function in Marlin, and if you read the configxxx.h they describe as "experimental" the functions which are still not mature as the other ones.. so I trust that Marlin mesh leveling will do his job.

In real life this is what I learned: a glass bed makes the real difference not the leveling process. Of couse you need to get that bed aligned. If you do the alignment correctly the difference are minimal in the end regardless which alignment you choose. Glass bed is a must. IMHO

[Zucca]

Does yours not have that capability? 

Yes and every single time I ask myself why I need the touch mode, I have octoprint a Marlin display. I do not need anything else.
the TFT touch is just an annoying extra which most in the cases is on my way.

Example when I print with octoprint I do not see a print status as in the marlin display. This is very annoying for me and I need to go switch to marlin all the time.
Of course I could leave it there in Marlin mode, but meehh I prefer optically the original LCD one.

[xrunner]

Question?  Is mesh leveling convenient, but potentially harmful to print quality?

No. Never seen any issues with it.

Here is my reasoning.  With manual leveling you are lining the bed up with the movement axes of the machine.  During printing the z-axis need only increment, making any backlash in this axis moot.  With mesh leveling the machine finds the best fit plane to the measured points and tries to construct the model perpendicular to that plane.  If the best fit plane is not perpendicular to the movement axes then z-axis travel up and down will be required,  possibly making backlash an issue.

For those using mesh leveling there might not be any observable problems if there is effectively no backlash, or if the table is actually perpendicular to the z-axis.  Has anyone noticed any cases where mesh bed leveling did have a negative effect on print outcome?

Yes what you said is true, there are slight up and down adjustments at first. Very slight. However, you set a parameter called fade-out and the adjustments will cease after x.x mm set in a menu. My fade-out is set to 4 mm. After that the print runs machine-true level, the bed is no longer an issue.

There is effectively no backlash anyway on such a very slowly moving vertical system as this, with weight pressing down all the time. The weight of the Z axis components are constantly pushing down whether its going up or down. The top of the lead-screw threads are in constant contact with the bottom of the nut threads. For the existing backlash to come into play, the system would have to accelerate down faster than the weight of the Z components could compensate for. It will never do that.

If it was X/Y movement there would be backlash using a lead screw (if not compensated by an anti-backlash nut or some other system). But the printer uses belts for those. Even TH3D states this about the anti-backlash nut you can get for it:

"Helps prevent Z gantry from dropping down when motors turn off"

https://www.th3dstudio.com/product/upgraded-leadscrew-nut-for-creality-printers-anti-backlash-nut/

That's really the only claim they make for it.

[Zucca]

just a 4mm chisel-tip tinned a little heavy. Much less chance of damaging surrounding bits, especially fracture-prone MMLCCs. 

PTTC-704!

[mnementh]

just a 4mm chisel-tip tinned a little heavy. Much less chance of damaging surrounding bits, especially fracture-prone MMLCCs. 

PTTC-704!

Tweezers are nice, but not a necessity with chips this small. Technique is all that's needed.

mnem
*missing my MetCal*