[Trouble with SLC communication]

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.

[Bug report 901]

I may be experiencing a similar issue. I tried to change all occurences of a binary image on a V570, but after changing it the image no longer appears on the screen and each screen that has an image is unresponsive. I have tried removing all of the images and the screens will work, but if I try to add any images back to the screens, they freeze again.

[Trouble with SLC communication]

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

[Trouble with SLC communication]

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.

[Trouble with SLC communication]

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

[Trouble with SLC communication]

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.

[Trouble with SLC communication]

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.

[Trouble with SLC communication]

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.

[Trouble with SLC communication]

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.