BlueFinBima
commented
3 years ago I installed Mariner on a Pi3B and can also reproduce the same problem there. Additionally, I run the following script, designed to mimic what Mariner's printer.py does, and with both this script and mariner communicating on the serial port, I see the \r\n in the serial monitor for my python script, but not from mariner.
'''
UART communication on Raspberry Pi to mimic Mariner comms
'''
import serial
from time import sleep
ser = serial.Serial ("/dev/serial0", 115200) #Open port with baud rate
while True:
sleep(1)
ser.write((f"M23 /W1bble.ctb").encode() + b"\r\n") #transmit data serially 115200I am completely at a loss to understand what I am seeing unless the mariner I am running is not the same as the code on github.
Hopefully this additional information will help someone more knowledgeable than I to point me in the right direction.
Many thanks
luizribeiro
BenStein1
J-Iszatt
fcollingwood
Blanks82
koshisan
jremen
mnbf9rca
DimitriGaming-png
I'm a new user (ie Mariner3D has never worked completely for me) I get the #180 symptom, however I do not get any control of the printer which seems different from the experiences of others who get this symptom.
Looking at the serial data being sent from the Pi Zero W to the Mars Pro, I see the following
M23 /first file.ctbM4006M4006M4006M4006M23 /second file.ctbM4006M4006M4006M4006M4006M4006M4006M4006that is, a constant stream of commands without CR LF.In order to rule out my serial monitor, I performed the following on the Pi Zero W
cat 1.txt > /dev/ttyS0where 1.txt contains three words separated by CR LF.I see the following in the serial monitor
My conclusion from this is that Mariner3D / Python is not sending the CR LF even though I can see from the Mariner code that it should be sent.
Assuming my observations are reliable, then I think that the commands from Mariner cannot be digested by the printer. I cannot escape the fact that nobody else sees this problem so it is likely to be a problem of my own making rather than Mariner.
A short description of what the bug is that the printer cannot be controlled via the UART.
Expected Behavior I expect that the printer will be sent commands terminated with an "\r\n". I can see in printer.py that this is the intent of what Mariner3D is doing. I don't see why this seems not to be happening.
There is nothing of interest in the Mariner3D log.
Details:
Other cmdline.txt is
root=PARTUUID=82934f69-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2[all] clause of config.txt containsPython is 3.7.