Closed PPAC37 closed 2 years ago
Also the fact that M503 result is filtered by Makelangelo requires going through another tool (Repetier Host, Pronterface, ...) if you want the complete / unmodified result of an M503.
I don't think it is related to your computer, I have the same behavior: when connecting to the robot, it is not reset and thus, if I ask it something, marlin will tell me that the line I sent is not in correct order.
On my setup, if I reset the robot by pressing the button on the board, I'll get all the startup log in marlin tab and then I'm able to home the robot. I don't know how to reset marlin with a gcode command, any clue ?
To my knowledge, there is no g-code to do a reset. https://marlinfw.org/meta/gcode/
Normally it seems to me that it is the serial connection protocol which makes a signal on one of the wires (an inversion) and that must trigger the reset at the connection ... (but the serial protocol escapes me, so I may be wrong...)
AFAIK it’s the ftdi chip that resets the mcu on connect unless reset is tied to…ground? It has to be tied one way or the other, I forget which.
On Feb 13, 2022, at 6:57 AM, PPAC37 @.***> wrote:
To my knowledge, there is no g-code to do a reset. https://marlinfw.org/meta/gcode/
Normally it seems to me that it is the serial connection protocol which makes a signal on one of the wires (an inversion) and that must trigger the reset at the connection ... (but the serial protocol escapes me, so I may be wrong...)
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.
To my knowledge, there is no g-code to do a reset. https://marlinfw.org/meta/gcode/
Normally it seems to me that it is the serial connection protocol which makes a signal on one of the wires (an inversion) and that must trigger the reset at the connection ... (but the serial protocol escapes me, so I may be wrong...)
there is a recent option in marlin #define SOFT_RESET_VIA_SERIAL // 'KILL' and '^X' commands will soft-reset the controller
but I can't get it working, @PPAC37 do you have more chance than me ?
I did a test after activating the EMERGENCY_PARSER and SOFT_RESET_VIA_SERIAL in configuration_adv.h but if I send KILL via Repetier Host it adds me a line number and I end up with an unknown command
and an echo "KILL" > /dev/ttyACM0
(with Repetier Host connected) seems to block me firmware (it starts blinking... )and Repetier Host don't log anymore ... so it "kills"/"bugs" the connection and/or the firmware for me but does not do a "clean" reset...
KILL probably disables the ISR and sends the main loop into a while(1) {}
maybe :'(
Here is the corresponding PR https://github.com/MarlinFirmware/Marlin/pull/21652 and I don't understand what it is used for.
@PPAC37, can you add <logger name="com.marginallyclever.makelangelo.plotter.plotterControls.MarlinInterface" level="trace" />
to src/main/resources/logback.xml
before <root level="info">
, connect to your robot and try to home it please ?
Can you try another test: launch makelangelo, connect to the robot, reset the robot with the button on the board and try to home it.
Can you send the log after those 2 tests please ?
01_Test1_trace_connect_home_makelangelo.log
02_Test2_trace_connected_reset_makelangelo.log ( the reset was done befor the M503 ...)
sad :-(
can you try setserial -a /dev/ttyACM0
when starting the computer, after connecting disconnecting makelangelo and after connecting disconnecting repetier host.
This tool prints all the available about the configuration of a serial port.
On my server, it gives:
> setserial -a /dev/ttyArduino
/dev/ttyArduino, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 9600, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal
I discover setserial Thank you!
$ sudo apt install setserial
# fresh boot
$ setserial -a /dev/ttyACM0
/dev/ttyACM0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 9600, close_delay: 12, divisor: 0
closing_wait: 750
Flags: spd_normal
# after Makelangelo Connecte then Disconnect done. ( no exchange ...)
$ setserial -a /dev/ttyACM0
/dev/ttyACM0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 9600, close_delay: 12, divisor: 0
closing_wait: 750
Flags: spd_normal
# after Repetier-Host Connect then Disconnect done.
$ setserial -a /dev/ttyACM0
/dev/ttyACM0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 250000, close_delay: 12, divisor: 0
closing_wait: 750
Flags: spd_normal
# after Makelangelo Connecte then Disconnect done. (recive ok due to after repetier ...)
q6@q6-pc:~/tmp_git_try/PPAC37/Makelangelo-software/target$ setserial -a /dev/ttyACM0
/dev/ttyACM0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 250000, close_delay: 12, divisor: 0
closing_wait: 750
Flags: spd_normal
So look like the Baud_base ( baudrate ? ) not correctly initialised under linux by the serial lib used in Makelangelo ? (or maybe the lib have reseted it as it was ... ? im lost ...)
Nice :-) maybe a bug in the serial lib :-(
So after a fresh boot, can you launch the following command before starting Makelangelo:
setserial -v /dev/ttyACM0 baud_base 250000
Next, the start Makelangelo and see what happened.
this do not change the outcome with makelangelo ... :-( ??? may i have made a commande typo ?
q6@q6-pc:~$ sudo setserial /dev/ttyACM0 baud_base 250000
q6@q6-pc:~$ sudo setserial /dev/ttyACM0 -v -a
/dev/ttyACM0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 9600, close_delay: 12, divisor: 0
closing_wait: 750
Flags: spd_normal
Seem like baud_base is not the baud rate ...
spd_cust use the custom divisor to set the speed at 38.4kb
(baud rate = baud_base / custom_divisor)
But i dont get it on what to use as custom_divisor ...
dammit, can you try another command: stty -F /dev/ttyACM0 250000
$ stty -F /dev/ttyACM0 250000
stty: argument «250000» incorrect
$ stty -F /dev/ttyACM0 ospeed 250000
$ setserial -a /dev/ttyACM0
/dev/ttyACM0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 9600, close_delay: 12, divisor: 0
closing_wait: 750
Flags: spd_normal
and same result no exchange under makelangelo on serial link...
Also ( but may be a misdirection) https://github.com/MarginallyClever/Makelangelo-software/blob/bc9dd294a2d0fed1de1340b3722262f0cbc84be3/src/main/java/com/marginallyclever/communications/serial/SerialConnection.java#L60
serialPort.setParams(...) normally returns a boolean. But in all my tests, if I log the returned boolean, it returns false... like setParams is not a success...
:sob:
stty -F /dev/ttyACM0 115200
seems to work but not with 250000 :-(
I don't know other tools that set the serial speed by CLI.
Another workaround is to use the baudrate dropdown menu to try a lower speed (need to recompile the firmware).
This issue is growing stale and will be automatically closed in 60 days if nothing is done.
I have a kind of serial port initialization fault just after starting my computer. (when I try to connect from Makelangelo, if I have just turned on my computer, ... there is no display in the marlin tab nor a response to an M503.)
Opening and closing a connection with repetier Host solves the problem. (so under Makelangelo when I open a connection I have many messages and order returns in the Marlin tab.)
Once a connection is correctly established, I no longer have the problem until the next computer restart.
Steps to make the bug happen
(but the port is reported open by
lsof
)and close a connexion via Repetier Host to get it working under Makelangelo
Platform (please complete the following information):
Log file Nothing in particular ... makelangelo.log
Additional context ?
? Serial port lib defect or a setting of my environment or a wrong or partially performed port initialization by Makelangelo serial port lib ...?
As I am used to printing from an SD card (as with 3D printers, the serial connection is often a source of problems, especially if the PC is lagging because it is used for something else at the same time...) and as I rather use Repetier Host or Pronterface to send g-codes when I need, it doesn't really bother me but a new user could be destabilized by that.