socket.sendto / UDP problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
When transmitting via UDP to a PLC, I run into a strange problem
where socket.sendto returns double the number of characters sent in the
datagram. I thought this was an error and used Wireshark to sniff the
connection and discovered that it did, in fact, include two copies of
the string I am transmitting in the same packet. The only
thing differentiating this string from prior commands is its length.
The functional ones are between 5 & 7 bytes (with 16 byte responses
received successfully) but transmitting a 66-byte message actually
results in 132 bytes being sent!
I am running 2.6.6 on Windows XP, which I understand has a default
minimum buffersize of 576 bytes which I would think is sufficient.
Apologies if this is somewhat incoherent, I'm cross-eyed from staring
at this!
- - Todd
- -- code --
def PLC_Functions(command, argument):
"""
Command is one of: GetTray, Status, SetText
Argument is one of: tray number (as string), None, message (as string)
The PC transmits and receives on socket 2260 (pcSocket)
The PLC transmits and receives on socket 2002
The protocol used is UDP
"""
MegaMatPLC =
(config.get('megamat','plcip'),int(config.get('megamat','targetport')))
# at some point it will be necessary to wrap these in TRY/EXCEPT to handle
the socket errors
# create UDP socket
pcSocket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM,
socket.IPPROTO_UDP)
# bind it
pcSocket.bind((config.get('megamat','pcip'),int(config.get('megamat','sourceport'
# make them blocking (i/o is 'fire-and-forget' to a PLC that may or may not
respond in a given time.)
# non-blocking fails and raises windows exceptions for some reason
(20-Oct-2010)
pcSocket.setblocking(True)
if command == 'CallTray':
# frame 1 (see docs for frame sequence)
print 'Received call tray command for tray %s' %(argument)
getReadyMsg = '0145\r'
totalsent = 0
while totalsent < len(getReadyMsg):
sent = pcSocket.sendto(getReadyMsg[totalsent:],MegaMatPLC)
if sent == 0:
raise RunTimeError('Transmission failure. Please confirm
MegaMat settings in megapy.ini')
totalsent = totalsent + sent
# Frame 2
response = ''
while response.find('\r') < 0:
response = pcSocket.recv(17)
if response == '':
raise RunTimeError('PLC did not respond')
#this should be changed. The MIF software will wait until it
receives a response or timeout, not ABEND
print response
if response[0:4] == '0135':
print 'Drive ready received.'
#Frame 3
getReadyMsg2 = '016040\r'
totalsent = 0
while totalsent < len(getReadyMsg2):
sent = pcSocket.sendto(getReadyMsg2[totalsent:],MegaMatPLC)
if sent == 0:
raise RunTimeError('Transmission failure. Please confirm
MegaMat settings in megapy.ini')
totalsent = totalsent + sent
# Frame 4
response = ''
while response.find('\r') < 0:
response = pcSocket.recv(16)
if response == '':
raise RunTimeError('PLC did not respond')
#this should be changed. The MIF software will wait until
it receives a response or timeout, not ABEND
print response
if response[0:4] == '0130':
# Frame 5
# Transmit tray request
if int(argument) < 10:
shelfPrefix = ''
else:
shelfPrefix = '000'
shelf = shelfPrefix + argument
unit = '001'
stack = '01'
"""
There is a 10 digit number plus 40 blanks spaces after the
shelf description built above.
It is possible this is for storing shelf descriptions and
barcodes on the PLC. We will
follow the example of the MIF software and put a phony b/c and
blank description.
X is a field terminator and \r is the end of transmission
(EoT.)
"""
fakeBarcode = '1234567890'
fortySpacesField = ' '*40 + 'X\r'
getShelfMsg = '0105' + shelf + unit + stack + fakeBarcode +
fortySpacesField
print 'Transmitting shelf request as follows: \n' + getShelfMsg
print 'Get shelf length %i' % (len(getShelfMsg))
totalsent = 0
while totalsent < len(getShelfMsg):
sent = pcSocket.sendto(getShelfMsg[totalsent:],MegaMatPLC)
print sent, totalsent, len(getShelfMsg)
if sent == 0:
raise Run
Re: socket.sendto / UDP problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 21 Oct 2010 00:07:58 +0100 MRAB 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's bound to a source port (192.168.10.2:2260, the local machine) and just transmits to an address with a port glommed on (192.168.10.1:2002, the PLC). Unfortunately I cannot alter the PLC's logic; it was provided by the vendor without source (and I'm not entirely sure i have the appropriate software to deal with it anyway as we're an Omron/A-B shop). I based this code on the actual conversation on the wire from the utility GUI that came with the storage unit. It ping pongs back and forth on just those two ports, likely because the old controller used a RS232 half-duplex interface. That being said, I don't know for a fact that the PLC cares about the source port -- they are usually pretty "dumb" and only care about the input but you never know what's been hard-coded. I will have to test this. I am primarily interested in the '\r'; it serves as the EOT (ie., 'over' not 'out') I know the response packet size is fixed and it only gets sent once in full. No re-transmission or fragmentation (this is likely by design - full stack isn't really necessary on this kind of PLC.) I'll change my loops to be more pythonic; it reads better. Thanks for your help, - - Todd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkzAVPAACgkQwnknPuQqPIPevgCdGHTXUiJLvyVOgcV12weBRDuV h0AAn0spYoMaxSuyoQi0EwEKXIk+rG20 =sgL9 -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: socket.sendto / UDP problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 21 Oct 2010 17:03:58 +0100 MRAB 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 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's > > bound to a source port (192.168.10.2:2260, the local machine) and > > just transmits to an address with a port glommed on > > (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. Ah, I comprehend now. Thanks! - - Todd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkzAb14ACgkQwnknPuQqPIOYEwCeNQNjGSQ/fwy2kLn862lY4fIk OosAn0WplhDaFE3gVVmyLHrFwfwjfLFm =j9fb -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: socket.sendto / UDP problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 21 Oct 2010 17:03:58 +0100 MRAB 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 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- -- http://mail.python.org/mailman/listinfo/python-list
Re: socket.sendto / UDP problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 22 Oct 2010 00:00:03 +0100 MRAB 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 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 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
Re: socket.sendto / UDP problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 22 Oct 2010 00:00:03 +0100 MRAB 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 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 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. Printing the repr() results in the exact string I built. I infer this to mean that the cause is lower down; either in the socket module or the Windows stack. XP SP2 was known to do buggy things with UDP sockets; I wonder if that is what is causing me grief. I'm going to extract this part of the code and try it on my Linux laptop and see if I can get different results. Thanks for your help, - - Todd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkzBhKcACgkQwnknPuQqPIOf6wCfe8xouwHBJGnC2eHbKo+Eyvjo tw4AnjbSd9gnoAigJsDfowQQ1vM+rkFv =/GQV -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: socket.sendto / UDP problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 22 Oct 2010 00:00:03 +0100 MRAB 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 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 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 respo > >>>>... > >>> 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, I must use only one socket. I have to use a fixed source port as the PLC will respond to that port. If I transmit using .sendto with an unbound socket the source port is picked at random making listening for the response impossible. It was my understanding that there could be a many-to-one relationship between sockets and ports but an attempt to recv without a bind throws an error and an attempt to bind to an already bound port throws an error. I thought the socket operations worked on the buffer so why does multiplexing fail? It shouldn't care how many listeners there are, it should just read the information off the wire and throw it somewhere everyone can read it. Is there a way to specify the source port for a transmission without first binding to it? - - Todd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkzBkV0ACgkQwnknPuQqPIM/4ACeKDGYAUJPdBjyGV2Iu6l/5bA1 X/MAoIWDOvnMhdA0NHXLo2Mv1Nm8kkZZ =4t/0 -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: socket.sendto / UDP problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 22 Oct 2010 10:53:45 -0400 Tom Pacheco 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 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 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
Re: socket.sendto / UDP problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thank you all for your help, I now have a functioning interface. As it
turns out, trying to do things the "correct" way was wrong. The timing
was so tight that doing anything (such as traversing the while-loop
once) instead of a read immediately after transmission meant we missed
the PLC's response. And, for whatever reason, I had to wrap the
outgoing text in bytes() (this is still a mystery, but obviously it
thinks strings going to the socket module are unicode.) The shorter, numeric,
messages were able to complete sufficiently quickly that catching the response
worked within a while loop but not the larger, 66-byte, message.
Again, thanks all for your assistance.
Cheers,
Todd
- The functional code ---
def PLC_Functions(command, argument):
"""
Command is one of: GetTray, Status, SetText
Argument is one of: tray number (as string), None, message (as string)
The PC (arbitrarily) transmits / receives on socket 2260 (pcSocket)
The PLC receives on socket 2002 and responds to whatever port it sees in
the header
The protocol used is UDP
"""
pcSocket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM,
socket.IPPROTO_UDP)
# bind it
pcSocket.bind((config.get('megamat','pcip'),int(config.get('megamat','sourceport'
# make them blocking (i/o is 'fire-and-forget' to a PLC that may or may not
respond in a given time.)
# non-blocking fails and raises windows exceptions for some reason
(20-Oct-2010)
pcSocket.settimeout(1.0) # 1ms? PLC will respond in ~0.10ms
if command == 'CallTray':
# frame 1 (see docs for frame sequence)
print 'Received call tray command for tray %s' %(argument)
getReadyMsg = '0145\r'
totalsent = 0
while totalsent < len(getReadyMsg):
sent = pcSocket.sendto(bytes(getReadyMsg[totalsent:]),MegaMatPLC)
response, address = pcSocket.recvfrom(17)
if sent == 0:
raise RunTimeError('Transmission failure. Please confirm
MegaMat settings in megapy.ini')
totalsent = totalsent + sent
# Frame 2
'''
response = ''
while '\r' not in response:
response, address = pcSocket.recvfrom(17)
if response == '':
raise RunTimeError('PLC did not respond')
#this should be changed. The MIF software will wait until it
receives a response or timeout, not ABEND
'''
print response, address
if response[0:4] == '0135':
print 'Drive ready received.'
# Frame 5
# Transmit tray request
if int(argument) < 10:
shelfPrefix = ''
else:
shelfPrefix = '000'
shelf = shelfPrefix + argument
unit = '001'
stack = '01'
"""
There is a 10 digit number plus 40 blanks spaces after the shelf
description built above.
It is possible this is for storing shelf descriptions and barcodes
on the PLC. We will
follow the example of the MIF software and put a phony b/c and
blank description.
X is a field terminator and \r is the end of transmission (EoT.)
"""
fakeBarcode = '1234567890'
fortySpacesField = '' + 'Todd Was Here' + '
' + 'X\r'
#fortySpacesField = ' '*40 + 'X\r'
getShelfMsg = '0105' + shelf + unit + stack + fakeBarcode +
fortySpacesField
print 'Transmitting shelf request as follows: \n' + getShelfMsg
sent = pcSocket.sendto(bytes(getShelfMsg),MegaMatPLC)
response, address = pcSocket.recvfrom(132)
print sent
print response, address
#Frame 6
'''
response = ''
while '\r' not in response:
response, address = pcSocket.recvfrom(16)
if response == '':
raise RunTimeError('PLC did not respond')
#this should be changed. The MIF software will wait until
it receives a response or timeout, not ABEND
'''
print response, address
pcSocket.close()
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAkzBzN0ACgkQwnknPuQqPINgfQCeN4hm8jDCnwU2niC0dOHkJO8F
+MAAn1/kECizBDEY4doQj1+3+Si9Zyjg
=SvAW
-END PGP SIGNATURE-
--
http://mail.python.org/mailman/listinfo/python-list
