-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 22 Oct 2010 10:53:45 -0400 Tom Pacheco <tomsli...@netp.org> wrote:
> On 10/21/2010 4:05 PM, 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. 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? > > > > Regards, > > > > - - Todd > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.16 (GNU/Linux) > > > > iEYEARECAAYFAkzAnQUACgkQwnknPuQqPIOx6QCgjNP/S/dODwO/c7xk8xKZk1A7 > > IMQAniGKd5yaqRo3nAmHJJsrkEP6iL/j > > =aH+4 > > -----END PGP SIGNATURE----- > > > what version of python are you using? > It sounds like you might be using python 3 which uses unicode for > strings. you would need to switch to bytes like b"Todd" > > - tom > > Python 2.6.6. That being said, there used to be an installation of 3.1 on the system that I removed. Would it be possible for stale .DLLs to interact with the 2.6.6 interpreter? Thanks for your help, - - Todd. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkzBqxoACgkQwnknPuQqPIO0SQCfcxdLqZevWEzWnwzJ8iHxNNLo fIcAniDEHDVGEQhptrvJ/Bd2wqwVezt6 =n8Rx -----END PGP SIGNATURE----- -- http://mail.python.org/mailman/listinfo/python-list