Red Lion Crimson/G310 String Handling

I have some code that writes the HMI's IP Address to a string in the PLC (Micrologix1400).

PLC.TAG = GetNetIp(0);

This does write the HMI IP address, but the problem that I have is that it seems to add a space at the end of the string. For example if the HMI IP address is 10.13.2.2 the String tag in the PLC should have a length of 9, but I'm ending up with a length of 10 due to the additional space. The HMI tag in Crimson is set up for a length of 15 (the max. number of characters the IP address could be) and under communications, the String Padding is set to NULL.

Anyone have any ideas on how to get rid of the extra space?

Old No. 7 said:

I have some code that writes the HMI's IP Address to a string in the PLC (Micrologix1400).

PLC.TAG = GetNetIp(0);

This does write the HMI IP address, but the problem that I have is that it seems to add a space at the end of the string. For example if the HMI IP address is 10.13.2.2 the String tag in the PLC should have a length of 9, but I'm ending up with a length of 10 due to the additional space. The HMI tag in Crimson is set up for a length of 15 (the max. number of characters the IP address could be) and under communications, the String Padding is set to NULL.

Anyone have any ideas on how to get rid of the extra space?

Click to expand...

I don't know of a reason off the top of my head, but add the Strip function to your logic and remove " " (space enclosed by quotes) and it should get rid of the space. If not, then there may be some other issue in your formatting or logic.

PLC.TAG = Strip(GetNetIp(0), " ");

JHarbin said:

I don't know of a reason off the top of my head, but add the Strip function to your logic and remove " " (space enclosed by quotes) and it should get rid of the space. If not, then there may be some other issue in your formatting or logic.

PLC.TAG = Strip(GetNetIp(0), " ");

Click to expand...

Good suggestion, but it didn't work. I still ended up with the extra space at the end. Just to make sure the Strip function worked, I tried:

PLC.TAG = Strip(GetNetIp(0), '2')

and the PLC ended up with a string of "10.13.. " still with a space at the end.

Old No. 7 said:

Good suggestion, but it didn't work. I still ended up with the extra space at the end. Just to make sure the Strip function worked, I tried:

PLC.TAG = Strip(GetNetIp(0), '2')

and the PLC ended up with a string of "10.13.. " still with a space at the end.

Click to expand...

OK, that accomplished what I hoped. It is the return function that is adding the space at the end. Or maybe the PLC.TAG formatting is the problem.

Try creating a String tag and making its source GetNetIp(0) Then in your logic use PLC.TAG = NewTag.

If that doesn't work, then you can work on formatting the tag, or creating an integer tag rather than a string tag and then workng on the formatting.

For my edification, why does PLC.TAG need to contain a string value for the Display IP Address?

Another option would be to handle the problem on the PLC end. Use an ASC instruction to locate the position of the space character, then an AEX to extract all of the characters up to that point into a new string.

It's a little complicated, but we have a supervisory software package needs it. We write it to a SQL database and our program has a webserver baked into it. We also use the FTP server to read/write recipes to/from the compact flash card. We can get rid of the spaces by changing our program, but this is bugging me.

I just noticed that the problem isn't just tied to the GetNetIP command. I have another string field on the HMI that writes to the ML1400. If I write "ABC" at the HMI, I end up with "ABC " with a length of 4 in the PLC. I can't believe I didn't notice this before. I wonder if something got jumbled in a Crimson update somewhere along the line. Hmmmm.

Two ideas for the ML1400 end of things:
1) strip off the spaces in the ML1400 using the ASC command to find the location, and AEX to get rid of the spaces. There will be some other logic to deal with changing the index position of the found spaces in order to find the positions of the characters you want to keep.
2) Reduce the LEN of the string by one character to remove the last character. This might be combined with an EQU looking at the last character to make sure it is a space:

BST MOV ST99:0.LEN N100:0 NXB AEX ST99:0 N100:0 1 ST99:1 NXB ASR ST99:1 ST99:2 BST SUB N100:0 1 N100:1 NXB MOV N100:1 ST99:0.LEN BND BND

I could not directly subtract one from the LEN sub element, so there is are integer addresses used to handle it.

I tested this in the emulator, so it should work...ST99:2 in the example above must be "preloaded" with the character you want removed from the end of the string. To do this, just open the data table and type in the space character and hit enter, then make sure the LEN changes to 1.

Old No. 7 said:

It's a little complicated, but we have a supervisory software package needs it. We write it to a SQL database and our program has a webserver baked into it. We also use the FTP server to read/write recipes to/from the compact flash card. We can get rid of the spaces by changing our program, but this is bugging me.

I just noticed that the problem isn't just tied to the GetNetIP command. I have another string field on the HMI that writes to the ML1400. If I write "ABC" at the HMI, I end up with "ABC " with a length of 4 in the PLC. I can't believe I didn't notice this before. I wonder if something got jumbled in a Crimson update somewhere along the line. Hmmmm.

Click to expand...

It could be a problem in the Crimson 3.0 but I wouldn't assume that it couldn't be in the way that the PLC is handling the string.

When I create a string tag and assign the Display's IP to it (through the GetNetIp function) and then check the Len of the tag it is correct. The display is a snapshot of a G315 through the web server.

Of course, it could have to do with the way the G3xx assigns the string tags...

I don't have time to get deeply into it, but I think this is just a result of the way Red Lion chose to handle Strings in their SLC/MicroLogix driver.

Strings in a PLC/SLC/MicroLogix are stored in a 42-Word array, where the Length is a 16-bit word, and the Data is arrayed two characters at a time into 16-bit words.

When you're doing character manipulation in the SLC/MicroLogix, this means you're very frequently using masks and swaps. I always end up with a stack of graph paper and an ASCII chart taped to the wall.


From what I've seen, the Red Lion driver can't write a Length that's an odd number; it always rounds up and adds the "String Padding" option that's designated at the very top level of the Communications / Global Options pane in Crimson 3.

In my most recent application, I just chose to handle this in the MicroLogix, searching out the first Null and changing the .LEN value.

That's it Ken. If I have an IP address of 10.13.2.12 the length is 10 without the extra space. If I have an IP address of 10.13.2.2 the length is still 10 with the extra space.

I suppose by dumb luck (my specialty) when I tested things in the past I just happened to choose strings that had an even number of characters.

Maybe one day I'll get ambitious and fix it in the PLC logic, but for now it's easier to just have our VB program scrub out the extra space when it grabs it out of SQL.

Ken Roach said:

I don't have time to get deeply into it, but I think this is just a result of the way Red Lion chose to handle Strings in their SLC/MicroLogix driver.

Strings in a PLC/SLC/MicroLogix are stored in a 42-Word array, where the Length is a 16-bit word, and the Data is arrayed two characters at a time into 16-bit words.

When you're doing character manipulation in the SLC/MicroLogix, this means you're very frequently using masks and swaps. I always end up with a stack of graph paper and an ASCII chart taped to the wall.


From what I've seen, the Red Lion driver can't write a Length that's an odd number; it always rounds up and adds the "String Padding" option that's designated at the very top level of the Communications / Global Options pane in Crimson 3.

In my most recent application, I just chose to handle this in the MicroLogix, searching out the first Null and changing the .LEN value.

Click to expand...

That is good information to know. Would changing this String Padding setting to NUL solve the OPs problem?

JHarbin, that doesn't help either. The string padding is already set to "NUL". If I set it to "Space", then it will fill the rest of the string with spaces. Since my IP address could potentially have up to 15 characters, that is the limit in my tag. I just tried it with "space" and 10.13.2.2 shows up as "10.13.2.2 " with 7 spaces (total length of 16 in the PLC). Since my tag is set to an odd number, the Red Lion adds an extra space at the end.

Old No. 7 said:

JHarbin, that doesn't help either. The string padding is already set to "NUL". If I set it to "Space", then it will fill the rest of the string with spaces. Since my IP address could potentially have up to 15 characters, that is the limit in my tag. I just tried it with "space" and 10.13.2.2 shows up as "10.13.2.2 " with 7 spaces (total length of 16 in the PLC). Since my tag is set to an odd number, the Red Lion adds an extra space at the end.

Click to expand...

I assume that someone has reported this directly to Redlion. It sounds like a driver issue - I understand the need for an even number of bytes - but it should be padded with the null.

If you haven't reported it to them, call their tech support or send a tech support email.

Since Redlion monitors this site, I expect we will hear something from them soon regarding this either way.

For those interested, Tech Support at Red Lion was able to recreate the issue with the "extra" space at the end of strings with an odd number of characters. He said that he would report it as a bug, but he didn't sound certain that the software people would agree and fix it. We'll see...

"Leftover" Characters

I'm posting a follow-up because another aspect of the way Crimson 3 handles PLC/SLC/MicroLogix Strings came up in my application last night.

In my case, I'm copying the String characters into an Integer array to be sent over Modbus/TCP to a third-party device. I use the Copy Word instruction to copy 10 Words (20 characters) from (for example) ST12:18.DATA[0] to N42:00-09.

The anomaly comes up when a String entry is shorter than the previous String entry.

Crimson 3 writes just the characters you've entered in the text entry box, plus a pad character. It doesn't fill up the rest of the 42 Data words in the String element.

When I enter "Test String" on the G3, I get "Test String" in the Integer array that is the destination of that CPW instruction described above.

If I next enter "Start", the ST12:18 string shows "Start ", with a Length of 6 characters (there's that Pad character again). But I get "Starttring" in the Integer array.

The characters that are written into the Data[x] array of the String element get "abandoned" there; they aren't seen in the String radix, but they're still present.

To work around this, I used brute force: I fill my Integer array with nulls, then one by one I do a Masked Move (MVM) to move each character from the ST12:18.Data[x] array to the N42:x array.

It takes two MVM's per Word, one with a mask of 0xFF00 and one with a mask of 0x00FF.

I'll get around to reworking this with indirect addressing and a for-next loop, but for now I wanted to post it to remind myself and help anyone else encountering the issue.