Downloads
If you want to learn more, please visit our website.
Please note: You will need to agree to the Terms & Conditions for each download.
Need Help?
If you need help with an application or have feedback from the Innovation Center, please contact us.
Sometimes there is a need to send data from one controller to another and be confident the data being sent/ received is accurate and not a combination of old and new data. This application note shows how to send one (500byte) packet of buffered data using a Produce / Consume (Class 1) connection over Ethernet/IP.
General Features
Advantages: This sequence facilitates the implementation and quick configuration when is need it to send one packet of buffered data using a Produce / Consume (Class 1) connection over Ethernet/IP, without any other hardware.
Limitations/Disadvantages: This sequence is available for CompactLogix / ControlLogix Controllers.
Is this helpful?
This code is defined for applications when it is needed to send one packet of buffered data over Ethernet/IP.
Application areas: Food, Manufacturing, Beverage
How can I get this working?
Implementation Guide
Step 01
Next steps offer an explication on the code and how buffer of data before sending it to another controller and using handshaking numbers (#’s) to indicate when a new packet of data has arrived.
Buffering of data: One reason for buffering data would be to keep a running list of data before transferring in case there is a communication failure. Another reason would be to make sure the data packet you are creating is complete. In this example I am buffering 10 (492byte) packets in a first in / first out fashion. If this is too much data buffering, this can be customized to your application.
Handshaking is used to indicate when there is a new packet of data being sent/ received. Some applications use what is called a footer # at the end of the packet, other applications use a header # at the beginning of the packet. In this example, I am using both a header and footer #. The basic operation of this is as follows; every time a new packet of data is ready to be sent, the incremented header and footer #’s are attached to the beginning and end of the (492byte) packet of data, making it a full (500byte) produce/ consume packet, when the other controller sees there is a difference between the old header/ footer # and the new header/ footer # it knows this is a new packet of data and buffers it in its memory. This new header / footer # is stored to be checked later when a new packet is sent again. This is taken one step further by introducing a bidirectional handshaking method. This means I am sending either the header or footer # back to the producer of the data as a trigger to send another packet.
send-data-between-controllers-with-handshake-in-studio-_Step 1-Image1
There are two Control Logix programs, one program produces data, and the other program consumes data. The program that is producing data is called CLX1_producing_ data_with_handshaking_ and_Buffering1. The program that consumes data is called CLX2_consuming_data_with_handshaking. They will be referenced as program CLX1_Produce and CLX2_Consume.
Data must be collected and buffered before sending it to the produced tag.
Refer to CLX1_produced program Rungs 7, 8, and 9.
Rung 7. Data is collected and buffered in a First in First out manner. In this example I am buffering 10 (123dint) data chunks (1 – 10). If there is no data in the 10th buffered data chunk, add 123 to the Buffered data pointer, if there is data there, stop filling the Buffered register.
Rung 8. When data appears in the 10th (123dint data chunk buffered register, The buffered register area is full and will set the Buffer full output.
Rung 9. If Buffer full output is set, shift Buffered data chunks 2 – 10 up by (123dints). Then fill the 10th buffered data chunk with zeros.
Step 02
Now that we have data buffered, start producing this data on the Ethernet network. Refer to CLX1_produced program Rungs 10, 11.
Rung 10. Will copy the first chunk of data from the Buffer to the produced tag.
Rung 11. Will assign a Header and Footer ID #. These numbers will range from (0 – 100). These ID’s will also be used as the handshaking numbers between the two CLX processors. The next scan through the ID’s will be increased by 1.
At this point the packet is formed and looks like this:
send-data-between-controllers-with-handshake-in-studio-_Step2-Image1
Step 03
The data is being consumed by another CLX2 processor over Ethernet. The consumed tag looks like this:
Refer to CLX2_consumed program Rung 1.
Rung 1. Compares the New ID’s assigned in Step 2 Rung 11 to the old ID’s Buffered in Step 6 Rung6. If the ID’s are different, it knows it is reading a new packet of data.
send-data-between-controllers-with-handshake-in-studio-_Step3-Image1
Step 04
If the communications stop, the control needs to be aware of this, refer to CLX2_consumed program Rung 2, 3, and 4.
Rung2. Every time there is a different in ID’s seen the counter counts +1
Rung3. If the counter doesn’t get done within 5 sec. the retentive timer times out.
Rung4. If the retentive timer gets done, there have not been comms for over 5 sec and the no comms. between clx1 and clx2 output is set. This can be used as an alarm bit.
send-data-between-controllers-with-handshake-in-studio-_Step4-Image1
Step 05
Double checking that the Header and Footer ID’s did not change. Refer to CLX2_consumed program Rung 5.
send-data-between-controllers-with-handshake-in-studio-_Step5-Image1
Step 06
Now it's time to copy data from the consume tag to a different register in the CLX2, to be used in its program.
Next move the present header and footer ID #’s into the Old ID register to be compared later when the next packet of new data is sent over. Now for the handshaking portion of the program.
The Footer ID # is sent back to the CLX1, in a Produced tag, to act as the handshaking piece of data, which will be compared in the CLX1 as you will see in Step8. Refer to CLX2_consumed program Rung 6 to 8.
send-data-between-controllers-with-handshake-in-studio-_Step6-Image1
Step 07
Once again if communications stop, the control needs to be aware of this. Refer to CLX1_produced program Rung 2, 3, and 4.
Rung2. Every time there is a different in ID’s seen the counter counts +1
Rung3. If the counter doesn’t get done within 5 sec. the retentive timer times out.
Rung4. If the retentive timer gets done, there have not been comms for over 5 sec and the no comms. between clx1 and clx2 output is set. This can be used as an alarm bit.
send-data-between-controllers-with-handshake-in-studio-_Step7-Image1
Step 08
Referring to Step6, the footer ID # is being produced by CLX2 and will now be consumed by CLX1, if the initial produced ID # matches the now consumed ID #, there is still communications, the handshaking is complete, and CLX1 is now ready produce a new packet of data.
But before producing a new packet of data, we must examine if our ID # has reached 100, if so, reset back to 0, and start counting up to 100 again. Refer to CLX1_produced program Rung 5 and 6.
send-data-between-controllers-with-handshake-in-studio-_Step8-Image1
send-data-between-controllers-with-handshake-in-studio-_Step 1-Image1
send-data-between-controllers-with-handshake-in-studio-_Step2-Image1
send-data-between-controllers-with-handshake-in-studio-_Step3-Image1
send-data-between-controllers-with-handshake-in-studio-_Step3-Image1
send-data-between-controllers-with-handshake-in-studio-_Step5-Image1
send-data-between-controllers-with-handshake-in-studio-_Step6-Image1
send-data-between-controllers-with-handshake-in-studio-_Step7-Image1
send-data-between-controllers-with-handshake-in-studio-_Step8-Image1
Send Data between Controllers with Handshake in Studio
Version 1.0 - November
Application and Configuration of a Torque Follower System with PowerFlex 755T- and the use of the TLink Module (FO Module) Configuration of a Power Flex 755T using a TLink module for load distribution, using a torque follower configuration.Downloads
Please note: You will need to agree to the Terms & Conditions for each download.
Need Help?
If you need help with an application or have feedback from the Innovation Center, please contact us.
The purpose of this document is to provide guidelines how to setup a load sharing application using a torque follower setup.
Load sharing is a term used to describe a system where multiple drives and motors are coupled and used to run one mechanical load.
The following assumptions are made:
The example is based on a large diameter bull gear with two motors. The motors are coupled via tooth sprockets and gearboxes.
This creates a rigid connection between the motors, ideal for a torque follower setup.
The torque follower (also known as master-slave) is a type of load sharing setup when we use one master drive in speed regulation and one follower drive in torque regulation.
The torque command generated by the master’s speed loop is transmitted to the follower drive to be used as torque reference.
A torque follower setup makes two or more motors act as 1 big motor. See below torque follower block diagram.
In this example the torque reference is transferred from the master drive to the follower drive via TLink option module.
Is this helpful?
If you are working with systems involving multiple motors coupled to a single load, this document will be very useful to you in setting up an efficient and effective control strategy.
How can I get this working?
References documents
Installation Guide
Step 01
Pasos de configuración VDF
1. General Settings
In this example both drives are equipped with a 20-750-TLINK-FOC-5 (Fiber 5 m) Module located in the Port 4, and a 20-750- ENC-1 Incremental Encoder card in the Port 5.
The following settings apply to both drives.
- 0:65 [Pri Mtr Ctrl Mode] = 4 “Induction FV”. This selects motor control mode as Induction Flux Vector.
- Enter motor data parameters in 10:400 - 10:407.
- 10: [Pri Vel Fb Sel] = 5:4 [Encoder Feeback]. This selects incremental encoder as motor feedback source.
- Enter encoder resolution in 5:2 [Encoder PPR].
2. Master Drive setup
3. TLink Option Module Master Drive setup
4. Slave Drive setup
Step 02
Tuning Steps
Tuning is critical working in Flux Vector control mode. We will use the Autotune function to measure motor characteristics. Autotune is composed of several individual tests, each of which is intended to identify one or more motor parameters. These tests require motor nameplate information to be entered into the drive parameters. We can run all the tests in the parameter 10:910 [Autotune].
These are the recommended steps:
1- Enter motor data parameters in 10:400 – 10:407.
2 - Run 10:910 [Autotune] = 1 “Direction”. This allows you to determine if the motor rotates in the desired direction. Also allows you to check if encoder feedback count increases in value for a forward velocity command.
3 - Measure the motor electrical parameters:
4 - Set the current regulator bandwidth 10:445 [VCL CReg BW]
5 - Run 10:910 [Autotune] = 4 “InertiaMotor” to measure the motor inertia. This test initiates momentary motor rotation to measure and update 10:900 [Motor Inertia].
This test is only an option if the load can be disconnected to run the test. If the load cannot be disconnected, you should enter the value manually in 10:900 [Motor Inertia].
6 - In the master drive, run 10:910 [Autotune] = 5 “Inertia Total”. This test initiates momentary rotation of the motor and load to measure total inertia and calculate 10:901 [Load Ratio]. After selecting this value, you must issue a start command to begin the test. Perform this test with the load connected to the motor.
10:900 [Motor Inertia] and 10:901 [Load Ratio] are used to calculate the torque scaler Kj, an internal parameter that compensates for the effects of inertia and affects overall tuning. Load Ratio is also used to calculate controller gains.
Since the application will be controlled by 2 load sharing motors, the Load Ratio of the Master drive measured during the test can be divided by 2.
7 - In the master drive, run 10:910 [Autotune] = 6 “BW Calc”. The bandwidth calculation test calculates control loop gains and dynamic limits.
8 - Run the master drive and adjust system bandwidth in 10:906 [System BW] if necessary. Decreasing system bandwidth stabilizes the system and increasing it improves performance. Typically, high gain results in a quicker response time, but excessive gain causes system instability.
For more information about tuning see PowerFlex 755T Flux Vector Tuning, publication 750-AT006.
Step 03
Signal Checks and Operation Steps
1. Signals Checks
Run the master motor (only) up to nominal speed. Master Drive: Check 10: [Trq Ref Limited] during acceleration.
2. Operation
To start the torque follower application
To stop the torque follower crusher application
When a drive is faulted
Step 04
Load Logix program into the controller Steps
1 - On the Studio development software we open the program “Torque_Follower_with_TLink”, the following image is then displayed, where the controller, an analog and a digital card, as well as the Ethernet card where the PowerFlex 755TS Drives will be part of the network are already added.
2 - On the menu bar, click on “communication” and choose “download” from the options that appear, then click again on the button in the window that opens, as shown in the following image.
3 - We wait for the program to download to the controller
4 - Finally we click on the Yes button on the window that appears after the program is loaded into the controller, this, to change the controller mode to “Remote Run”
Application and Configuration of a Torque Follower System with PowerFlex 755T- and the use of the TLink Module (FO Module)
Version 1.0 - December
Home to Torque Limit Sequence in Studio The Home to Torque Limit Sequence is defined for applications to monitoring torque while driving an axis into a mechanical hard-stopThis application explains how to use the Home to Torque-level sequence in Studio software, and the considerations required when using this homing method. This document provides an example for a typical homing program routine.
Home to torque-level homing is a process that references a known position by monitoring torque while driving an axis into a mechanical hard-stop. Once the actual torque level reaches or exceeds a specified torque level for a set time of 500 ms, a status flag is set in the controller.
General Features
Advantages:
This sequence facilitates the implementation and quick configuration for Homing an Axis when is required monitor the torque.
Limitations/Disadvantages:
This sequence is available for CompactLogix / ControlLogix Controllers.
This code is defined for applications to monitoring torque while driving an axis into a mechanical hard-stop.
Downloads
Please note: You will need to agree to the Terms & Conditions for each download.
Need Help?
If you need help with an application or have feedback from the Innovation Center, please contact us.
How can I make it work?Installation Guide
Step 01 - Configure the Axis Homing Tab
Because the process of home to torque-level requires axis motion, the axis homing mode must be configured as Active.
1- Open the Axis Properties tab. And complete the next configuration. The Torque level option sets the Home Position after the output torque reaches the Torque Level value, reverses direction, and moves until the Homing Torque Above Threshold bit is low and the status bit sets. The Torque Level – Marker sets the Home Position after the output torque reaches the Torque Level value, reverses direction, and encounters an encoder marker.
When either the Torque Level or Torque Level - Marker homing option is selected on the Homing tab, the Torque Level field is activated in the Active Home Sequence Group. The units for this field are a percentage of the continuous torque of the motor (% Continuous Torque) limited by the drive-rated current/motor-rated current ratio. This number is interpreted in the drive as an absolute value and the range is 0...TorqueLimitPositive value.
Forward Bi-directional and Reverse Bi-directional are the only options for the Direction field when Torque Level or Torque Level - Marker homing sequence is selected. Uni-directional homing is not possible, because the Home to Torque-level sequence relies on a mechanical hard-stop.
Step 02 - Drive Bipolar Torque Limit Adjustment
When homing an axis to a mechanical hard-stop, set the Home Torque-level value above the torque value required to move the system, but low enough not to cause problems with the system mechanics.
As part of the process of homing to a torque limit, limit the Peak Torque value to a level 10% above the Home Torque value to reduce the stresses on the mechanics and to eliminate the chance of an over-current fault.
The 10% value is an estimated starting point. This value may need adjustment based on the application requirements. Limit the Peak Torque value before issuing the homing instruction (MAH) and reset the Peak Torque field to the original value after homing completes.
Step 03 - Disable Soft Overtravel Limit
If the application requires the use of soft-overtravel limits (Limits tab) to safeguard the system mechanics, the Soft Travel Limits must be disabled for the axis to home.
The Soft Travel Limits must be disabled through programming to prevent a fault from occurring during the homing operation, but re-enabled after homing completes.
Step 04 - Ladder Code Sequence
This sequence shows how to adjust the peak torque limit and disable the soft-overtravel limit checking when homing to a torque limit. The code uses a state model methodology in which each rung of code needs to complete successfully before moving to the next rung.
Rung 11 of the ladder code checks to make sure that the axis position, after homing, is within the Soft Travel Limits before re-enabling soft-overtravel limit checking. In this code a 1.15 cm Offset move is configured in the Homing tab and that is the final home position. The 0.5 cm is within the Soft Travel Limits set on the Limits tab.
List of Tags Used
Axis Properties - Homing Tab
Axis Properties - Limits Tab
Ladder Code Example
Potential for Position Error Fault
When executing a torque limit homing procedure there is potential for a Position Error fault. As mentioned earlier, for the home to torque limit to complete, the output torque to the motor must reach (or exceed) the specified torque level for a set time of 500 ms. During this time the axis is against the mechanical hard-stop, and following error is increasing in the position loop. If the Position Error Tolerance value is exceeded before completion of the homing instruction, a Position Error fault (E19) will result.
There are two ways to limit the occurrence of an E19.
- Set the Position Error Tolerance value on the Limits tab of the Axis Properties to a value high enough to eliminate a fault from occurring.
- Modify the Position Error Tolerance value via an SSV instruction similar to the method used in code above to change the Bipolar Torque Limit.
Rung 6 of the ladder code opens the Position Error window. This allows the Homing to complete without causing a Position Error fault. The original value is reset after Homing completes.
Home to Torque Limit Sequence in Studio
Version 1.0 - August
Torque Calculator for Servo Motors This will help you convert motor torque feedback from percent to torque units and also calculate the Peak Torque/Force Lim parameter.Simplify the calculation of the motor feedback torque in torque units for servo motors, as well as the conversion of the maximum torque from a given value in torque units to percent.
The use of the block or AOI (for Add-On Instruction) is extremely simple, just open the attached file labeled “AOI_TorqueCalculator_ForServoMotor - Application Code.ACD” and copy to your project file.
Add-On Instruction should look like this:
Limitations/Disadvantages
It can be used only with Servodrives with SERCOS network.
The AOI_TorqueCalculator_ForServoMotor automatically calculates the motor Torque Feedback in torque units. This AOI can also calculate the Peak Torque/Force Lim in percent from a desired maximum motor torque limit given in torque units.
This AOI is constituted by three sets of parameters: one set for configuration of the AOI, one set to convert Torque Feedback from % to torque units, and a set to convert the Peak Torque/Force Lim from torque units to %.
The user needs to enter only two motor parameters in the AOI: Continuous Stall Torque and Peak Stall Torque found in datasheets. All the other parameters needed in this AOI are automatically read from the drive when this AOI is enabled. This AOI continuously converts the Torque Feedback from percent to a given toque unit while enabled. The result is placed in the parameter Out_Torque_Nm. The torque unit is the same of the parameters Inp_ContStallTorque_Nm and Inp_PeakStallTorque_Nm. Meanwhile, this AOI can be used to calculate the parameter Peak Torque/Force Lim from the torque entered in the parameter Inp_DesiredTorqueLim_Nm, which corresponds to the maximum peak torque required for a particular application. The parameter Inp_DesiredTorqueLim_Nm is entered in torque units and the result for the Peak Torque/Force Lim stored in the parameter Out_ForceTorqueLim_Perc is given in percent.
This AOI must remain enabled to calculate Torque Feedback in a given torque unit.
AOI Control
Typically, the AOI_TorqueCalculator_ForServoMotor instruction can be executed when torque feedback needs to be read in torque units or when the Peak Torque/Force Lim needs to be calculated for specific torque limit as shown below.
Appendix: Parameter Definitions
Inp_Axis:
Axis (Servo_Axis_Drive data structure) that will have torque converted torque units.
Ref_MotorContStallCur:
This is a Message data type tag. This parameter is used to read the Motor Continuous Stall Current from the drive. The Motor Continuous Stall Current is parameter 111 (S:0:111) in a Kinetix drive. The Ref_MotorContStallCur tag is configured in the AOI as shown below. The Destination is the tag MTC.Inp_DriveContCur_mA.
Ref_MotorPeakStallCur:
This is a Message data type tag. This parameter is used to read the Motor Peak Stall Current from the drive. The Motor Continuous Peak Current is parameter 109 (S:0:109) in a Kinetix drive. The Ref_MotorPeakStallCur tag is configured in the AOI as shown below. The Destination is the tag MTC.Inp_MotorPeakStallCur_mA.
Ref_DriveContCur:
This is a Message data type tag. This parameter is used to read the Drive Continuous Current from the drive. The Drive Continuous Current is parameter 112 (S:0:112) in a Kinetix drive. The Ref_DriveContCur tag is configured in the AOI as shown below. The Destination is the tag MTC.Inp_DriveContCur_mA.
Ref_DrivePeakCur:
This is a Message data type tag. This parameter is used to read the Drive Peak Current from the drive. The Drive Peak Current is parameter 110 (S:0:110) in a Kinetix drive. The Ref_DrivePeakCur tag is set in the AOI as shown below. The Destination is the tag MTC.Inp_DrivePeakCur_mA.
Inp_ContStallTorque_Nm:
This is a REAL data type tag. The user uses this parameter to enter the Motor Continuous Stall Torque, which is found in the motor nameplate or in the Motion Selection Guide. This parameter is shown to be given in Nm. However, any other torque unit can be used if the Inp_PeakStallTorque_Nm be also set in the same toque unit. Thus, the torque feedback given in the Out_Torque_Nm will also be given in this same torque unit.
Inp_PeakStallTorque_Nm:
This is a REAL data type tag. The user uses this parameter to enter the Motor Peak Stall Torque, which is found in the Motion Selection Guide.
Out_Torque_Nm:
This is a REAL data type tag. This parameter shows the Torque Feedback converted from percent to the torque unit given by the parameters Inp_ContStallTorque_Nm and Inp_PeakStallTorque_Nm.
Inp_DesiredTorqueLim_Nm:
This is a REAL data type tag. This parameter is used to enter in torque units the torque limit for a particular application. The AOI converts this torque from torque units to percentage. This torque in percent is the Peak Torque/Force Lim to be manually entered in the Limits tab of the Axis Properties. The torque entered in this parameter must be in the same unit as the parameters Inp_ContStallTorque_Nm and Inp_PeakStallTorque_Nm.
Out_TorqueForceLim_Perc:
This is a REAL data type tag. This parameter returns the Peak Torque/Force Lim necessary to limit the motor torque to the value entered in the parameter Inp_DesiredTorqueLim_Nm. This parameter is given in percentage.
Sts_EN:
The Enable bit is set while the rung is on.
Sts_TLim:
This Torque Limit bit is set when the value entered in the Inp_DesiredTorqueLim_Nm parameter is higher than the torque that the motor-drive system can deliver.
Sts_ER:
The Error bit is set if same of the message instructions used to read parameters from the drive fail to communicate with the drive. This bit is reset when the AOI is enabled. When an error occurs, the error message can be read in the Message Configuration window which can be accessed by hitting the box beside the tag name as shown below.
Inp_MotorContStallCur_mA:
This is a DINT data type tag. This parameter is the Destination in the Ref_MotorContStallCur message. This parameter contains the Motor Continuous Stall Current in mA read from the drive by the Ref_MotorContStallCur message.
If you are looking for more details, kindly visit ISTE Automation.
Inp_MotorPeakStallCur_mA:
This is a DINT data type tag. This parameter is the Destination in the Ref_MotorPeakStallCur message. This parameter contains the Motor Peak Stall Current in mA read from the drive by the Ref_MotorPeakStallCur message.
Inp_DriveContCur_mA:
This is a DINT data type tag. This parameter is the Destination in the Ref_DriveContCur message. This parameter contains the Drive Continuous Current in mA read from the drive by the Ref_DriveContCur message.
Inp_DrivePeakCur_mA:
This is a DINT data type tag. This parameter is the Destination in the Ref_DrivePeakCur message. This parameter contains the Drive Peak Current in mA read from the drive by the Ref_DrivePeakCur message.
Downloads
Please note: You will need to agree to the Terms & Conditions for each download.
Need Help?
If you need help with an application or have feedback from the Innovation Center, please contact us.
Motor Starting Sequence with SQL Recipe Parameters The SQL Motor Starting Sequence features the use of FactoryTalk Transaction Manager (FTTM) to bind the communication between an SQL database and Studio.The SQL motor startup sequence introduces the use of FactoryTalk Transaction Manager (FTTM) to link communication between an SQL database and Studio . FTTM reads values from different recipes for flexible and reconfigurable manufacturing and applies these values to tags in sequence programs to start the corresponding process once the current routine is completed. This way, an information exchange is implemented between production floor control and commercial databases.
The current model performs bidirectional information transactions between FTTM and Studio . These are carried out once the control system indicates it and proceeds to take information from the database for application in the system. All transactions made are stored for the necessary traceability of production operations. With applications in consumption, automotive, packaging, and other industries, this project serves as a template for commissioning motors with parameters in databases.
General characteristics
The motor startup sequence with an SQL database offers the following features:
Advantages
The demand for multiple SKUs (Stock Keeping Unit) on production lines requires quick transitions between manufacturing setups. This project serves as a fundamental basis for connecting a Studio program and an SQL database with all necessary production parameters. Through flexible technology, manufacturers will be able to improve equipment performance and overall efficiency (OEE), while digitizing operations to provide real-time process control and production support.
Customer demand will continue to increase and present different scenarios on production lines. Manufacturers will need to implement flexible and reconfigurable manufacturing to address these challenges. Through this project, a Studio program commissions motors according to the selected recipe number and provides an integrated database solution for production companies.
Implementations of this project can vary from serving as a demonstration for companies facing these challenges to being used as a template for configuring production parameters from an SQL instruction database.
Hardware:
Software:
Knowledge:
Familiarity with the use of SQL databases, motor commissioning through frequency inverters and PAC controllers, knowledge of network configuration for motor stations.
FactoryTalk Transaction Manager Basic Configuration Lab.
Downloads
Please note: You will need to agree to the Terms & Conditions for each download.
Need Help?
If you need help with an application or have feedback from the Innovation Center, please contact us.
Installation Guide
Step 1
Identify the applications used for this implementation: Studio , SQL Server Management Studio, FactoryTalk Transaction Manager, and FactoryTalk Administration Console.
Step 2
In the FactoryTalk Administration Console application, create a shortcut to the motor system controller named "Mach1_Ent".
Step 3
3.1 Enter the Studio program attached with the motor startup sequence. Go to the Object_Assignments routine. Adjust the variables of the motor commands towards the used PowerFlex VFDs.
3.2. If you wish to create different variables for your VFDs, do so in Controller Tags.
3.3. If you need to change or improve the routine, you can activate or deactivate them with the Jump to Sub Routine (JSR) instruction found in the Servos routine.
Step 4
Access the routines of each station (in this case there are five stations) and assign values to the variables using the MOV command. For example, if you want to change the "PRESET" time of a timer, in our case the S1M1_TimeOn1, or if you want to change the RPM value of the motor, you can also do it with this instruction. In the attached program, there are examples for assigning time intervals and changing speeds.
Step 5
Access FTTM and add the created variables as Data Points in the Checklist. Then click on Save Edits and subsequently Assemble Edits.
Step 6
Access the SQL queries in the MotorStationCommands Excel file and modify the database using the columns as the variables used in Studio to commission the motors. Add as many recipes as desired.
Step 7
Access Programmability: Stored Procedures: dbo.Recipe_sp. Modify the SQL query procedure to get the values of the columns and assign them as data points in FTTM.
Step 8
In step 4 of the FTTM checklist, add the parameters of the revised procedure in the previous step of the SQL database.
Step 9
Separate the input and output parameters of the variables in step 5 of the FTTM configuration. Assign null values to all input variables for motor control. Apply and save all changes and start the FTTM configuration.
Step 10
Enter the Studio program and test all changes by selecting different recipes. To do this, enter the recipe number in the RecipeReq tag in the S01_TransactionManager program. Then toggle the Recipe_On_Off bit. Validate the process operation by checking the recipe values once the current cycle is completed.
MagneMover Lite and Cobot UR5 Digital Twin Implementation Digital Twin creation through Emulate3D with ICT and robotics collaboration.The Digital Twin interaction between a cobot and a 1-meter MagneMover LITE (MML) system is the foundation for the development of both technologies through Emulate3D. This project can be used to demonstrate MML technologies and robots working together, or as a template for developing digital twin models of these technologies. Using the Studio program, MML vehicles can be commissioned, and a routine can be created.
The implementation of the digital twin model demonstrates the capabilities that enable its use throughout the industry. The model allows for performance tracking of multiple systems on a manufacturing floor. It also provides the opportunity to optimize production processes through digital emulation without the need to shut down production. Additionally, it is possible to ensure higher quality, train operators, and make configuration changes in a secure virtual environment with immersive reach into cyberspace.
General Characteristics
The integration of a MagneMover LITE system and a cobot via a digital twin offers the following features:
Advantages
Digital Twins are a game-changer for manufacturers looking to optimize their production processes and stay ahead of the competition. By creating a virtual environment to model and analyze their operations, manufacturers can identify inefficiencies and areas for improvement, leading to increased productivity and cost reduction. With Digital Twins, manufacturers can design an efficient layout and allocate equipment accordingly, eliminating the need for hardware testing and saving valuable time and money.
No longer do you have to wait for a machine to be built to test controls and confirm that mechanics and logic are working correctly. This saves valuable time and resources and reduces the costs spent on correcting errors found during the physical implementation stage. By working together, you can visualize an efficient transition for implementing the digital twin in your production lines and understand the benefits it brings.
Once your system is up and running, a digital twin records data on behavioral trends and performance history. This creates a reference for improvements and operational training methods throughout the system's life cycle. With this valuable information at your fingertips, you can optimize your processes, increase efficiency and productivity, and take your manufacturing to the next level.
Hardware:
Software:
Expertise:
Downloads
Please note: You will need to agree to the Terms & Conditions for each download.
Need Help?
If you need help with an application or have feedback from the Innovation Center, please contact us.
Installation Guide
Step 1:
Identify the applications used for implementation: Studio and Emulate3D.
Step 2
Change the IP address of the components used to place them in the same network mask:
Paso 3:
Replace the physical devices in the Studio configuration and configure the assigned IP addresses while keeping the same device names.
Step 4
Replace the controller in the Studio configuration for program download.
Step 5
Validate the connection of each part of the system through pings in Command Prompt. After that, change the IP address of the components in Emulate3D.
5.1 Click on Global Settings of the MML controller and change the PLC's IP address.
5.2 Click on Node Settings of the MML controller and change the node controller's IP address.
5.3 Change the HLC address in the NCHost tab to the node controller's IP address.
Step 6
Click on IO Browser and import the tag configuration from the shared Excel file.
Step 7
Open the attached Studio project and locate the "R02_StartupSequence" program with the path: msp10: P01_MM_Management.
Change the IP address of the node controller in line 2.
Step 8
Download the Studio project to the PLC controller and select Run Mode.
Step 9
In the same program, apply a Toggle Bit to Cmd_Startup to initialize the MML motor and wait for the nStartSeq value to be 999 to validate the initialization process.
Step 10
Enter the "R05_MotionPositionMove Program" program in the same path and apply a Toggle Bit to "AutoCycle." This will start the MML system's motion program. In this program, the vehicular motion sequence can be edited.
Step 11
11.1 Open the Emulate3D model and verify that the connection type in the NC Host tab is Status.
11.2 Select Connect under the HLC Address section.
11.3 Select the MML controller and in the NC Host tab, select Connect Movers and Connect Paths.
11.4 Change the Mover Polling Rate for smoother movements by decreasing its value.
Step 12
12.1 On the Home Tab, select the play icon.
12.2 Verify that the components move correctly. If the cobot is in a different static position, repeat Step 7 and check the PLC connection in IO Browser to the digital model.
Energy saving monitoring system with FactoryTalk Optix FactoryTalk Optix and variable speed drives for process control and efficiency in the soft drink industry.The "Energy Saving Monitoring System with FactoryTalk Optix" developed in FactoryTalk Optix aims to provide a clear and understandable visualization of energy efficiencies by allowing operators to monitor tank levels, flow rates in pipes, and other critical parameters in the extraction and pumping process in a beverage industry; thus, facilitating faster decision-making and problem resolution.
Additionally, integration with FactoryTalk Optix enables effective alarm management. Operators can configure alerts for critical events, such as tank level deviations or equipment failures, ensuring timely intervention and minimizing downtime. This way, we can ensure:
Characteristics
“Energy Saving Monitoring System with FactoryTalk Optix" offers the following features:
Advantages
The growing demand to achieve "net zero” carbon emissions require technologies that allow us to monitor the energy consumption of motors in plants and; if it is an application where torque is variable, as it is the case with pumps, take small actions that allow consume less water and energy. Thus, through the PowerFlex 520 family, manufacturers will be able to improve the performance and overall efficiency of the equipment (OEE).
Customer demand is versatile and presents different scenarios in production lines. Manufacturers will have to implement flexible and reconfigurable automation to address energy consumption challenges. Through this project, a Studio program simulates the water demand required by the industry, and Optix allows users to become aware of the savings that the drive provides.
Hardware:
Software:
Knowledge required:
Familiarity with modifying parameters of frequency drives of the 520 family A-B and knowledge of the CompactLogix family.
Downloads
Please note: You will need to agree to the Terms & Conditions for each download.
Need help?
If you need help with an application or have feedback from the Innovation Center, please contact us.
Installation Guide
Step 1:
Familiarization with the Program.
Note that in the left panel "Controller Organizer," there are 4 routines. In BATCH_CONTROLS, can be found the control of system power on/off and motors power on/off. In the "FILLING ROUTINE", the filling process of a tank is simulated, while in the "EXTRACTING ROUTINE," the tank extraction is simulated. The "FLOW_METERS" routine simulates how the water flow increases as more time is spent pumping.
Step 2
Verify that the SoftDrinkProduction program has been downloaded into the controller and is already online.
Step 3:
Familiarize yourself with the PowerFlex 525, that is, which parameter it starts, stops, and which one changes the speed. Note that the PowerFlex is active and running.
Step 4
Open the Factory Talk Optix program.
Step 5
Verify that the controller is already on the correct BackPlane on FactoryTalk Optix.
Step 6
Run the program from the main toolbar located at the top of the interface.
Step 7
7.1 Once the program is running, the main screen will be displayed where you can observe:
The navigation bar is located at the bottom.
Extraction Screen: Allows monitoring the extraction process from a well to notify the operator if a pipe leak occurs.
7.2. Process Control Screen: Here, the extraction process from a tank can be visualized.
At the beginning, a warning screen will appear informing us that the production for the beverage industry in this example ranges from 200 bottles per minute (BPM) to 480 BPM.
7.3. On this screen, on the left, you can reset the parameters of the "Extraction" and "Process Control" screens (parameters such as tank level, pumping and extraction flows, the number of bottles entered, etc.). In the textbox on the right, you can enter the number of bottles required for production and observe how the revolutions per minute (RPMs) change on the motor's faceplate.
7.4. Alarm Screen: This screen allows monitoring all system alarms, as well as important trends such as tank level, pump speed, and pumping flow in gallons per minute [GPM].
7.5. Data Screen: Allows recording tank level data, as well as detecting leaks in the water extraction process from the well into the tank.
7.6. Savings Screen: In this screen, you can observe how by varying the motor intensity, based on the affinity laws of centrifugal pumps, greater energy savings are achieved compared to controlling the flow with a throttling valve.
MicroLink Remote Control, MicroLink MQTT Remote Control Streamline IoT in industrial environments. Unlock MQTT capabilities effortlessly through Micro800 controllers.MicroLink MQTT is a transformative suite of User-Defined Function Blocks (UDFBs) for Micro800 controllers, enabling seamless MQTT communication with any MQTT broker. This package includes three function blocks: one for establishing connections, one for subscribing to specific topics, and one for publishing data. It offers high customizability with settings for unique MQTT IDs, broker/server IP addresses, usernames, passwords, and your chosen Quality of Service (QoS).
Target to use with PowerFlex 523 and 525 component drives from Rockwell Automation.
This code can be used with the following equipment:
MicroLink MQTT is a UDFBs suite designed for seamless integration with Micro800 controllers from Rockwell Automation. It's meant to enhance the capabilities of these controllers by enabling MQTT communication with any MQTT broker.
This solution is especially useful for remote control use cases and in the industrial field where data exchange and communication efficiency are critical. MicroLink MQTT provides three function blocks for establishing connections, subscribing to specific topics, and publishing data.
With MicroLink MQTT, users can easily establish a connection to an MQTT broker, subscribe to the data they need, and publish data back to the broker. It offers high customization options for MQTT IDs, broker/server IP addresses, usernames, passwords, and your chosen Quality of Service (QoS), ensuring efficient and secure data communication.
Therefore, whether you're an industrial operator looking to optimize data communication or a developer who needs to integrate efficient data exchange in your applications, MicroLink MQTT can be the perfect solution.
General Features
Our package provides three core User-Defined Function Blocks:
Each function block is highly customizable, allowing you to specify unique MQTT IDs, broker/server IP addresses, usernames, passwords, and your preferred Quality of Service (QoS). With RA_MQTT v2, every aspect of your MQTT communications is in your hands.
Limitations / Disadvantages
The architecture implies using Micro820, Micro850, Micro870 hardware. And this is the required software:
Knowledge
A foundational understanding of ladder programming and system configuration using the Connected Components Workbench software is highly recommended. Additionally, familiarity with MQTT protocols would be beneficial.
Downloads
Please note: You will need to agree to the Terms & Conditions for each download.
Need Help?
If you need help with an application or have feedback from the Innovation Center, please contact us.
Installation Guide
Step 1:
Establishing Connection Settings to Connect to or Disconnect from a MQTT Broker
An MQTT broker essentially serves as a server to manage MQTT messages. To connect to an MQTT broker, we must input the broker's IP address and port number into the RA_MQTT_CONNECT_v2 UDFB. The broker could be housed on your computer (in which case you would need to install and operate an MQTT broker compatible with your OS), or it could be a remote server, such as the ones previously mentioned.
1.1 Assign the IP address and port number of the MQTT broker to your RA_MQTT_CONNECT_v2 UDFB
This example is for connecting to the test.mosquitto.org broker in the cloud. An alternative to entering the IP address directly is to enable Domain Name Service (set ‘EnableDNS’ TRUE) after entering in the MQTT broker URL into ‘MQTTBrokerName’ and the local DNS server IP address into ‘DNSIPaddr’ in rung 2.
1.2 Enter a unique ‘clientName’, as well as a ‘userID’ and ‘userPass’ if your MQTT broker requires it. (Many public MQTT brokers do not require a username and password, so these fields are optional and can be left blank if not required.)
1.3 Set ‘EnableMQTT’ to TRUE to connect to the MQTT broker.
Note:
There are a few things to keep in mind to ensure a successful connection. The MQTTsocketSts should eventually display a 9. If it shows a 7 and then reverts back to 0, it could imply that your broker is either not running or doesn't exist.
The data in resultData_Out is helpful for diagnostic troubleshooting. Typically, when you send a connect command to the server, the server responds with an acknowledgement. The acknowledgement is indicated by the 1st byte, which in this instance, is '32'.
Another frequent response you'll receive is a ping acknowledgement, denoted by '208' in the 1st byte of the returned data. The ping command is sent to the remote broker at 50-second intervals. This interval is hardcoded in the UDFB but can be modified if needed.
If the return data is something other than 32 or 208 upon connection, it could suggest that the client has subscribed to a topic that was broadcasted while it was offline. The message is retained and sent to the client when it comes back online. If you encounter this, process the message and then reinitialize the connection.
1.4 If you want to configure for LWT, you need to access these parameters in the UDFB:
322| willTopic := willTopic_In; 323| willData := willData_In;
‘willTopic_In’ is where you enter the Last Will topic for the connection.
‘willData_In’ is where you enter the testament for the connection.
The MQTT broker will publish the testament to all clients that subscribe to the Last Will topic when the client is disconnected abruptly.
1.5 If you want to disconnect gracefully from the server (without triggering LWT), set ‘disconnect_Cmd’ to TRUE.
This is a rising edge triggered bit, so you can reset it immediately.
Step 2
Subscribing to or Unsubscribing from a Topic
The MQTT protocol exchanges data through subscribe and publish methods. Clients communicate directly only with the MQTT broker. Clients subscribing to a topic will receive a message from the broker when another client publishes to that topic. Clients can be of any form as long as they have a running MQTT client application. For example, it could be software on a PC, a connector or API for the software, an app on a , or application code on a PLC.
2.1. Enter the name of the topic (‘topicName_input’) to subscribe to or unsubscribe from.
2.2. Set the quality of service (‘subQoS’) for the subscription. By default, use ‘0’ as it consumes the least bandwidth.
2.3. Set ‘subscribe’ or ‘unsubscribe’ to TRUE to subscribe to or unsubscribe from the topic.
2.4. These bits detect for rising edge, so you can reset them immediately.
2.5 Notice that the resultData_Out from RA_MQTT_CONNECT_v2 is also copied to respondData_In.
Note:
It is recommended to use only 1 instance of each UDFB.
Step 3:
Publishing a Topic
When a topic with data is published to an MQTT broker, the broker then forwards this topic data to all the clients subscribed to it. The client that publishes the message does not know if any remote nodes receive the topic, as that responsibility lies with the broker, depending on the QoS level. Topics can be published or subscribed to at any QoS level, but they will only be delivered at the lowest QoS level.
3.1. Enter the topic to publish into ‘pubTopic_In’.
3.2. Enter the data for the topic into ‘pubData_In’.
3.3. Set the quality of service into ‘pubQoS’. By default, use ‘0’ as it consumes the least bandwidth.
3.4. Set ‘publish’ to TRUE to publish the topic with its data. It will automatically will be set back to FALSE when ‘publishDN’ becomes TRUE.
3.5. Notice that the resultData_Out from RA_MQTT_CONNECT_v2 is also copied to respondData_In.
Step 4
Getting Messages from Subscribe Topics
The MQTT broker handles all topic subscriptions. It sends the data of any published topic to the clients that are subscribed to it. When a topic is received by the Micro800 MQTT client, it populates the 'TopicName' and 'TopicData' array variables in the RA_MQTT_CONNECT_v2 UDFB. The data is stored in a First In/First Out order, so it is crucial to process the data before it gets overwritten.
Step 5
Subscribing to an Array of Topics
MQTT_Subscriptions is an optional Structured Text program that works in conjunction with the MQTT_Client program. It enables you to subscribe to a 'Subscriptions' array of preconfigured topics. Adjust the array dimension of the global variable 'Subscriptions' to the desired size and modify the initial value of the local variable 'maxSubscriptions' to match the array size (default=10). 'Subscriptions' is a User-Defined Data Type (UDT) array that comprises the MQTT topic 'Name', the latest topic 'Data', a timestamp based on the RTC value when the latest topic 'Data' was received, and a 'Subscribed' indicator. Enter the desired topic names to subscribe to as initial values for Subscriptions[i].Name before downloading the project to the controller.
Local variable 'enableSubcriptions' must be TRUE in order to enable this functionality.
Step 6
Automatically Publishing an Array of Topics
MQTT_Publications is an optional Structured Text program that works in conjunction with the MQTT_Client program. It allows you to publish an entire 'Publications' array of preconfigured topics. Adjust the array dimension of the global variable 'Publications' to the desired size and modify the initial value of the local variable 'maxPublications' to match the size of the array (default=10). 'Publications' is a User-Defined Data Type (UDT) array that comprises the MQTT topic 'Name', the latest topic 'Value', the previous topic value 'Valueprev', and a timestamp based on the RTC value when the latest topic 'Value' was published. Enter the desired topic names to publish as initial values for Publications[i].Name before downloading the project to the controller.
Set the local variable 'ChangeOfState' to TRUE to publish any value that changes on an exception basis. Set the local variable 'Interval' to TRUE and 'intervalTime' to a non-zero value to publish all of the current values that aren't null ('') on a timed interval basis. Typically, one would choose either 'ChangeOfState' or 'Interval' as the method for publishing topic updates. For a one-time update, set the local variable 'OnDemand' to TRUE to publish all current values that aren't null (''). 'OnDemand' is set to FALSE once the entire 'Publications' array has been published. The local variable 'enablePublications' must be set to TRUE to enable this program functionality.
Want more information on Pulp Molding AOI Machine? Feel free to contact us.