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 here 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 type B” connector that leads directly to the main motherboard, where you can use a cable to connect the printer to a computer.
- A “USB type A” connector that leads to the LCD module. This is for inserting USB memory sticks or flash drives with your print files.
The phrase “two heads are better than one” does not apply here, rather, I might use the phrase “two 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 by line.
Having been a part of the A5 community for a while now, the main 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 board can be 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 main motherboard can encounter an error, and reports it to the LCD, but the LCD module just ignores it, and does not inform or alert the user.
- The filament run-out sensor is connected to the LCD module only. If you print a gcode file via a USB cable directly to the main motherboard (e.g. via octopi or pronterface) the main motherboard is unable to read this sensor and you lose that feature.
- The LCD module is responsible for power-failure resuming features, so again, if printing via a USB cable, you lose this feature too.
Recently, I have encountered some people having problems with the printer making random spurious incorrect movements now and then. Printing the file via the SD card socket on the LCD module works perfectly, but printing the same file from the USB port would result in strange glitch detours every now and then.
By enabling debug mode on the marlin firmware (M111 S7), we were able to make the main motherboard echo back every command it received. Comparing the output, with the gcode input file, there seemed to be random sections of gcode missing! Randomly, a line of gcode would stop, 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)
By visualising the Gcode file and the debug log, the difference (the error) can be clearly seen:
Visualised Original Gcode
Visualised Gcode from Debug Log
I also 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. Different USB sticks were tried with no change. Several MKS LCD firmware updates have been released, but this issue was not fixed with the latest version.