ABTCP and SLC500/03 communications

Hello all. Hope to get some ideas because I am having issues that are driving me nuts for the past week.

Background info:

AB SLC500/03
Ethernet
Currently using OPCLINK and RSLINX OPC SERVER on a Windows 2003 Server for comms to Intouch 9.5 SP1.
Works well but slow.

I was thinking of bypassing OPCLINK and using ABTCP for direct ethernet comms.

ISSUE 1)

It wasn't that diffcult to configure Intouch and ABTCP to get comms happening but there are a few error messages in the SMC logs.

"Error - When topic 'AUTO_START3' tried to Read the block O0:6 thru O0:10 it encountered the following error:
STS=10: Illegal command or format - check the Topic Configuration dialog, the block sizes may be too large, or the wrong PLC type may be selected"

I was wondering if anyone has encountered this error message before?

ISSUE 2)

Certain registers seem to toggle between 0 and 1 when using ABTCP. This is not normal behavior since the same register when pulled using OPCLINK / RSLINX OPC SERVER is steady. It is a compressor run status. Since it is running it should be 1 and not toggling between 0 and 1.

Again any insight would be appreciated. I aplogise for the vagueness of the post. I am new to this field.

Thanks.

The first problem is that the SLC 5/03 does NOT have an ethernet port. Yes, there is an RJ-45 connector, but that is DH485, NOT ethernet. Hence, the ABTCP driver will not work.

In the SLC line, the only one to have native ethernet is the 5/05.

Hopefully, you have not fried the ethernet port on your computer.

Oops, I may have mis-read the topic configurations in RSLINX. It is an SLC 5/05.

I am sure by now you can tell how green I am in this field.
Sorry and Thanks!


On another note,
As I was scouring the Wonderware forums and I did manage to find some more information about configuring ABTCP with SLC 5/05. I did manage to get rid of the error message I mentioned in Issue 1. But Issue 2 still remains. Still don't know why the values keeping toggling between 1 and 0 when I use WW client to test I/O Server comms.

More wonderful advice please?

Oops again. The Issue #1 is back again. So I am back to square 1.
It seems to be a losing battle. *sigh*

limeister said:

Oops again. The Issue #1 is back again. So I am back to square 1.
It seems to be a losing battle. *sigh*

Click to expand...

As far as I recall, Wonderware's IO Servers simply cannot directly read the Output table directly in SLC's, and might have trouble with the Input table.

Buffer all of your bits into internal B or N addresses, and read them with Wonderware.

I think they can read the I/O tables, but it comes in squirreley (technical term). The way the I/O addresses for WW is not a direct correlation to the I/O addresses in the SLC. So with that said, you are back to rdrast's suggestion of copying your I's and O's to bit or integer registers.

Russell

I was searching the WW forums again and came upon this tech note.
Is this cause of all my woes?

Tech Note 42
Incorrect Values Written to a SLC Processor when using ABTCP or ABDHPlus DAServer
http://wdnresource.wonderware.com/support/kbcd/html/1/t001137.htm

limeister said:

Tech Note 42
Incorrect Values Written to a SLC Processor when using ABTCP or ABDHPlus DAServer
http://wdnresource.wonderware.com/support/kbcd/html/1/t001137.htm

Click to expand...

That's an old bug that's hopefully fixed by now.
If you open the DASABTCP.chm help file, there's a section called "Addressing SLC I/O Modules" under "SLC-500 Item Naming" and it describes how the real IO's are addressed. There's a good example describing how they sequencially address the IO's instead of using the actual IO address.
For a lot less of a headache, do what rdrast suggested.

A silly question but ABTCP and DASABTCP are not the same thing correct?
If I use DASABTCP will it help clear both issues I am experiencing?

Sorry but I am trying to think of alternatives before I start altering PLC ladder code. I am allowed to edit WW as much as I please but the staff here get really nervous when I start mentioning altering PLC code.
It's difficult to get permission here.

DaveW said:

That's an old bug that's hopefully fixed by now.
If you open the DASABTCP.chm help file, there's a section called "Addressing SLC I/O Modules" under "SLC-500 Item Naming" and it describes how the real IO's are addressed. There's a good example describing how they sequencially address the IO's instead of using the actual IO address.
For a lot less of a headache, do what rdrast suggested.

Click to expand...

limeister,
You dont have to change the PLC Logic. Review Dave's post here and check out the section on addressing the I's and O's. I think we all recommend adding logic to the PLC to keep from addressing like this help file describes becuase it is confusing to deal with and easy to make mistakes. The hard part about doing controls is not the programming, but insuring that what you did will be easily maintained and that others will be able to understand what you have done. To that end I would recommend going to the trouble of getting permission to add several MOV statements to your PLC program to transfer registers from the discrete Input and Output tables to Bits or Integers. It may be an easier sell if you make it known that you do not need to make any changes to the existing logic. If you can take the PLC down and add a separate ladder and separate data files for this operation, your logic should be somewhat isolated. If you cant take the PLC down, then you will have to have a block of unused registers, but you can still keep off the running logic. If you use existing registers, make sure you cross reference the registers you use to insure they are not used in the program. I really dont think using another available driver will solve your problem unless you want to purchase RSLinx and let it do the talking.

Review the help file section that Dave has pointed you towards and you will better understand what we have been trying to get across.

Russell

limeister said:

Hello all. Hope to get some ideas because I am having issues that are driving me nuts for the past week.

Background info:

AB SLC500/03
Ethernet
Currently using OPCLINK and RSLINX OPC SERVER on a Windows 2003 Server for comms to Intouch 9.5 SP1.
Works well but slow.

I was thinking of bypassing OPCLINK and using ABTCP for direct ethernet comms.

ISSUE 1)

It wasn't that diffcult to configure Intouch and ABTCP to get comms happening but there are a few error messages in the SMC logs.

"Error - When topic 'AUTO_START3' tried to Read the block O0:6 thru O0:10 it encountered the following error:
STS=10: Illegal command or format - check the Topic Configuration dialog, the block sizes may be too large, or the wrong PLC type may be selected"

I was wondering if anyone has encountered this error message before?

ISSUE 2)

Certain registers seem to toggle between 0 and 1 when using ABTCP. This is not normal behavior since the same register when pulled using OPCLINK / RSLINX OPC SERVER is steady. It is a compressor run status. Since it is running it should be 1 and not toggling between 0 and 1.

Again any insight would be appreciated. I aplogise for the vagueness of the post. I am new to this field.

Thanks.

Click to expand...

Issue 1 is due to a data formatting mismatch between the DASABTCP Server and the SLC500 I/O Image Table. Read the help files with the Server for a conversion map. Better yet, do not directly address real I/O with an HMI. Copy the data into a register instead.

Issue 2 is a feature, not a bug. Most PLCs limit an HMI's read window to the housekeeping portion of their sweep. AB PLC5 and SLC500 PLCs do not. Since reads can update mid-sweep, you should use internal device status registers for your status logic and then move them to a different set of registers at the end of the Main program block to be read by the HMI. This prevents the "blinking" that occurs if the last valid state of the registers after the PLC sweep is complete is not what your I/O Server is reading.