Re: Process Control Help
On Jul 28, 1:40 am, "Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote: > <[EMAIL PROTECTED]> wrote: > > > I'm attempting to start some process control using Python. I've have > > quite a bit of literature on networking, and have made some tinkering > > servers and clients for different protocols HTTP, FTP, etc... But now > > it's time for the murky web of industrial protocol. I'm looking to > > start with IO and servo controls via Ethernet. > > > Questions: > > > Is there an existing forum on this already? > > What protocols are the most python friendly? i.e. are transparent > > enough that i can create my own python driver. (or do these drivers > > exist?) > > What ethernet accesible servo and IO industrial devices have people > > had success with? > > What is it that you are trying to do? > Some of the commercial devices come with their own software, and > you may not need python or anything else. > A lot of the industrial connectivity is still RS-485 or RS-422 and not > Ethernet based - although some of the protocols, have, I think, been ported. > > If you say more, then someone can maybe help you, as there are quite a few > people on this group who seem to dabble in process control. > > - Hendrik- Hide quoted text - > > - Show quoted text We're looking to run some industrial machinery from a PC. Starting with some basic servo controls and IO port reading for something like an XYZ table (just X would be a good start!). Now there is some existing software out there for PC control but this software is, to my understanding, largely unnecessary and "black box". This "black box" creates a problem when trying to e.g. control servos and IO with the same program. And if we want to include an HMI like a touchscreen, or export the machinery's production into a RSS feed, the web of software becomes messy and slow. If we could consolidate this software into a single, non "black-box" package, we could see significant improvements in development time. Having to program 3 different devices with three different languages to control your PLC, Servos, and module X is the status quo we face, but it is quite frustrating and limited. Soo I need to find some ethernet friendly IO, serial would be fine but but it's a leash in many instances. I know some protocols have been ported to ethernet, but I am having extreme difficulty figuring out what these protocols entail. ModBus/TCP is the one I'd like to choose. I know that people have done this kind of software but it seems that industrial python remains a bit taboo because of proprietary issues... Ty -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption recommendation
On Jul 31, 10:19 am, "JS" <[EMAIL PROTECTED]> wrote: > Can someone help me find the proper way to do AES encryption/decryption > using Python? > > Thanks! I did a quick look around the internet and found this seemingly good link AES in general. Might be a good start. http://msdn.microsoft.com/msdnmag/issues/03/11/AES/#S4 Looks like you'll need some matrix manipulations modules, and hopefully you'll be able to utilize Python's indexing and data strengths to keep things simple! -- http://mail.python.org/mailman/listinfo/python-list
Re: Process Control Help
On Jul 31, 12:45 pm, Walt Leipold <[EMAIL PROTECTED]> wrote: > Azazello wrote: > > > We're looking to run some industrial machinery from a PC. Starting > > with some basic servo controls and IO port reading for something like > > an XYZ table (just X would be a good start!). Now there is some > > existing software out there for PC control but this software is, to my > > understanding, largely unnecessary and "black box". This "black box" > > creates a problem when trying to e.g. control servos and IO with the > > same program. And if we want to include an HMI like a touchscreen, or > > export the machinery's production into a RSS feed, the web of software > > becomes messy and slow. > > > Soo > > I need to find some ethernet friendly IO, serial would be fine but but > > it's a leash in many instances. I know some protocols have been > > ported to ethernet, but I am having extreme difficulty figuring out > > what these protocols entail. ModBus/TCP is the one I'd like to > > choose. > > > I know that people have done this kind of software but it > > seems that industrial python remains a bit taboo because of > > proprietary issues... > > It has nothing to do with 'proprietary issues'. A lot of it has to do > with the perception of support -- who will support Python and custom > Python code if my plant shuts down? Who will train my developers and > operators? Who can I sue? The rest of it is because of the way the > industry evolved, and the kinds of programmers and development teams > that write industrial control packages. > > > If we could consolidate this software into a single, non > > "black-box" package, we could see significant improvements > > in development time. > > You *might* save on development time (although I wouldn't bet on it), > but you'll lose on testing time. Heck, you'll even lose because you > have to document your stuff and train people to use it -- what happens > to your custom system if you get hit by a bus? > > > Having to program 3 different devices with three > > different languages to control your PLC, Servos, and module X is > > the status quo we face, but it is quite frustrating and limited. > > I share your frustration with the status quo in industrial automation. > On the other hand, I've been brought in to customer sites a number of > time to fix their re-invented wheels, and my advice is not to re-invent > the wheel. > > Yes, it's a shame that you have to buy three packages to perform three > functions, and then buy other 3rd-party packages to tie them together. > Yes, it's a shame that industrial software is expensive, and > proprietary, and Windows-only, and generally has a brain-dead scripting > language (when it has any scriptability at all). Still, as much as it > galls me to say it, if your company's primary business isn't writing > industrial automation software, don't write industrial automation > software. > > For reasons of quality, long-term supportability, manageability, > insurability, and several other -ilities, the sad facts are: > > * Unless you're a hobbyist, if you want to do machine/motion control, do > it from a PLC. Windows is not reliable, stable, or real-time enough to > be trusted to control moving pieces of hardware, and custom software, > possibly with hand-crafted multithreading, is not as reliable or > predicatable as ladder logic on a PLC. (Look up "Therac 25" for some > reasons why.) Python is a great language, but it depends on the > underlying OS for threading, and has a GIL that can bite you too. The > first time you see twenty tons of machinery move unexpectedly because > you inadvertently changed one bit in memory, you become very > conservative about your software platform. > > * Unless you're a hobbyist, if you want to do data acquisition or i/o, > purchase an i/o server for your particular bus/instrumentation from a > major manufacturer. You *can* write your own i/o server, especially for > simple protocols like Modbus, but the commercial versions have been > tested more exhaustively than you can manage. Also, the most common > protocol these days is OPC, which isn't a protocol at all in the > conventional sense -- it's a set of APIs to a Windows DLL, with the > wire-level details completely opaque -- so you'd have to buy a library > for that anyway. > > * Unless you're a hobbyist, if you want an HMI, purchase LabView or > InTouch or RSView or whatever, and use their tools to draw and > 'configure' your screens. (
Re: sending very large packets over the network
On Aug 1, 8:50 pm, Gary Herron <[EMAIL PROTECTED]> wrote:
> Walker Lindley wrote:
> > OK, I'm back with another networking question. I'm trying to seend
> > large amounts of information over TCP (the length of data being given
> > to send() is on the order of 16000 characters in length).
> > Unfortunately on the receiving end, the packets appear to be
> > truncated. So I wrote some code that continuously tries to send bigger
> > and bigger packets until it fails and noticed that it never fails at
> > the same length. I'm not even sure these two things are related, but
> > is there some undocumented (or documented and I missed it) maximum
> > size for data you can pass to send()?
>
> For ethernet connections the size is often about 1500. But the size
> depends on the underlying protocol, and even if you know the underlying
> protocol along the full route, you can't rely on packets that are
> received being the same as those that are sent.
>
> TCP/IP is a *stream* connection. What you are guaranteed is this: All
> the bytes that are sent from one end will be received eventually on the
> other end, in the proper order. (Or failing that, you will receive an
> error notification.) No guarantee is made about the packet sizes on
> either end, and you can't even rely on the packets being the same in
> number or length on the two ends.
>
> Your send code can try sending a packet of any size, but it must be
> prepared to examine the number of bytes actually sent, and retry with
> the remainder in a loop until all bytes are sent.Similarly your
> receiving code must loop around the receive accepting whatever sized
> packets makes it through the connection.
>
> In many TCP/IP connections, it seems that the packets received are
> one-for-one with the packets sent, but relying on this *IS AN ERROR*
> that will bite you. It fails to across the internet (sometimes) and
> when (at least some) wireless cards are involved.
>
> You may be better off using a package that knows all this and handles it
> properly. Modules asyncore and asynchat are one possibility.
>
> Gary Herron
>
>
>
>
>
> > the sample code is as follows
> > #server
> > import socket
>
> > s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> > s.bind(("", 2000))
> > s.listen(0)
> > sock, addrinfo = s.accept()
> > for i in range(2 ** 16):
> > length = int(sock.recv(16))
> > print "excpecting data of length:", length
> > data = sock.recv(length)
> > print "received data of length:", len(data)
> > print
> > s.close()
> > sock.close()
>
> > #client
> > import socket
> > import time
>
> > s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> > s.bind(("", 2001))
> > s.connect(("localhost", 2000))
> > for i in range(2 ** 16):
> > packet = "h" * i
> > s.send("%16d" % len(packet))
> > print "attempting to send data of length:", len(packet)
> > tmp = s.send(packet)
> > print "actually sent data of length:", tmp
> > print
> > time.sleep(.001)
> > s.close()
>
> > i just put them in different files and ran them from the command line.
> > Any help or suggestions would be greatly appreciated. Thanks.
>
> > -Walker
>
> > --
> > This e-mail is licensed under the Creative Commons
> > Attribution-NoDerivs 2.5 License. To view a copy of this license,
> > visithttp://creativecommons.org/licenses/by-nd/2.5/or send a letter
> > to Creative Commons, 543 Howard Street, 5th Floor, San Francisco,
> > California, 94105, USA.- Hide quoted text -
>
> - Show quoted text -
I'm not an expert on networking so take my advice with a grain of
salt!
My guess is that you're encountering race-like conditions between the
send and recv. commmands because you're running your communication
command 2^16 times, hoping that send and recv. are synchronous on
every step. This is especially true when you're running other
commands in your data sending loops! Prints take quite a lot of time.
Also, the send command in C (i'm not sure if this is true in python)
does not guarantee that all of your data gets out.
I'm assuming that you're somewhat new to networking so I would
recommend shying away from running an Asynchronous polling server.
Although it is probably a better way to do this.
My suggestions:
Write a while loop in the server with some end of stream checking,
timeouts, et cetera. This will give you a bit of flexibility and
feedback when things go to pot. Use the sendall() command in your
client because it throws an exception if data isn't properly sent. and
will eliminate a unsightly for loop.
Client
socket.sendall(data)
Something akin to this old piece of test code
datastream = ''
## A timeout exception is thrown if the receiver is waiting on the
line for .25 seconds
socket.settimeout(.25)
while 1:
try:
buf = socket.recv(1024) ## If data on line put in buffer
except socket.timeout: ## Data buffer timeout, breaks
while loop
break
if buf == '': ## If an empty buffer, jump to top of loop (beginning
of file c
Re: Python Book Recommendations
On Aug 15, 7:47 am, "Shawn Milochik" <[EMAIL PROTECTED]> wrote: > If I could have only one book, I would buy "Core Python, Second > Edition," by Wesley Chun. > > For the record, I own: > Core Python, Second Edition (great) > wxPython in Action (haven't used yet) > Beginning Python (barely used) > Python in a Nutshell (use as a reference, although interactive python > dir() is more useful) > Dive into Python (great book) > Python Cookbook (great book) > Python Pocket Reference (not very useful) > Python Phrasebook (I love the Phrasebook series, but this isn't a > necessary book) I would like to add: Foundations of Python Network Programming I also use the Python Essential Reference. (although all of the information is probably online it's nice to have a solid paper reference) -- http://mail.python.org/mailman/listinfo/python-list
