We do serial differently.

[Kyle Evans]

On Wed, Oct 25, 2017 at 11:43 AM, Kyle Evans <kevans91 at ksu.edu> wrote:

> On Wed, Oct 25, 2017 at 11:34 AM, Zaphod Beeblebrox <zbeeble at gmail.com>
> wrote:
>
>> On Mon, Oct 23, 2017 at 9:45 AM, Kyle Evans <kevans91 at ksu.edu> wrote:
>>
>>> Hi,
>>>
>>> Are you able to connect to it otherwise (w/ cu or friends) and issue,
>>> say, an M105 manually?
>>>
>>
>> yes.  With CU I can connect, it resets, then I can issue an "M105<cr>"
>> and it parrots back some status.
>>
>
> Ok, cool, that's expected and sounds like Pronterface is doing something
> it shouldn't be.
>
> I'll poke at it a little bit more- last I checked, it didn't look like it
> was doing anything too crazy with pyserial and I've got a working OctoPrint
> (w/ pyserial) setup, so I know that works to some extent.
>
>
For the sake of argument, can you try applying the following patch [1] to
printrun? I don't see a need to be toggling DTR here, and that might narrow
things down a little bit.

[1]
diff --git a/printrun/printcore.py b/printrun/printcore.py
index b54e750..fd531c3 100644
--- a/printrun/printcore.py
+++ b/printrun/printcore.py
@@ -218,11 +218,6 @@ class printcore():
                                           parity = PARITY_ODD)
                     self.printer.close()
                     self.printer.parity = PARITY_NONE
-                    try:  #this appears not to work on many platforms, so
we're going to call it but not care if it fails
-                        self.printer.setDTR(dtr);
-                    except:
-                        #self.logError(_("Could not set DTR on this
platform")) #not sure whether to output an error message
-                        pass
                     self.printer.open()
                 except SerialException as e:
                     self.logError(_("Could not connect to %s at baudrate
%s:") % (self.port, self.baud) +