DF-1 Micrologix String Writes -- Illegal Command or Format?

[vorfeed]

Hi everyone,

I'm working on a third-party Allen-Bradley driver in C, and I'm trying to use the Typed Write command (0x0F 0x67) to write to the ST table on a MicroLogix 1500 Series A.

I can write to all the other data types using this same command, and I can read ST entries from this PLC just fine (using a similar command, 0x0F 0x68). For some reason, trying to write the same value to the same register using Typed Write returns error 0x10 (Illegal Command or Format). Here's what I'm sending -- is there anything obviously wrong with it? Is the datatype and/or data size wrong, maybe? Or should I be using Protected Typed Logical Write With Three Address Fields instead?

I tried asking TechConnect support, but they won't give me any help with third-party applications. I'd appreciate any advice you can give me. Thanks!

Attempting to write tag ST9:0 (data: B12345)
Datatype: 14
New string:
Char 0: 06
Char 1: 00
Char 2: 31 1
Char 3: 42 B
Char 4: 33 3
Char 5: 32 2
Char 6: 35 5
Char 7: 34 4
[padded with 0s up to and including Char 83]

LBA:
[7] [0] [9] [0]
Type/Data Parameter:
99 09 56 39 54
Write Request:
0f 00 84 0a 67 00 00 01 00 07 00 09 00 99 09 56 39 54

Sent Data : length 161
(0000) : 70 00 89 00 06 D0 8B 62 00 00
(0010) : 00 00 00 00 00 00 00 00 00 00
(0020) : 00 00 00 00 00 00 00 00 0F 00
(0030) : 02 00 A1 00 04 00 D1 06 00 00
(0040) : B1 00 75 00 07 00 4B 02 20 67
(0050) : 24 01 07 06 04 78 56 34 12 0F
(0060) : 00 84 0A 67 00 00 01 00 07 00
(0070) : 09 00 99 09 56 39 54 06 00 31
(0080) : 42 33 32 35 34 00 00 00 00 00
(0090) : 00 00 00 00 00 00 00 00 00 00
(0100) : 00 00 00 00 00 00 00 00 00 00
(0110) : 00 00 00 00 00 00 00 00 00 00
(0120) : 00 00 00 00 00 00 00 00 00 00
(0130) : 00 00 00 00 00 00 00 00 00 00
(0140) : 00 00 00 00 00 00 00 00 00 00
(0150) : 00 00 00 00 00 00 00 00 00 00
(0160) : 00

Recv'd Data: length 61
(0000) : 70 00 25 00 06 D0 8B 62 00 00
(0010) : 00 00 00 00 00 00 00 00 00 00
(0020) : 00 00 00 00 00 00 00 00 0F 00
(0030) : 02 00 A1 00 04 00 98 96 75 00
(0040) : B1 00 11 00 07 00 CB 00 00 00
(0050) : 07 06 04 78 56 34 12 4F 10 84
(0060) : 0A

error code is 10, EXT STS 0

Exiting with error (Illegal command or format) B12345 for ST9:0"

Thanks!

 

[vorfeed]

Any help? Surely someone has done this before...

 

[OkiePC]

Any help? Surely someone has done this before...

Actually, your question is relatively unique. Few people write their own drivers.

There's a member named Archie who probably has the most experience of anyone on here.

You might shoot him a P.M.

Looking at what you're doing, and guessing, since I have never done anything like this myself:

1) Are you sure you need to pad the string with zeros? Since you're writing to the LEN portion of the ST element, maybe the padding characters are causing a problem.
2) Can the string actually be 83 characters in length? As far as I know, the string itself is 82 characters in length, with two extra bytes at the beginning to hold the length.
3) Is it possible the bytes need to be swapped?

 

[vorfeed]

OkiePC,

Thanks for the reply! I'll contact Archie.

1) Are you sure you need to pad the string with zeros? Since you're writing to the LEN portion of the ST element, maybe the padding characters are causing a problem.
2) Can the string actually be 83 characters in length? As far as I know, the string itself is 82 characters in length, with two extra bytes at the beginning to hold the length.
3) Is it possible the bytes need to be swapped?

1) I think the string does need to be padded -- this is the way the strings come back from the PLC when I do a read on this register. It always sends back the entire 84 character string, with all the extra characters set to 0. I just gave it a try without padding, sending the length of the data as both 6 (the length of the string itself) and 8 (the length plus the extra 2 characters which encode the length), but both return the same Illegal Command or Format error.
2) The string is actually 84 characters long (it's 0-83, not 1-83), with the first two characters being the length.
3) I arranged the bytes the same way they are when they come back from the PLC on a read -- I don't suppose they'd be backward relative to reading when writing? I gave this a try, too, by reversing the encoded length bytes (i.e. sending 0 6 rather than 6 0), but it didn't seem to make a difference (either with padding or without).

Thanks for the suggestions!

 

[Archie]

Probably the easiest way to get the bytes to send is to download the DF1Comm driver, go to the PrefixAndSend function and put a break point at the SendData call.

http://sourceforge.net/projects/abdf1/

Here is an example stream to send to the PLC that will write B12345 in ST9:0 (all values in Hex)

10 DLE
02 STX
08 Target Node
0B Source Node
0F Command
00 STS
59 TNS1
00 TNS2
AA Function
09 Bytes to write
09 File Number
8D File Type
00 Element
00 Sub Element
06 String Length
00
31 "1"
42 "B"
33 "3"
32 "2"
35 "5"
34 "4"
00
10 DLE
03 ETX
05 CRC
37 CRC

 

[vorfeed]

Probably the easiest way to get the bytes to send is to download the DF1Comm driver, go to the PrefixAndSend function and put a break point at the SendData call.

http://sourceforge.net/projects/abdf1/

Here is an example stream to send to the PLC that will write B12345 in ST9:0 (all values in Hex)

Thanks! That definitely looks like it's using Protected Typed Logical Write With Three Address Fields (function 0xAA), so I'll implement that rather than the Typed Write and see if it helps.

 

[cjh]

I've done this before with the Protected Typed Logical Write with 3 address fields (0xAA) as well but I ran into an issue that I had to code around.

As I recall, the string data itself can only be 82 chars. There is an additional 2 bytes for the length (LEN).

I was unable to successfully write all 82 chars in one packet. I had to limit my write to 78 chars (plus the 2 bytes for the LEN member) on the first write and then write the last 4 chars on the second write.

I always write all 82 chars every time (null fill everything past the valid string data).

 

[vorfeed]

I've done this before with the Protected Typed Logical Write with 3 address fields (0xAA) as well but I ran into an issue that I had to code around.

As I recall, the string data itself can only be 82 chars. There is an additional 2 bytes for the length (LEN).

I was unable to successfully write all 82 chars in one packet. I had to limit my write to 78 chars (plus the 2 bytes for the LEN member) on the first write and then write the last 4 chars on the second write.

I always write all 82 chars every time (null fill everything past the valid string data).

Thanks for the tip, this'll help as well.

 

[vorfeed]

Update: Protected Typed Logical Write With Three Address Fields (function 0xAA) seems to work as above, but when the string has an odd length (like for instance "B123456" rather than "B12345"), it shows up in RSLogix as "B12345\00". Subsequent queries return "B123456" as they should, though, so the data is obviously in there.

Anyone have a workaround? I tried sending the entire null-padded 84 characters, as well as adding one 0 to the end of the string as in the DF1Comm example above, but RSLogix still substitutes that "\00" string for the last character.

Thanks again for all your help!

 

[Archie]

Update: Protected Typed Logical Write With Three Address Fields (function 0xAA) seems to work as above, but when the string has an odd length (like for instance "B123456" rather than "B12345"), it shows up in RSLogix as "B12345\00". Subsequent queries return "B123456" as they should, though, so the data is obviously in there.

Is the String length value showing up correctly in RSLogix?

 

[vorfeed]

Is the String length value showing up correctly in RSLogix?

Yes. For "B12345" RSLogix lists 6 for the length, and for "B12345\00" (actually "B123456") it lists 7.

For the record, though, I just figured it out. I was reversing every other character in the string and then tacking the last (odd-numbered) character onto the end, but you can't do that -- you have to add an extra 0 to the end of the string first, and then reverse the entire string including the extra 0 (i.e. you must send 07 00 31 42 33 32 35 00 36, not the more natural-seeming 07 00 31 42 33 32 35 36 00). Now that I've got the whole string topsy-turvy, it works fine.

Thanks again for all your help... this forum is the best!