PDA

View Full Version : FB Cycle Time vs macrocycle


CHRISC1024
February 2nd, 2011, 12:26 PM
All,
I have a question that I am confused on. I wil take one example of this but the variables for number of segments can range from 1 to 4 per linking device.

We have linking device that has 4 H! segments. 3 segments are running a macrocycle of 1000ms and 1 is running a macrocycle of 1500ms. The FB Cycle Time for the bridge is set to 750ms (550 FB Schedule Duration/200 Unscheduled Time). How do you caculated the required FB Cycle time for the bridge (linking device) when you have multiple segments running at different macrocycles. I am still trying to do some digging online for this setting and am running into a wall of non-information.

I have read the linking device manual and user guide and application guide for the configuration software. The platform is Allen Bradley using the following:
1757-FFLD4
RSFieldbus
RSLogix5000

We are adjusting the macrocycles according to a technote they released and am trying to figure out how to set the FB Cycle Time.

Any insight would be great as there is no mention to this setting in any of thier documentation.

agupta
February 3rd, 2011, 09:22 AM
The macrocycle time is the period at which the LAS sends the CD to the devices. Every link (segment) has its own macrocycle time. The exact time at which the CD is sent is synchronized to the Data link time of that link. The FB execution period and the exact time when a FB is executed is also synchronized to the Data Link time of that link. Thus, the CD is sent only after the FB is executed, so that its latest output is published. The Host has to figure out the FB and LAS (CD) schedule and download CD schedule to the LAS and the FB schedule to the device. The FB execution period is set individually in each device.
In the LD (Linking Device) with four H1 links, there is one LAS for every link. The macrocycle and FB schedule for each link is independent of each other.
There is no specification to synchronize the Data Link time across multiple links. If a published value from one link has to be sent to another link, it will not be synchronized to the FB execution in the destination link.
If the LD (Bridge) is also running FB application, and if it is in the LAS for one or more links then the FB cycle time (period) has to be same as the macrocycle time of the link in which the FB is running.
If the LD is running FB application on the HSE side, then its FB cycle time is not related to and not synchronized with the macrocycle time and Data link time of any link. Due to this lack of synchronization, the FB in the host controller (which can be the LD) should have a period larger that the link macrocycle time, so that there is one or more published value received in between two execution of the same FB in the host.

Jyrgen
February 4th, 2011, 03:01 AM
I am curious to hear whether someone needs synchronized links.

In addition to synchronized data link times I would like to see a small upper limit for bridging and republishing delays in linking devices.

Comments welcome.

CHRISC1024
February 4th, 2011, 05:48 AM
From what I've been told by inside support is the FB Cycle Time for the Bridge only applies to devices hanging on the HSE side. I was told there are none at this time on this project so I'm assuming that the 550ms of scheduled FB Duration set by the software is for the bridge only to the PCS. The thing that concerns me is there's no documentation as to what this setting is and what gets transmitted durring that time. Right now the FB Cycle time is a 70/30% split between scheduled/unscheduled so I'm assuming that would be ok but I'm not sure what needs to be transmitted durring the unscheduled portion of the FB Cycle Time.

We already have discovered that there are settings that need to be adjusted in the Ethernet card in the PCS rack in respect to each control module that is assinged to communicate through it and these settings are not correct. This setting is supposed to be 1/2 of the macrocycle and right now it's 20%. We are thinking that this could be causing communication issues between the Ethernet Card and the linking device.

agupta
February 5th, 2011, 10:47 AM
The FB that are running in the HSE part of the LD and either use input from a field device or send output to a field device should run at a period that is larger than the macrocycle of the link. Running it any faster does not have any advantage, because the block will not get a fresher input. In general the FB in the HSE (LD) should have a period larger than the link macrocycle, because the execution time of the two is not synchronized.
For example, FB in HSE(LD) and macrocycle both are 1 second. The input to the PID in the HSE can be up to 1 s old. It may take another 1 s for the PID output to be sent to the AO in the field device. Thus, there will be a latency of up to 2 s.

jberge
February 6th, 2011, 08:00 AM
The macrocycle for the HSE port is independent of the macrocycles of the H1 ports so you need not make any such calculation.

It could be useful if different H1 ports were synchronized. It would improve the performance of control loops spread across different busses. That is, better performance in those rare cases where transmitter and valve are connected to different H1 ports.

CHRISC1024
February 7th, 2011, 05:47 AM
Jonas,
For all control valves, the transmitter that is associated with it is on the same segment. Are you saying that we should set all 4 macrocycles to the same setting on a linking device if possible? Also, if my largest macrocycle is 1500ms, should the FB Cycle be set to this as well?

jberge
February 8th, 2011, 02:26 AM
Dear Chris,

No you do not need to set the same macrocycle on the four H1 ports.

If you use the PID in the contol valve, so the complete loop executes in the field, then the loop is independent of any linking device or controller cycle.

"FB cycle" is not a standard FF term, I assume it is the cycle time of the blocks in the linking device or controller. I'm not familiar with your system, but generall speaking that time should not affect any of the macrocycles. If the H1 macrocycle is several times slower than the controller cycle, the controller may report bad communication due "stale data" (you can adjust "stale count" to avoid this - the DeltaV system does it automatically). Setting it same or slightly slower should be fine.

Cheers,
Jonas

CHRISC1024
February 8th, 2011, 09:54 AM
Jonas,
Thanks for the response. I didn't think you meant that we should set the macrocycles the sme but jsut wanted to make sure. I know each segment's macrocycle is dependant on the number of device and VCR's being used. As frea as I've been told, all control is done in the host with no control in the field(thus the PID would be handled in the host not the device). Currently, the FB Cycle Time is slightly slower than the lowest macrocycle so that should be ok. We have also adjusted the stale count from the preset 3 in the linking device.

Thank you to everyone for the information. I'm trying to get a better understanding of the front end programming/configuration. I've only had hands on training with a Delta Vsystem from the programming/configuration side and the Rockwell System is much different and seems to require a more detailed approach when setting up and configuring the H1 and HSE side.