We do serial differently.

[Zaphod Beeblebrox]

I've tried hacking at directly.  I can't send it a file (as in that 
script) because the printer isn't setup yet.  I'm still working on it.

... I have poked on the .send() method (with M105) ... and that doesn't 
seem to have effect.  Also ... if I ctrl-C the python process, it 
doesn't exit.  I'm not patient... but so far I've only been able to exit 
with CTRL-\ ... (core dump).


On 27/10/2017 07:59, Kyle Evans wrote:
> What happens if you just invoke printcore directly, like the example 
> script in the printrun readme?
>
> Pronterface has got to be doing something not-entirely-sane here. The 
> reset should always coincide with the port being open()d, and it 
> should behave like the Arduino IDE and cu(1) do. The mega doesn't 
> really have any crazy requirements just to function properly.
>
>
> On Oct 26, 2017 11:46 PM, "Zaphod Beeblebrox" <zbeeble at gmail.com 
> <mailto:zbeeble at gmail.com>> wrote:
>
>     OK.  I played with this all again ... a bit.
>
>     Firstly, when I run "arduino" (the IDE) ... the arduino board
>     resets  immediately (I can tell this because it has an LCD screen
>     attached).
>
>     But when I run pronterface, it doesn't reset until 5 seconds
>     (roughly) after pronterface exits.
>
>     I tried adding a hardcoded setDTR(0) or setDTR(1) near this code
>     ... but it doesn't seem to make any palpable difference.
>
>     On Wed, Oct 25, 2017 at 1:11 PM, Kyle Evans <kevans91 at ksu.edu
>     <mailto:kevans91 at ksu.edu>> wrote:
>
>         On Wed, Oct 25, 2017 at 11:43 AM, Kyle Evans <kevans91 at ksu.edu
>         <mailto:kevans91 at ksu.edu>> wrote:
>
>             On Wed, Oct 25, 2017 at 11:34 AM, Zaphod Beeblebrox
>             <zbeeble at gmail.com <mailto:zbeeble at gmail.com>> wrote:
>
>                 On Mon, Oct 23, 2017 at 9:45 AM, Kyle Evans
>                 <kevans91 at ksu.edu <mailto: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) +
>
>
>
>