Communicating a string - RSLogix 5000

I'm working with a CompactLogix system and RSLogix 5000.

I used a condition on a rung to copy a string from itself to another string when the length (LEN) changed from zero. This was run through a one-shot to only do this once.

While monitoring the program from RSLogix 5000 I cleared the first string and the target string. Then I entered a 5 character string into the first one. Checking the result the target string got the length of 5 but its characters were 5 hex zeroes.

I think I've seen this before with an HMI and another external device when I tried to trigger on the LEN changing to non-zero and didn't think much but worked my way around it. I'm guessing that RSLogix 5000 and other external devices send the LEN in one messge then the array of SINTs in another, leaving a condition for a moment of the string with a length but not valid characters.

Maybe I need to use the 'handshake' bit available with controls on the HMI.

Any observations? Maybe everyone else already knew this and never triggerr just off the LEN.

[Edit - using Ethernet, just in case it matters.]

Which instruction?

Are you using a COP instruction to move the .DATA array? If so, try a CONCAT with a blank string tag as source B.

COPy will normally work just fine. The point is, I'm doing the copy when the LEN changes from zero and apparently the SINT character array hasn't arrived yet. In previous programs I ended up initiating a delay after the LEN changes before doing the copy and that seems to work.

Actually I can't think of any non-atomic pieces of information which get sent by an HMI other than a STRING.

I hope I follow OK, but I just tried this rung and the COP works fine on an L36..

NEQ String1.LEN 0 COP String1 String2 1

I did initialize the LEN to 0 and it still works.

y2kmfic - place a one shot after the NEQ of the string length. Then set the string1 using RSLogix5000 or an HMI. That way there is only one copy. Your line would continously copy after the LEN changes to non-zero.

The system I am using has many things going on with the Ethernet port. Perhaps that is causing a very small delay between the writing of the length and that of the SINT array of characters.

The ONS might have a lot to do with it

Had to put a timer in there, as you had to do in the past. The code below doesn't work until you take the PRE up to 100. It also helped to remind the Dest string what its LEN is supposed to be.



DelayTONR.PRE := 100;

IF SourceString.LEN > 0 THEN DelayTONR.TimerEnable := 1; ELSE DelayTONR.TimerEnable := 0; END_IF;

IF DelayTONR.TT THEN COP(SourceString.DATA[0],DestString.DATA[0],83); DestString.LEN := SourceString.LEN; END_IF;

IF DelayTONR.DN THEN DelayTONR.Reset := 1; END_IF;

DelayTONR.Reset := 0;

TONR(DelayTONR);

This all started for me when using a Real Time Automation Ethernet/IP to ASCII gateway. It communicates both ways by using strings.

I needed to take action as soon as a new string arrived. But I soon found that the LEN changing to non-zero was not a sufficient indication. Thus I had to use the timer offset similar to what dan_bob suggests.

I think you've put your finger right on it, Bernie: the HMI has to do two writes to get the String datatype across.

If you look in the Data Types folder for the default String, you'll see that the LEN element (4 bytes) comes first, followed by the 82-byte SINT[82] array.

RTA's code could have chosen either one to do first, but it probably just does them in the order they appear in the datatype definition.

dan_bob's method looks simple and straightforward.

If you wanted to extend that, I suppose you could clear out the Data[x] array that's being written to, and check the first byte for a nonzero value before copying the incoming String to another place.

This is also a good situation to use the Handshake/Acknowledge bits offered in some data entry HMI objects.