Shop OBEX P1 Docs P2 Docs Learn Events
Industrial Ethernet/IP or CIP communication to an Allen Bradley SLC — Parallax Forums

Industrial Ethernet/IP or CIP communication to an Allen Bradley SLC

Shane MShane M Posts: 58
edited 2009-09-10 13:53 in Propeller 1
I need to talk to an Allen Bradley SLC via Ethernet IP to read registers.

I have the pink internet module that will communicate via UDP.

I understand I need to communicate via port 2222 in UDP.· However I can't find out any more.

I may be wrong to assume the PINK would do it.· Though I'm pretty sure it will based on my reading so far.

Does anyone have experience with this.· I would pay for your time if I could get some sample code started.· I have an SLC to test with.

Thanks in advance.· Shane

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2009-09-05 04:53
    Have you looked at page 10 of the PINK documentation? This gives an example of sending a text UDP message to a particular IP address and Port. There's a status register that indicates that a UDP message is received (see pages 8 & 9).

    If you're going to use a Stamp with the PINK, post any further messages to the Stamp forum. If you're planning to use a Propeller, continue with this thread.

    Do you have the Allen Bradley SLC documentation that describes the UDP messages needed and the responses?

    If you are going to use a Propeller, then the FullDuplexSerial driver is the usual way to do serial I/O. There is an Extended FullDuplexSerial object in the Object Exchange that can help you handle strings and numeric data received from the PINK.
  • hinvhinv Posts: 1,255
    edited 2009-09-05 05:02
    Hi Shane,

    I would do more information gathering before nailing down hardware. Do you have a working connection to the SLC now?(just what is an SLC anyway?)
    Would it be possible to put a hub on that connection and use something like Ethereal on linux to start grabbing packets.
    Are there any tight timing constraints. Is all communication ack'd at the application layer?
    As far as experience with ethernet goes, do a search for Harrison. He has written an IP stack for the propeller that uses a less expensive solution(enc28j60) than the pink module.

    http://harrisonpham.com/dp/proptcp

    For hardware, check out:
    http://ucontroller.com/documentation/PropNICDoc.html
    and
    http://shop.ebay.com/i.html?_nkw=enc28j60&_sacat=0&_trksid=p3286.m270.l1313&_odkw=enc28j6o&_osacat=0

    I have nothing against the PINK, but I haven't read much about it and it is kind of pricey and seems like overkill for the application you are talking about.

    I hope this helps,

    Doug

    Post Edited (hinv) : 9/5/2009 5:18:26 AM GMT
  • dMajodMajo Posts: 855
    edited 2009-09-05 06:35
    Mike said...
    ... Do you have the Allen Bradley SLC documentation that describes the UDP messages needed and the responses? ...

    Hinv·said...
    I would do more information gathering before nailing down hardware. Do you have a working connection to the SLC now?(just what is an SLC anyway?) ...

    It's a PLC from Allen Bradley (Rockwell Automation): here is the SLC 5 and SLC 5/05 ethernet documentation



    @Shane, I do not know the PINK module and haven't got time to read its documentation. It is some time now that I am testing the TIBBO platform. For testing/development pourposes I have taken the EM1000 because of the storage (1MB) and IOs. The smallest one is EM203(64KB). It comes preprogrammed as a serial device server but you can change the firmware and obtain the full TIOS platform (programmable in basic). This way you can handle the communication with it and exchange only the needed data with the prop. It depends on your (prop) application requirements, if you want to handle the tcp/ip stack by prop or not.


    With the EM1000 I have never used all the program storage and when I have some spare time I want try to boot the prop from it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    · Propeller Object Exchange (last Publications / Updates)
  • hinvhinv Posts: 1,255
    edited 2009-09-05 12:20
    To counterbalance my comment on the price and it being overkill, I have had a look at the documentation of PINK, and It looks quite good and simple to use. If you buy a module on ebay, don't expect any where near the kind of tech support you will get from parallax.

    Doug
  • Peter NachtweyPeter Nachtwey Posts: 9
    edited 2009-09-05 13:10
    My company has three Ethernet/IP certified products and we were one of the first to other than Rockwell to have a Ethernet/IP certified product.
    Etherent/IP is a difficult application layer to implement. I would strip down the goal to be able to transfer only N files or maybe F files too but you can get by with just reading and writing N files. To read and write B, I, and O files you will need to COP the data to and from the N files.

    I see a few problems.
    The Ethernet/IP protocol isn't always 32 bit aligned. There will be a lot of data shuffling to access bytes and words. I have implemented DF1 on a DSP that only has DINTs and it was painful to access the bytes within the DINTs. It requires a lot of shifting and masking.
    2. Even a minimal Ethernet/IP stack will be around 10KB above the TCP/IP stack. That is just for the code. It may be much bigger because 32 bit controllers often have bigger code sizes than 16 bit computers. Especially when they can't manipulate bytes within a COG.
    3. The memory required for buffers and for each connection will eat up too much of the available ram. If you limit the transfers so that only one transfer can be in progress at one time then you may have a chance. You will also have to limit the size of a TCP/IP transfer to sizes where the packets will not fragment.
    4. The propeller chip is much better at replacing the PLC itself. Just think about it. Scan times in the 100 microsecond range. I don't think the Propeller chip is a good choice for the Ethernet. I would consider using SPI to talk a more Ethernet friendly micro controller and use the propeller chip(s) to replace the PLC and do the industrial I/O.
  • localrogerlocalroger Posts: 3,452
    edited 2009-09-05 15:09
    The situation is not as dire as Peter makes it out to be. I've been experimenting with the ENC28J60 (via ucontroller.com's propNIC board) and the protocol drivers written in Spin by Harrison http://harrisonpham.com/dp/proptcp . Spin isn't very fast but it has no trouble with byte-aligned data Harrison's stack does work while leaving most of Hub RAM free. Since Shane's PLC communicates via UDP, a lossy protocol that doesn't require buffers for packet ordering or retransmission, a much more basic implementation would probably suffice.
  • WurlitzerWurlitzer Posts: 237
    edited 2009-09-05 16:11
    Shane, please keep us posted with your progress. AB is one of the more difficult companies to communicate with their products PLC, Drives, HMIs.. you name it. They tried their best to obfuscate as much of their protocol as possible in an attempt to lock you in completely to their "Integrated Architecture" .

    Their communication modules are overly expensive and as I have found out over the 26+ years dealing with them they no longer are the high quality solution. When Rockwell purchased them the strong AB brand was not treated well

    If I were ever to be appointed to head the AB/Rockwell software operations the first thing I would do is start hiring replacements for everyone except those who designed the ControlLogix series (minus the communication of course).

    I would be very interested to see what you end up with.
  • Erik FriesenErik Friesen Posts: 1,071
    edited 2009-09-05 17:43
    That is interesting to hear, Wurlitzer. I tried talking to some AB frequency drives with automations directs products via rs485, and automation would not let me enter the drives address, but told me it was out of range of acceptable addresses. Maybe I just didn't know how.
  • Shane MShane M Posts: 58
    edited 2009-09-05 18:25
    What a great group of people! Thanks!

    So far all comments are helpful.

    Peter has encouraged me because I ONLY need to read N registers (integers). All I need to do is read that value. Not write. Not COP (I believe is the object oriented protocol). Nothing else.

    And btw I agree 100% on Allen Bradleys approach and current posture.

    More info would be appreciated if this narrows it down.

    Also as a side note. I already communicate to the plc via rs232. However newer slc/plc units don't have serial ports. For once I'm just trying to plan ahead. [noparse]:)[/noparse].

    Shane
  • Shane MShane M Posts: 58
    edited 2009-09-05 20:49
    Thanks.· That is also encouraging.

    I'm trying to reduce this to the most basic components.· If I can connect via UDP port 2222 and I have the SLC address.· I'm thinking I just need to know what characters to SEND.· Then figure out what to do with what I get back.

    Many of the protocol charts I read keep comparing this to SMTP, POP3, and other UDP protocols.· They all work on the same principal.· So I am looking for those final keys to the puzzle.

    Shane
    localroger said...
    The situation is not as dire as Peter makes it out to be. I've been experimenting with the ENC28J60 (via ucontroller.com's propNIC board) and the protocol drivers written in Spin by Harrison http://harrisonpham.com/dp/proptcp . Spin isn't very fast but it has no trouble with byte-aligned data Harrison's stack does work while leaving most of Hub RAM free. Since Shane's PLC communicates via UDP, a lossy protocol that doesn't require buffers for packet ordering or retransmission, a much more basic implementation would probably suffice.
  • Shane MShane M Posts: 58
    edited 2009-09-05 21:02
    Good questions: Here is the top level stuff that talks about the N (integer registers).· http://www.abmicro.pl/appli/pdf_1/aiABTCP.pdf

    It also says the protocol standard is PCCC.· http://www.ctiplcio.com/manual/abeth.htm· So far this is the closest I have to an answer.· I'm still researching right now.

    Thanks!
    Mike Green said...
    Have you looked at page 10 of the PINK documentation? This gives an example of sending a text UDP message to a particular IP address and Port. There's a status register that indicates that a UDP message is received (see pages 8 & 9).

    If you're going to use a Stamp with the PINK, post any further messages to the Stamp forum. If you're planning to use a Propeller, continue with this thread.

    Do you have the Allen Bradley SLC documentation that describes the UDP messages needed and the responses?

    If you are going to use a Propeller, then the FullDuplexSerial driver is the usual way to do serial I/O. There is an Extended FullDuplexSerial object in the Object Exchange that can help you handle strings and numeric data received from the PINK.
  • WurlitzerWurlitzer Posts: 237
    edited 2009-09-06 14:26
    Erik Friesen said...
    That is interesting to hear, Wurlitzer. I tried talking to some AB frequency drives with automations directs products via rs485, and automation would not let me enter the drives address, but told me it was out of range of acceptable addresses. Maybe I just didn't know how.

    Erik, on AB Drives (something I have dealt with in depth) you also have to be very careful of the version of the drive. For example a PowerFlex 70 with Enhanced Control and Standard Control

    AB priced "Enhanced Control" lower to encourage people to buy this and it did have additional features. HOWEVER and it is a big HOWEVER, if you have this drive on a network originally configured for "Standard Control" (which had a mix of 16 and 32 bit words) the communications would get all screwed up attempting to communicate with an Enhanced Control drive which had all 32 bit words.

    I had a customer who, in an attempt to save money, bought a slew of Enhanced Control drives for backup (without consulting me) and of course they needed one late one Sunday and could not get their SCADA system to communicate. They were not happy.
  • Shane MShane M Posts: 58
    edited 2009-09-07 02:52
    Ok guys. Unless anyone has any other advice. I think I'll first write a test communication program in perl or C on my PC and see if I can get this talking. Then I can worry about how to do the same with the propeller. Any other advice?
  • Shane MShane M Posts: 58
    edited 2009-09-10 03:50
    Ok everyone. Before I start hacking code. Does anyone disagree that "in theory" I should be able to connect to the SLC via UDP and with the right combination of writing data and waiting for the response I should be able to read an N register? Eric and Wurlitzer seem to have the best handle on what I'm trying to do. Any further advice/comments?

    Shane

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    Shane Merem
    www.websiteforge.com
    www.magnusoft.com

    ·
  • kb2hapkb2hap Posts: 218
    edited 2009-09-10 11:58
    there is a guy named archie in the plcs.net forums and the mrplc.com forums who have written ethernet drivers for the SLC's in VB.net he has the source listed on sourceforge under something like abethernet. take a look it may help you out a bit.
    dan

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    DTQ
  • Shane MShane M Posts: 58
    edited 2009-09-10 13:53
    Thanks!· That may be the break I need!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    Shane Merem
    www.websiteforge.com
    www.magnusoft.com

    ·
Sign In or Register to comment.