Sign in to follow this  
Followers 0
Colin Carpenter

Logix 5000 Dint to Int and back again

9 posts in this topic

Hi, Back to programming Control Logix after a few years lay off. Wonder if someone could confirm that what I'm trying to do is OK. Two Control Logix Controller (both 1756-L55 v15.02), each fitted with a 1756-ENBT Ethernet Card I propose to set up 100 Produced and 100 Consumed tags in each controller and use them for ethernet comms between the controllers. The remote controller will received some INT words via DH+ that I need to copy onto the Produced tags (which are DINT tags by definition) Once the tags have transferred across the ethernet, I need to copy the DINT words back onto INT words. In summary, using the MOV command, the process will be INT->DINT->ethernet->DINT->INT The question is, will the bits of the last INT be the same as (and in the same order as) the bits of the original INT. I'm pretty sure it will be fine, but I can't test it until I get to site, and things can get a bit fractious then. Thanks

Share this post


Link to post
Share on other sites
Your fundamentals are sound but there are a handful of considerations to make this work best. The first is the integrity of the data coming over DH+. If at all possible, use the ControlLogix to initiate Read messages to get the data from the source. You can then use the /DN bit of the MSG instruction to be certain the data has all been read and placed in the destination tag. Next, use a Copy Synchronous (CPS) instruction to pack the INT array of data into a DINT array of half as many elements. Remember that the Length of a COP or CPS instruction is the number of destination elements, not dwords/words/bytes. If you are transferring 100 INT elements to a DINT array, the length will be 50 elements. Definitely produce and consume Array tags, not individual DINT elements. The amount of processor and -ENBT work as well as CIP connections and Ethernet bandwidth to transfer a single large array is much, much lower than that to transfer a large number of single-element tags. On the Consuming end, use the CPS instruction also to copy the DINT array into an INT array. Lastly, the "15.02" you cited for the Logix controllers is hopefully the version number of the RSLogix 5000 software, which is fine. The 1756-L55 controller firmware itself MUST be version 15.05 to avoid a background CRC error that will fault -L55 controllers after a few months of continuous runtime.

Share this post


Link to post
Share on other sites
Thanks Ken, the CPS instruction is the thing that I wasn't sure of, and I'll look it up and use it. Incidentally, this job of full of co-incidences. CPS is also the initials of the company I'm working for on this, and the plant is controlling a CIP set (stands for "clean in place" in dairy terminology), and to cap it all, CRC are my initials. Spooky

Share this post


Link to post
Share on other sites
Question, why don't you create a user defined data type contain all the data types you need to pass from on plc to the other, i.e. int, dint, real, etc. The data type will be created in each plc identical to the other.

Share this post


Link to post
Share on other sites
I don't believe this is possible with DH+

Share this post


Link to post
Share on other sites
>>On the Consuming end, use the CPS instruction also to copy the DINT array into an INT array.<< I checked out the CPS command in the programming instruction manual, and it states: Important: the Source and Destination operands should be the same data type, or unexpected results may occur. And this is the bit that still worries me a little. Coming from the Mitsubishi world (shock, horror ), their software is very specific on not mixing INT and DINT values in functions. For example their MOV command for INTs becomes DMOV for DINTs, and putting both an INT and a DINT value into a function block will result in an error when the programme compiles. To overcome this, they have two functions that help, named DINT to INT and the reverse INT to DINT. I imagine that these functions take the bottom 16 bits of each value and transfer them exactly. It means that a large DINT decimal number cannot be transferred to an INT, but that is something that you learn to make sure will never happen. The Allen Bradley software seems to allow mixing of DINT and INT variables in the same function, but warns that unexpected results may occur, which makes sense if a DINT has a larger decimal number that cannot be stored in a 16 bit INT. If that truncating of the number is the "unexpected result" that they warn about, then I can happily live with that, but I would be happier being able to find a DINT to INT instruction that I know will remove all doubt about the integrity of the operation. Am reading the manual now and may find the answer, but if anyone has come across this, I would be grateful for a pointer. Thanks, Colin PS. Thinking about it a bit more, as the original word is a 16 bit INT word, presumably only the lower 16 bits of the DINT produced and consumed tangs would ever be use, so when it then pops back out as an INT there shouldn't be a problem .... it's just the uncertainty that worries me a little, and I can't test it until getting to site when time is very limited. Edited by Colin Carpenter

Share this post


Link to post
Share on other sites
After a bit more research, I found that the bit in the manual about data conversion, and it appears that as long as you steer clear of signed integers (SINT), then the lower 16 bits of a DINT will convert faithfully to the 16 bits of an INT, so that all appears to be OK. Thanks.

Share this post


Link to post
Share on other sites
When you use a COP or CPS, the bit pattern is copied directly; the value of the tag is not considered at all. When you use a MOV instruction, the value of the data is taken into consideration by the controller. That's why you can mix REAL and DINT and INT when you are using the MOV, because the controller takes care of the conversion for you. A nitpick; SINT is "Short Integer". All integer datatypes (DINT, INT, SINT) in the Allen-Bradley world are signed, with the most-significant-bit serving as the +/- sign bit. Although some HMI devices from A-B will display data as though it was unsigned, there is no such thing as unsigned math in the controller. The "unexpected results may occur" refers to the possibility of overruns or underruns that users might assume would work differently. If you did a COP of a INT[10] array into a DINT[10] array, for example, the elements DINT[5-9] would be unwritten, remaining at whatever value they might have been before. If you assumed they would be zeroed out, that's "unexpected" to you. The Apple user's group magazine I worked for very long time ago used to feature in each edition a short program (like 5 to 10 lines) that utilized low-level math or system functions in an inventive way. The title of the feature was "So What Did You Expect ?". I loved that magazine.

Share this post


Link to post
Share on other sites
Thanks for that, Ken, that's a great help. I wonder if you might know whether or not it's possible to set up a "produced and consumed tags" system on two Logix controllers with the ethernet cards already installed and configured whilst in "online mode". I've done online ladder changes before, but this would mean adding tags and adding the remote ethernet card, chassis and controller (in the IO section on the left hand side), all while the two controllers are running. Thanks, Colin

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0