Repetier Host V1.6.1 Connection Problems with USB CDC Interface

Hiya,

Could somebody on the Repetier team explain how the serial connection is made within Repetier Host?  

I'm working on developing firmware for the FSL K22F (Cortex M4 with built in USB) following the Arduino Marlin/Repetier code.  

For the interface, I'm using the built in USB as a CDC interface.  Plugging the M4 into a Windows machine gets it recognized without any issues.  For Windows 10, there is no need for the .inf file which is required for WinXP, Win7 & Win8.  

On these machines, I can connect and communicate with the M4 without any problems to Tera Term and Cura.  I have also tried to communicate with the M4 using some home grown C Windows programs I've written over the years without any problems.  

Repetier Host does NOT seem to recognize the printer not and clicking on the "Connect" button seems to just hang Repetier Host.  Once Repetier Host starts hanging, the only way to get any response is to pull the USB cable (and get the log information "A device attached to the system is not functioning.").  I have reviewed other questions on these forums as well as the Interwebs and I have confirmed the com port Device Manager as well as the operating speed.  

This, along with the various questions about communications (especially as they seem to all involve USB CDC connections) leads me to believe that the communications approach used by Repetier Host is not using the standard Windows APIs or they are being used in an unusual manner.  

Could somebody on the Repetier team respond with comments about how the serial interface is implemented and are there other things to try?  

Thanx,

myke

Comments

  • We are using the default c# serial class to communicate. So as long as this creates a serial COM port it should work. The host uses settings for DTR and RTS that work on all boards we know. These are normally used to reset boards and not real part of serial communication. Are there any requirements for your connection?
  • First off, thank you for the quick response.  Very impressive.  

    Okay, I think things are starting to make sense.  As DTR and RTS are from the Computer ("DCE" in RS-232 parlance), I'm guessing that your software is waiting for RTS to be asserted, indicating that there is a device (RS-232 "DTE") on the other end to communicate with - correct?  

    If that's the case, is there a way to turn off the hardware handshaking?  The USB CDC stack I'm working with does not have the ability to set/receive the virtual handshaking lines.  I will follow up with the USB stack source, but I wouldn't hold out too much hope for that.  

    At the very least, could I suggest that the messaging in Repetier Host be a bit more descriptive in terms of the problem in the logging window (and maybe time out after a few seconds without the handshaking line becoming asserted)?  

    Thanx,

    myke
  • No we do not wait for RTS/DTR. We actively toggle them on and then off. This triggers on most boards a reset so we have a defined starting point. So all you need to have is the ability to let these change and not respond to it. It should after a while say no start detected (because of missing reset you firmware does not sen dstart) then it sends the initalization commands anyway and it should work. Like with Printrboard which also use direct USB.
  • How long should I wait?  I have waited over an hour without any response from Repetier Host locked up until I pull the USB cable and get the error message indicated above.

    Can the handshaking lines be disabled in Repetier Host?  Is there anything I can do to help test/explain the behaviour I'm seeing?

    Thanx,

    myke
  • It shoudl only take a few seconds. Not hours.

    I think in 1.0.6 you had to select the dtr bahaviour. There you had several modes to select from. So maybe try that version to see if one of them works. You could even set do nothing (Printboard I think was mentioned here).
  • Okay.  Tried 1.06 with the DTR disabled.  

    Definitely got further than the last time:
    • The "Connect"/"Disconnect" buttons are now working as expected.  
    • I got it to send commands once to my hardware - now it is halted with "8 Commands Waiting", even if I power down/power up the PC.  
    Unfortunately, I can't repeat the performance or clear the command waiting queue.  

    Any ideas?  
  • Upon further examination, it seems like the port on the PC is being put into an invalid state by Repetier Host.  I can't work with Cura or Tera Term after the operation but if I pull the USB cable and plug it back in, things work okay.  

    I say Repetier Host is doing it because I don't see the same behaviour from Tera Term or Cura.  

    I still have "8 Commands Waiting".  

    Sorry, what else can I try?  
  • Apparently, I can set/read the virtual handshaking lines in the USB CDC stack that I'm using.  

    What values should I be setting and what should I be waiting for?

    Thanx!

    myke
  • Does not look like communication. x commands waiting normally means it did not get any response from printer also it has send commands.

    Can you say if Repetier-Server is able to connect to the printer? The logic is the same but it uses native C functions to communicate and not the .NET serial library.

    We do no handshaking on connection, just call the plain open for the com port.

    Can you say how USB CDC differs from normal Serial over USB for windows? As I understand you both offer a serial COM port so the software does not need to bother about implementation details.
  • Hiya,

    I'm echoing everything that comes in from Repetier-Host.  I simply don't see anything coming in from Repetier-Host except for the one time I got some commands coming in is when I went to 1.0.6 and turned off the hardware handshaking.  

    I have not tried Repetier-Server.  I will do that later.  

    I do not have the option for a hardware serial port.  

    "Serial over USB" *is* USB CDC: at the app level, it should appear identical to a hardware serial port or any other USB CDC device (like the AVR 32U8 normally used for the Arduino USB CDC interface or a cheap serial to USB cable).  

    Let me do some research on the .NET serial library versus the native APIs.  I wonder if the issue is in there that is causing things to not behave as you think/expect.  

    So, my take aways are:
    1. Try Repetier-Server and see if the communications works differently.
    2. Look at the .NET serial library versus native Windows APIs.  

    I'll get back to you.  
  • Okay, I've done a bit of digging on the .NET serial library.  

    *Lots* of people report the same issues that I have with (relatively) unique hardware - I found one issues with the same hardware device and USB stack as I am using.  

    When you are initializing the serial port in C#, are you turning off handshaking explicitly, ie the highlighted line below:

     // Create a new SerialPort object with default settings.
    _serialPort = new SerialPort();

    // Allow the user to set the appropriate properties.
    _serialPort.PortName = SetPortName(_serialPort.PortName);
    _serialPort.BaudRate = SetPortBaudRate(_serialPort.BaudRate);
    _serialPort.Parity = SetPortParity(_serialPort.Parity);
    _serialPort.DataBits = SetPortDataBits(_serialPort.DataBits);
    _serialPort.StopBits = SetPortStopBits(_serialPort.StopBits);
    _serialPort.Handshake = SetPortHandshake(_serialPort.Handshake.None);

    or, are you leaving it as the default (see the highlighed line below) because the documentation implies that handshaking is not set:

     // Create a new SerialPort object with default settings.
    _serialPort = new SerialPort();
    .
    :
    _serialPort.Handshake = SetPortHandshake(_serialPort.Handshake);

    I suspect the issue is that the default Handshake parameters is to have it active.  


    Okay after finding the Arduino's ATMEGA16U USB to Serial chip's firmware, the RTS line state is set which is what I believe the .NET SerialPort is looking for.  

    Could you please:
    1. Look at the Repetier-Host C# source code and see if the "None" attribute is used with the Handshake during initialization?  
    2. Look at the Repetier-Server source code and check to see if the RTS line is polled there as well?

    Thanx,

    myke

  • Ok, checked the code.

    Handshake is not set explicitly. Have added it in host for next update.

    Server does not set it explicityly, so it is what boost does in that case. Might be on or off, but works on all boards I own.

    Both set Dtr/Rts first low and then high to trigger a reset. So it is not used as part of a handshake but only to trigger special lines on the board.
  • Try this host install

    it sets handshake explicitly to none. Otherwise it's 1.6.1.
  • No Joy with 1.6.2.  Installation went okay.  

    I'll try Repetier-Server presently and report back on how it works.

    Thanx for the quick response.

    myke
Sign In or Register to comment.