L7X vs L8X Data Exchange

[dalporto]

Hi all.

I'm trying to set up communication between a 1756-L72 (EN2TR) and a 1756-L82 (CPU port) using produced / consumed tags.

From the L72 config, I was able to add the L82 in the tree under the EN2TR with the module discovery, and the data exchange is working when I produce a value in the L82 and read it in the L72.

I then tried to "add/discover" the L72 EN2TR to the L82 Ethernet tree, and it's not discovered. So I manually added it (EN2TR + L72, and it's not working.

It's creating (only in L82) two new structures (In/Out) that it didn't on L72. Looks like the data Type is refering to an ENET module, which is weird.

You can see the fault code on the screen shot.

Any clue anyone?

 

[robertmee]

I see you have a consumed tag already defined. If your target tag in the other PLC is a different size, it can cause the errors. I'd start with getting the IO config happy before creating a consumed tag, just to eliminate confusion.

 

[dalporto]

Nah, I put 1 DINT on both side to test, but it was afterwards I tried to set up that comm..

The issue here is the L82 not "seeing" the EN2TR / L72 in the other rack I guess.

It's working the other way around.

I have the right addresses.
I have the right rack positions.
I have the correct versions configured.
I disabled / enabled keying to check if it was the issue.

I don't understand why L82 is creating structures when I add the EN2TR / L72 in the Ethernet tree, maybe there is something different with L8X. Looks like it's a part of the error I'm getting.

Fact is that the L82 can not discover the EN2TR by itself.

 

[robertmee]

Dunno, I literally did the same this past week...added produce/consume between an L82es and L72s...no issues. The data structure you displayed is normal. I have the same tags on mine.

Are you sure the rack size of 13 is correct? According to the KB, error 0109 is due to an incorrect rack size specified.

 

[dalporto]

Ohhhh.

It was planned for a 13, but I may have a 10 to test. The rack is now 50 km from me now, but it was fitting in something that wouldn't fit a 13 slots at home, so that may be that..

I'm going to try. Thanks.

But even before that, the L82 wouldn't discover the EN2TR.

 

[dalporto]

Hey Robert.

It's not the first time you help me.

It was that.

Thank you very much, really really appreciated.

Have a nice weekend!

-Ben

 

[dalporto]

So I can drive a 17 slots config on a 4 slots backplane, but this is where Rockwell draws the line I guess, do not mess up with the rack size, but just sometimes.

Thank you it's working now.

Any insight on how I should handle the data?

I was thinking about a user defined structure to standardize all data exchange, like INT/BOOL / INT / REAL, but I don't know if it's the way to go.

On Schneider I would do WORD for Binaries and REAL for all analogs, but it's not working the same.

 

[robertmee]

So I can drive a 17 slots config on a 4 slots backplane, but this is where Rockwell draws the line I guess, do not mess up with the rack size, but just sometimes.

Thank you it's working now.

Any insight on how I should handle the data?

I was thinking about a user defined structure to standardize all data exchange, like INT/BOOL / INT / REAL, but I don't know if it's the way to go.

On Schneider I would do WORD for Binaries and REAL for all analogs, but it's not working the same.

I use a standard UDT for all comms...it has an array of DINTs, array of Reals and a Heartbeat tag thats a free running timer to monitor comms. The DINTs cover both word and Boolean, the Reals cover floats. I've never had a reason to pass strings. Most data is status (bit of word) or production data (linespeed).

 

[dalporto]

Thanks again!

 

[ASF]

Also make the first element of your UDT an element of type CONNECTION_STATUS. That gives you two BOOL's (RunMode and ConnectionFaulted) that allows you to monitor the status of the comms link without any additional logic/heartbeats/etc. If ConnectionFaulted is false, the connection to the producer is good, and if RunMode is true, the producer is actively running code.

 

[dalporto]

Also make the first element of your UDT an element of type CONNECTION_STATUS. That gives you two BOOL's (RunMode and ConnectionFaulted) that allows you to monitor the status of the comms link without any additional logic/heartbeats/etc. If ConnectionFaulted is false, the connection to the producer is good, and if RunMode is true, the producer is actively running code.

That was actually my next question. I created a watchdog with the system seconds from each PLC, but I was wondering how to have the actual connection status.

On the L82 when I populated the Ethernet tree, it created 2 structures with the "remote" slots status, with data that looks the same for each slot (2#1111_1111_1111_1111_1111_1111_1111_1111 for .Fault and same with 0's for the .data) while some of programmed modules not even in the rack. Not sure if there is something exploitable in that.

I'm gonna try the connection status, but I'll keep my watchdog too since I don't think it will cover for a remote PLC stopped / in Program Mode.

Thanks.

 

[ASF]

I'm gonna try the connection status, but I'll keep my watchdog too sing I don't think it will cover for a remote PLC stopped / in Program Mode.

It does cover that, that's the whole purpose of the RunMode bit.

Even if both PLC's are in program mode, the ConnectionStatus and RunMode bits reflect the status of the connection and the mode of the remote processor. Try it out!

 

[dalporto]

Oh yes, it works!

Thank you for the tip!

So long, 5 rungs watchdog.

 

[robertmee]

It does cover that, that's the whole purpose of the RunMode bit.

Even if both PLC's are in program mode, the ConnectionStatus and RunMode bits reflect the status of the connection and the mode of the remote processor. Try it out!

Pretty nifty....ive used heartbeats from Logix 5 and 500 days so carried that standard into 5000. I'll have to try the connection status. Always learning.