1769-L33ER talking to 4 1769-L16ER

Hej guys

I have a system that will get together in the same network one 1769-L33ER as main CPU and 4 pieces 1769-L16ER as "local CPUs".
This system is a "slave" for a central system on s ship and I'm suppose to talk Modbus TCP to the central system thru the main CPU.
Now my question to you is this:
What would be the smartest way to handle this: read all the data from the "local" CPUs, store that into the main CPU and then send it to SAS or try to have read and sent directly to SAS without having it stored on the main CPU.
I also have some data that the main CPU gets from 2 distribution boards.

Any suggestions are very much appreciated.

Any data you transfer between the local CPUs and main CPUs should be set up as produced and consumed tags. Basically, any tag you want to read from the local CPU should be set up as a "Produced" tag type (as opposed to Base, Alias, or Consumed). In the main CPU, set up a tag with the same name and make it a "Consumed" type. Then there will be a dialog to point it to a processor. Do the same in the Local CPU programs but have the Main CPU in their project trees. This should handle the communications and data transfer without having to muck about with explicit messaging. You can add additional processors in your main CPU's project tree. I'm not sure if you can configure one ethernet port on the L33ER for Ethernet/IP and the other for Modbus TCP, but I would look into that.

Thanks for the good input. I'll do that since it looks faster and more adequate.

I have though another question
If I have the same tags in all the 4 local CPUs (like pump1/pumpUDT data type) should I change the name of the tags so that they are unique or is good enough to point to the different CPUs?

gabidamir said:

I have though another question
If I have the same tags in all the 4 local CPUs (like pump1/pumpUDT data type) should I change the name of the tags so that they are unique or is good enough to point to the different CPUs?

Click to expand...

Make them unique. Because in the main CPU you're going to have to match the tag name to what they are in the local CPUs, and you'll need four unique tags in the main CPU.

Thanks
the way I made it its like this
In the local CPUs tags are the same name (when looking at every CPU and tag /pump1-CPU1) but when creating them in the main CPU they are called pump1CPU1 and pump1CPU2 and so on
I think that it should be ok
Once again thank you for your input. Highly appreciated.

gabidamir said:

Thanks
the way I made it its like this
In the local CPUs tags are the same name (when looking at every CPU and tag /pump1-CPU1) but when creating them in the main CPU they are called pump1CPU1 and pump1CPU2 and so on
I think that it should be ok
Once again thank you for your input. Highly appreciated.

Click to expand...

That should be alright. Looks in the main CPU when you set up the consumed tags you can specify the tag name in the local CPU you're looking for, so your setup should work just fine.

gabidamir said:

...I have a system that will get together in the same network one 1769-L33ER as main CPU and 4 pieces 1769-L16ER as "local CPUs".
This system is a "slave" for a central system on s ship and I'm suppose to talk Modbus TCP to the central system thru the main CPU...

Click to expand...

FactoryTalktotheHand said:

...Any data you transfer between the local CPUs and main CPUs should be set up as produced and consumed tags...

...This should handle the communications and data transfer without having to muck about with explicit messaging...

Click to expand...

Just a question or two I have on the networking arrangement, which may have an impact on the produced/consumed option...

When you say the controllers within the sub-system will "get together in the same network",

I assume you intend to connect them using their Ethernet ports?
If so, using what protocol, EtherNet/IP?
Or do they also have to use the Modbus TCP protocol?

If EtherNet/IP, then yes produced/consumed tags are supported. But if Modbus TCP is your poison, then they are not supported. Modbus TCP must use the Open Sockets feature of the Ethernet ports. This will require program code and the use of Explicit Messaging.

FactoryTalktotheHand said:

...I'm not sure if you can configure one ethernet port on the L33ER for Ethernet/IP and the other for Modbus TCP, but I would look into that.

Click to expand...

Firstly...

The dual Ethernet ports on the 5370 CompactLogix controllers are not stand-alone ports. They are not separately configurable for different protocols. You cannot connect the controller to two separate physical networks with two separate IP addresses. They are for connecting the controller in a Device Level Ring (DLR) or Linear topology. Think of the dual port as a physical splitter to a single port. You can, however, disable the second physical port if you are not connecting more than one Ethernet lead to the controller. This is useful for preventing a user from attempting to connect to the network via the free port while the process is running. If your application does not use the Ethernet port for communications, then you can disable both physical ports. See attached screenshot from the properties of a 1769-L33ER I have on the bench here.

Secondly...

If you are using EtherNet/IP from the main controller on the sub-system to the 4 local controllers, then that's fine. But what about the main controller also needing to act as a Slave to the central system (SAS)?

Modbus TCP is not natively supported in the Logix controllers. You would have to program extensive code to handle the Open Sockets communications between the controller and SAS. This code can use up a lot of the controller's memory, but the L3 controller should be fine if your program is not too large already. If you were to use Modbus TCP between the L3 and L1 controllers, then the code used in the Slave L1s would eat up a lot of their memory.

The good news is that Modbus TCP and EtherNet/IP protocols can co-exist on the same physical network. Your 1769-L33ER can simultaneously handle Ethernet/IP produced/consumed data to the 4 x 1769-L16ER, while acting as a Modbus TCP Slave to the central system (SAS), all through its single Ethernet port.

The main 1769-L33ER will require program code to set it up as a Modbus TCP Slave to the SAS. The following Technote outlines Modbus TCP Master and Slave usage within the Logix controllers, and provides you with sample code for both Master and Slave setups, of which you can add the Slave code to your program within the 1769-L33ER...

470365 - Sample Code for Modbus TCP Master and Slave
Access Level: Everyone

Regards,
George

Hej George

first of all thank you for your expertise.

Secondly
the situation stands like this
the main CPU will talk Ethernet/IP to the local CPUs and Modbus TCP to SAS as a server(slave). I will use the sample code from Rockwell to achieve that.
The local CPUs also talk Modbus TCP to some Vacon frequency inverters (using the ModbusTCP Master sample code from Rockwell)
So since Ethernet/IP and Modbus TCP can coexist on the same physical network I think that this should be ok.
About the memory you are right since now I'm running my local CPUs to their limit with this sample code master TCP and also my own code.
If you are familiar with the sample code from AB maybe you can help with a small thing.
They say that upon a write function I need to clear the reqBuilt flag when there is new data to be written. My question is if the pollinterval is set to a certain value and my program writes the new data into the tags that the Modbus application is taking its data from why do I need to clear this flag?
Or is it that the command is only done if the flag is 0?
If so what about the reads? Isn't it the same?
Thank you in advance.

Thanks for the background info Geospark. I love learning new things. I'm not sure I understand about the Explicit messaging. gabidamir said he was talking Ethernet/IP to the Local PLCs. Are you saying if he's also using Modbus TCP then the produced/consumed tag model won't work? If so, would he be better off buying a standalone Modbus TCP Module like this one from Prosoft? http://www.prosoft-technology.com/P...x/Modbus-TCP-IP-Enhanced-Communication-Module

Open Sockets - Transactions, Requests, Rebuilds(ReqBuilt)

FactoryTalktotheHand said:

...Are you saying if he's also using Modbus TCP then the produced/consumed tag model won't work?...

Click to expand...

No, I was saying if he was only using Modbus TCP then the produced/consumed tag model won't work. If only Modbus TCP, gabidamir would have to use Explicit Messaging to implement Open Sockets communications.

Because Ethernet/IP and Modbus TCP can co-exist on the same network, Ethernet/IP is not impeded in anyway by the presence of Modbus TCP on the network. Ethernet /IP can continue to service normal functions like produced/consumed data, Distributed I/O, HMI communications, Messaging, et al.

gabidamir said:

...They say that upon a write function I need to clear the reqBuilt flag when there is new data to be written. My question is if the pollinterval is set to a certain value and my program writes the new data into the tags that the Modbus application is taking its data from why do I need to clear this flag?
Or is it that the command is only done if the flag is 0?
If so what about the reads? Isn't it the same?...

Click to expand...

No, it's not the same for reads, and your program is not writing the new data. At least not unless you instruct it to. Open Sockets is somewhat different to normal communications you may be used to...

When you configure an Open Sockets "Read" transaction, you are setting the parameters for the transaction to "Read" from a set address, or array of addresses, at a polled interval. Because the Master does not influence the data being read from the address, or addresses, it only needs to "Build" the transaction once, and then continues to read in the data, regardless of whether that data is static, or dynamic. This way, a "Read" transaction is blindly polling the data without needing to refresh the transaction.

When you configure an Open Sockets "Write" transaction, you are setting the parameters for the transaction to "Write" to a set address, or array of addresses, at a polled interval. Because the Master does have an influence on the data being written, it must rebuild the transaction each time the data to be written changes, else it will keep writing the value of the data when the transaction was first built i.e. potentially stale data.

Example "Write" Transaction:

PollInterval = 10 (10 x 100ms = 1sec)
TransType = 15 (Modbus - Write Multiple Coils)
BeginAddress = 99 (Start writing to 00100 (00 = Coils; 100 = address)
Count = 25 (25 Coil addresses will be written)
LocalOffset = 100 (Starting at index address 100 through 124)

When a "Write" transaction is called, a "Request" string is "Built" using the values you have set for the transaction. This string is used when a "Connection" is established with the other device. If the data being written changes, this "Request" string must be rebuilt in order to refresh the transactions data i.e. the "Request" string must be rebuilt. This is enabled by a reset of the "ReqBuilt" bit, forcing the transactions "Request" values to be refreshed.

The only other way to refresh the data to be written is to close and reopen the Connection, forcing a rebuild. but this is not efficient.

Regards,
George

Hi Geospark
it's nice to see that experts as yourself take the time to teach novices
now i understand the need to reset the reqBuilt flag.
is there a certain place that i need to do that (i have no experience what so ever with this application, and not that much experience with ControlLogix programming) or should i do something like this:
in the main routine i can compare the actual data from the modbus tag and the data to bi written from the drive AOI and if they are not equal then reset the reqBuilt bit?
I have to say that i'm using two AOI for drives and pumps and the related logic for them so in the controller main routine i can access the controller scoped tags easy.
What would be your advice on this matter.
Once again thank you for your time.

I don't know about the expert part, but my advice would be to follow, as best you can, the sample code. I would not be too worried about checking if the data to be written has changed or not. You should just reset the ReqBuilt bit for your transactions every time they are complete and it will auto refresh the data regardless.

The sample code is already designed to do this for you.

If you look at the routine "ClearCommsBuffersAndTriggers". On rung 4, a MOV places a 0 in Cldx. Cldx is a Connection Index tag. Here it is used, with the aid of a FOR instruction, to index through and reset the ReqBuilt bits and Requests for however many transactions are used in Connection 0. The FOR instruction controls the indexing that is carried out in the routine entered in the "Routine Name" field.

This is done in the "ClearTransTrigger" routine, as indicated in the FOR instruction. In the "ClearTransTrigger" routine, rung 0, when Cldx is EQU to 0, it resets all the Transaction .ReqBuilt bits, and the Requests for Connection 0 by indexing through the number set in the FOR. Once the FOR is finished indexing and resetting, then back in the "ClearCommsBuffersAndTriggers" routine, the next MOV on rung 4 places a 1 in Cldx, and the FOR instruction steps to the "ClearTransTrigger" routine to now reset similarly for Connection 1 on rung 1, and so on.

I haven't much time, being Friday evening, to go into greater detail, but have a chew on that for now.

Regards,
George

Hej Geospark

I thing I have it working now
This week towards the end of it I will start testing the system (one of the local panels) and I will see how it goes.
The most interesting part (testing the whole system main CPU and 4 local CPUs) I will not be able to do yet since the cabinets are not ready but I will get my hands on that later on

once again thank you for your time and good advices