Problem with EN2SE data to ControlLogix PLC

Anybus Support Anybus Gateways
#1

My Anybus device is configured for RS232 Generic Data mode running 9600 baud and have added the device to my PLC configuration. I have the outbound transactions (to the subnetwork) and process tags seemingly working properly as I can send a character string out and it is read properly from my computer Hyperterminal application.

My issue is currently with the inbound transaction (from the subnetwork) which is currently data coming from my Hyperterminal. When I send a text file with the word “STANDBY”, I can monitor the serial log via the HMS Configuration Manager, and I see the characters come thru S-T-A-N-D-B-Y, but the HMS transaction to my high-level network doesn’t seem to function properly. My input process tags on my PLC come thru as S-B, missing all the other characters.

Is this a latency issue? I tried to configured the PLC RPI (requested packet interval), but the lowest setting is 2ms. A data line of 9600 baud is essentially 1.2ms per byte. So is my data essentially being clipped by the limitations of the device configuration for my ControlLogix PLC???

Please help.

#2

If you can see the data in the node monitor and it is correct, than it appears the serial side it working OK. Can you provide the .cfg file?

#4

log.txt (581 Bytes)
generic.cfg (16.0 KB)
Hopefully this worked correctly.

#5

You have the data length as 1. Make the produce and consume data size match and make sure to change the trigger address in PLC, and the counter locations:

image

image

image

image

#6

Well my data incoming from the subnetwork is only 7 characters (7 bytes) exact, hence the data string “STANDBY”. I would like to set the consume data size at 7 bytes, but the problem is the data would pass thru the HMS to my PLC only 1 byte at a time. Is it required that the produce and consume data size must match??? The only way I could receive ANY characters on the PLC side was to either use the VariableData frame object or set my Data frame object to size 1 byte.

You see my log file, does it make sense that “STANDBY” would not populate a 7 byte data mapping in my HMS? When I tried the “Data” frame object with size 7, the HMS subnetwork status would receive errors for “invalid message”, I think because the string was not 7 bytes, it was only 1 byte at a time. Also, my incoming data string does not have a start or end character and no delimiter, so I can’t tell the HMS to look for any special delimiting characters.

#7

The produce and consume data size do not have to match.

You should use the variable data object or 8 bytes (4 registers). Right now you are writing to the same register every character, so when you try to read from the PLC it is getting overwritten too quick.

Keep in mind that the Anybus is addressing registers, which are 2 bytes, so trying to use an odd number of bytes can be problematic and is probably the reason you received an error.

#8

Well I’m not trying to write every character to the same register. I’m trying to write STANDBY with each character being in its own byte, but the HMS doesn’t seem to parse it that way. I can try to do an 8 byte object and do STANDBY_ but I think my result will be the same…

#9

Still can’t figure it out. Changed to STANDBY_, and made my object size 8 bytes, but no data is being populated in the node monitor for the consumed data, it’s not being moved to internal memory. Confirmed that the log still sees STANDBY_, but it seems the HMS cannot move STANDBY_ into bytes 0-7 accordingly. Please help.

#10

Let me make sure I understand. You start logging. You are wring to the trigger byte, 0x012. Then you say that you are seeing the characters ‘STANDBY_’ in the log, like this (except with the extra character ‘_’):

image

And you have the Consume transaction set up like this:

image

You are not seeing the data in this highlighted area?

image

#11

Please help me make sure I understand the trigger byte fully. The manual for the trigger byte says

The trigger byte value will be increased each time a valid transaction has been consumed by the device.

Correct me if I’m wrong, but that byte is read only on the PLC side, not writable. So should I see the counter increment 1 for each character or 1 for the full string?

So far, I have tried with various attempts at setting the consume data length to 1, 7, and 8 bytes. The only time I actually see my sent RS232 data populate in the HMS memory area and at my PLC input tag is when I have it set to data length 1 byte. When I have the data length set to 7 (for STANDBY) or 8 bytes (for STANDBY_), the subnetwork status returns an error for “invalid message”. It seems like when I have the data length set at 7 or 8, the HMS doesn’t read all the characters together as 1 message, but rather each character is it’s own message with a length of 1 byte.

On that note, I tried to enable the Start Character and End Character using the “(” and “)” parenthesis for the delimiting characters, using consume data length 8 bytes, and tried to send the string “(STANDBY_)” with the open and close parenthesis, but still received the subnetwork error for “invalid message”.

#12

To answer your question, yes that is correct, I don’t see the string STANDBY_ populate in the node monitor.

#13

Yes, the trigger byte should be in the Output Area so the Fieldbus side can write to it. It would increment each write, whether the message contained one byte or a string.

Is there a user manual for the serial device? In order to configure the Anybus, we need to know how the serial device is communicating.

#14

Sorry, now I’m confused again, the Consume trigger byte should be mapped to the “Process Tags OUT” ? and this tag should be written by the PLC when it’s supposed to consume data? That doesn’t quite make sense to me. How does the PLC know when data is being sent?

My understanding was the trigger byte value increases each time the Anybus consumes valid data. Right? How does the Anybus operate differently if I disable the trigger byte? It theoretically shouldn’t operate any different.

Unfortunately the manual for my serial device sending the strings to the Anybus is very bland and doesn’t list specifics on the syntax of the string. I have reached out to the team that operates that system for this information but haven’t yet heard back.

#15

Blockquote
Let me make sure I understand. You start logging. You are wring to the trigger byte, 0x012. Then you say that you are seeing the characters ‘STANDBY_’ in the log, like this (except with the extra character ‘_’):
image
And you have the Consume transaction set up like this:
image
You are not seeing the data in this highlighted area?
image

Yes, this is correct. Should I see the data in the highlighted area?

#16

When you enable the Trigger Byte, the Query is issued when the trigger byte value has changed. This feature enables the control system to notify the linking device when to issue a particular Query. To use this feature correctly, the control system must first update the data area associated with the Query/transaction, then increase the trigger byte by one. The location of the trigger byte is specified by the “Trigger byte address” parameter. The trigger byte is checked at the interval specified in the “Update time” parameter.

#17

Please keep in mind that there is a Produce and a Consume trigger byte. The Produce trigger should be (in most cases) mapped to the “OUT” memory area so the PLC can write to it. The Consume is just a counter.

Did you want to go over this by phone? You can reach us at 312-893-5636 or let me know if you would prefer for me to call you.

#18

I feel like I understand how this is supposed to work and have a good idea how to set it up, but for some reason, the consume data just doesn’t seem to want to work for me. I cannot get my STANDBY_ to populate the 8 bytes in memory correctly even though the log shows all of the characters. I’m working on another task today but I may call you later this week for some phone support. Thanks.

#19

Yes, please give me a call when you have a chance and in the meantime, any information that you can get from the OEM about how this device operated will be helpful to us.

#21

Topic closed due to inactivity.