Date: Fri, 27 Oct 2017 06:59:16 -0500 From: Kyle Evans <kevans91@ksu.edu> To: Zaphod Beeblebrox <zbeeble@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: We do serial differently. Message-ID: <CACNAnaFB5yo0bSdKMCSFhkh8GNvS2t4fQA8ujRDxqPQH2GKLWg@mail.gmail.com> In-Reply-To: <CACpH0Mcacy_REUPUSbfJ=6UnrBuPU09zgVEG6ZnCW4tSmG9Ohg@mail.gmail.com> References: <CACpH0Md0ckYH6k5ufAwCoc-_ThtJHrV9%2BdUtp66%2BSSjVuyhpxA@mail.gmail.com> <CACNAnaEu0-mdO9HTgOX8BRF5_FMVsszQzan6RYKEsLzoMgDXjQ@mail.gmail.com> <CACpH0MdpucayKsWzPN86w9tJkydQhhz5eL8GLHfADE1C12kr3A@mail.gmail.com> <CACNAnaGf7yAP6Sc6coNhZVcZyw0OA1ZUvaOu=t3D-tfn4sXwcQ@mail.gmail.com> <CACNAnaFAbKWFJ9NiR=gS8y_9-RDHzNFACZku8mpaphGZHU2Org@mail.gmail.com> <CACpH0Mcacy_REUPUSbfJ=6UnrBuPU09zgVEG6ZnCW4tSmG9Ohg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@ksu.edu> wrote:
> On Wed, Oct 25, 2017 at 11:43 AM, Kyle Evans <kevans91@ksu.edu> wrote:
>
>> On Wed, Oct 25, 2017 at 11:34 AM, Zaphod Beeblebrox <zbeeble@gmail.com>
>> wrote:
>>
>>> On Mon, Oct 23, 2017 at 9:45 AM, Kyle Evans <kevans91@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) +
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaFB5yo0bSdKMCSFhkh8GNvS2t4fQA8ujRDxqPQH2GKLWg>