Sea World needs help!

Background: Here at Sea World San Diego we have a SLC 5/03 system running our special effects in our 4D theater. The system receiving various inputs on a few digital input cards from a very old DOS based Iwerks show control computer. I was sent to a TWO WEEK crash course in SLC 500 programming so I could write the ladder logic. That all worked out fine. Now I'm installing a new show control system of my design and I wish to communicate from my show control computer via RS-232 dirctly to the PLC and contol my output cards that way, thus eliminating 50 channels of I/O hardware/wiring. I need to know how to code my communications to keep the PLC happy. If I can get a 8 bit code into a register and handle it from there in the ladder logic that would be great!

Two free tickets to the best responce!

Does that include plane fare

There are several DF1 open source applications that may work or at least show you how to develop communications between your program and the plc.
http://www.plctalk.net/qanda/showthread.php?t=32269&highlight=DF1

That is one, also search for threads on DF1, and threads by Jiri Toman and Jason Valenzuela.

Rick,

I suppose it is possible to do what you propose, but I have never done it. PLC programming software is designed to interface with proprietary Human Interface Control program (graphic screen control programs) and the necessary machine-level assembly language computer code is not generally made available at the user level, although there are some who have figured it out.

On the other hand, there are many, many user interface and HMI control programs that will work with a personal computer to control the SLC 5/03. The first one (and probably most expensive) is Rockwell's own RSView32 program, which would allow you to completely control your SLC 5/03 PLC. However, most of these HMI software programs will be set up and tuned for industrial-type machine control.

What I am saying is that it will be much easier to control the SLC with a software program designed for that purpose, instead of trying to write your own.

Those DF1 open source projects and the DF1 protocol command set reference are a great place to start.

A central repository of Rockwell communication developer data:

http://www.rockwellautomation.com/enabled/guides.html

Ordinarily I discourage users from writing their own communication drivers because they can be more complex than most folks realize, no matter what protocol they are using.

Your requirements are fairly simple. Do you know how to calculate a block character check (BCC) or a CRC-16 checksum ? Those are probably the hardest part of the comm driver.

Thanks for the links. I'll check them out.

Rick

I do not know how to setup the BCC or a CRC-16 checksum. i was hoping that I would need to hassle with developing a com driver in the first place. What I'm used to is equipment that specifies a start character, the message in a specific format and an end character, done, simple as that. I guess in the SLC world things are not like that with serial comms? Somehow I should not be suprised.

Rickatsea said:

I do not know how to setup the BCC or a CRC-16 checksum. i was hoping that I would need to hassle with developing a com driver in the first place. What I'm used to is equipment that specifies a start character, the message in a specific format and an end character, done, simple as that. I guess in the SLC world things are not like that with serial comms? Somehow I should not be suprised.

Click to expand...

We couldn't afford to go to Sea World if it were that simple. The salaries have to be justified somehow!

Rickatsea said:

I do not know how to setup the BCC or a CRC-16 checksum. i was hoping that I would need to hassle with developing a com driver in the first place. What I'm used to is equipment that specifies a start character, the message in a specific format and an end character, done, simple as that. I guess in the SLC world things are not like that with serial comms? Somehow I should not be suprised.

Click to expand...

That SLC can work with ASCII but your PC program must also work with ASCII. As shown you can use or create DF1 applications.

The problem is your program is unknown so it is hard to say what can be done. Just because the PC has an RS232 port does not mean your program can use it.

How long would the show PC application have to run for?

iFix will run for 2 hours in demo mode with full functionality and comes with a DF1 driver

Would that work?

Other options would be to dump the PC and go with a panelview/Xycom type solution.

A slightly different approach is Opto22, which is cheap enough and has free HMI software too.
For a small investment that might be a better fit.

Rick,

It seems that your programming level may not be adequate to tackle the software development that would be necessary to interface your Show Control computer with an SLC 5/03 programmable logic controller.

Now your task is to evaluate whether it would be easier to change the Show Control software for some other SLC-compatible software, or change the SLC to some hardware that is already compatible with your existing Show Control setup. In either case, the SLC program will probably need revision.

There are Input/Output modules available that connect directly to a personal computer that might be compatible with your existing program.

Either way, you will have to learn some new software skills, or contract with someone to modify the SLC program for you.

Sure, there are some protocols that are so simple you can draw them on a bar napkin. Having no checksum is great if you don't care about the data integrity or have a magical communications link that never drops a bit.

But in the industrial world the stakes are just as high as they are in entertainment and commerce. That's why we use features like the Transaction Sequence Word and the checksum. We've been building these controllers for decades, and users expect the 1985 units to be compatible with the 2007 units, so archaic addressing modes have to be supported.

Consider this format for a SLC-500 Typed Data Write, from another active thread on the Forum:


SLC-500 Typed Data Write Request:

10 02 01 00 0F 00 75 00 AA 02 97 89 0A 00 58 02 10 03 4B

10 02 Start of Transmission
01 Destination Address
00 Source Address
0F Command
00 Status
75 00 Transaction Sequence Word (TNSW)
AA Function 0xAA Typed Write with Three Address Fields
02 Data size 2 bytes
97 Data File 0x97 = 151 decimal
89 Data File Type = Integer
0A Data File Element = 0x0A = 10 decimal
00 Data File sub-element 0
58 02 Data Values 0x0258 = 600 decimal
10 03 End of Transmission
4B BCC Checksum



You could simplify this protocol.

Eliminate the Source and Destination values, so it's a point-to-point protocol only and not a network protocol.

Eliminate the Command byte, so eliminate about 1/2 the commands in the protocol.

Eliminate the Data Type and Data File. Now you're closer to Modbus, where the Data File is implicit in the Service Code. This reduced the number of data tables in the target system from hundreds to a handful.

Eliminate the checksum. Just trust that the data will come through correctly.


Then you'd be down to a simplified protocol:

10 02 Start of Transmission
AA Function 0xAA Typed Write with Three Address Fields
02 Data size 2 bytes
0A Data File Element = 0x0A = 10 decimal
58 02 Data Values 0x0258 = 600 decimal
10 03 End of Transmission

And I expect you'd be happier with it, and that it would work fine for communication between an I/O device and a show control program.

But it wouldn't be suitable for a general-purpose industrial communications protocol on a general-purpose programmable control system.

I agree strongly with Ron Doran: the fastest path to a solution is to use ASCII Read instructions in the SLC, and just send it strings of data with a start character, data block, and stop character.

It's an afternoon's work for an SLC-capable programmer, and means you don't have to break a sweat learning some new math functions for an error checking mechanism.

You hit the nail on the head. I've worked for 19 years and I can hardly afford it if i had to pay to get in!

This all assumes that the SLC is set up to be completely autonomous, so if messages don't get through the thing simply won't move. Or more importantly, if it is moving and told to stop it doesn't matter if the message actually doesn't make it and it doesn't stop immediately but will stop before it hurts anyone/anything on its own.

With the old hardwired system the command structure was pretty positive. Highly simplified comms can't be trusted to be that solid.

Keith