Repetier (Firmware + Host) + Ramps + alternative Serial adapter

Hello,
I'm working on a serial TFT as addon for my printer.
I'm using a STM32F01xxx as MCU, so my configuration is:
Repetier Host <-> STM32 <-> Ramps 1.4
I wrote a simple pass through code for the STM32 , so every incoming message from repetier host is directly send to ramps 1.4 and vice versa. Everything is working fine (like local echo, sending Gcodes), but Repetier Host wont get any connection, so I think, I'm missing something:
Normally via USB connected RAMPS will start a reset sequence when Repetier host is connected - but it doesn't do that in my scenario.
More details:
The alternative Serial (STM32) is connected via D0 / D1 (serial 0 = USB serial), I know this might be a problem because of an USB-serial conflict. The ramps board is NOT connected via USB. There are no problems with baudrate or different voltage levels (added a level converter, normally there is no problem using 3.3v and 5v, but I even checked this), neither with my STM32 code (serial passthrough is a easy going thing).
So are there special start codes (didn't sniffed them on my serial monitor) with repetier host or need I change some firmware settings bypassing serial USB on ramps? Oddly enough Printrun as host is working flawlessly - only repetier host refused to work with my setup.
I believe Repetier Host is using the DTR/CTS pins for the start sequence?
Has somebody any hint?

thanks Matthias

Comments

  • You can enable log in host to see exactly what communication is going on.

    Host toggles DTR and RTS pin twice to reset and if it does not see a "start" within some time it simply sends teh start gcode (for those printers without reset) and expect an answer. Just make sure to not use some hardware flow control where DTR/RTS might get used.
  • Ok, thanks for your answer!
    I logged the communication as well without result, but I'm on the right track with DTR/RTS:
    The STM32 is connected "native" via HID-Class serial communication.
    So in theory I can guess what happend (didn't proofed it with my logic analyzer):
    After connecting to Repetier host (push "connect") I see in the protocol a single "M105" command, after that the communication stops (from repetier-host), so I believe that after M105 the DTR/RTS is toggled, causing a reset not in the Ramps, but in the STM32 (USB serial)!
    So the serial adapter will disappear for a short time in OSX. (I tried OSX only, I've to proof the behavior under Windows) - USB HID serial is really bad implemented in OSX (and getting worse from version to version)
    So Repetier Host does not recognize that the adapter is deactivated/activated and is fooled by the OS(x) and is going to communicate with a "ghost device"

    So now comes the interesting part maybe for you as developer:
    I guess that all of those MKS TFT's and/or many other (upcoming?) printer-Boards with "native" USB-HID serial will have the same behavior if there is no change in the core library (ignoring DTR/RTS signals in the USB HID class). It also depends on the used core (on STM32 there are about ~3 major cores actually in use, I have no idea how about NXP and other 32bit MCUs)

    An easy way / workaround would be a option (checkbox) in the repetier-host printer tab: "disable DTR/RTS on startup" - this might fix problems with future printer boards (feature request)

    Other solutions:
    Using a secondary serial converter (CH340, FTDI...) for the display (unecessary expensive hack)
    Rewriting the USB-HID-Class serial class in the core and disable/ignoring DTR/RTS (bad hack)

    Matthias

  • Ok, I tried my hardware setup under Windows 7 - and:
    It works like a charm.
    So again a OSX problem. OSX is really a painkiller with USB-Hid and it is getting worse with every new OSX version..... time to say goodbye to  apple.
  • Ok, just one tip, maybe for all "serial display/TFT" or even bluetooth/EXP8266 users:

    Do not use "Serial" (D0/D1) on AUX 1 if the printer is connected via USB
    Alternative: Serial1 or Serial3 (Serial 2 uses the Aux4 port on Ramps so you should avoid it if in use with SD-Card, Smart LCD...)
    So we have:
    Mega Serial
    Serial :  00 (RX) and 01 (TX) (our USB-connection!)
    Serial 1: 19 (RX) and 18 (TX) 
    Serial 2: 17 (RX) and 16 (TX) 
    Serial 3: 15 (RX) and 14 (TX) 

    Mapping Ramps:
    Serial 0: Aux 1 (USB serial conflict!)
    Serial 1: Z-Min (TX) Z-Max (RX)
    Serial 2: Aux 4 (Display, SD-Card...)
    Serial 3: Y-Min (TX) Y-Max (RX)

    In Repetier Firmware I just set in "General" --> "Bluetooth serial port" --> "Serial 1" (...or in configuration.h)
    As written on the table above, I removed / remapped the Z-min (Z-max is not in use) endstop pin to somewhere else (good pins are: x-max or y-max, because they are also not in use by standard printers)

    With this configuration there is no further need in pass through the USB-serial signal in the serial TFT and you'll avoid conflicts, because serial pin sharing (USB serial on the mega also uses D0/D1) is dangerous and not a good idea (Example: repetier host  and the serial-tft(on Serial0) are sending data the same time ---> conflict).
  • @madias
    Hi
    Can you please tell me more about your setup because I was thinking about making the same thing (using an stm32f103 as tft driver to control the printer board using gcodes over serial)

    what tft you are using with the stm32?
    and have you made a graphics user interface? and what library do you used for that ?

    thank you in advance
  • Dear ASH, sorry for the late reply:
    Can we discuss this here?
    http://www.stm32duino.com/viewtopic.php?f=19&t=3477
  • thank you for your reply @madias
    I will take a look to that topic and we can discuss it there

  • I'll post my last working code in this thread!
  • @madias
    actually I registered to stm32duino.com and activated my account but I cannot post a reply to your topic there !!
  • I am also working on it. My printer not even gets connected sometimes. An error 0x80248007 is displaying most of the time when I turn on my pc.
Sign In or Register to comment.