Interface and Editing

You Can Select Multiple Controls and Change the Same Parameter for all Controls at Once

Have a bunch of items in a grid, each one with the same 5% margin from the left, and suddenly you decide 3% looks much nicer? No need to click through each one nor find and replace in the HTML source files! Just select all controls and change the parameter in the properties tab. The property you changed is now changed for every control you selected.

The Document Outline is a Great Help When Working on a Screen

Having trouble selecting a control, or is a control lost behind another? As great as the main WYSIWYG (what-you-see-is-what-you-get) editor screen is, the Document Outline provides greater visibility into nested controls (when using Grids and Containers) and invisible controls. I almost always have this pinned to my XAE layouts when developing with TwinCAT HMI.

Symbols and Parameters

“Symbol” and Related Terms to Know When Searching Infosys

Symbol just refers to a tag or variable, in TwinCAT HMI. There are variations:

• Server Symbols are symbols saved in the TwinCAT HMI server. Most notably Mapped Symbols are a type of server symbol which comes from the PLC.
• Internal Symbol are symbols which are limited to a single browser instance.
• Symbol Expression refers to the text

You Can Double Click on a Symbol to Pop Up a Nifty Binding Details Window

When you have a symbol in a data binding or function binding, you can double click on it to pop up a ‘Edit Binding’ window. This can show you some details on modes and settings and can also be used to quickly edit the symbol name. In the screenshot below, I might have a similar ‘IsAlarmLowEnabled’, and I can switch this symbol binding to that symbol more quickly than reopening the Create Data Binding window

When Making a Parameter for a User Control, Comments are Very Underrated

User controls are great for creating reusable custom controls, but they’re even better when you comment any parameters you make. Now, not only can developers that use your control (including future you, probably) hover to see your comment, they’ll also be able to hover to see the datatype!

Function Bindings and Scripting

Function Bindings are Basically Javascript

Consider a function binding as a continually evaluating single JS expression where symbol expressions get evaluated as their value and the result of the JS expression is what the parameter sees.

Remember that the function binding accepts and evaluates only a single JS expression. With that in mind…

“IIFE”s are incredibly useful when you want multiple expressions in a function binding but don’t want to write a full TwinCAT HMI function

Custom Javascript or Typescript functions in TwinCAT HMI are an excellent tool, especially when you will need to run the same snippet in multiple places. But sometimes you want to have a few expressions together in a one-off function binding. Ordinarily, one can’t do the following in a function binding:

let a = 1;

let b = 2;

return(a+b);

Well, you could write that in a function binding, but you won’t get anything useful back. Instead, you can write this:

(function (){

  let a = 1;

  let b = 2;

  return(a+b);

})();

I’ve grown to really love TwinCAT HMI for its power and extensibility, for industrial HMI applications from simple to complex. I hope these tips are useful as you create your design.

Contact us today to learn more about how we can help you achieve your goals, and our range of Automation solutions – including TwinCAT HMI services.

The post Beckhoff TwinCAT HMI – Tips and Tricks appeared first on DMC, Inc..

We will be using the information from TwinSAFE Tutorial 11: Safe Addressing for AMP and AMI, and TwinSAFE Tutorial 1: SafeMotion Wizard – Creating and configuring a Safe Motion project with SLS.

Load In IO

The drives and safety IO will need to have been scanned or added into your IO tree and  axes created in a MOTION project. After downloading the Drive Manager 2 (DM2) software from Beckhoff, a project can be added to the TwinCAT solution. See Beckhoff’s Quick commissioning guide | EN TE5950 TC3 Drive Manager 2 for more information on setting up DM2.

With the system still in config mode, a new DM2 project can be created by right-clicking on the solution and selecting ‘Add’. Then, in the project tree, you can select the new project, and it will search for drives. In the popup, you should see every drive currently connected to the PLC.

In this example, DM2 was able to automatically find all of these drives shown below. You can click “Check all” at the top for both options to enable automatic scanning of the motors and have ‘Scan motor in Pre-Op’ selection.

The other setting shown will be system specific, follow the specs for your motors. Any additional gear box ratio and settings for the motor should be applied.

Then, make sure you Activate Config to push configuration settings and scaling from the DM2 project to the motors.

Create and Expose PLC Variables

Create a PLC project if you haven’t already. Our safety program will require input from the PLC. In either a global variable list (GVL) or a program (PRG), make your four output address variables.

OUT_bSafetyResetSignal AT %Q*: BOOL;
OUT_bSafetyRun AT %Q*: BOOL;
OUT_bSafetyErrorAck AT %Q*: BOOL;
OUT_bSafetyDriveErrorAck AT %Q*: BOOL;

OUT_bSafetyResetSignal AT %Q*: BOOL;
OUT_bSafetyRun AT %Q*: BOOL;
OUT_bSafetyErrorAck AT %Q*: BOOL;
OUT_bSafetyDriveErrorAck AT %Q*: BOOL;

Build, so that the variables generate in the instance of the PLC project and can later be used for linking.

Every TwinSAFE program for an EL6910 or newer logics is required to have “RUN” and “ERRACK” signals linked to standard signals, which we are calling OUT_bSafetyRun and OUT_bSafetyErrorAck, as error acknowledgement is not automatic in TwinSAFE. Without these, the TwinSAFE Group our function blocks are in will not execute. Additionally, we have created a reset signal (OUT_bSafetyResetSignal) that we can use in the PLC to reset our function blocks when specific conditions are met. This could be from an external push button, an HMI screen, or some other code condition.

Lastly, specific to the fact that we are making a safety program for Beckhoff Motors with embedded safety cards, we have a separate error acknowledgment signal (OUT_bSafetyDriveErrorAck) for the drives. This is because many types of drives require explicit error acknowledgement, and it may be that this needs to be distinct from error acknowledgment of the entire TwinSAFE group. The operating manual for your specific drive’s safety card is the best reference.

Creating the Standard EL6910 Safety Project

Click the blue cog icon in the top left of the TwinCAT toolbar to swap the system back into config mode and select yes on the popup to activate free run. This will allow for proper scanning of terminals.

Now, a standard TwinSAFE project can be created by right clicking on the safety node and selecting ‘Add New Item’. In the window, select “TwinCAT Safety Project Preconfigured Inputs” to create a project with preconfigured inputs.

In the project’s Target System, select the terminal you will use as your safety controller. For this example, here is the relevant safety IO.

We have an EtherCAT coupler, a power supply terminal, a safety digital input/output card, a standard digital output card, a standard digital input card, a dedicated safety controller card, and a license key terminal followed by a bus end cap. For more information about each terminal, see Beckhoff’s EtherCAT terminals overview.

After selecting the Target system from the drop down, you need to ensure the Safe Address matches the hardware address for the terminal. This example uses an EL6910, so the hardware address was set via the dipswitch on the physical terminal and, when scanned in, we see it reads the number expected in the hardware address field.

NOTE: If you forgot to set the hardware address on any of your safety terminals (EK1914, EL2911, EL6910, or any ELx9xxx series terminals), please pause now and safely power down your system so that the physical terminals can be accessed. Read the operating manual for each terminal for information on how to set the hardware address. Remember, each address must be unique within the network and 0 is not a valid TwinSAFE address.

To make the Safe Address match the hardware address, select the green reload button next to the hardware address box to make sure the number in the field is correct, and then the green arrow button to push the number to the safe address field.

Additionally, for this project we are going to select the two checkmarks for Connection Inputs/Outputs for visible traceability. This allows for an exact interpretation of the links.

‘Save-All’ with CTRL+SHIFT+S or via the top menu bar before leaving this page.

Add Relevant Alias Devices

With our safety controller configured to hold a project, you can now import in your PLC variables, and any additional safety terminals. Importantly, you do not want to add any of the drives to this safety project. They will instead be added via the safe motion wizard later.

To do this, right-click on our newly created safety project’s Alias Devices folder. From here, you can click on New Item and make both of the additional digital Inputs. You should name both of them appropriately. Then, you can import any safety terminals you will use in the safety project from your IO.

As shown above, two of the inputs we need were created already by choosing to make a preconfigured safety project. Since we already created the PLC variables we need to link to, we can do that as well. For each alias device created, open its page and click the:

symbol to link each to its corresponding PLC variable.

Now, the blocks inside the standard safety project can be made.

Write the .SAL

First, you add a safeEStop and safeAnd block. This is for our single dual channel EStop. Then, create variables that match those below. It is important that this layout of this is not deviated from for reasons discussed below.

bPLCRestart and bPLCDriveErrorAck will be the two additional standard digital input variables we created. In order to have the drive error acknowledgment signal properly reset the entire safety system, it must be the first input on the safeAnd block as it is a standard input. Beckhoff has documentation on TwinSAFE Logic and Function Blocks if you want to learn more.

bChannelA and bChannelB represent both channels of the E-Stop, and will be physically wired through the EL2911. By clicking on the EStopIn1 port you can open the properties tab and change the channel interface from Single-Channel Both Activated to Two-Channel and set a discrepancy time.

For now, we will not do the Variable Mapping as there is more to add in. Save All and then Verify the project. Errors are expected and can be ignored for now.

Safe Addressing for AMP and AMI

Beckhoff AMP and AMI drives have internal TwinSAFE cards that like their physical terminal counterparts, also require unique safe addresses. These drives do not have physical hardware switches though and must be set a different way. AX8xxx drives do have physical hardware switches to set and this section can be skipped for such hardware.

With the system in config mode, and free run activated, navigate to the TwinSAFE toolbar. If you do not have this toolbar added, you can do so from right-clicking in the toolbar area and clicking to add TwinCAT Safety, or under View on the menu bar, View>Toolbars>TwinCAT Safety.

Click ‘Download Safe Address’. In the popup, select all the drives you need to set the safe address of.

Click ’Next‘. Now you need to assign  a unique safe address within the network for each drive. Remember, address 0 is not a valid TwinSAFE address. In this example, the Terminal number was arbitrarily decided to be made the drive’s address. When finished, click Next.

Input the default TwinSAFE username (Administrator) and password (TwinSAFE) to the window and select all the devices to download the safe addresses.

Read through and finish verifying you work, closing the window with the ‘Finish’ button when you are done.

Now, you need to power cycle your system (specifically, the drives) so that upon system startup, the drives will load the correct FSOE address.

To check and make sure the address was set, in the IO tree navigate to any drive and go to the CoE – Online tab. Click Update All to refresh the information there. Scroll down until you see Safe Address and expand it. By default, the FSOE address was 1, it should now be what you set it to.

In this picture, we can see the FSOE was set to 4

Create Safe Motion Wizard Safety Project

If you have not followed the above steps for Safe Addressing AND powered cycled your motors for AMP or AMI systems, do not continue.

Now that you have your standard safety project and safe addresses on your drives, you can run the Beckhoff TwinSAFE Motion Wizard. This requires >=v1.3.0 of the Safety Editor. Start the wizard from the drop-down option under TwinSAFE>Wizards>Start Safe Motion Wizard….

Then, in the popup that opens, select your drives under Target Type  if they do not automatically populate. Check all of the drives as the project targets.

Click ‘Next’. For the safety feedbacks, on the AMP8xxxx system there is only the default encoder option available for all drives, and only on channel A. Choose the option appropriate for your hardware.

An AX8xxx system might have options for channel A and B, as well as options on what encoder can be selected on each. If only using one channel on AX8xxxx systems, select No Safety Encoder for the unused channel.

Click ‘Next’. For selecting safety function(s), we only desire STO functionality and will therefore touch nothing. This is auto-selected for all of our drives.

Click ‘Next’. The project can be given a name on the configuration page. We will call it Safe Motion.

Click ‘Next’. On the assignment step, click on the “…” button to select the drives. This will create the FSOE connections in the standard safety project to allow communication between it and the safe motion project.

Click ‘Next’. For the Safe Address page, a few incorrect states can be noted. As the system should be connected, you should not see the red boxes. The wizard should automatically load in the correct TwinSAFE address from the drives.

If this is being performed offline, manually putting the FSOE addresses here would suffice.

Troubleshooting Note: If addresses show up as zero, and we have communication to the drive under the EtherCAT master (free run turned on), it is possible that the safe addresses were not set properly either via safe addressing download or dipswitch. Cancel the wizard and perform necessary checks, do not try and continue with an FSOE address of zero on any device.

The following is incorrect:

This is correct:

Click ‘Next’. Read and acknowledge the safety warning and exit the wizard by clicking the ‘Finish’ button.

There should be a popup that the safe motion wizard project was created successfully, and the master project was updated successfully.

Finishing the Standard EL6910 Safety Project

As promised, we now return to the standard safety project for variable mapping.

In the standard safety project we created before, you should now see new custom FSOE connections for each of the drives. This is why we did not manually add the drives to this project earlier.

Open up the .SAL and click on the bottom tab for Variable Mapping. The following picture shows all the mappings with explanations of each piece to follow.

The first two variables are the standard I/O variables from the PLC defined by the preconfigured project. They should already be mapped for you.

Next, the bPLCRestart signal to our safeEStop block is mapped to the corresponding alias device digital input created earlier. As previously mentioned, this allows for the PLC to issue a signal for restart of the safeEstop block and ensuing error acknowledgement, presumably after an EStop press.

bChannelA and bChannelB are the two inputs from our physical EStop, run through the EL2911 safety terminal and activate our safeEStop block.

The EStopOut signal from the safeEStop block is mapped to a multitude of devices. Notably, both  ChA STO and SS1 bits for each drive. You can hold down CTRL+Click to select a multitude of variables. In addition to the drives, another standard variable was created to see the EStop signal status in the PLC (not necessary for functionality), and the signal was mapped to the coupler (also not necessary). This was done for the ability to add other functionality desired later.

The safeAnd block then takes in the EStop signal, expected to be high, with drive error acknowledgment from the PLC. This lets the PLC acknowledge drive errors and if the EStop has been reset since it was last pressed, the bSafetyErrorAck then pushes the error acknowledgment to the drive. CTRL+Click to select all the error acks on each drive.

Save-All when done.

Finishing the Safe Motion Wizard Project

Looking at the newly created safe motion wizard project, there is nothing in the SALs we need to touch as the wizard handles it all. For this example, since we have multiple AMP8xxx series drives, we need to do multisettings. If you only had one drive, this part is not necessary, and you can skip to the last section.

Multi-Settings

In the safe motion wizard project, there is a last bit of configuration to be done before everything fits nicely together. If we open the Multi-settings.sms, we see all the drives we previously added. If we horizontally scroll to the right, we can see that Run and Err_Ack don’t have all the same links as the first motor.

You need to click the “…” on each and add the run and err ack links. Then it should look like this when it is finished.

Completing and Downloading

With the projects complete, you can now verify the main project and then perform a multi-download.

Now activate the configuration.

Using the login feature on the PLC, you can now toggle the ErrAck and Run signals. You will now be able to move the motors via the MOTION project, or Drive Manager 2.

Ready to take your Automation project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals. 

The post Getting Started with Beckhoff AMP8000 Series Motors in TwinSAFE appeared first on DMC, Inc..

This blog will continue to use the Beckhoff XTS_Base GitHub and the large XTS starter kit. 

Beckhoff XTS Series

• Part 1 – Downloads and Starter Project
• Part 2 – Setting Up a Physical XTS System
• Part 3 – Simulation and PLC Logic
• Part 4 – Movers
• Part 5 – Stations
• Part 6 – Position Triggers

Customizing the Logic

Let’s update this logic to customize our system a bit more. For my system, I’m going to have stations and position triggers at the following places:

Update the Station and Position Trigger Positions

Remove the existing station and position trigger definitions on lines 108-117 and replace it with the following:

// Initialize station positions
Station[0].Position := 5;
Station[1].Position := 3200;
Station[2].Position := 3300;
Station[3].Position := 3400;
Station[4].Position := 3500;

PositionTrigger[0].Position := 1500;
PositionTrigger[1].Position := 2000;

This will define the stations and position triggers as shown above.

Updating the Station and Position Trigger Logic

Next, we need to update the logic of these stations and position triggers to get them to behave as we want. For this application, let’s have the mover run at high velocity across the top rail, then go down to the low velocity around the bend. Once it clears the bend, it can go back up to the medium velocity until it reaches the next station. Once we have a mover in each of the four bottom left stations, send them all back to station 0. Replacing lines 210-265 with the following code will do that:

// Station 0 Logic
IF Station[0].MoverInPosition THEN
    StationTimer[0](IN := TRUE, PT := T#1000MS);
    IF StationTimer[0].Q THEN
        Station[0].CurrentMover.MoveVelocity(highVelocity);
    END_IF
ELSE
    StationTimer[0](IN := FALSE);
END_IF
    // Position Trigger 0 Logic
IF PositionTrigger[0].MoverPassedPosition THEN
    PositionTrigger[0].CurrentMover.SetVelocity(lowVelocity);
    PositionTrigger[0].MuteCurrent();
END_IF
    // Position Trigger 1 Logic
IF PositionTrigger[1].MoverPassedPosition THEN
    PositionTrigger[1].CurrentMover.SetVelocity(mediumVelocity);
    PositionTrigger[1].CurrentMover.MoveToStation(Station[nextStation]);
    nextStation := nextStation – 1;
    IF nextStation = 0 THEN
        nextStation := 4;
    END_IF
    PositionTrigger[1].MuteCurrent();
END_IF

// Group of Stations 1, 2, 3, and 4 Logic
IF Station[1].MoverInPosition AND Station[2].MoverInPosition AND Station[3].MoverInPosition AND Station[4].MoverInPosition THEN
    StationTimer[1](IN := TRUE, PT := T#750MS);
    IF StationTimer[1].Q THEN
        StationTimer[1](IN := FALSE);
        Station[1].CurrentMover.MoveToStation(Station[0]);
        Station[2].CurrentMover.MoveToStation(Station[0]);
        Station[3].CurrentMover.MoveToStation(Station[0]);
        Station[4].CurrentMover.MoveToStation(Station[0]);
    END_IF
END_IF

Execute the New Code

Save the new code and activate the configuration. After logging in, you should be able to open the Controls visualization, press the Enable button, and then the Start button to start seeing the movers follow the new logic.

This is just an example of the many customizations you can make to your XTS system. There’s even more functionality that comes with this starter project, though. In the next entry in this blog series, we will go over zones and add those to our custom logic.

If you’d like help with the next steps for your XTS system, DMC is proud to be a Beckhoff System Integrator and has worked on multiple XTS projects and applications. Learn more about our Beckhoff partnership and contact us for your next project.

Ready to take your Automation project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals.

The post Beckhoff XTS Part 7: Customizing Logic appeared first on DMC, Inc..

This blog will continue to use the Beckhoff XTS_Base GitHub and the large XTS starter kit. 

Beckhoff XTS Series

• Part 1 – Downloads and Starter Project
• Part 2 – Setting Up a Physical XTS System
• Part 3 – Simulation and PLC Logic
• Part 4 – Movers
• Part 5 – Stations
• Part 7 – Customizing Logic

Position Triggers

Position triggers are defined positions along the XTS track that know when movers pass by. This can allow for on-the-fly redirections or changes in velocity.

Declaring a Position Trigger

In MAIN, in the variable declaration we already have an array of position triggers defined with the line

PositionTrigger : ARRAY[0..2] OF PositionTrigger;

PositionTrigger : ARRAY[0..2] OF PositionTrigger;

This defines 3 position triggers to use. If you want to use more, you can increase the array bounds. It’s also likely worth using a global constant similar to how the stations are defined.

Configuring Position Triggers

The existing starter project already has 3 position triggers configured, shown below.

Similarly to the stations, the position definition for these position triggers is in the MS_INTIIALIZING_OBJECTIVES section of the MAIN state machine, which is at line 115.

PositionTrigger[0].Position := 1500;
PositionTrigger[1].Position := 2000;
PositionTrigger[2].Position := 3500; 

PositionTrigger[0].Position := 1500;
PositionTrigger[1].Position := 2000;
PositionTrigger[2].Position := 3500; 

We can see that the position triggers are given positions (in mm) around the track that line up with the picture above. Changing these positions will change where along the track the position triggers exist.

These position triggers also have CyclicLogic methods that must be called every scan and are already called for us at line 419.

PositionTrigger[0].Cyclic();
PositionTrigger[1].Cyclic();
PositionTrigger[2].Cyclic();

PositionTrigger[0].Cyclic();
PositionTrigger[1].Cyclic();
PositionTrigger[2].Cyclic();

If you add more position triggers, make sure to call their CyclicLogic methods as well.

The stations also make sure to unregister movers on stopping or disabling. This happens on lines 332 and 367 by calling the UnregisterAll method for each position trigger.

FOR i := 0 TO SIZEOF(PositionTrigger) / SIZEOF(PositionTrigger[0]) - 1 DO
  PositionTrigger[i].UnregisterAll();
END_FOR

FOR i := 0 TO SIZEOF(PositionTrigger) / SIZEOF(PositionTrigger[0]) - 1 DO
  PositionTrigger[i].UnregisterAll();
END_FOR

Position Trigger Logic

The existing starter project already has some position trigger logic. The logic for these position triggers is in the MS_RUN section of the MAIN state machine, which starts at line 250. There’s a few methods and properties about the position triggers that are useful to describe to interpret this code:

MoverPassedPosition

MoverPassedPosition is a property of the position trigger object. It goes TRUE when a mover passed the configured position trigger’s position. This will allow for logic based on the position trigger to affect the mover passing by.

MuteCurrent

MuteCurrent is a method of the position trigger object. It will set MoverPassedPosition to FALSE and clear out the mover being tracked by the position trigger. This can be used to indicate the position trigger logic is done and a new mover can be handled.

With these properties and methods, let’s see what the current position triggers are doing.

// Position Trigger 0 Logic
IF PositionTrigger[0].MoverPassedPosition THEN
  PositionTrigger[0].CurrentMover.SetVelocity(lowVelocity);
  PositionTrigger[0].MuteCurrent();
END_IF

// Position Trigger 1 Logic
IF PositionTrigger[1].MoverPassedPosition THEN
  PositionTrigger[1].CurrentMover.SetVelocity(highVelocity);
  PositionTrigger[1].MuteCurrent();
END_IF

// Position Trigger 2 Logic
IF PositionTrigger[2].MoverPassedPosition THEN
  PositionTrigger[2].CurrentMover.SetVelocity(lowVelocity);
  PositionTrigger[2].CurrentMover.MoveToStation(Station[0]);
  PositionTrigger[2].MuteCurrent();
END_IF

// Position Trigger 0 Logic
IF PositionTrigger[0].MoverPassedPosition THEN
  PositionTrigger[0].CurrentMover.SetVelocity(lowVelocity);
  PositionTrigger[0].MuteCurrent();
END_IF

// Position Trigger 1 Logic
IF PositionTrigger[1].MoverPassedPosition THEN
  PositionTrigger[1].CurrentMover.SetVelocity(highVelocity);
  PositionTrigger[1].MuteCurrent();
END_IF

// Position Trigger 2 Logic
IF PositionTrigger[2].MoverPassedPosition THEN
  PositionTrigger[2].CurrentMover.SetVelocity(lowVelocity);
  PositionTrigger[2].CurrentMover.MoveToStation(Station[0]);
  PositionTrigger[2].MuteCurrent();
END_IF

Position triggers 0 and 1 are doing similar things. They both wait for a mover to pass their position and then change the velocity of the mover. Position trigger 0 changes to low velocity and position trigger 1 changes to high velocity. They then both call the MuteCurrent methods to clear out the mover from the position trigger. Note that neither of these position triggers are sending a command to the mover, just changing its velocity. The mover is still obeying the MoveVelocity command from station 4.

Position trigger 2 waits for a mover to pass its position, sets the velocity low, and then commands the mover to move to station 0. This will override the move velocity command from station 4 and so the mover will next stop at station 0. The logic then calls MuteCurrent to signal the position trigger has processed the mover.

Now that we’ve reviewed movers, stations, and positions triggers we can not only understand the existing starter project logic but also write our own custom logic. In the next entry in this blog series, we will go over writing some custom logic for our XTS application.

If you’d like help with the next steps for your XTS system, DMC is proud to be a Beckhoff System Integrator and has worked on multiple XTS projects and applications. Learn more about our Beckhoff partnership and contact us for your next project.

Ready to take your Automation project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals.

The post Beckhoff XTS Part 6: Position Triggers appeared first on DMC, Inc..

This blog will go over the Beckhoff XTS Station block that comes with the base starter project. We will see how to configure the stations properly and what methods we have at our disposal to use with our system. This blog will continue to use the Beckhoff XTS_Base GitHub and the large XTS starter kit.

Beckhoff XTS Series

• Part 1 – Downloads and Starter Project
• Part 2 – Setting Up a Physical XTS System
• Part 3 – Simulation and PLC Logic
• Part 4 – Movers
• Part 6 – Position Triggers
• Part 7 – Customizing Logic

Stations

Stations are defined positions along the XTS track where movers will stop until commanded to do something else. This allows for a mover to reach the station, have some actions performed on it while stationary, then to be sent elsewhere on the track.

Declaring Stations

In MAIN, in the variable declaration we already have an array of stations declared with the line

Station : ARRAY[0..GVL.NUM_STATIONS - 1] OF Station;

Station : ARRAY[0..GVL.NUM_STATIONS - 1] OF Station;

If you want to add more stations, you can change the value of NUM_STATIONS in the GVL file. There’s advantages and disadvantages to having your stations in an array. The advantages are that they’re all stored in one place, the name is consistent across various stations, and it’s easy to iterate through all the stations if needed. Additionally, adding stations between two existing stations is as easy as shifting the other stations in the array up an index. The disadvantage is that the station names are not going to be as descriptive as they could be if they were individually named. For this blog, we’re going to continue using the array of stations.

Configuring Stations

The existing starter project already has 5 stations configured, shown below:

The position definition for these stations is in the MS_INTIIALIZING_OBJECTIVES section of the MAIN state machine, which is at line 109.

Station[0].Position := 5;
Station[1].Position := 750;
Station[2].Position := 1200;
Station[3].Position := 1300;
Station[4].Position := 1400;

Station[0].Position := 5;
Station[1].Position := 750;
Station[2].Position := 1200;
Station[3].Position := 1300;
Station[4].Position := 1400;

We can see that the stations are given positions (in mm) around the track that line up with the picture above. Changing these positions will change where along the track the stations exist.

We also need to make sure to call the CyclicLogic method of the station object. This is already done for us in line 414.

FOR i := 0 TO GVL.NUM_STATIONS - 1 DO
  Station[i].Cyclic();
END_FOR

FOR i := 0 TO GVL.NUM_STATIONS - 1 DO
  Station[i].Cyclic();
END_FOR

One other thing these stations are already configured to do is to unregister movers on stopping or disabling. This will make sure that no movers are “trapped” at stations when the system starts back up. This is done in lines 327 and 362 by calling the UnregisterAll method for each station.

FOR i := 0 TO GVL.NUM_STATIONS - 1 DO
  Station[i].UnregisterAll();
END_FOR

FOR i := 0 TO GVL.NUM_STATIONS - 1 DO
  Station[i].UnregisterAll();
END_FOR

Station Logic

The existing starter project already has some stations logic. The logic for these stations is in the MS_RUN section of the MAIN state machine, which starts at line 212. There’s a couple methods and properties about the station objects that are useful to describe to interpret this code.

MoverInPosition

MoverInPosition is a property of the station object. This property is true if a mover has arrived at the station. This is important to check before trying to do anything with a station’s mover because if there is no mover in the station, the code will try to command an invalid mover reference.

CurrentMover

CurrentMover is a property of the station object. This property is a reference to the mover that is currently at the station. This allows commands to the movers to go through the stations so logic can be configured on a station level rather than on a mover level.

With these methods and properties, we can better understand what the existing stations are doing.

// Station 0 Logic
IF Station[0].MoverInPosition THEN
  StationTimer[0](IN := TRUE, PT := T#1000MS);
  IF StationTimer[0].Q THEN
    Station[0].CurrentMover.SetVelocity(mediumVelocity);
    Station[0].CurrentMover.MoveToStation(Station[1]);
  END_IF
ELSE
  StationTimer[0](IN := FALSE);
END_IF

// Station 0 Logic
IF Station[0].MoverInPosition THEN
  StationTimer[0](IN := TRUE, PT := T#1000MS);
  IF StationTimer[0].Q THEN
    Station[0].CurrentMover.SetVelocity(mediumVelocity);
    Station[0].CurrentMover.MoveToStation(Station[1]);
  END_IF
ELSE
  StationTimer[0](IN := FALSE);
END_IF

Station 0 is straightforward. Once a mover arrives, the logic waits for 1 second before setting the velocity to medium velocity and sending the mover to station 1.

// Station 1 Logic
IF Station[1].MoverInPosition THEN
  StationTimer[1](IN := TRUE, PT := T#250MS);
  IF StationTimer[1].Q THEN
    Station[1].CurrentMover.SetVelocity(mediumVelocity);
    Station[1].CurrentMover.MoveToStation(Station[nextStation]);
    nextStation := nextStation - 1;
    IF nextStation = 1 THEN
      nextStation := 4;
    END_IF
  END_IF
ELSE
  StationTimer[1](IN := FALSE);
END_IF

// Station 1 Logic
IF Station[1].MoverInPosition THEN
  StationTimer[1](IN := TRUE, PT := T#250MS);
  IF StationTimer[1].Q THEN
    Station[1].CurrentMover.SetVelocity(mediumVelocity);
    Station[1].CurrentMover.MoveToStation(Station[nextStation]);
    nextStation := nextStation - 1;
    IF nextStation = 1 THEN
      nextStation := 4;
    END_IF
  END_IF
ELSE
  StationTimer[1](IN := FALSE);
END_IF

Station 1 has some similar logic. It only waits for 250 milliseconds and then rotates through sending to station 4, then station 3, then station 2, then back to station 4. This is a great example of how you can use the XTS system to multi-task with processes that have higher cycle times.

// Group of Stations 2, 3, and 4 Logic
IF Station[2].MoverInPosition AND Station[3].MoverInPosition AND Station[4].MoverInPosition THEN
  StationTimer[2](IN := TRUE, PT := T#750MS);
  IF StationTimer[2].Q THEN
    StationTimer[2](IN := FALSE);

    Station[2].CurrentMover.MoveVelocity(500);
    Station[3].CurrentMover.MoveVelocity(500);
    Station[4].CurrentMover.MoveVelocity(500);
  END_IF
END_IF

// Group of Stations 2, 3, and 4 Logic
IF Station[2].MoverInPosition AND Station[3].MoverInPosition AND Station[4].MoverInPosition THEN
  StationTimer[2](IN := TRUE, PT := T#750MS);
  IF StationTimer[2].Q THEN
    StationTimer[2](IN := FALSE);

    Station[2].CurrentMover.MoveVelocity(500);
    Station[3].CurrentMover.MoveVelocity(500);
    Station[4].CurrentMover.MoveVelocity(500);
  END_IF
END_IF

Stations 2 through 4 have their logic combined since they’re intended to be parallel processes. Once a mover has arrived in each of the three stations, the logic waits for 750 milliseconds before commanding all three movers to move at 500mm/s.

If we’re commanding these movers to move at 500mm/s until they receive another command, how will they ever stop? The first answer is that they have collision avoidance, so the movers will stop if they would run into a mover ahead of them. The second answer is that we have position triggers further along the track to give them new commands. In the next blog in this series, we will go over position triggers.

If you’d like help with the next steps for your XTS system, DMC is proud to be a Beckhoff System Integrator and has worked on multiple XTS projects and applications. Learn more about our Beckhoff partnership and contact us for your next project.

Ready to take your Automation project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals.

The post Beckhoff XTS Part 5: Stations appeared first on DMC, Inc..

This blog will go over the Beckhoff XTS mover blocks that comes with the base starter project. We will see how to configure the movers properly and what methods we have at our disposal to use with our system. This blog will continue to use the Beckhoff XTS_Base GitHub and the large XTS starter kit. 

Beckhoff XTS Series

• Part 1 – Downloads and Starter Project
• Part 2 – Setting Up a Physical XTS System
• Part 3 – Simulation and PLC Logic
• Part 5 – Stations
• Part 6 – Position Triggers
• Part 7 – Customizing Logic

Movers

Movers are the software representation of the physical XTS movers. The mover object built into the base project is a great starting point since it comes with a lot of useful methods for controlling the mover behavior. 

Declaring Movers

In the previous entry in this blog series, we made sure to update the number of movers to match the physical movers in our system. In the MAIN program, we can see that the movers are declared with the line.

Mover : ARRAY[0..GVL.NUM_MOVERS - 1] OF Mover;

Mover : ARRAY[0..GVL.NUM_MOVERS - 1] OF Mover;

As mentioned in the previous section, this NUM_MOVERS should be exactly equal to the number of physical movers in the XTS system. Additionally, the axis references of these mover objects should be linked to the motion axes. If you haven’t already done that see this section. 

Configuring Movers

Like most drives, the movers need to have a set of parameters and to go through an enable process before they can run. The base project already does both things for us. In the MAIN program the code starting at line 52 is where the parameter set is applied to all of the movers configured in our system. 

FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  Mover[i].MotionParameters := ParameterSet;
END_FOR

FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  Mover[i].MotionParameters := ParameterSet;
END_FOR

The lines starting at line 46 define the parameter set, which includes acceleration, deceleration, jerk, velocity, and direction. 

ParameterSet.Jerk     := 1E5; // mm/s3
ParameterSet.Acceleration := 1E4; // mm/s2
ParameterSet.Deceleration := 1E4; // mm/s2
ParameterSet.Velocity   := 1E3; // mm/s
ParameterSet.Direction   := mcDirectionPositive;

ParameterSet.Jerk     := 1E5; // mm/s3
ParameterSet.Acceleration := 1E4; // mm/s2
ParameterSet.Deceleration := 1E4; // mm/s2
ParameterSet.Velocity   := 1E3; // mm/s
ParameterSet.Direction   := mcDirectionPositive;

Line 72 is where the movers are enabled 

FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  Mover[i].Enable();
END_FOR

FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  Mover[i].Enable();
END_FOR

and a few lines down in line 87 is where their Ready property is checked to see if they got enabled properly. 

FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  IF Mover[i].Ready = FALSE THEN
    allMoversEnabled := FALSE;
  END_IF
END_FOR

FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  IF Mover[i].Ready = FALSE THEN
    allMoversEnabled := FALSE;
  END_IF
END_FOR

Additionally, the movers must be assigned to a track. This happens starting at line 144 by calling ActivateTrack and passing in the track the mover is to be assigned to. 

FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  Mover[i].ActivateTrack(Track[1]);
END_FOR

FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  Mover[i].ActivateTrack(Track[1]);
END_FOR

For the basic starter project, all movers are assigned to track 1. If your application has multiple tracks, this is where you can specify which movers belong to which track. A few lines down at line 153 is where the logic checks the mover’s IsTrackReady property to make sure they’re properly assigned to their track. 

allMoverTracksEnabled := TRUE;
FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  IF (NOT Mover[i].IsTrackReady) THEN
    allMoverTracksEnabled := FALSE;
  END_IF;
END_FOR

allMoverTracksEnabled := TRUE;
FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  IF (NOT Mover[i].IsTrackReady) THEN
    allMoverTracksEnabled := FALSE;
  END_IF;
END_FOR

To stop the movers, the logic will need to call the Halt method. This is already implemented in line 286 of the base starter project. 

FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  Mover[i].Halt();
END_FOR

FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  Mover[i].Halt();
END_FOR

Once the movers are stopped, they can be disabled using the Disable method. Again, this is already implemented in line 348. 

FOR i := 0 TO GVL.NUM_MOVERS DO
  Mover[i].Disable();
END_FOR

FOR i := 0 TO GVL.NUM_MOVERS DO
  Mover[i].Disable();
END_FOR

It’s worth noting that if you have a vertically mounted track, disabling the movers will often let them succumb to gravity. It could be worth implementing something that gets the movers off the curved sections before disabling them. 

Many of these XTS library objects have methods named Cyclic or CyclicLogic that need to be called every scan in order to function properly, so check those are getting called correctly if any issues come up. For our movers, this happens at line 408. 

FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  Mover[i].Cyclic(GroupRef);
  Mover[i].AxisReference.ReadStatus();
END_FOR;

FOR i := 0 TO GVL.NUM_MOVERS - 1 DO
  Mover[i].Cyclic(GroupRef);
  Mover[i].AxisReference.ReadStatus();
END_FOR;

The logic also calls the ReadStatus method of the mover’s internal axis reference to ensure the status values are up to date. 

Now we’ve gone over a lot of the configuration that these movers need. We can enable them, assign a parameter set to them, assign them to tracks, stop them and disable them. We’re also calling the Cyclic method that ensures our commands get processed properly. Now it’s time for the fun part, getting the movers to move around the track. 

Mover Logic

The mover objects come with four main methods that will help control their movement throughout the track. Here’s a quick description of each of the methods. 

SetVelocity

SetVelocity is a method of the mover object. It will immediately change the velocity of the mover to the commanded velocity (in mm/s).

MoveVelocity

MoveVelocity is a method of the mover object. It will command a mover to run at the commanded velocity (in mm/s) until it receives another command.

MoveToStation

MoveToStation is a method of the mover object. It will command a mover to go to the commanded station. Note that there’s no velocity input for this method, so the mover will go at its existing velocity, which was likely last given by SetVelocity or MoveVelocity. The mover will stop once it reaches the commanded station.

MoveToPosition

MoveToPosition is a method of the mover object. It will command a mover to go to the inputted position (in mm). Similar to MoveToStation, there is no velocity input so this will use the mover’s existing velocity.

The MoveToStation function is particularly useful, but first we have to understand what a station is. We will go over stations in the next entry in this blog series.

If you’d like help with the next steps for your XTS system, DMC is proud to be a Beckhoff System Integrator and has worked on multiple XTS projects and applications. Learn more about our Beckhoff partnership and contact us for your next project.

Ready to take your Automation project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals.

The post Beckhoff XTS Part 4: Movers appeared first on DMC, Inc..

Beckhoff XTS Series

• Part 1 – Downloads and Starter Project
• Part 2 – Setting Up a Physical XTS System
• Part 4 – Movers
• Part 5 – Stations
• Part 6 – Position Triggers
• Part 7 – Customizing Logic

Setting Up an XTS Simulation 

Start the XTS Simulator 

XTS has a built-in simulator that you can start through the XTS simulation builder. This is the gear icon with a blue arrow. 

Start the XTS Simulation Builder

This starts the XTS simulation builder. You can select from a few template projects, but modifying the base project will give you the most control over the XTS system being set up. To do this, click the pencil next to modify base project. 

Configure XTS Modules

The first tab of the simulation builder is to configure the modules. Here you can add XTS track modules to build your track. In the top bar, you can select from the catalog of XTS modules and hovering over each module will give you the part number. To add a module, either select the module and click the add module plus button or double click on the module. 

The last four digits of each module’s part number represent its length in millimeters. There are some modules that look the same but have different lengths, so be sure to select the correct length of each part for your application. Below is a simulation track for the XTS larger starter kit. It uses two AT2002-0250, 2 AT2050-0250, and 10 AT2000-0250 modules to form a 4m loop. 

Configure XTS Movers 

Next, navigate to the Movers tab. 

Here you can add movers to the XTS track. Similar to the modules, at the top you can select which mover from the Beckhoff XTS catalog you’d like to add to the track. To add a mover, select the type and then click the add mover plus button. Below are the simulation movers for the XTS large starter kit. It uses 10 AT9014-0070 movers. 

Configure Parts, Tracks, and Stations 

For this example, we’re not going to be using any parts, tracks, or stations. Here’s a quick rundown of what each of them are with links to the Beckhoff documentation for more detail. 

• Parts – Groupings of modules. Since our large starter kit is a loop, we only have the one part which was added by default. 
• Tracks – A route that can be used by movers that is made up of one or multiple parts. Since our large starter kit is a loop with only one part, we also only use the single default track. 
• Stations – A station in this configurator is still in the beta phase and is currently purely cosmetic. Stations will display in the XTS tool window, but the movers cannot use these stations in their logic. We will set up stations in the PLC logic later, so we don’t have to set any up here. 

Configure XTS Real-Time Settings 

Lastly, we need to set the real-time settings for the XTS system. This is functionally the same as going to SYSTEM > Real-Time, but it’s conveniently here in the configurator as well. First, navigate to the System tab and click the download button to sync the number of cores on your target to the configurator. 

Say “yes” to the popup that asks if you want to overwrite the current CPU config. 

The XTS Task 1 has to be configured onto an isolated CPU by itself with a 250μs base time and 1 cycle tick. Isolated cores are represented by an orange rectangle on the right side of the core. You can select which cores are being used with the checkbox on the left side and move tasks around using the up and down arrows on each task. The remaining tasks on the system can be set up to fit your system’s needs, but the XTS Task 1 should be configured like the image below. 

If you’re simulating on your engineering computer, keep in mind that all tasks must be on isolated cores, not just the XTS Task 1. The image above has all tasks on isolated cores for this reason. 

Finish the XTS Simulation Builder 

Click the next button a couple times and the XTS simulation builder should process the information to add the XTS system to your solution. This may take a few minutes, but afterwards the simulation builder should close. To start sending movers around the track, go to step 5. 

Adding Logic to the XTS System 

This section assumes that you’re using the XTS_Base code provided on Beckhoff’s GitHub. It’s highly recommended to use this since it provides well-tested code for commonly used XTS tools like movers, stations, zones, position triggers, etc. 

Check IdDetectionMode 

Under SYSTEM > TcCOM Object > XTS ProcessingUnit 1, go to the Parameter (Init) tab. Under the section for Mover ID Detection, we will want to set IdDetectionMode to the correct detection mode for our system. 

If you’re simulating an XTS system, the IdDetectionMode should be set to Standard. If you’re working with a physical XTS system, then it depends on your movers. Some movers are identified with mover 1 magnet plates. If you have no mover 1 magnet plates, set IdDetectionMode to Standard. With one mover 1 magnet plate, set the IdDetectionMode to Mover1. With multiple mover 1 magnet plates, set the IdDetectionMode to MultipleMover1. 

Setting the GVL Parameters

Under the Main Project, open GVLs > GVL. In this global variable list, you’ll need to set the following variables 

• NUM_MOVERS – This should be the number of movers in your XTS system. In our case, 10. 
• NUM_STATIONS – This should be set to a number greater than or equal to the number of stations you’ll add to your system. In our case, we will keep it at 10. 
• TRACK_LENGTH – This should be the length of the track in your XTS system in millimeters. In our case, 4000mm. If you don’t know the track length, you can find it under SYSTEM > TcCOM Object > XTS ProcessingUnit 1 > Track 1 in the Parameter (Online) tab. The Length parameter should show an online value which should be entered for TRACK_LENGTH. 
• NUM_TRACKS – This should be set to the number of tracks in your system. In our case, 1. 

Update the Track OTCID in MAIN 

In the MAIN program inside the POUs folder, on line 138 there is an assignment to Track[1].OTCID. This will likely need to be changed. 

You can find your track’s OTCID under SYSTEM > TcCOM Objects > XTS ProcessingUnit 1 > Track 1 in the Object tab. 

You can then copy this value and assign it to Track[1].OTCID in MAIN. Make sure to change the “0x” prefix to a “16#” to match structured text formatting for hexadecimal numbers. 

Link the Mover Axes 

Rebuild the solution first by going to the top toolbar and selecting Build > Rebuild Solution. This makes sure that our change to NUM_MOVERS regenerated the correct number of AXIS_REFs to link to. After rebuilding, go to MOTION > NC SAF > Axes and you’ll see a list of axes that are in our solution. They should already be linked to their I/O components, which should be Mover Controllers. The next step is to link them to their PLC AXIS_REFs. Select all the axes using Shift + Click, then right click to select Change Axis PLC Links. 

You should see the mover axis references show up. Click each reference to link all the movers to their NC axes. The linking should look like the image below afterwards. 

Run the Program 

We can now activate our configuration. Do this by clicking the icon shown below. 

Click OK in the next popup. 

If you haven’t already purchased licenses from Beckhoff, you’ll likely get a popup asking if you want to activate trial licenses. Click yes and follow the steps to get a free 7-day trial license. Once you deploy the code onto a production machine, make sure to get a license from your local Beckhoff sales representative. 

After activating configuration, the target device should switch into run mode, which is indicated by the green gear icon next to the activate configuration button being highlighted instead of the blue one. Once in run mode, we can enable and start the movers. 

Start the Movers 

The solution we pulled from the Beckhoff GitHub already has a simple HMI to get the movers started. Let’s log in by clicking the green door with the arrow pointing towards it. 

After logging in, open the visualization under Main Project > VISUs > Controls.

This provides four buttons for interacting with the XTS system. 

• Enable – Will run the enable sequence for the movers, which initializes their order and assigns movers to tracks. 
• Start – Once the movers are enabled, this will start running the station logic for the movers, 
• Stop – This will stop the movers but will keep them enabled. 
• Disable – This will remove the movers from their tracks, which allows for errors to be reset. If your track is mounted vertically, it’s worth noting that this will depower the movers and they will succumb to gravity. 

Click the enable button. Then click the start button. If you have a physical XTS system, you should see the movers start to move. Both physical and simulation systems can take advantage of the XTS tool window to see a live view of the track. 

Live Monitor the XTS Track 

Go back to the XTS tool window. You should be able to click the live view button to see the current state of the movers on the XTS track. 

At this point, you should see the movers going around the track according to the station logic that was already in the code we downloaded from Beckhoff’s GitHub. 

This should help get your physical or simulated XTS system moving. However, all XTS systems are different and this default station logic likely isn’t going to work for your application. Next time, we will explore how to set up stations, position triggers, zones, and other things that can help customize the XTS system further. 

If you’d like help with the next steps for your XTS system, DMC is proud to be a Beckhoff System Integrator and has worked on multiple XTS projects and applications. Learn more about our Beckhoff partnership and contact us for your next project. 

The post Beckhoff XTS Part 3 – Simulation and PLC Logic appeared first on DMC, Inc..

Note: This blog and all its images are from TwinCAT XAE build 3.1.4024.62. Since XTS is one of Beckhoff’s newer offerings, they are consistently providing more features so some aspects may look different in newer versions, especially in builds 3.1.4026.XX and beyond. As a reminder, this blog series is utilizing the XTS_Base code provided on Beckhoff’s GitHub. 

Beckhoff XTS Series

• Part 1 – Downloads and Starter Project
• Part 3 – Simulation and PLC Logic
• Part 4 – Movers
• Part 5 – Stations
• Part 6 – Position Triggers
• Part 7 – Customizing Logic

Setting Up a Physical XTS System 

This blog will be using the large XTS starter kit, though the steps should be similar for any XTS track and mover configuration. 

Scan in IO 

Before we can set up the XTS system, we have to bring the XTS hardware into the TwinCAT solution. To do this, go down to I/O, right click on Devices, and select Scan. If you’re not able to scan, it’s likely your target is in run mode. You’ll have to switch it into config mode by clicking the blue icon with the gear in it before scanning devices in. 

If you get a popup saying that not all types of devices can be found automatically, click OK. The XTS tracks and movers should be found automatically. Select Yes for both the scan for boxes and the activate free run popups.

If the hardware is connected to the PLC correctly and powered on, you will see a popup similar to the one below. Make sure to select the RT-Ethernet Adapter and the EtherCAT devices. In the image below its devices 4, 9, 10, and 11.

After clicking OK, the software will take some time to scan in the hardware. After it scans, you should see all the devices you have connected to the PLC appear in the IO tree. For example, the large XTS starter kit IO looks like the image below.

Note: the movers are not included in the IO tree. That will come later.

Start the XTS Configurator

Go back to the XTS tool window and start the XTS configurator. This is the gear icon with a green arrow.

Configure XTS Parts

You’ll be presented with a popup for the XTS configurator. Click past the first screen to get to the screen for configuring parts. You’ll see a warning towards the bottom that says no modules have been added yet. Right above that, click the plus button to add some modules.

After clicking the plus button, you should see the devices with XTS parts available for selection. The image below is what the large XTS starter kit scans in as. Select all the devices by using Shift+Click and click OK. 

After clicking OK, the modules should be displayed in the bottom left where the “no modules” warning used to be. These can be adjusted relative to each other by selecting a module and using the up/down arrows to adjust its relative location. Note that the track shape is displayed in the main window to help orient the track to its physical setup. Once you’re done adding parts, select the right arrow in the bottom right corner.

Configure XTS Tracks

See Beckhoff’s information page on XTS tracks for a complete definition. Generally, tracks are groupings of XTS parts that have minimal or no overlap in movers and/or parts. The large XTS starter kit has only one track and it is a loop, so we will check the box for is closed. 

If your system has multiple tracks, you can add them through the plus button in the top bar and configure each individually by selecting each track under the XTS ProcessingUnit and adding the parts that are associated with that track. Click to the next section of the configurator once you’re done configuring tracks.

Configure XTS Stations

XTS stations in this configurator are still in the beta phase and are currently purely cosmetic. They will display in the XTS tool window, but the movers cannot use these stations in their logic. If you want to set up cosmetic stations, you can add them with the plus button in the top bar. These can be useful for visualizing your XTS stations but can often be misleading since they’re not directly tied to mover logic. In this example, we won’t use these cosmetic stations, but feel free to add them if it’s useful in your application.

Click to the next section of the configurator once you’re done configuring stations.

Configuring XTS Movers

Before adding any movers, make sure to select the mover type and magnet plate type that you’re using in your application. If needed, you can reference the Beckhoff XTS catalog to verify which mover type you have.

Once the mover type and magnet plate type are selected, click the plus button until you have added the same number of movers as the physical system. In the large XTS starter kit, we have 10 AT9011_0070 movers with magnet plates AT9001_0550, so that’s what the image below shows.

Click to the next section of the configurator once you’re done configuring movers.

Configuring Control Areas

Control areas can be defined to allow different parameter sets to be used for different track segments. For example, if our XTS starter kit was mounted vertically, we might want different PID control for the movers while they’re sliding with/against gravity. For this example, we will not set up any control areas. Click to the next section of the configurator once you’re done configuring control areas.

Configuring XTS Real-Time Settings

Lastly, we need to set the real-time settings for the XTS system. This is functionally the same as going to SYSTEM > Real-Time, but it’s conveniently here in the configurator as well. First, navigate to the System tab and click the download button to sync the number of cores on your target to the configurator.

Say yes to the popup that asks if you want to overwrite the current CPU config.

The XTS Task 1 has to be configured onto an isolated CPU by itself with a 250μs base time and 1 cycle tick. Isolated cores are represented by an orange rectangle on the right side of the core. You can select which cores are being used with the checkbox on the left side and move tasks around using the up and down arrows on each task. The remaining tasks on the system can be set up to fit your system’s needs, but the XTS Task 1 should be configured like the image below.

Finish the XTS Configurator

Click the next button a couple times and the XTS configurator should process the information to add the XTS system to your solution. This may take a few minutes, but afterwards the configurator should close.

Our physical XTS system has now been set up. The next blog in this series will go over how to set up a simulated version of your XTS system and how to update the PLC logic to start sending movers around the track.

Beckhoff XTS Series

Part 1 – Downloads and Starter Project
Part 3 – Simulation and PLC Logic

If you’d like help with the next steps for your XTS system, DMC is proud to be a Beckhoff System Integrator and has worked on multiple XTS projects and applications. Learn more about our Beckhoff partnership and contact us for your next project.

The post Beckhoff XTS Part 2 – Setting Up a Physical XTS System appeared first on DMC, Inc..

Beckhoff XTS Series

• Part 2 – Setting Up a Physical XTS System
• Part 3 – Simulation and PLC Logic
• Part 4 – Movers
• Part 5 – Stations
• Part 6 – Position Triggers
• Part 7 – Customizing Logic

Table of Contents

Why Beckhoff XTS?
Download and Installation
  Download
  Installation
Setting Up Base Project
  Open the XTS Tool Window
  Clear Out the Existing XTS System

Why Beckhoff XTS?

The eXtended Transport System (XTS) is Beckhoff’s linear product transport solution. Linear transport systems allow for smart product transportation. Since products are on individual movers, it allows for easy diverting of rejected products or parallelization of duplicated stations to reduce cycle time. Since the movers can be programmed to stop at stations, this allows for parts to be manipulated directly on the movers, which can greatly reduce the amount of time it takes to move products from station to station. Additionally, a linear transport system often reduces the footprint on the factory floor as compared to traditional conveyor belt solutions. 

XTS is unique from other linear transport systems because it utilizes the EtherCAT framework and TwinCAT Motion libraries to produce a plug-and-play solution for many applications. There’s also a wide variety of options to customize your XTS system from no-cable technology (NCT) allowing you to power electronics on each individual mover to hygienic solutions that are IP69K rated.  

Beckhoff XTS can be the right solution for a wide variety of applications, and this blog series on getting started with XTS is going to help give you the tools to effectively utilize this innovative technology. We’ll start with installing the right packages and setting up a base project today. 

Download and Installation

Download

First, download TF5850 and TF5410 from the Beckhoff website. The installers are located in Documentation and Downloads > Software and Tools. 

Installation

Once downloaded, you will need to run the two .EXE files on both the engineering computer and on the PLC. To download onto the PLC, the simplest way is to move the .EXE files onto a USB and plug this into the PLC. Once the USB is plugged in, you can either remote into the PLC (Remote Desktop Connection) or connect a monitor and mouse using any of the outputs on the PLC. Once connected, run the .EXE files on the PLC and install the software.

Note: You will have to restart the engineering computer and PLC after running the installers, so make sure the PLC’s system is in a state to do so.

Open TwinCAT XAE

Once installation is complete, open TwinCAT XAE. This blog will use the XTS_Base code provided on Beckhoff’s GitHub since it provides a lot of reusable code to interact with movers and set up stations. Downloading this project will give a great starting point for the rest of this blog series, but you should be able to follow along in your own TwinCAT solution if desired. If you haven’t already installed TwinCAT XAE or configured your Beckhoff IPC yet, check out our setup blog on how to get started and then come back to step 3.

Setting Up Base Project

Open the XTS Tool Window

In the top bar of the XAE solution, go to TwinCAT > XTS > XTS Tool Window to open the XTS tool window.

This is where we can configure our XTS track, movers, and ultimately go online to monitor the XTS system. The XTS_Base project this blog starts with already has an XTS track configured. Let’s clear out that track so we can set it up ourselves. 

Clear Out the Existing XTS System

There are three main places where XTS components are stored. They are SYSTEM > TcCOM Objects, MOTION > NC SAF > Axes, and I/O > Devices. This blog series will go into more detail about each of these sections later on, but for now we will want to clear out everything under these sections to remove the existing XTS system. Namely, remove XtsProcessingUnit 1, Mover Axis 1-6, and Device 1 and Device 3. We also need to remove SYSTEM > Tasks > XTS Task 1.

Once all those objects have been removed, go back to the XTS tool window and click the refresh button. The XTS track and movers should disappear.

With that, the downloads and starter project are set up for our XTS project. We are now ready to set up our own XTS system. The next blog in this series will go over how to set up a physical XTS system.

Beckhoff XTS Series

Part 2 – Setting Up a Physical XTS System
Part 3 – Simulation and PLC Logic

If you’d like help with the next steps for your XTS system, DMC is proud to be a Beckhoff System Integrator and has worked on multiple XTS projects and applications. Learn more about our Beckhoff partnership and contact us for your next project.

The post Beckhoff XTS Part 1 – Downloads and Starter Project appeared first on DMC, Inc..

Software Requirements 

This example will utilize TwinCAT 3 XaeShell and the TF6281 software license for Ethernet I/P Scanner communication. 

Task 1: Add Ethernet I/P Device in Project 

Use the dropdown ‘IO → Devices → Add new item’ and select the Ethernet/IP Scanner option. 

Next, we need to import a new EDS file for our Ethernet I/P field device. Right-click on the newly added EIP Scanner and select the ‘Import EDS File’ option. 

Navigate to the location of the EDS file for your device, then click ‘Open’. This will allow you to select the proper file for your device. 

Next, Right-click on the EIP Scanner again and select ‘Add New Item…’. Then select your newly added device from the EDS import. In this example I have added 2 different Cognex Camera models. 

Now, we need to open the added device properties and set the IP address of the device. 

The next step is to append the IO connection. Selecting yes to the popup option below will allow the connection to pull all the pre-configured tags in the EDS file, so that we do not have to individually bit and byte map all the data in the Ethernet I/P communication to the camera. 

The final step is to link the IO tags to the variable within the PLC program. Using the ‘Change Link’ option will allow you to search through the configured program variables and assign them to the appropriate IO tag.   

Task 2: Configure LAN Port for Ethernet/IP  

The first step is to install TwinCAT XaeShell on the IPC. With this installation comes the ability to install the Realtime Ethernet Driver to the LAN ports on the IPC. Using the install file from your TwinCAT install at the file path: (C:\TwinCAT\3.1\System\TcRteInstall.exe) you can run this simple application to install the runtime driver. For more information on the runtime driver see this link.  

The other option is to Open TwinCAT XaeShell on the IPC. Navigate to the dropdown menu ‘TwinCAT → Show Realtime Ethernet Compatible Devices…’ 

Next, you want to select the proper ethernet port on your IPC under ‘Compatible devices’. Clicking ‘Install’ will allow that port to now be used for Ethernet I/P Communication for the PLC program. After the installation, you will notice the ethernet port now shows up as ‘Ethernet – TwinCAT-Intel PCI (Ethernet Adapter)’ under ‘Installed and ready to use devices (realtime capable).’ 

Next, we want to make sure to configure the ethernet port for the correct address and subnet to communicate with the Ethernet I/P device. Notice the network adapter now has the ‘TwinCAT-Intel PCI Ethernet Adapter’ description in the Network Connections menu. 

Now, back in the PLC Project, we need to setup the properties of the Ethernet I/P Scanner. In TwinCAT on your computer, setup the route target system as the address of the IPC. Double click on the device, ‘TC3 EIP Scanner’, to open its properties. On the adapter tab we can search for the network adapter that we just installed the runtime driver on. Select that adapter, and the MAC and IP Address you configured in the IPC should automatically populate in the fields on that tab. 

Then, click over to the Settings tab and input an IP address and Network Mask. The IP address of the Master must be different than the static IP address on the IPC network adapter! 

Now, you should be able to build the solution and start the PLC into run mode.  At this point I was able to trigger the camera from the PLC. To do this I simply performed some online writes to the outputs mapped to the camera from the PLC program. 

Learn more about DMC’s Beckhoff expertise and contact us today to get started on your next project.

The post Using Ethernet/IP Natively with TwinCAT appeared first on DMC, Inc..