| Lynn's Industrial Automation Protocol Tips |
| Home > Rockwell > DF1_Tips > | |||||||||||||
|
The information on this web page is either Lynn's opinion or something Lynn agrees with. He has complete control over its contents. Nothing contained within this pages is approved by or represents the opinion of Digi International, The Modbus Organization, the Modbus-IDA Group, ODVA, or any other organization Lynn is associated with. AB/DF1 Protocol Tips
Question? What if the SRC or DST address is DLE? Answer: Yes, the DLE escaping happens in the DST and SRC bytes. The message starting "0x01 0x00 0x0F ..." becomes "0x10 0x10 0x00 0x0F ..." when DST address is 16 or 0x10/DLE. Question? Any special values or limitations for TNS? Answer: Yes, avoid sending your first request with TNS equal zero. Some devices initialize their saved 'Last_TNS' as zero. So if your first request has TNS equal zero, they will discard your request as a duplicate. In theory they are supposed to also check the CMD and SRC byte for duplicate detect, but not all third-party DF1 products do. Oh, and you'll need to escape (duplicate) any DLE value in your TNS. Question? Any tricks for the CRC? Answer: Yes, don't use the algorithm in the DF1 manual. The DF1 CRC16 calculation is the SAME polynomial as the CRC for Modbus. The only difference is Modbus starts with a CRC of hex 0xFFFF and DF1 starts with 0. So you can reuse your faster table-lookup CRC algorithms common for Modbus. Or you'll find a nice 'C' code example for the DF1 CRC in the ODVA Ethernet/IP specification in Volume 1, Appendix-C, Section C-7. The first algorithm is the traditional bit-cycling design, and the second algorithm is a much faster table-lookup method. Question? What is DF1's normal speed and parity settings? Answer: Most Rockwell PLC seem to default to 19200,8,N,1 Since DF1 is a fully binary protocol, 7-date bits will NEVER be a valid setting. Plus I have never seen a Rockwell PLC that allows changing the parity from N/None to something else. No doubt some HMI allow settings like 8,E,1, but if no PLC support this neither must you. Based on what I've seen, one should be able to make a product hard-coded to just 8,N,1 and not have problems with Rockwell devices. I can imagine some 3rd party products may support even or odd parity, but generally users will not be expecting this flexibility. Question? Can I auto-detect baud rate in DF1 Full-Duplex? Answer: Yes, DF1 FULL-DUPLEX is unusually auto-baud friendly. Since the ACK/NAK in DF1 Full-Duplex is defined as independent of the source/destination addresses, plus DF1 is pretty much limited to 8,N,1 auto-baud is quite easy. If you set a baud-rate and send an ENQ symbol (0x10 0x05), if the correct baud rate is set you will receive an ACK or NAK from the attached device. We don't care which - this is just the normal ENQ function of requesting a repeat of the last symbol sent. If we don't see an ACK or NAK, then either the remote is not connected, not powered up, or the baud rate is wrong. One note of caution ... 2 devices auto-baud detecting against each other is a bad idea. With good luck they will - after many seconds or even MINUTES - finally find a common setting, but with bad luck they may hit on 300 baud as 'correct' baud rate. You don't want this. So make sure you allow the user to hard-code the desired baud-rate. If possible, you will also benefit from saving the last-seen setting in NVRAM. This way you can start after boot with the MOST LIKELY baud rate first. My last auto-baud product would actually alternate between last known good setting and a variable setting. So if the last good baud rate seen was 9600, my auto-baud routine would try the following baud rates in this order: 9600, 19200, 9600, 38400, 9600, 1200, 9600, 2400 etc. This should greatly speed up the auto-baud if your device boots a small bit faster than the attached device. Question? Can I auto-detect CRC or BCC in DF1 Full-Duplex? Answer: Yes, DF1 FULL-DUPLEX is unusually auto-detect friendly. This relates to the auto-baud detect. Since the ACK/NAK in DF1 Full-Duplex is defined as independent of the validity of the function, you can detect the CRC or BCC setting fairly easily. Once you have determined the correct baud rate, just send a simple command like a diagnostic loop-back or echo. Page 7-8 of the DF1 manual 1770-6.5.16 shows this command. Even if the attached device does NOT support this command it must return an ACK or NAK based on the validity of the checksum you send. You can use this to check if a CRC or BCC produces the correct response. Just be aware that some line noise can produce a NAK even with the correct checksum selected, so best to double-check your result and also allow the user to hard-code the desired setting if they know it. The PLC being out of buffer space also produces NAKs, so I would NOT allow any auto-change of checksum after the units is up and running even if many NAK are seen in a row. Once you have seen an ACK, that setting should not easily be abandoned. Most modest MicroLogix are hard-coded to the good 16-bit CRC and cannot be set to BCC. Most powerful ControlLogix processors default to the weaker BCC - which seems a bit odd to me. But oh well, Rockwell doesn't ask my opinion on such matters, do they. Question? How does DF1 Full-Duplex treat DST and SRC? Answer: In theory they are ignored, since this is a point-to-point peer link. However, bridge products like the Digi One IAP or AB's NetENI use the DST byte for routing purposes. In addition, newer firmwares for the AB SLC5/03/4/5 PLC support use of the DST byte to bridge messages from DF1 to DH485/DH+/CSPv4 respectively. RSLinx forces DST=1 and SRC=0. In addition, some older PLC5 firmware literally tweak the SRC byte in responses to indicate which data file is being used for PLC2 responses. So a request to DST=1 SRC=0 may come back as DST=0 SRC=9. So when you start any DF1 protocol work, begin assuming you'll see DST=1 and SRC=0. It is useful to support other values; just don't relie on using other values. Question? What is an example DF1 Full-Duplex request? Answer: Below is an exact byte sequence to read 10 words starting at N7:0 These best commands for MicroLogix and SLC5 are the "protected typed logical read with three address fields" on DF1 spec page 7-17 and the matching "write" on page 7-18. Make sure your code can recreate this - including the correct CRC16 (all bytes are hex): 0x10 02 01 00 0f 00 e4 3a I split the message into 3 parts; the first part is the header: 0x1002 01 00 0f 00 e43a (TNS of E4 3A is a random value, but you must use this for the CRC given below to be correct. It must change for every new request. Avoid sending TNS=0 because it can cause problems if the serial device has just powered up) The middle part is the actual payload or application message. In this case it is a SLC-style Read of 20 bytes from file #7 of type Integer, starting at the first element. 0xa2 14 07 89 00 00 The final part is the end-of-message and checksum:
0x1003 15b9 Once you get this message working in your code, then you can vary the fields as required. |
||||||||||||
| Feedback - Contact | Lynn's Industrial Automation Protocol Tips | Copyright 2004 | |||||||||||