-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 22 Oct 2010 00:00:03 +0100 MRAB <pyt...@mrabarnett.plus.com> wrote:
> On 21/10/2010 21:05, Todd Walter wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Thu, 21 Oct 2010 17:03:58 +0100 > > MRAB<pyt...@mrabarnett.plus.com> wrote: > > > >> On 21/10/2010 15:57, Todd Walter wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> On Thu, 21 Oct 2010 00:07:58 +0100 > >>> MRAB<pyt...@mrabarnett.plus.com> wrote: > >>> > >>>>> > >>>> [snip] > >>>> > >>>> The docs for 'sendto' say: > >>>> > >>>> """The socket should not be connected to a remote socket, > >>>> since the destination socket is specified by address.""" > >>>> > >>>> Could your problem be caused by you binding the socket to a > >>>> source port, so it's going out both to the bound port _and_ the > >>>> one given the binding? > >>>> > >>>> Have you tried using two sockets, one outgoing and the other > >>>> incoming? > >>>> > >>>> BTW, your code for handling the response doesn't cope with it > >>>> coming in a bit at a time. It loops discard any previous data > >>>> from the previous iteration. > >>>> > >>>> Also, it's more Pythonic to say: > >>>> > >>>> while '\r' not in response: > >>>> ... > >>> I haven't bound the socket to a remote port, as I read it; it'sp > >>> bound to a source port (192.168.10.2:2260, the local machine) and > >>> just transmits to an address with a port glommed onu sn > >>> (192.168.10.1:2002, the PLC). > >> [snip] > >> What I meant was that you're using 'pcSocket' for both directions > >> and using .bind on it. > >> > >> Try creating two sockets, 'pcInSocket' and 'pcOutSocket', and bind > >> only pcOutSocket. > > > > As it turns out, Windows will throw a 10022 if you try > > and .recvfrom on an unbound port so I went back to the old way as > > it didn't seem to be related to my problem. > > > Oops! I should've said "bind only pcInSocket". Sorry! :-( > | > > I re-captured the packets from the utility again and I noticed > > that my text string is getting s p a c e d o u t in the datagram > > whereas the primary utility sends a nice cohesive "spacedout". My > > early transmissions work this way, successfully, as well and I > > think it is because either Python or Windows is treating my text > > strings differently than my numerical strings; more clearly when I > > send "1234" it goes out "1234" and when I send "Todd" it goes out > > as "T o d d ". This will obviously overflow the PLC and cause a > > reset. > > > > Any ideas? > > > If they're all bytestrings then the contents shouldn't matter. Try > printing their repr just to check. No problem. I will keep trying until I get it! :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkzBfuEACgkQwnknPuQqPIM0RACbBIqd8Ajf0APavZP4GkjeXSG0 DL4An07ZH+N5MVq8rru/OmsOpoR1CmnN =QFwU -----END PGP SIGNATURE----- -- http://mail.python.org/mailman/listinfo/python-list
