In my JGAurora A5 printer, it is run by a pair of MakerBase modules. The printer is run by a Makerbase MKS Gen L motherboard, which runs the open-source
Marlin firmware. The printer LCD screen is an entirely separate component, and hither JGAurora have used the MKS TFT28 LCD module, which is an entirely proprietary product.

The A5 has two USB ports on the side of the printer:

  • A “USB blazon B” connector that leads directly to the main motherboard, where y’all can use a cable to connect the printer to a figurer.
  • A “USB blazon A” connector that leads to the LCD module. This is for inserting USB retention sticks or wink drives with your print files.

The phrase “2 heads are better than i” does not apply here, rather, I might apply the phrase “ii cooks spoil the broth”.

In the A5, the MKS LCD module is responsible for reading files off the USB stick, and for sending those gcode commands to the main motherboard, line past line.

Having been a part of the A5 customs for a while now, the primary problem with this setup is that it introduces several new points of failure:

  • The connection from the USB port on the printer, to the LCD lath can exist bad, causing corrupted or failed prints
  • The connection from the LCD board to the main motherboard can be bad, also causing corrupted or failed prints
  • The principal motherboard can encounter an error, and reports information technology to the LCD, but the LCD module just ignores information technology, and does non inform or alert the user.
  • The filament run-out sensor is connected to the LCD module simply. If you lot impress a gcode file via a USB cable directly to the primary motherboard (eastward.g. via
    octopi
    or
    pronterface) the main motherboard is unable to read this sensor and you lose that characteristic.
  • The LCD module is responsible for power-failure resuming features, and so again, if printing via a USB cable, you lose this feature too.
Read:  Download Firmware Powerbeam M 5 400

Recently, I accept encountered some people having problems with the printer making random spurious wrong movements now and so. Printing the file via the SD card socket on the LCD module works perfectly, simply press the same file from the USB port would effect in strange glitch detours every now so.

By
enabling debug mode on the marlin firmware
(M111 S7), we were able to make the primary motherboard echo dorsum every command information technology received. Comparing the output, with the gcode input file, there seemed to be random sections of gcode missing! Randomly, a line of gcode would terminate, and then several lines would skip, and then printing would resume.

Gcode File:
download here

Raw Debug Log:
download here

Printing result (stopped after glitch)


Connecting Mks Tft Screen an Marlin Firmware

By visualising the Gcode file and the debug log, the difference (the error) can exist clearly seen:

Visualised Original Gcode



Visualised Gcode from Debug Log



I likewise verified that the checksum of all lines received by the main LCD were valid – even the line that appeared to be an error! This is the line received by the main motherboard that is responsible for the long blip:

echo:N55 G1 X1*81

The checksum 81 is a valid checksum for this command.

This confirmed that the LCD module was reading incomplete data off the USB, and creating valid checksums for the corrupted data.

This indicates that in some cases, problems can occur with the MKS LCD module reading data off USB sticks. Dissimilar USB sticks were tried with no change. Several
MKS LCD firmware updates
have been released, simply this effect was not fixed with the latest version.

Read:  To Use the Gpt Partitioning System on a Hard Drive What Firmware Is Required

How frustrating!