Communication problems with Windows

[David Elworthy]

I am having repeatable problems in communicating between a Windows machine and two different boards running Smoothieware. First, I should mention that my test set up is a board connected over USB but not yet installed in a printer and with nothing connected to it. I want to check that the board is working before I do the work of rewiring the printer. So my first question before going any further is: is this a suitable test set up? Or would something in the firmware give up working if there is nothing connected? I have also done these tests with two thermistors but nothing else attached. If the answer is "no, this test set up won't work", then the rest of this message is irrelevant. Otherwise, read on.

Assuming that this is a good setup, here are the symptoms.

Case 1:

a. I connect to the board with Repetier Host.

b. After a short time, usually 2-3 minutes, the M105 commands to read the temperature do not receive a response.

c. A short time after this, I get an error from Repetier Host: "Communication Timeout - reset send buffer block".

d. At this point, the serial lights on the board stop flashing and go either solid on or solid off. Note that I think this is just a consequence of Repetier Host sending an "Emergency" command - see case 2.

e. Typically, the Windows device manager shows an error a short while after this, not on the COM port, but on the USB device associated with it: "Device Descriptor Request Failed".

Case 2:

a. I connect using PuTTy in serial terminal mode.

b. Every now and again I type a command such as ls or help.

c. After the same short length of time, I don't get any response.

d. If I exist and restart PuTTy, the response to the command is now displayed. So the board did read the command, and the board has not stopped worked, but something was blocking the communication.

(Side note: "d" is true with Windows 10, but I think with Windows 7 the communication didn't resume).

I have tried this on two separate boards: a Panucatt Azteeg X5 mini V3 and a MKS SBASE v1.3. Sorry, not true Smoothieboards, but I hope you will forgive me.

The response to the "version" command on the X5 board is:

Build version: edge-3332442, Build date: Apr 22 2016 15:52:55, MCU: LPC1769, System Clock: 120MHz

And I have also tried the master version.

The driver version is reported by Windows as: 5.1.2600.0, dated 3/13/2014.

The communication settings are:

Repetier Host: Serial Connection, COM3, 115200 baud, ASCII protocol, receive cache size 127, communication timeout 40.

PuTTy: COM3, 115200, 8 data bits, 1 stop bit, no parity, no flow control.

Driver: COM3, 115200, 8 data bits, 1 stop bit, no parity, no flow control.

The config.txt file is attached. I have also tried this file with msd_disable=true, on the theory that something might be polling he SD card and interrupting the communication.

As for the host computer, I have tried several configurations:

1. Computer A, a Dell desktop, running Windows 10.

2. Computer A, running Windows 7 (prior to the upgrade to A).

3. Computer B, a different Dell desktop, running Windows 7.

And there are some cases which have worked for at least one hour with reporting any communication errors.

4. Computer A, running Ubuntu 14.04.

5. Computer C, a HP laptop, running Ubuntu.

I believe this points to a problem in the Windows driver, or possibly in the interaction between that driver and the underlying USB stack. The successes on 4 and 5, and the failures on both 1 and 3 suggest the problem is not the host hardware. The failures on 1 and 2 suggest with reasonable probability that it is not the version of Windows. The failure on two different boards suggest it is not the board; they also used different SD cards and USB cables.

The smoothieware pages given an email address to send reports of failed Windows installs to, and I have done this but with no response.

If you have any ideas that could help me, please let me know. I am also very happy to help with detailed debugging. I'm a software engineer by profession so if you need me to do things like running custom builds, I am happy to do that.

[Triffid Hunter]

The windows driver comes with windows - all we provide is a small text file that tells windows to use it with Smoothie's USB because apparently, despite USB being specifically designed to self-describe, it can't work that out for itself.

We have absolutely zero ability to debug/fix/update the windows driver.

Also, Smoothie completely ignores any and all COM port parameters such as baud rate, parity, etc on USB serial, so don't worry about getting them "right".

This sounds to me like your windows OS is configured to put USB devices that haven't been used for a while to sleep or something like that. If you can find a way to stop it doing that to Smoothie, see what happens.

Furthermore, there's known problems with repetier host. We suggest pronterface, although putty should work fine for basic testing too.

If smoothie responds poorly to USB sleep states, that might warrant some investigation, but for the most part (with a few known caveats such as SD card access during printing being problematic) it works fine for almost everyone.

In the meantime, since Linux works perfectly, use Linux :P

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Elworthy]

I will look into USB suspend setting tonight, but it seems puzzling that it would be this. When connected to Repetier, the board is being pinged for the temperature every three seconds, meaning the COM port and the USB hub underneath it are being used, so why would it be a candidate for suspending.

What are the "known problems" with Repetier Host? It has worked with complete reliability for me with Arduino+RAMPS for over a year.

Switching to Linux is not an option, for a wide variety of reasons.

[Triffid Hunter]

We have frequent reports of repetier mangling gcode and doing weird comms stuff that can ruin prints, all the issues disappear when affected users switch to pronterface

[John Gelnaw]

On Saturday, June 25, 2016 at 3:53:07 AM UTC-4, Triffid Hunter wrote:

We have frequent reports of repetier mangling gcode and doing weird comms stuff that can ruin prints, all the issues disappear when affected users switch to pronterface

You know, if I posted somewhere "we have frequent reports of smoothieware locking up and ruining prints, and all the problems disappear when affected users switch to a different firmware", you'd be pretty annoyed.

I've looked for these "frequent reports", and they all seem to stop about 3 years (or more) ago.

I've also been using Repetier Host for 2+ years, with marlin, repetier, and smoothie firmwares, and never had these problems.

Pronterface isn't a terrible utility, but it's seriously lacking in workflow functionality compared with Repetier Host.

On the other hand, "USB selective suspend" under Windows 7 and later (under power management profile) is indeed Evil, and will drive you mental should you fall victim to it.

[Arthur Wolf]

Well, the repetier problem is something that we have people report on IRC at least a few times a month.

It's not a HUGE problem, it's just that repetier will tend to ignore or modify things that it does not understand, where other hosts do not.

It doesn't mean you can't use Smoothie and Repetier together, it just means sometimes it'll do weird or unexpected things. And even then it's pretty rare.

We contacted Repetier a long time ago, they do not care. I'm not sure what more we can do.

So this leads to us telling people "see if it works with Pronterface" when they say they have a problem with Repetier. It's just a way to pinpoint the issue, nobody is trying to force you to use a specific host.

I don't think it's the problem you have here either anyway.

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

[David Elworthy]

I am still unsure whether Windows selective suspend is the problem. Details follow:

- my computer has a Dell-provided power configuration which has USB selective suspend enabled. I changed it to disabled => still fails.

- certain entries in the Universal Serial Bus Controllers selection of the device manager have a Power Management setting with a checkbox for "Allow the computer to turn off this device to save power". Unchecked all of them => still fails.

- there is a registry setting SelectiveSuspendEnabled. Located the specific device using the address found in the COM port device driver info and set it to 0 => still fails.

- downloaded a copy of the Windows Message Analyzer and after wrestling with the interface got it to display the USB events. This does show an error of the type 'SsErr_FailedResumeOnPort', and the fact that this is a Resume implies that there was a Suspend at some point, though it does not appear in the logs. I don't have much idea what I am doing with Windows Message Analyzer, though.

I'm not going to get into the Repetier vs Pronterface discussion, except to say that I think it's a red herring, since as I mentioned I see a problem when using PuTTy as well. I suggest this part of the discussion should be moved to a separate thread if it's going to continue.

I have had Panucatt board work on Ethernet (tested for about 2 hours) without any communication problems, so I might just go that route. Any issues I should be aware of in doing so? As a side note, when I first configured it to use DHCP, it was assigned an address which is not on my LAN: 173.222.239.190. This appears to belong to Akamai. I have it on a fixed IP now.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[wolfmanjm]

I think you have two different problems here.

1. Repetier host requires a special setting to work with smoothie. By default it uses the wrong protocol to talk to smoothie, it presumes there is a serial buffer like Marlin has, the correct protocol for smoothie is send one line, wait for OK send next line, anything else will eventually cause errors. I do not use repetier so cannot say which setting it is you need to make, but when people set the correct communication setting it works.

2. You have a noisy USB cable/too long/No ferrite or not on same power outlet as smoothie PSU causing a ground loop.

Both will cause hangs or disconnects.

[David Elworthy]

I'm fairly confident the USB cable isn't the problem. I have used two or three different ones of varying lengths and two of them with ferrite. The cables have worked fine with plenty of other bare board devices (RAMPS, Arduino, Xmos StartKit, ...).

Reptier has a setting for the protocol (ASCII vs Repetier protocol) and for Ping-pong (wait for ok, as you described) communication. I had already tried the protocol setting. The Ping pong setting doesn't not fix the problem, it just gives slightly different behaviour at the point when it fails (the Communication Timeout error is reported on the first failing command rather then after a few have stacked up. I also increased the communication timeout to 120s, which seems large enough for any reasonable case.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to a topic in the Google Groups "Smoothieware Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smoothieware-support/BrFvenR1_G8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smoothieware-sup...@googlegroups.com.

[David Elworthy]

BTW, I just wanted to say I do appreciate all the replies on this thread.

[dandebo10]

Hi David,

Did you manage to resolve this issue? I also have a problem that sounds very muck like yours.

I think it has to do with the Bloatware that Dell installs on its pc's. I have 2 Dell desktops that keep disconnecting every 10-15 mins. And a HP laptop that works fine.

I just wondered if you managed to identified what caused your issue. 

Thanks in advance

Dan

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to a topic in the Google Groups "Smoothieware Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smoothieware-support/BrFvenR1_G8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to smoothieware-support+unsub...@googlegroups.com.

[David Elworthy]

No, I never found a solution to this. I ended up setting up Repetier Server running on a Raspberry Pi, and having the Pi connect to the printer over USB.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsubscrib...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to a topic in the Google Groups "Smoothieware Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smoothieware-support/BrFvenR1_G8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to smoothieware-support+unsubscrib...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--