A question about 1747-SDN and 1761-NET-DNI

I have a problem with the communication between a MicroLogix 1500 and a SLC-5/04 (I think it's a 5/04, definitely 5/03 or above).

Our model assembly line (pre-built, we're unable to alter any wiring since it's the college's equipment) is split into 8 stations.

We're tyring to work out how integer files from the M/Logix 1500 at station 1 are sent to the SLC over DeviceNet.

Station 1 (and all other stations) has a 1761-NET-DNI between the M/L 1500 and the 1747-SDN DeviceNet scanner module.

We set the scanner's scanlist to scan only the DNI's on the stations we need. No problem there. And the DNI's are mapped to the M1/M0 files of the scanner.

Integer files, N20:0 and N20:1 are read from the MicroLogix 1500 by the DNI and are sent to the 1747-SDN. No problems there.

In the existing SLC program, one of the first rungs contains a COPy instruction, as follows

COP 

SOURCE: #M1.1.0

DEST: #N20:0

LENGTH: 80

I understand this to mean that the scanner's M1 file (which is read by the SLC) is going to be tranferred into the N20 integer file in the SLC. 80 consecutive files will be transferred. Great.

HOWEVER...

Investigation into the actual workings of the program led us to find that the N20 files from the M/Logix 1500 were actually being stored in the N21 files in the SLC - not the N20 files as the copy instruction should have dictated.

We proved the problem by examining N20:1/1 in the M/Logix 1500 and checking the status of the same bit in the SLC - we found that the same bit (labelled the same) was at address N21.1/1.

The problem is driving us crazy! Have we missed something?

I can post the DNI parameters if need be.

Thanks for your time and patience,

Richard Byrne.

Richard, you missed two or three things:

1. The N20 file in the MicroLogix is being copied to N21 in the SLC. Just because there is a command in the SLC that copies some data to N20 DOES NOT MEAN that the data came from the same memory location in another processor.

2. When files are copied, if the "Length' parameter is longer than the number of words in a file, then the rest are simply wrapped into the next consecutive file.

3. Remember that the memory locations in the SLC are continuous, and the SLC doesn't care what name you give to each group of locations, or what length (within some min and max). I would bet that the number of "Elements" in the N20 file is less than 80. In RSLogix, open the "Properties" of N20 by going to "Data Files", "N20", then Right Click, select "Properties", then check to see what the Element (word) size is set for. If it is less than 80, then your data is simply wrapping over into File N21. The maximum number of elements that can be in each Integer file is 256.

4. The moral of this tale is "You have got to know the details of your data." You cannot depend on the PLC to put it in the right place. You have to know where it came from, how long it is, what type it is, where it will end up, and whether there is room for it at the new location.

Lancie1,

Thanks for the prompt reply.

I see what you mean about elements in the integer file, but surely there is no chance of the contents being wrapped around after the first element. The M/Logix 1500 sends only two elements, N20:0 and N20:1 - if the wrapping scenario is true then there would only be 1 element in the N20 file of the SLC, ie, N20:0

So what is the N20 Element length set for? 1? If so, then the other 79 words are probably going into N21, N22, N23, N24, and so on.

Actually I just noticed that you are copying bits, so probably the first 16 go into N20, the second 16 into N21, the third 16 into N22, the fourth into N23, and the last 16 into N24 (assuming these are all one-element length files.

Just because N21 is labeled the same as the N20 location in the Micrologix doesn't mean a thing. Obviously somebody meant it to be the same bits, but the question always is, "Are they really?"

A good test is to turn on a bit in the Micro, say N20:0/1, then look at the same bit in the SLC to see it it goes on, then back off. If not, then you can ASSUME that the label is wrong.

I'm unable to check the actual setting until next week - I don't have RSLogix 500 at home. I'll check it next week.

But I've had a brainwave...

Since my partner and I want to write our own program for the system anyway, we could do the following:

1. Map the input (to the 1747-SDN, from the DNI) to say M1:1.0. That way, N20:0 from the M/Logix 1500 is guaranteed to be there every day of the week.

2. In the SLC program, copy M1:1.0 into N20:0 of the SLC processor, whenever we need to access the data from the M/Logix 1500.

By doing this, are we not forcing the two PLCs to hold the same data in the exact same location? This would make the rest of our program easier also.

RB

rbyrne said:

By doing this, are we not forcing the two PLCs to hold the same data in the exact same location? This would make the rest of our program easier also.

Click to expand...

Yes, and No. Yes, the SLC will see the N20 data from the MicroLogix. Then if the SLC makes a change in N20, how does the MicroLogix know about it? If the SLC changes the data and the Micro needs to know, then periodically you will have to copy it back in the other direction also. That may be why you have two different addresses. One (N20?) may be DATA FROM the Micro, the other (N21) DATA TO the Micro.

Great, that answers my question, thanks.

I could use an inbox/outbox type system for the SLC - N20 for the inbox, N21 for the outbox. As you say, that might be what is already being done.

Exerimentation is in order I think...

Thanks again,

Richard Byrne.

Richard,

Here are parts of the COPy command help file. It verifies that what I said (about the file wrapping to the next location) is true:

COP Description
When rung conditions are true to this output instruction, a user-defined source file is copied to a destination file.
The COP instruction does not use status bits. If you need an enable bit, program a parallel output that uses a storage address.
Source and destination elements may be of a different type, however, the destination file type determines how many words of data will be transferred.
Note If your destination is a timer, counter, or control file, be sure that the source words corresponding to the status words of your destination file contain zeros.
Make certain the SOURCE and DEST (destination) files contain at least the number of elements specified in the LENGTH. Also be careful to avoid copying data into elements that already contain needed data from other operations.
Entering Parameters
Source is the address of the file you want to copy. Use the file indicator (#) in the address. When using an SLC 5/03 OS301 or OS302, an SLC 5/04 OS401, or an SLC 5/05 controller, floating point and string values are supported.
Destination is the starting address where the source file is copied. Use the file indicator (#) in the address. When using an SLC 5/03 OS301 or OS302, an SLC 5/04 OS401, or an SLC 5/05 controller, floating point and string values are supported.
Length is the number of elements in the file you want to copy. A timer, for example, is a single element that uses 3 words - the control (status) word, the preset word, and the accumulator word. (If the destination file type is 1 word per element, you can specify a maximum length of 128 words. If the destination is a timer file (3 words per timer), you can specify a maximum length of 42 elements (3 x 42 = 126). In this case 2 words would remain unused.
Warning! When using file instructions and also indexed addressing, both applications store a value in status word S:24. Make sure that you monitor and/or load the correct offset value prior to using an indexed address. Otherwise, unpredictable operation could occur, resulting in possible personal injury and/or damage to equipment.
Rockwell Software 2000

Click to expand...