Trouble with SLC communication

[bdanders]

I have an Allen Bradley SLC 5/03 that I'm using as a DF1 master to pull data from a Unitronics V570. Everything usually works just fine except for one really strange issue. If one of the Integer values that I'm accessing is greater than 4095 and less than 4352 then the message fails and I get no information. All I can guess is that it is probably somehow related to the binary significance of those numbers but other than this, I'm at a loss. I don't even know how to tell which end of the communication is causing it. It is completely repeatable on any of the integer values that are being polled and so far I haven't found any other numbers that duplicate the symptom. I'd really love to hear some theories on what might be causing this. Thanks.

[Damian]

I have an Allen Bradley SLC 5/03 that I'm using as a DF1 master to pull data from a Unitronics V570. Everything usually works just fine except for one really strange issue. If one of the Integer values that I'm accessing is greater than 4095 and less than 4352 then the message fails and I get no information. All I can guess is that it is probably somehow related to the binary significance of those numbers but other than this, I'm at a loss. I don't even know how to tell which end of the communication is causing it. It is completely repeatable on any of the integer values that are being polled and so far I haven't found any other numbers that duplicate the symptom. I'd really love to hear some theories on what might be causing this. Thanks.

So as soon as you get a bit set in the 2^12th place, your numbers are hosed until you then get a bit set again in the 2^8th through 2^11th place? Most likely the DF1 block on the UNI side. What memory address are you mapping to and from? Can you post the configuration parameters you are using?

[bdanders]

So as soon as you get a bit set in the 2^12th place, your numbers are hosed until you then get a bit set again in the 2^8th through 2^11th place? Most likely the DF1 block on the UNI side. What memory address are you mapping to and from? Can you post the configuration parameters you are using?

That certainly seems like what's going on but I can't figure out why it's happening.

Right now I'm doing a vector copy of 30 elements from MI0 to MI1792 so that the addressing on the SLC side matches up. The SLC MSG command reads from the "N7:0" address (which maps to the V570 MI1792) and writes to its own N9:0 address with a length of 30 elements.

The DF1SCAN is configured to run on COM2 with settings initialized at 19200,8,N,1.

[bdanders]

So I decided to see what other integer values might cause a similar failure. I set up a temporary loop on the SLC that increments an integer and then writes that integer to the V570. It then tries to read that value back from the V570. If it is unable to read the same value after 3 seconds, it stores the number. So far the numbers that will cause the message to fail are 16,272,528,784,1040,1296,1552,1808,6064,2320, and 2576. I've only been able to get enough alone time with the machine to check through 2600, but there is already a clear pattern developing here. I just don't know what it means.

[Damian]

So I decided to see what other integer values might cause a similar failure. I set up a temporary loop on the SLC that increments an integer and then writes that integer to the V570. It then tries to read that value back from the V570. If it is unable to read the same value after 3 seconds, it stores the number. So far the numbers that will cause the message to fail are 16,272,528,784,1040,1296,1552,1808,6064,2320, and 2576. I've only been able to get enough alone time with the machine to check through 2600, but there is already a clear pattern developing here. I just don't know what it means.

I am assuming that 6064 is actually 2064?

My first suspicion is that the V570 is incorrectly interpretting the "0001" as an EOT. I wish I had my my SLC03 on hand so I could try and replicate the same error.

Try changing the Unit ID.

Also, what are your comm settings? (ie 19200,8,n,1)

I seem to remember back when I fussed around with this that it was sensitive to a certain baud rate. Possibly changing them may help?

Heres a link to some DF1 info regarding how the info is packaged

http://www.iatips.com/df1_tips.html

If I stumble over my 5/03 sometime soon I'll give it a try.

D

[bdanders]

After doing some more digging, it's becoming pretty clear what is going on. By monitoring the data being sent back from the V570 I've found that if the integer value being read contains hex "10" in either of the bytes (272=h:01 10, 4100=h:10 04) then the DF1 reply message has an extra "10" byte in between the two data bytes in the reply. This causes the reply message to be one byte longer than expected by the SLC, which then rejects it as corrupt. At this point it's pretty clearly a problem with the DF1 function block. Unitronics tech support is involved now, hopefully they can get this sorted out quickly.

[Damian]

After doing some more digging, it's becoming pretty clear what is going on. By monitoring the data being sent back from the V570 I've found that if the integer value being read contains hex "10" in either of the bytes (272=h:01 10, 4100=h:10 04) then the DF1 reply message has an extra "10" byte in between the two data bytes in the reply. This causes the reply message to be one byte longer than expected by the SLC, which then rejects it as corrupt. At this point it's pretty clearly a problem with the DF1 function block. Unitronics tech support is involved now, hopefully they can get this sorted out quickly.

Please be sure to post the resolution on this.

I did find an ML1400 to try out on it.

I was able to write to the V570 with no issues.

I was unable to get a read to perform without error.

In info mode, monitoring the port set to DF1, I can see that the Uni is transmitting the characters. I can't say for certain just yet, but the size of the response seems much too long. I'll have to dig up the DF1 procol and compare the correct framing.

I find this really odd because I have had this working in the past on a SLC and never had any transmission issues.

On a side note.................................

IF you don't have any other DF1 nodes you need to support,

and

IF your SLC5/03 has fairly recent firmware (within the past few years -- actually can be upgraded as well)

and

IF you RSLogix500 software in fairly current (within the past few years

You can instead use the 5/03 as a modbus master. Same port, same cable, same everything. Just a software change.

I have done this in the past and it works much better than the DF1.

Another advantage of this is the Modbus address mapping in the V570 is much less convoluted.

So if you have the choice between using the DF1 and modbus, IMHO I recommend simply switching over to the Modbus protocol.

D

[Damian]

OK .............. The plot thickens.

I instead tried again with my CompactLogix L35E.

Everything all of the sudden was working great again ........ Until............

I tried some of the values you mentioned above

and got Error Code 001F and extended error Code 0204.

So, I have been able to duplicate your issue after all.

This is all starting to make sense now.

The reason I switched to Modbus regarding my earlier post was that I never could get the DF1 communication to work reliably.

Now I finally know why.

I had a hearbeat integer that would just continue to count up in the V570. This was so I could just look for a change in state on that integer to verify that I had communication.

Now It is clear that my comms kept timing out because the number would eventually be read as one of the "hex 10 byte values" and cause the above mentioned error.

I mentioned this way back in the last post of this thread

http://forum.unitronics.com/index.php?/topic/74-the-modbus-blues/page__p__306__hl__df1__fromsearch__1#entry306

I now know it is the same problem you are experiencing.

Judging by the old forum, I suspect this is also what was happening to JOEB

http://www.unitronics.com/forum/topic.asp?TOPIC_ID=2462&SearchTerms=L35E

D

[bdanders]

Damian, I actually read your post about Modbus while I was searching for a solution to my issue. I might give that a try, but I think it's also pretty important to get this issue resolved.

Here are some sample responses that I logged from the V570. Does this look anything like the responses that you're getting? This was the response to a DF1 command attempting to read 1 element from address N7:0 (maps to MI1792). Integer values with an asterisk have an extra byte ("10") between the two data bytes.

Decimal_Hex_______DLE_STX_DST_SRC_CMD_STS_TNS_TNS_Byte1_!!!!_Byte2_____DLE_ETX_CRC_CRC

4000____h:_0FA0_|_10__02__01__00__4F__00__C4__20__A0_________0F____00__10__03__D6__F4

*4100___h:_1004_|_10__02__01__00__4F__00__C4__21__04____10___10____00__10__03__43__76

*16_____h:_0010_|_10__02__01__00__4F__00__C4__23__10____10___00____00__10__03__73__52

15______h:_000F_|_10__02__01__00__4F__00__C4__24__0F_________00____00__10__03__36__23

*272____h:_0110_|_10__02__01__00__4F__00__C4__25__10____10___01____00__10__03__22__F4

*528____h:_0210_|_10__02__01__00__4F__00__C4__26__10____10___02____00__10__03__D2__C7

[Damian]

Damian, I actually read your post about Modbus while I was searching for a solution to my issue. I might give that a try, but I think it's also pretty important to get this issue resolved.

Here are some sample responses that I logged from the V570. Does this look anything like the responses that you're getting? This was the response to a DF1 command attempting to read 1 element from address N7:0 (maps to MI1792). Integer values with an asterisk have an extra byte ("10") between the two data bytes.

Decimal_Hex_______DLE_STX_DST_SRC_CMD_STS_TNS_TNS_Byte1_!!!!_Byte2_____DLE_ETX_CRC_CRC

4000____h:_0FA0_|_10__02__01__00__4F__00__C4__20__A0_________0F____00__10__03__D6__F4

*4100___h:_1004_|_10__02__01__00__4F__00__C4__21__04____10___10____00__10__03__43__76

*16_____h:_0010_|_10__02__01__00__4F__00__C4__23__10____10___00____00__10__03__73__52

15______h:_000F_|_10__02__01__00__4F__00__C4__24__0F_________00____00__10__03__36__23

*272____h:_0110_|_10__02__01__00__4F__00__C4__25__10____10___01____00__10__03__22__F4

*528____h:_0210_|_10__02__01__00__4F__00__C4__26__10____10___02____00__10__03__D2__C7

Our responses are essentially the same.

After some quick research, the "extra" 10h is actually correct. It is called DLE ESCAPING or DLE STUFFING

Any time the DLE character occurs within the Data, Address, or Mask Field, it must be doubled so that the controller does not misinterpret it as a control character.

This still doesn't explain WHY the AB is choking of the incoming data.

I haven't had time to work it out, but I suspect that the Unitronics function is not calculating the checksum properly when DLE ESCAPING occurs. I say this only because otherwise the framing of the data looks to be correct. The checksum gets tricky because it is NOT supposed to account for the "extra" DLEs when performing the calculation.

Oddly, it would be expected that it would also choke when trying to access an address of of say for example (N7:16 > 1808) which are both on the "10h" list.

D

[bdanders]

I think you nailed it. It looks like the V570 is using the "DLE escaping" character as part of the CRC calculation. I'll pass this along to the Unitronics folks so hopefully they can get it resolved quickly.

[bdanders]

The problem has been fixed with a (currently unofficial) OS update. Thanks for all the help.

[Damian]

Has the DF1 issue been remedied in v9.0.1?

[bdanders]

Has the DF1 issue been remedied in v9.0.1?

I'm not positive, but I don't think that the fixed version has been released yet.

[Ofir]

Hi,

Currently the fix has been made in new OS which is not official yet but if you need it please send a mail to support@unitronics.com and we will send you.

Anyway the OS will be released soon.

[Damian]

Thanks guys for the update!

[jbutcher]

I'm running into the same apparent issue as Damian, characters are transmitted but my MicroLogix rejects them with the "Bad parameter in MSG reply packet" error. 

 

Running  Unitronics v1210 on OS v3.006 and a MicroLogix 1400 connected over DF1. Write commands appear to work fine but I haven't found a single read that works, and I've been cycling through various variable types. Very odd. 

 

Very odd.