Mitsubishi TCP/IP Library User’s Manual - · PDF filefor a Q or L Series Mitsubishi PLC...

Mitsubishi PLC TCP/IP Library User’s Manual

990000628 Rev. A

Although every effort is made to ensure the accuracy of this document, MagneMotion, Inc. assumes no responsibility forany errors, omissions, or inaccuracies. Information provided within this manual is subject to change without notice. Anysample code referenced in this document and that may be included with MagneMotion software is included for illustrationonly and is, therefore, unsupported.

MagneMotion®, MagneMover®, QuickStick®, MM LITE™, and SYNC IT™ are trademarks or registered trademarks ofMagneMotion, Inc. All other trademarks are properties of their respective owners.

This product is protected under one or more U.S. and International patents. Additional U.S. and International patentspending.

©2014 MagneMotion, Inc. All Rights Reserved. The information included in this manual is MagneMotion, Inc.proprietary information and is provided for the use of MagneMotion, Inc. customers only and cannot be used fordistribution, reproduction, or sale without the express written permission of MagneMotion, Inc. In no event willMagneMotion, Inc. be responsible or liable for indirect or consequential damages resulting from the use or application ofthis equipment.

MagneMotion, Inc.139 Barnum RoadDevens, MA 01434USAPhone: +1 978-757-9100Fax: +1 978-757-9200www.magnemotion.com

This technology is subject to United States Export Administration Regulations and authorized to the destination only;diversion contrary to U.S. law is prohibited.

Printed in the U.S.A.

MagneMotion, Inc.2 990000628 Rev. A

http://www.magnemotion.com

Contents

Figures ............................................................................................................. vii

Tables............................................................................................................... ix

ChangesOverview........................................................................................................................ xi

Rev. A ...................................................................................................................... xi

About This ManualOverview........................................................................................................................ xiii

Purpose..................................................................................................................... xiiiAudience .................................................................................................................. xiiiPrerequisites............................................................................................................. xiii

MagneMotion Documentation ....................................................................................... xivManual Conventions ................................................................................................ xivNotes, Safety Notices, and Symbols ........................................................................ xvManual Structure...................................................................................................... xviRelated Manuals ...................................................................................................... xvii

Contact Information....................................................................................................... xviii

1 IntroductionOverview........................................................................................................................1-1TCP/IP Library Overview..............................................................................................1-2Transport System Components Overview .....................................................................1-4Transport System Software Overview...........................................................................1-5Getting Started with the TCP/IP Library .......................................................................1-7

2 Transport System ControlOverview........................................................................................................................2-1Connecting to the Transport System..............................................................................2-2

Physical Connection ................................................................................................2-2Transport System Operation Projects ......................................................................2-2

Create a New Project .........................................................................................2-2Open an Existing Project ...................................................................................2-3

Mitsubishi PLC TCP/IP Library User’s Manual i

Contents

Configure PLC Operating Parameters .....................................................................2-3Define the Integrated Ethernet Connection .......................................................2-4Define the External Ethernet Connection ..........................................................2-6

Configuring the MMI Engine and Memory Map ..........................................................2-12Install the Library.....................................................................................................2-12Configure the Engine ...............................................................................................2-13Configure the Status Memory..................................................................................2-13Send Queue Memory ...............................................................................................2-14

Running the Transport System ......................................................................................2-15Basic Operation Overview.......................................................................................2-15

Response and Status Updates ............................................................................2-16Ordering Vehicle Movement .............................................................................2-16

Transport System Control Examples .......................................................................2-18Transport System Startup and Reset ........................................................................2-19

Reset...................................................................................................................2-19Startup................................................................................................................2-22Suspend..............................................................................................................2-25Resume...............................................................................................................2-28

Monitoring Transport System Status .......................................................................2-31High Level Controller ........................................................................................2-31Node Controllers................................................................................................2-31Nodes .................................................................................................................2-32Paths...................................................................................................................2-32Vehicles .............................................................................................................2-33Motors ................................................................................................................2-34

Moving Vehicles......................................................................................................2-36Direction of Movement......................................................................................2-36Move to Position ................................................................................................2-38Move to Station..................................................................................................2-40

Entering or Exiting Through a Terminus Node .............................................................2-42Vehicle Entry onto the Transport System................................................................2-42Vehicle Exit from the Transport System .................................................................2-46

Shutting Down the Transport System............................................................................2-50

3 Application NotesOverview........................................................................................................................3-1Vehicle Movement.........................................................................................................3-2

Vehicle Positioning..................................................................................................3-2Safe Stopping Distance Movement..........................................................................3-3

Emergency Stop.............................................................................................................3-4Initiating an E-Stop..................................................................................................3-4

Node Controller-based E-Stop...........................................................................3-4Host Controller-based E-Stop............................................................................3-4

Recovering from an E-Stop .....................................................................................3-5Node Controller-based E-Stop...........................................................................3-5Host Controller-based E-Stop............................................................................3-5

MagneMotion, Inc.ii 990000628 Rev. A

Contents

Interlock .........................................................................................................................3-6Initiating an Interlock...............................................................................................3-6Recovering from an Interlock ..................................................................................3-6

Emergency Off...............................................................................................................3-7Initiating an EMO ....................................................................................................3-7Recovering from an EMO........................................................................................3-7

Movement Through a Switch, Shuttle, or Turntable .....................................................3-8Switch ......................................................................................................................3-8

Forward Through a Merge Switch.....................................................................3-8Backward Through a Merge Switch ..................................................................3-9Reversing Through a Merge Switch ..................................................................3-9Forward Through a Diverge Switch ..................................................................3-10Backward Through a Diverge Switch................................................................3-11Reversing Through a Diverge Switch................................................................3-11

Shuttle ......................................................................................................................3-13Forward Through a Shuttle ................................................................................3-13Backward Through a Shuttle .............................................................................3-13Reversing Through a Shuttle .............................................................................3-14

Turntable ..................................................................................................................3-15Forward Through a Turntable............................................................................3-15Backward Through a Turntable .........................................................................3-15Reversing Through a Turntable .........................................................................3-16

Movement Through a Terminus Node...........................................................................3-17Entry Handshake......................................................................................................3-17

Signal Descriptions ............................................................................................3-17Entry Handshake Timing ...................................................................................3-18

Exit Handshake ........................................................................................................3-20Signal Descriptions ............................................................................................3-20Exit Handshake Timing .....................................................................................3-20

Movement Through a Gateway Node............................................................................3-22Automatic Path Recovery ..............................................................................................3-23

Use Automatic Path Recovery On Resume .............................................................3-23Use Automatic Path Recovery Always....................................................................3-23

Motor Types...................................................................................................................3-24MagneMover LITE ..................................................................................................3-24QuickStick ...............................................................................................................3-25

Node Types ....................................................................................................................3-26Relay Node ..............................................................................................................3-26Merge Node .............................................................................................................3-27Diverge Node...........................................................................................................3-28Turntable Node ........................................................................................................3-29Terminus Node ........................................................................................................3-30Simple Node ............................................................................................................3-31Shuttle Node ............................................................................................................3-32Merge-Diverge Node ...............................................................................................3-33Gateway Node..........................................................................................................3-35

Mitsubishi PLC TCP/IP Library User’s Manual iii

Contents

4 Protocol and Structured Data Type ReferenceOverview........................................................................................................................4-1Introduction....................................................................................................................4-2

Example of Function Block Setup ...........................................................................4-2Host Controller to HLC Function Block Definitions.....................................................4-3

MMI_B0_MoveVehicleToStation...........................................................................4-4MMI_B1_MoveVehicleToPosition .........................................................................4-7MMI_B2_Startup.....................................................................................................4-10MMI_B3_ResumeMovement ..................................................................................4-12MMI_B4_SuspendMovement .................................................................................4-14MMI_B5_StatusRequest..........................................................................................4-16MMI_B6_SetEntrySignal ........................................................................................4-19MMI_B6_SetExitSignal ..........................................................................................4-21MMI_B8_Reset .......................................................................................................4-23MMI_B9_DeleteVehicle .........................................................................................4-25MMI_Engine............................................................................................................4-27

HLC to Host Controller Status Memory Labels ............................................................4-32MMI_HLC_status ....................................................................................................4-33MMI_motor_status ..................................................................................................4-35MMI_node_command_status ..................................................................................4-42MMI_node_controller_status...................................................................................4-44MMI_node_status ....................................................................................................4-46MMI_path_command_status ...................................................................................4-50MMI_path_status .....................................................................................................4-52MMI_vehicle_order_status ......................................................................................4-55MMI_vehicle_status ................................................................................................4-58MMI_send_queue ....................................................................................................4-61

Function Block Error Codes ..........................................................................................4-62HLC Status Codes..........................................................................................................4-63

5 TroubleshootingOverview........................................................................................................................5-1Troubleshooting .............................................................................................................5-2

TCP/IP Communications .........................................................................................5-2PLC Troubleshooting...............................................................................................5-3

Contact MagneMotion Technical Support.....................................................................5-4

AppendixOverview.......................................................................................................................A-1Communications Protocol.............................................................................................A-2

Communications Format.........................................................................................A-2File Maintenance...........................................................................................................A-3

Backup Files ...........................................................................................................A-3Creating Backup Files.............................................................................................A-3Restoring from Backup Files ..................................................................................A-3

MagneMotion, Inc.iv 990000628 Rev. A

Contents

Additional Documentation............................................................................................A-4Release Notes..........................................................................................................A-4Upgrade Procedure .................................................................................................A-4

Transport System Limits...............................................................................................A-5

Glossary ......................................................................................................... G-1

Index ................................................................................................................ I-1

Mitsubishi PLC TCP/IP Library User’s Manual v

Contents

This page intentionally left blank.

MagneMotion, Inc.vi 990000628 Rev. A

Figures

1-1 Simplified View of MagneMotion Transport System Components .......................1-41-2 Simplified View of Transport System Software Relationships ..............................1-5

2-1 Parameter Settings Window ....................................................................................2-42-2 Built-in Ethernet Port Open Setting Dialog ............................................................2-52-3 Configured Ethernet Port Settings ..........................................................................2-62-4 Network Parameter - MELSECNET/CC IE/Ethernet Module Config Tab ............2-72-5 Configured Network Parameters ............................................................................2-82-6 Ethernet Operation Setting Dialog ..........................................................................2-82-7 Ethernet Operation Settings ....................................................................................2-92-8 Network Parameter Ethernet Open Setting Tab .....................................................2-92-9 Network Parameter Settings ...................................................................................2-112-10 Vehicle Command Sequence ..................................................................................2-172-11 Merge/Diverge Transport System for Examples ....................................................2-182-12 Transport System for Motion Examples .................................................................2-362-13 Terminus Node Entry Example ..............................................................................2-422-14 Terminus Node Exit Example .................................................................................2-46

3-1 Vehicle Positioning Example ..................................................................................3-23-2 Vehicle Movement Profile ......................................................................................3-33-3 Merge Switch Movement ........................................................................................3-83-4 Diverge Switch Movement .....................................................................................3-103-5 Shuttle Switch Movement .......................................................................................3-133-6 Turntable Switch Movement ..................................................................................3-153-7 Entry Handshake Timing ........................................................................................3-183-8 Exit Handshake Timing ..........................................................................................3-203-9 Gateway Node Movement ......................................................................................3-223-10 MagneMover LITE Motor ......................................................................................3-243-11 QuickStick Motor ...................................................................................................3-253-12 Relay Node .............................................................................................................3-263-13 Merge Node ............................................................................................................3-273-14 Diverge Node ..........................................................................................................3-283-15 Turntable Node .......................................................................................................3-293-16 Terminus Node .......................................................................................................3-303-17 Simple Node ...........................................................................................................3-313-18 Shuttle Node ...........................................................................................................3-323-19 Merge-Diverge Node ..............................................................................................3-333-20 Gateway Node .........................................................................................................3-35

Mitsubishi PLC TCP/IP Library User’s Manual vii

Figures

4-1 Dialogue creating a Function Block .......................................................................4-24-2 MMI_B0_MoveVehicleToStation Function Block ................................................4-44-3 MMI_B1_MoveVehicleToPosition Function Block ..............................................4-74-4 MMI_B2_Startup Function Block ..........................................................................4-104-5 MMI_B3_ResumeMovement Function Block .......................................................4-124-6 MMI_B4_SuspendMovement Function Block .......................................................4-144-7 MMI_B5_StatusRequest Function Block ...............................................................4-164-8 MMI_B6_SetEntrySignal Function Block .............................................................4-194-9 MMI_B6_SetExitSignal Function Block ................................................................4-214-10 MMI_B8_Reset Function Block .............................................................................4-234-11 MMI_B9_DeleteVehicle Function Block ...............................................................4-254-12 MMI_Engine Function Block .................................................................................4-28

MagneMotion, Inc.viii 990000628 Rev. A

Tables

2-1 Mitsubishi PLC TCP/IP Library Options ...............................................................2-12

4-1 PLC to HLC Function Blocks .................................................................................4-34-2 Internal Function Blocks .........................................................................................4-34-3 PLC Status Memory Labels ....................................................................................4-324-4 Internal Memory Labels ..........................................................................................4-324-5 Function Block Error Codes ...................................................................................4-624-6 HLC Status Codes ...................................................................................................4-63

5-1 Initial Host Controller Communications Troubleshooting .....................................5-25-2 Basic PLC Communications Troubleshooting .......................................................5-3

A-1 MagneMotion Transport System Limits ................................................................A-5A-2 MagneMotion Transport System Motion Limits ...................................................A-5

Mitsubishi PLC TCP/IP Library User’s Manual ix

Tables


MagneMotion, Inc.x 990000628 Rev. A

Changes

Overview

Changes may be made to this manual to ensure that it continues to provide the most complete documentation possible for MagneMotion’s Mitsubishi PLC Library for TCP/IP Communica-tions. This section provides a brief description of each change.

NOTE: Distribution of this manual and all addendums and attachments is not controlled. Changes may have been made at any time. To identify the current revision, contact MagneMotion Customer Support.

Rev. A

Initial release for Version 1.7.3.

Mitsubishi PLC TCP/IP Library User’s Manual xi

Changes


MagneMotion, Inc.xii 990000628 Rev. A

About This Manual

Overview

This section provides information about the use of this manual, including the manual struc-ture, related documentation, format conventions, and safety conventions.

Purpose

This manual describes the application and protocol for communication between the Magne-Motion High Level Controller application and a Mitsubishi PLC (Q or L Series) equipped with a TCP/IP interface. This manual also provides basic troubleshooting information.

Use this manual in combination with the other manuals and documentation that accompanies the transport system and with the training classes offered by MagneMotion, Inc. to design, install, configure, test, and operate a MagneMotion transport system.

Audience

This manual is intended for all users of MagneMotion transport systems and provides infor-mation on how to use the MagneMotion’s Mitsubishi PLC TCP/IP Library with GX Works2 for a Q or L Series Mitsubishi PLC to operate the transport system.

NOTE: Depending on user access privileges and application configuration, certain opera-tions described within this manual may not be available.

Prerequisites

This manual assumes familiarity with PLC programming. All examples in this manual assume a familiarity with Mitsubishi Q or L series PLCs and GX Works2. Details on how to build lad-der logic that utilizes the Status Memory and the Function Block definitions defined in this manual for a production system are beyond the scope of this manual.

This manual assumes a basic familiarity with personal computers and with the Windows® operating system. This manual also assumes that the hardware for the MagneMotion transport system has already been installed, that the full documentation for the transport system is avail-able, and that personnel operating the transport system have been properly trained.

Mitsubishi PLC TCP/IP Library User’s Manual xiii

About This ManualMagneMotion Documentation

MagneMotion Documentation

The documentation provided with the MagneMotion transport system includes this manual, which provides complete documentation for the use of the MagneMotion’s Mitsubishi PLC TCP/IP Library for the transport system. There may be information in other manuals which affect the configuration and operation of the transport system.

The examples in this manual are included solely for illustrative purposes. Because of the many variables and requirements associated with any transport system installation, MagneMotion, Inc. cannot assume responsibility or liability for actual use based on these examples.

Manual Conventions

• Dialog Box – A window that solicits a user response.

• Click or Left-click – Click the left mouse button1.

• Right-click – Click the right mouse button.

• Double-click – Click the left mouse button twice in quick succession.

• Control-click – Hold down <Ctrl> and click the left mouse button.

• Click-and-hold – Press down the left mouse button and hold it down while moving the mouse.

• Select – Highlight a menu item with the mouse or the tab or arrow keys.

• Selectable menu choices, option titles (button, check box, and text box), function titles, and area or field titles in dialog boxes are shown in bold type and are capitalized exactly as they appear in the software. Examples: Add to End..., Paths, Path Details, OK.

• Dialog box titles or headers are shown in bold type, capitalized exactly as they appear in the software. Example: the Open XML Configuration File dialog box.

• Keyboard keys and key combinations (pressing more than one key at a time) are shown enclosed in carets. Examples: <F2>, <Enter>, <Ctrl>, <Ctrl-x>.

• Responses to user actions are shown in italics. Example: Motion on all specified Paths is enabled.

• Data Entry – There are several conventions for data entry:

• Exact – The text is shown in quotes. Example: Enter the name ‘Origin’ in the text field.

• Variable – The text is shown in italics. Example: Save the file as file_name.xml.

• Code Samples – Shown in monospaced text. Example: Paths.

1. Mouse usage terms assumes typical ‘right-hand’ mouse configuration.

MagneMotion, Inc.xiv 990000628 Rev. A


• Numbers – All numbers are assumed to be decimal unless otherwise noted. Non-deci-mal numbers (binary or hexadecimal) are explicitly stated.

• Binary – Followed by 2, e.g., 1100 0001 01012, 1111 1111 1111 11112.

• Hex – Followed by 16, e.g., C1516, FFFF16. Note that Hex numbers displayed in the software are preceded by 0x, e.g., 0xC15, 0xFFFF. Hex values in the Mitsubishi PLCs may be preceded by an ‘h’, e.g., hC15, hFFFF.

• Measurements – All measurements are SI (International System of Units). The for-mat for dual dimensions is SI_units [English_units]; e.g., 250 mm [9.8 in].

• Text in blue is a hyperlink. These links are active when viewing the manual as a PDF. Selecting a hyperlink changes the manual view to the page of the item referenced. Note that in some cases the item referenced is on the same page, so no change in the view will occur.

Notes, Safety Notices, and Symbols

Notes, Safety Notices, and Symbols used within this manual have very specific meanings and formats. Examples of notes, the different types of safety notices and their general meanings is provided below. Adhere to all safety notices provided throughout this manual to ensure safe installation and use.

Notes

Notes are set apart from other text and provide additional or explanatory information. The text for Notes is in standard type as shown below.

NOTE: A note provides additional or explanatory information.

Safety Notices

Safety Notices are set apart from other text. The color of the panel at the top of the notice and the text in the panel indicates the severity of the hazard, the symbol on the left of the notice identifies the type of hazard (refer to Symbol Identification for symbol descriptions), and the text in the message panel identifies the hazard, methods to avoid the hazard, and the conse-quences of not avoiding the hazard.

Examples of the standard safety notices used in this manual are provided below and include a description of hazard level indicated by each type of notice.

DANGER

Danger indicates a hazardous situation which, if not avoided,will result in death or serious injury.

Mitsubishi PLC TCP/IP Library User’s Manual xv


Symbol Identification

Symbols are used in this manual to identify hazards, mandatory actions, and prohibited actions. The symbols used in this manual and their descriptions are provided below.

Manual Structure

This manual contains the following chapters:

• Introduction: Provides an overview of MagneMotion’s Mitsubishi PLC TCP/IP Library, which is used to monitor and control a MagneMotion transport system.

• Transport System Control: Provides information on using MagneMotion’s Mitsubishi PLC TCP/IP Library to monitor and control a MagneMotion transport system.

• Application Notes: Provides examples and step-by-step procedures related to specific tasks using MagneMotion’s Mitsubishi PLC TCP/IP Library with a MagneMotion transport system.

WARNING

Warning indicates a hazardous situation which, if notavoided, could result in death or serious injury.

CAUTION

Caution indicates a hazardous situation, which if notavoided, could result in minor or moderate injury.

NOTICE

Notice indicates practices not related to personal injury that could result inequipment or property damage.

Symbol Description

General Hazard Alert – Indicates that failure to follow recommended pro-cedures can result in unsafe conditions, which may cause injury or equip-ment damage.

MagneMotion, Inc.xvi 990000628 Rev. A


• Protocol and Structured Data Type Reference: Provides an overview of MagneMo-tion’s Mitsubishi PLC TCP/IP Library and details of each Function Block and each SDT.

• Troubleshooting: Provides troubleshooting of problems within the MagneMotion transport system not identified by error messages.

• Appendix: Provides additional information about the communications protocol and MagneMotion transport systems in several separate appendices.

• Glossary: A list of terms and definitions used in this manual and for the transport sys-tem and its components.

• Index: A cross-reference to this manual organized by subject.

NOTE: The software version of MagneMotion’s Mitsubishi PLC TCP/IP Library supplied on the CD ROM may be newer than the version that is described in this manual (indicated in Changes at the front of this manual). However, all features documented in this manual are supported. Note that specific builds of the Library may not imple-ment all of the features described in this manual.

Related Manuals

Before configuring or running the transport system, consult the following documentation:

• MagneMover® LITE Configurator User’s Manual, 990000558.orQuickStick® Configurator User’s Manual, 990000559.

• Node Controller Web Interface User’s Manual, 990000377.

• NCHost TCP Interface Utility User’s Manual, 990000562.

• Mitsubishi PLC TCP/IP Library User’s Manual, 990000628 (this manual).

• Host Controller TCP/IP Communication Protocol User’s Manual, 990000436.

• MagneMover® LITE User’s Manual, 990000410.orQuickStick® User’s Manual, 990000460.

• LSM Synchronization Option User’s Manual, 990000447.

NOTE: Distribution of this manual and all addendums and attachments are not controlled. Changes may have been made to this manual or the software at any time. To identify the current revisions or to obtain a current version of the software, contact MagneMotion Customer Support.

Mitsubishi PLC TCP/IP Library User’s Manual xvii

About This ManualContact Information

Contact Information

Main Office Customer Support

MagneMotion, Inc.139 Barnum RoadDevens, MA 01434USAPhone: +1 978-757-9100Fax: +1 978-757-9200

+1 [email protected]

MagneMotion, Inc.xviii 990000628 Rev. A

Introduction 1

Overview

This chapter provides an overview of MagneMotion’s Mitsubishi PLC TCP/IP Library, the transport system hardware and software, and the basic set of tasks needed to use the Library with a MagneMotion transport system.

Use this manual to develop an application using MagneMotion’s Mitsubishi PLC TCP/IP Library to monitor and control a MagneMotion transport system. Note that some procedures provided in this manual as examples may vary in actual use based on the transport system configuration, communications, and other variables.

This manual supports:

• QuickStick® transport systems.

• MagneMover® LITE transport systems.

Included in this chapter are overviews of:

• MagneMotion’s Mitsubishi PLC TCP/IP Library.

• The transport system components.

• The transport system software.

• Getting started with TCP/IP communications.

Mitsubishi PLC TCP/IP Library User’s Manual 1-1

IntroductionTCP/IP Library Overview

TCP/IP Library Overview

MagneMotion’s Mitsubishi PLC TCP/IP Library is provided by MagneMotion to interface between the PLC and the transport system during operation. This Library supports transport system startup, controlling and monitoring vehicle movement on the transport system, moni-toring transport system module status, and handshaking with external equipment to transfer vehicles on and off the transport system.

The transport system is a configuration of linear synchronous motors placed end-to-end to form long chains or Paths that move vehicles in a controlled manner at various accelera-tion/deceleration and velocity profiles while carrying a wide range of payloads with high pre-cision. The transport system consists of the following components, at a minimum:

• MagneMover LITE or QuickStick motors.

• Vehicles with Magnet Arrays.

• Node Controllers.

• Power Supplies.

• Paths and Nodes.

• User-supplied Host Controller (Mitsubishi PLC, Q or L Series).

The specific Mitsubishi PLC should be selected based on the transport system size, application, and integrated peripherals. Consult MagneMotion Customer Support for sizing recommendations.

• User-designed and supplied guideway and track system.

The start of each Path is connected to a Node Controller. Multiple Node Controllers can be used for systems with a large number of Paths. The High Level Controller application runs on one Node Controller, which interfaces the complete system of motors with the Host Control-ler. This interface allows the Host Controller to send commands to and receive status from the transport system. This manual describes the MagneMotion Library that the Mitsubishi PLC High Level Controller software uses to communicate with Host Controllers via TCP/IP over Ethernet.

Supplied with MagneMotion’s Mitsubishi PLC TCP/IP Library are several ladder logic sam-ples to provide the user with examples of Library use for transport system control.

• Minimum Program Example – Copies in an instance of each function block and ini-tializes the Engine. This can be used for manual control of the transport system.

• QS Terminus Program – Provides sample logic for implementing the states and hand-shaking required to use the Terminus Nodes for vehicle entry to, and exit from, the transport system.

• ML Ladder Program – Provides sample logic that manages independent state machines for each vehicle and destination, which can be used to control the sequence of moving vehicles around the transport system.

MagneMotion, Inc.1-2 990000628 Rev. A

IntroductionTCP/IP Library Overview

Each of the components of the transport system must be completely defined in the Node Con-figuration File to ensure proper operation of the transport system. Once the transport system is fully defined it can be monitored and controlled using the Host Controller through the Library interface.

NOTE: Changes to the user’s control application may be necessary if any aspect of the trans-port system changes, such as number or length of Paths, vehicle length, payload weight, or other physical factors.


IntroductionTransport System Components Overview

Transport System Components Overview

This section identifies the components of a MagneMotion transport system as shown in Fig-ure 1-1 and described after the figure.

Figure 1-1: Simplified View of MagneMotion Transport System Components

• DC Power Cables and Serial Communication Cables – Distributes DC power to the motors of the transport system and carries communications between the components.

• High Level Controller (HLC) – Software application running on one Node Controller that handles all communication with the user-supplied Host Controller and directs communication as appropriate to individual Node Controllers.

• Host Controller – Provides user control and monitoring of the transport system. Sup-plied by the user, for this application it is a Mitsubishi Q or L Series PLC.

• Motor – Refers to a MagneMotion linear synchronous motor (LSM).

• Network – Ethernet network providing communications (TCP/IP) between the Host Controller and the HLC (TCP/IP is used between Node Controllers).

• Node Controller (NC) – Coordinates motor operations and communicates with the High Level Controller. Three types of Node Controller are available:• NC-12 Node Controller (not shown) – Provides one network port, two

RS-232 ports, 12 RS-422 ports, 16 digital inputs, and 16 digital outputs.• Standard Node Controller – Provides one network port, two RS-232 ports,

eight RS-422 ports, 16 digital inputs, and 16 digital outputs.• Node Controller LITE (not shown) – Provides one network port and four

RS-422 ports.

• Power Supply – Provides DC power to the motors.

• Vehicle with Magnet Array – Carries a payload through the transport system as directed. The magnet array is mounted to the vehicle and interacts with the motors, which moves each vehicle independently.

DC Power Cables

Power Supply

Motors

Vehicles

Serial Communication Cables

Node Controller(and High Level Controller)

Network(Ethernet)

Host Controller(PC or PLC)


IntroductionTransport System Software Overview

Transport System Software Overview

Several software applications are used to configure, test, and administer a MagneMotion transport system as shown in Figure 1-2 and described after the figure. Refer to Related Man-uals on page xvii for the reference manuals for these applications.

Figure 1-2: Simplified View of Transport System Software Relationships

• Node Controller Web Interface – A web-based software application supplied by MagneMotion, resident on the Node Controllers, for administration of the parts of the transport system.

• MMI Library – A software Engine, Function Blocks, and SDTs that reside on the Host Controller (Mitsubishi Q or L Series PLC) and provides the interface between the Host Controller and the MMI High Level Controller (HLC) in the transport system. The Engine manages communication with the HLC and status memory. Once the Engine has been instantiated appropriately, the various function blocks are used to issue commands and status requests to the HLC.

• NCHost TCP Interface Utility – A Windows® software application supplied by MagneMotion to move vehicles for test or demonstration purposes without the Host Controller to verify that vehicles move correctly before integrating a transport system into a production environment.

User’s Host Controller(Mitsubishi PLC)

MagneMotion Configurator

Node ControllerNode Controller Web Interface

NCHost TCP Interface Utility

Motor

Node Controller Software Image (controller_image.img)Motor Image Files (motor_image.erf)Motor Type Files (motor_type.xml)Magnet Array Type File (magnet_array_type.xml)Node Configuration File (node_configuration.xml)

node_configuration.xml

Node Controller Administration

System Control

System Testing(NCHost.exe)

(MMConfigTool.exe)

track_file.mmtrkdemo_script.txt

track_layout.ndx

MMILibrary

TCP/IP

TCP/IP

TCP/IP


IntroductionTransport System Software Overview

• Demonstration Script (Demo Script) – A text file (demo_script.txt) uploaded to the NCHost TCP Interface Utility to move vehicles on the transport system for test or demonstration purposes.

• MagneMotion Configurator (Configurator) – A Windows software application sup-plied by MagneMotion to create or change the Track Layout File or the Node Config-uration File without editing the files directly.

• Node Configuration File (Configuration File) – An XML file (node_configura-tion.xml) that contains all of the parameters for the components in the transport sys-tem. The Node Configuration File is uploaded to all Node Controllers in the transport system.

• Track File – A text file (track_file.mmtrk) that contains parameters of the transport system. The Track File is used by the NCHost TCP Interface Utility to provide a graphical representation of the transport system.

• Track Layout File – An XML file (track_layout.ndx) that contains all of the parame-ters for the graphical representation of the transport system. The Track Layout File can be used to generate the Node Configuration File and the Track File.

• Node Controller Image File (IMG file) – The software files for the Node Controllers (controller_image.img), includes the Node Controller and High Level Controller applications. The Node Controller Image File is uploaded to all Node Controllers in the transport system.

• Motor Image Files (ERF file) – The software files for the motors (motor_image.erf). The Motor Image Files are uploaded to all Node Controllers in the transport system and then downloaded to all motors.

• Motor Type Files – XML files (motor_type.xml) that contain basic information about the specific MagneMotion motor types being used. The Motor Type Files are uploaded to all Node Controllers in the transport system.

• Magnet Array Type Files – XML files (magnet_array_type.xml) that contain basic information about the specific MagneMotion magnet array type used on the vehicles in the transport system. The Magnet Array Type File is uploaded to all Node Control-lers in the transport system.

NOTICE

Making changes to the Image or Type files could cause improper operationof the transport system.


IntroductionGetting Started with the TCP/IP Library

Getting Started with the TCP/IP Library

Use this manual as a guide and reference when developing applications using MagneMotion’s Mitsubishi PLC TCP/IP Library. Follow the steps in this section to get the entire transport sys-tem operational quickly with the aid of the other MagneMotion manuals (refer to Related Manuals on page xvii).

NOTE: Ensure that complete design specifications, including the physical layout of the transport system, are available before starting to configure the transport system.

To get started quickly with the transport system:

1. Save the files and folders from the MagneMotion System Software and Installation CD-ROM that came with the transport system to a folder on a computer for user access.

NOTE: The minimum computer requirements for running MagneMotion software applications are a PC running Windows 7 with .NET 4.0 and an Ethernet port. However, the application developed using MagneMotion’s Mitsubishi PLC TCP/IP Library must be run on a Mitsubishi PLC (Q or L Series).

2. Install the components of the MagneMotion transport system as described in either the MagneMover® LITE User’s Manual or the QuickStick® User’s Manual.

3. Install the MagneMotion Configurator on a computer for user access (refer to either the MagneMover® LITE Configurator User’s Manual or the QuickStick® Configurator User’s Manual).

A. For MM LITE systems, create the Track Layout File (track_layout.ndx) to define the components and their relationships in the transport system.

B. For all transport systems, create the Node Configuration File (node_configura-tion.xml) to define the components and operating parameters of the transport system.

NOTE: EtherNet/IP must not be selected for transport system control in the Node Configuration File.

4. Set the Node Controller IP addresses, specify the Node Controller to be used as the High Level Controller, and upload the configuration, image, and type files to each Node Controller (refer to the Node Controller Web Interface User’s Manual).

5. Program the motors using the Motor Image Files (refer to the Node Controller Web Interface User’s Manual and NCHost TCP Interface Utility User’s Manual).

6. Test and debug the transport system by using the NCHost TCP Interface Utility and Demo Scripts (refer to the NCHost TCP Interface Utility User’s Manual). This pro-vides an easy method to verify proper operation and make adjustments such as refin-ing the control loop tuning.

NOTE: The NCHost TCP Interface Utility is for test and verification trials only. The user’s Host Controller must be used to control the transport system after ver-ification of functionality.


IntroductionGetting Started with the TCP/IP Library

7. Configure the Host Controller to control the transport system as required to meet the material movement needs of the facility where the system is installed as described in the sections below. Use this manual when developing an application for a Host Con-troller using MagneMotion’s Mitsubishi PLC TCP/IP Library.

1. Connecting to the Transport System on page 2-2.

2. Configuring the MMI Engine and Memory Map on page 2-12.

3. Running the Transport System on page 2-15.

4. Monitoring Transport System Status on page 2-31.

5. Vehicle Movement on page 3-2.


Transport System Control 2

Overview

This chapter provides basic information on using MagneMotion’s Mitsubishi PLC TCP/IP Library to monitor and control a MagneMotion transport system.

Refer to Application Notes on page 3-1 for detailed information on vehicle movement and using the transport system. Refer to Protocol and Structured Data Type Reference on page 4-1 for detailed information on the Status Memory map and each Function Block. This chapter includes command overviews and provides a representation of the memory map. For complete message transmission protocol refer to Communications Protocol on page A-2.

Included in this chapter are instructions for:

• Connecting to the transport system.

• Running the transport system.

• Monitoring transport system status including Node Controllers, Nodes, Paths, vehi-cles, and motors.

• Moving a vehicle to Positions and Stations.

• Entering or Exiting through a Terminus Node.

• Shutting down the transport system.


Transport System ControlConnecting to the Transport System

Connecting to the Transport System

This section describes how to connect the Host Controller to the transport system’s High Level Controller (HLC) to monitor and control the transport system. Note that once the con-nection from the Host Controller to the HLC is established there is no need for the Host Con-troller to login to the HLC.

NOTE: For detailed information about the GX Works2, the Mitsubishi Q and L PLCs, and creating and running projects refer to the GX Works2 documentation.

Physical Connection

1. Make a network connection from the Host Controller (Mitsubishi PLC) to the HLC using standard 10/100 Base-TX, half or full duplex twisted pair Ethernet cable.

2. From the Host Controller, connect to the High Level Controller (HLC), refer to Com-munications Protocol on page A-2.

3. Use the Ping utility on the Host Controller to verify the connection to the HLC.

Transport System Operation Projects

MagneMotion's Mitsubishi PLC Library includes sample code that provides a reference or can be used as a basis to create the Host application. The sample code includes:

• Minimum Program Example – Copies in an instance of each function block and ini-tializes the Engine. This can be used for manual control of the transport system.

• QS Terminus Program – Provides sample logic for implementing the states and hand-shaking required to use the Terminus Nodes for vehicle entry to, and exit from, the transport system.

• ML Ladder Program – Provides sample logic that manages independent state machines for each vehicle and destination, which can be used to control the sequence of moving vehicles around the transport system.

To create a new project, or open a previously developed project to provide transport system monitoring and control, refer to the Documentation supplied with the PLC and GX Works2.

Create a New Project

1. From the Project tab in the main menu, select New.

The New Project dialog is opened.

2. Configure the Project as shown below and select OK.

• Series: LCPU or QCPU.

• Type: As determined by the hardware.



• Project Type: Structured Project.

• Language: Structured Ladder/FBD.

3. From the Project tab in the main menu, select Save.

The Save As dialog is opened.

A. Browse to the appropriate location to save the project, enter a File name and select Save.

4. Configure the project as described in:

• Define the Integrated Ethernet Connection on page 2-4.

• Define the External Ethernet Connection on page 2-6.

• Install the Library on page 2-12.

• Configure the Engine on page 2-13.

• Configure the Status Memory on page 2-13.

• Send Queue Memory on page 2-14.

Open an Existing Project

Open either an existing program or one of the MMI sample programs (refer to Transport Sys-tem Operation Projects on page 2-2).

1. From the Project tab in the main menu, select Open.

The Open dialog is opened.

A. Browse to the appropriate location, select the project, and select Open.

The selected project is opened.

2. Configure the project as previously described or develop the project as described in Running the Transport System on page 2-15.

Configure PLC Operating Parameters

The PLC must be configured for proper operation. This includes configuring the Ethernet con-nection and identifying the IP address and communications Port of the HLC.

NOTE: The built-in Ethernet port must be configured if it will be used for programming the PLC, even if an external Ethernet port is to be used for HLC control.

PLC parameter changes must be downloaded to the PLC to take effect, and a power cycle should be performed after the download has been completed.



Define the Integrated Ethernet Connection

The internal TCP communication parameters and IP addresses need to be established in GX Works2 in order to begin communication with the HLC.

1. Run GX Works2.

2. Open the transport system control project.

3. In the Navigation pane under Project, expand Parameter then select PLC Parame-ter and select the Built-in Ethernet Port Setting tab.

The Parameter Setting window is opened as shown in Figure 2-1.

Figure 2-1: Parameter Settings Window

4. From the Built-in Ethernet Port Setting tab, configure the following:

• IP Address: Address of the PLC.

• Subnet Mask: Mask pattern used to constrain the network.

• Default Router IP Address: The gateway used to connect the transport sys-tem network with other networks.



• Communication Data Code: Binary.

• Enable online change: Deselected.

5. From the Built-in Ethernet Port Setting tab, select IP packet transfer setting.

6. In the IP packet transfer setting dialog ensure the IP packet transfer function is set to Not used.

7. From the Built-in Ethernet Port Setting tab, select Open Setting.

The Built-in Ethernet Port Open Setting dialog is opened as shown in Figure 2-2.

Figure 2-2: Built-in Ethernet Port Open Setting Dialog

8. In the table, configure the connection to the HLC using Socket Communication as shown below and in Figure 2-3. Refer to the Host Controller TCP/IP Communication Protocol User’s Manual for port usage.

• Protocol: TCP.

• Open System: Socket Communication.

• TCP Connection: Active.

• Host Station: Port for communication with the HLC. This should be set to ensure there are no conflicts with other devices on the network.

• Destination IP Address: IP address of the High Level Controller.

• Destination Port No.: 799.

NOTE: Only one connection may be established and it must have a destina-tion port of 799 for transport system control and monitoring.

• Start Device to Store Predefined Protocol: Not used on Q PLCs (not avail-able on L PLCs).



Figure 2-3: Configured Ethernet Port Settings

9. Select End to save the changes and close the Built-in Ethernet Port Open Setting dia-log.

10. Select End to save the changes and close the Parameter Setting window.

Define the External Ethernet Connection

The external TCP communication parameters and IP addresses need to be established in GX Works2 in order to begin communication with the HLC. MagneMotion recommends configur-ing the connection as described below, refer to the Mitsubishi PLC documentation for more information.


2. In the Navigation window under Project, expand Parameter, then expand Network Parameter, and select Ethernet / CC IE Field.

The Network Parameter - MELSECNET/CC IE/Ethernet Module Configuration tab is opened as shown in Figure 2-4.



Figure 2-4: Network Parameter - MELSECNET/CC IE/Ethernet Module Config Tab

3. In the table, configure the connection to the Ethernet Module as shown below and in Figure 2-5.

• Network Type: Ethernet.

• Start I/O No.: Ethernet module I/O address (from the Diagnostics tab in the main menu, select System Monitor to display the I/O address).

• Network No.: User defined, based on configuration of the PLC network (typi-cally 1).

• Group No.: User defined, based on configuration of the PLC network (typi-cally 0).

• Station No.: User defined, based on configuration of the PLC network (typi-cally 1).

• Mode: Online.



Figure 2-5: Configured Network Parameters

4. Select Operation Setting under Module 1.

The Ethernet Operation Setting dialog is opened as shown in Figure 2-6.

Figure 2-6: Ethernet Operation Setting Dialog

5. Configure the Ethernet operation as shown below and in Figure 2-7 and select End.

• Communication Data Code: Binary Code.

• Initial Timing: Always wait for OPEN.

• IP Address Setting: IP address of the Ethernet module.

• Send Frame Setting: Ethernet (V2.0).

• TCP Existence Confirmation Setting: Use the KeepAlive.



Figure 2-7: Ethernet Operation Settings

6. Select End to save the changes and close the Ethernet Operation Setting dialog.

7. Select Open Setting under Module 1.

The Network Parameter Ethernet Open Setting tab is opened as shown in Figure 2-8.

Figure 2-8: Network Parameter Ethernet Open Setting Tab

8. Configure the paired Receive and Send Network Parameters as shown below and in Figure 2-9 and select End.

NOTE: It is critical that the Receive connection number be the smaller connection number in the Send/Receive pair and must be configured first.



Receive

• Protocol: TCP.

• Open System: Active.

• Fixed Buffer: Receive.

• Fixed Buffer Communication: No Procedure.

• Pairing Open: Enable.

NOTE: Setting Pairing Open to Enable will automatically create the Send parameters entry.

• Existence Confirmation: No Confirmation.

• Host Station Port No.: User defined.



Send

• Protocol: TCP.

• Open System: Active.

• Fixed Buffer: Send.

• Fixed Buffer Communication: No Procedure.

• Pairing Open: Enable.

• Existence Confirmation: No Confirmation.

• Host Station Port No.: User defined.





Figure 2-9: Network Parameter Settings

9. Select End to save the changes and close the Network Parameter Ethernet Open Set-ting tab.

10. Select End to save the changes and close the Network Parameter - MELSECNET/CC IE/Ethernet Module Configuration tab.


Transport System ControlConfiguring the MMI Engine and Memory Map

Configuring the MMI Engine and Memory Map

This section describes how to configure the MMI Engine and the PLC’s Memory Map for communications with the High Level Controller (HLC).

The MMI Engine provides the interface between MagneMotion’s TCP/IP communications protocol and the GX Works2 programming environment of the Mitsubishi Q and L Series PLCs. The Engine is designed to be called from a Scan or Fixed Scan program. The fixed scan interval should be selected based on the size of the processor, the size of the MMI system, and the performance requirements.

NOTE: The MMI Engine is designed to communicate with only a single HLC.

The Status Memory needs to be accessible to the user program, and available to the MMI Engine. For this reason, the Status Memory is allocated in a Global Label List. To configure the Status Memory, create a Global Label List with a variable with VAR_GLOBAL as the Class, Label Name is selected by the user, and Data type is sdt_MMI_status.

NOTE: The status memory area that is maintained by the MMI Engine must be treated as read-only by the user program. The user program must not to write to this memory area as it could cause faulty data to be read by the program that wouldn't reflect the best known state of the system.

Install the Library

MagneMotion’s Mitsubishi PLC TCP/IP Library provides a complete set of function blocks and SDTs for monitoring and control of the transport system. The Library must be installed in the GX Works2 project to provide access to this interface. Note that there are three versions of MagneMotion’s Mitsubishi PLC TCP/IP Library as shown in Table 2-1. Only install the Library appropriate for the PLC configuration.

All Libraries use the same function blocks. Therefore, the Host application can be created and tested for any Q or L CPU. If the CPU type or Ethernet module type is changed, uninstall the current Library and install the appropriate Library. No changes are required to high-level code, including instantiation of the Engine.

NOTE: If using one of the MMI sample projects, the Library is already installed.

Table 2-1: Mitsubishi PLC TCP/IP Library Options

Library Description

MMI_TCP_Lib_Integrated_Rev1_7_3.sul MMI Engine for Q or L CPU with built in Ethernet.

MMI_TCP_Lib_Q_External_Rev1_7_3.sul*

* Library for the L External Ethernet PLC will be available in 2015.

MMI Engine for Q CPU with external Ethernet module.




2. From the Project tab in the main menu, select Library, then select Install....

The Import Library to Project dialog is opened.

3. Select Browse.

The Open Library dialog is opened.

A. Browse to the appropriate location, select the Library (*.sul), and select Open.

The Open Library dialog is closed and the library name and path are entered into the Import Library to Project dialog.

4. Select OK.

The selected Library is installed.

Configure the Engine

The Engine converts GX Works2 function blocks to messages in the MMI TCP/IP protocol and queues them for transmission to the HLC in the Send Queue Memory. The Engine also receives messages in the MMI TCP/IP protocol and updates the Status Memory based on the contents of those messages.

To use the MMI Engine, create a Program Block in the POU (Program Organization Unit) section of the Project. This program should be the main program, which will initialize and refresh the Engine and call the transport system control programs.

NOTE: Instantiate only one instance of the MMI Engine.


2. Create a program that executes the following:

• Locally defines all Engine parameters or writes the Engine parameters as global labels.

• Initializes the Engine by either using the previously defined parameters or passing in the previously defined global labels.

NOTE: This instance of the MMI Engine creates and manages the TCP con-nection with the HLC. It must be executed every scan to ensure reli-able results.

• Call the main transport system control program.

Configure the Status Memory

Status Memory is used to store status data from the transport system. This memory is updated by the MMI Engine based on messages from the HLC. This memory is stored in a series of Global Variables configured by the user. All Global Variable names must match the specific names defined in Protocol and Structured Data Type Reference on page 4-1.



The Status Memory is allocated in a Global Label List to ensure it is accessible to the user’s program and available to the MMI Engine.

NOTE: The Status Memory must be treated as Read-Only. To ensure proper operation, only the MMI Engine should write to the Status Memory.


2. In the previously created program (POU):

A. Either create a Global Label List, or utilize an existing Global Label list (e.g., import MMI_Data_Globals.csv from MagneMotion’s Mitsubishi PLC TCP/IP Library).

B. In the Global Label List insert variables as shown below. Device labels can be assigned by the user, or assigned using the default assignment provided by GX Works2.

• Class: VAR_GLOBAL.

• Label Name: As defined in Protocol and Structured Data Type Refer-ence on page 4-1.

• Data type: as defined in Protocol and Structured Data Type Reference on page 4-1.

For the following SDTs, the SDT must specify the same range for the array as specified in the Node Configuration File (refer to the MagneMover® LITE Configurator User’s Manual or the QuickStick® Configurator User’s Manual).

• MMI_node_command_status, MMI_node_status.

• MMI_node_controller_status.

• MMI_path_status, MMI_path_command_status, MMI_motor_status.

• MMI_vehicle_order_status, MMI_vehicle_status.

Send Queue Memory

The Send Queue Memory is used to store messages that will be sent to the HLC in the trans-port system during the next scan. This memory is updated by the MMI Engine based on exe-cution of function blocks in the user’s logic. This memory is stored in a common Structured Data Type (SDT) called sdt_send_queue and is allocated in the MagneMotion Library’s Global Label List.

NOTE: Any unsent messages in the Send Queue are discarded if the connection to the HLC is disconnected.


Transport System ControlRunning the Transport System

Running the Transport System

This section describes how to control and monitor the transport system. This includes ensur-ing that all components of the transport system have been started properly so they are ready to move the vehicles, all vehicles on the transport system are identified, moving vehicles as required, and stopping and restarting all motion on the transport system.

Basic Operation Overview

1. Power up the various parts of the transport system (Host Controller, Node Controllers, Motors, etc.).

2. Connect the PLC to the Node Controller running as the High Level Controller for the transport system (refer to Connecting to the Transport System on page 2-2).

3. Start the application on the PLC that contains MagneMotion’s Mitsubishi PLC TCP/IP Library with the MMI Engine instantiated.

4. Establish communications from the PLC to the HLC. This is done automatically when power is turned on to both the PLC and the Node Controller if the PLC has been con-figured to connect to the HLC (refer to MMI_Engine on page 4-27).

5. Get the initial status of the transport system (refer to MMI_HLC_status on page 4-33, and MMI_node_controller_status on page 4-44).

6. Ensure that all Node Controllers in the system are in the operational state. This can take over a minute in very large systems or on long paths.

7. Reset all Paths in the transport system (refer to Reset on page 2-19).

The HLC sends status messages for each Path indicating that the command was received and an additional status message indicating that the reset either completed or failed, and if it failed the reason for the failure. The MMI Engine receives the mes-sages and then updates the MMI_path_command_status and MMI_path_status mem-ory in the PLC for each Path.

8. Start all Paths in the transport system (refer to Startup on page 2-22).

The HLC sends a status message for each Path indicating that the command was received and an additional status message indicating that the startup either completed or failed, and if it failed the reason for the failure. The MMI Engine receives the mes-sages and then updates the MMI_path_command_status and MMI_path_status mem-ory in the PLC for each Path.

9. Send Vehicle Order messages to the HLC to move the vehicles to their start-up loca-tions (refer to Ordering Vehicle Movement on page 2-16).

10. Send Vehicle Order messages to the HLC to move the vehicles as required (refer to Ordering Vehicle Movement on page 2-16).

The HLC sends a status message for each movement command indicating that the command was received and an additional status message indicating that the movement



either completed or failed, and if it failed the reason for the failure. The MMI Engine receives the messages and then updates the MMI_vehicle_order_status and MMI_vehicle_status memory for each vehicle. The MMI Engine also updates the MMI_path_status and MMI_node_status memory for each Path and Node as the vehicle moves through the Paths and Nodes.

11. Send status request messages to the HLC, or establish status polling rates using the MMI Engine, and review the MMI_node_status and MMI_path_status memory to ver-ify the status of the transport system (refer to Monitoring Transport System Status on page 2-31).

The HLC sends status messages as requested. The MMI Engine receives the messages and then updates the appropriate memory locations.

12. Optionally, stop motion on specific Paths in the transport system as required (refer to Suspend on page 2-25).

13. Optionally, restart motion on suspended Paths as required (refer to Resume on page 2-28).

14. Shut down the transport system for service or when not being used (refer to Shutting Down the Transport System on page 2-50).

Response and Status Updates

The MagneMotion transport systems provide a large amount of feedback. This feedback falls into two categories, response and status as described below.

A response is sent without user prompting when specific events occur within the transport system. The most common response is a command status response (i.e, completion of either vehicle movement, startup, or reset, refer to MMI_vehicle_order_status and MMI_path_command_status). This response is sent when a command is received and processed by the HLC and again when that command completes. Responses are the cornerstone of the transport system architecture. The MMI_vehicle_order_status and MMI_path_command_status arrays are updated by the Engine upon receipt of a status response.

The status memory SDTs provide information on the current state of elements within the transport system. These include the vehicles (refer to MMI_vehicle_status), Paths (refer to MMI_path_status), Node Controllers (refer to MMI_node_controller_status), and individual motors (refer to MMI_motor_status). These memory labels are updated as specified by the appropriate poll rate inputs to the Engine or when requested using the MMI_B5_StatusRequest function block.

Ordering Vehicle Movement

The control software in the transport system uses a “fire and forget” logic that allows to user to issue a command to move a vehicle and then be notified of the vehicle’s arrival at its desti-nation with no need to monitor the vehicle during the actual movement. The typical command sequence is shown in Figure 2-10 and described after the figure. Refer to Moving Vehicles on page 2-36 for detailed examples of vehicle movement.



Figure 2-10: Vehicle Command Sequence

1. Store a copy of the current Vehicle Order Number (refer to LastOrderRcv_Num in MMI_vehicle_order_status).

2. Execute the appropriate vehicle function block (refer to MMI_B0_MoveVehicleToSta-tion, MMI_B1_MoveVehicleToPosition, or MMI_B9_DeleteVehicle).

3. Store the new the Vehicle Order Number and compare it against the previously stored Vehicle Order Number (from Step 1) to verify the Order was received (refer to LastOrderRcv_Num). Order number is incremented by one over value from Step 1.

4. Check the status for the new Vehicle Order Number (from Step 3) to verify the Order was accepted (refer to LastOrderRcv_Status). Order status value is 0x00.

5. Check the status for the Vehicle Order Number to verify the Order was completed (refer to LastOrderAcc_Status). Order status value is 0x80.

Store Previous Vehicle Order Number

Store New Vehicle Order Number and Verify Order Received

Check Vehicle Order Status to verify Order accepted

Check Vehicle Order Status to verify Order completed

Execute Vehicle Move Function



Transport System Control Examples

Most examples provided in this section reference the simplified transport system layout shown in Figure 2-11.

Figure 2-11: Merge/Diverge Transport System for Examples

Path 3

Path 4

Path 1

Path 2

Node 2

Node 3

Forward(Downstream)

Forward(Downstream)

1

2

Relay Node

Diverge Node

Guideway

Vehicle

Node 1Merge Node

Station 1(0.750)

Station 2(1.250)

3

4

NC 1HLC

NC 2 NC 3



Transport System Startup and Reset

This section describes how to start, or restart the basic components of the transport system during initial startup or when returning it to service using the function blocks provided with MagneMotion’s Mitsubishi PLC TCP/IP Library. Note that motion can not be started if Sus-pend is active (E-Stop or Interlock is On). All examples provided reference Figure 2-11.

NOTE: The numeric formats shown in the examples are used for clarity in the documenta-tion, the actual formats must be specified in GX Works2.

Reset

Use the MMI_B8_Reset function block to issue a Reset command to reset the motors on the specified Paths and to reset all motors on all Paths when a new Node Configuration File has been uploaded to the Node Controllers.

All Paths

To reset all Paths, use the MMI_B8_Reset function block with the wPathID input set to ‘0’.

The Engine updates the MMI_path_command_status array for each Path with the command status for that Path returned by the HLC (the table represents the MMI_path_command_status array and each column identifies a Path and indicates the com-mand status).

wPathID 0

array_index 1 2 3 4

Sent_Count 37844 36245 32130 34191

Received_Count 37844 36245 32130 34191

Accepted_Count 37843 36244 32129 34190

LastCmdRcv 0xB8 0xB8 0xB8 0xB8

LastCmdRcv_Status 0x00 0x00 0x00 0x00

LastCmdAcc 0xB8 0xB8 0xB8 0xB8

LastCmdAcc_Status 0x00 0x00 0x00 0x00



The Engine also updates the MMI_path_status array for each Path with the current sta-tus for that Path returned by the HLC (the table represents the MMI_path_status array and each column identifies a Path and indicates the current status).

Once the reset is complete, the Engine updates the MMI_path_command_status array for each Path with the results of the reset returned by the HLC (completed success-fully).


array_index 1 2 3 4

UpdateCount 57309 57309 57309 57309

Present 1 1 1 1

NumVehicles 0 0 0 0

PathState 3 3 3 3

PathMoveStatus 0000_0000 0000_0000 0000_0000 0000_0000

UpstreamCommStatus 0 0 0 0

DownstreamCommStatus 0 0 0 0

array_index 1 2 3 4

Sent_Count 37844 36245 32130 34191

Received_Count 37844 36245 32130 34191

Accepted_Count 37844 36245 32130 34191





array_index 1 2 3 4

UpdateCount 57310 57310 57310 57310

Present 1 1 1 1

NumVehicles 0 0 0 0

PathState 0 0 0 0



Specific Path

To reset a specific Path (e.g., #1), use the MMI_B8_Reset function block with the wPathID input set to the ID of the specific Path.

The Engine updates the MMI_path_command_status array for the specific Path with the command status for that Path returned by the HLC. The Engine also updates the MMI_path_status array for the Path with the current status for that Path returned by the HLC.

Once the reset is complete, the Engine updates the MMI_path_command_status array for that Path with the results of the reset command returned by the HLC. The Engine also updates the MMI_path_status array for the Path with the current status for that Path returned by the HLC.

PathMoveStatus 0000_0000 0000_0000 0000_0000 0000_0000



wPathID 1

array_index 1 2 3 4



Startup

Use the MMI_B2_Startup function block to issue a Startup command when first connecting to a High Level Controller, after cycling power to the transport system, after resetting the HLC, after resetting Path(s), or to locate all vehicles on the transport system. Note that Paths can not be started if Suspend is active (E-Stop or Interlock is On).

All Paths

To startup all Paths, use the MMI_B2_Startup function block with the wPathID input set to ‘0’.



wPathID 0

array_index 1 2 3 4

Sent_Count 37845 36246 32131 34192

Received_Count 37845 36246 32131 34192

Accepted_Count 37844 36245 32130 34191





array_index 1 2 3 4

UpdateCount 57311 57311 57311 57311

Present 1 1 1 1

NumVehicles 0 0 0 0

PathState 1 1 1 1

PathMoveStatus 0000_0000 0000_0000 0000_0000 0000_0000



Once the startup is complete, the Engine updates the MMI_path_command_status array for each Path with the results of the reset returned by the HLC (completed suc-cessfully).




array_index 1 2 3 4

Sent_Count 37846 36246 32131 34192

Received_Count 37846 36246 32131 34192

Accepted_Count 37846 36246 32131 34192





array_index 1 2 3 4

UpdateCount 57312 57312 57312 57312

Present 1 1 1 1

NumVehicles 2 0 2 0

PathState 2 2 2 2

PathMoveStatus 0000_0000 0000_0000 0000_0000 0000_0000



array_index 1 2 3 4



Specific Path

To startup a specific Path (e.g., #1), use the MMI_B2_Startup function block with the wPathID input set to the ID of the specific Path.


Once the startup is complete, the Engine updates the MMI_path_command_status array for that Path with the results of the startup command returned by the HLC. The Engine also updates the MMI_path_status array for the Path with the current status for that Path returned by the HLC.

wPathID 1



Suspend

Use the MMI_B4_SuspendMovement function block to issue a Suspend command to stop all vehicle motion on the specified Path(s) in the transport system and hold all vehicles in their stopped location. Note that stopping motion on one specific Path does not affect motion on other Paths unless the vehicles on those Paths are commanded to the suspended Path(s).

All Paths

To suspend movement on all Paths, use the MMI_B4_SuspendMovement function block with the wPathID input set to ‘0’.



wPathID 0

array_index 1 2 3 4

Sent_Count 37847 36248 32133 34194

Received_Count 37847 36248 32133 34194

Accepted_Count 37846 36247 32132 34193





array_index 1 2 3 4

UpdateCount 57313 57313 57313 57313

Present 1 1 1 1

NumVehicles 2 0 2 0

PathState 2 2 2 2

PathMoveStatus 0000_0000 0000_0000 0000_0000 0000_0000



Once the suspension is complete, the Engine updates the MMI_path_command_status array for each Path with the results of the reset returned by the HLC (completed suc-cessfully).




array_index 1 2 3 4

Sent_Count 37848 36248 32133 34194

Received_Count 37848 36248 32133 34194

Accepted_Count 37848 36248 32133 34194





array_index 1 2 3 4

UpdateCount 57313 57313 57313 57313

Present 1 1 1 1

NumVehicles 2 0 2 0

PathState 2 2 2 2

PathMoveStatus 0000_0001 0000_0001 0000_0001 0000_0001



array_index 1 2 3 4



Specific Path

To suspend movement on a specific Path (e.g., #1), use MMI_B4_SuspendMovement function block with the wPathID input set to the ID of the specific Path.


Once the suspension is complete (all motion stopped), the Engine updates the MMI_path_command_status array for that Path with the results of the suspend command returned by the HLC. The Engine also updates the MMI_path_status array for the Path with the current status for that Path returned by the HLC.

wPathID 1



Resume

Use the MMI_B3_ResumeMovement function block to issue a Resume command to start vehi-cle motion on the specified Path(s) after a Suspend command or after an Emergency Stop (E-Stop) was issued and the E-Stop button has been manually reset. All vehicles will resume motion based on all currently active movement commands.

All Paths

To resume movement on all Paths, use the MMI_B3_ResumeMovement function block with the wPathID input set to ‘0’.



wPathID 0

array_index 1 2 3 4

Sent_Count 37849 36250 32135 34196

Received_Count 37849 36250 32135 34196

Accepted_Count 37848 36249 32134 34195





array_index 1 2 3 4

UpdateCount 57314 57314 57314 57314

Present 1 1 1 1

NumVehicles 2 0 2 0

PathState 2 2 2 2

PathMoveStatus 0000_0001 0000_0001 0000_0001 0000_0001



Once the resume is complete, the Engine updates the MMI_path_command_status array for each Path with the results of the reset returned by the HLC (completed suc-cessfully).




array_index 1 2 3 4

Sent_Count 37849 36250 32135 34196

Received_Count 37849 36250 32135 34196

Accepted_Count 37849 36250 32135 34196





array_index 1 2 3 4

UpdateCount 57315 57315 57315 57315

Present 1 1 1 1

NumVehicles 2 0 2 0

PathState 2 2 2 2

PathMoveStatus 0000_0000 0000_0000 0000_0000 0000_0000



array_index 1 2 3 4



Specific Path

To resume movement on a specific Path (e.g., #1), use the MMI_B3_ResumeMovement function block with the wPathID input set to the ID of the specific Path.


Once the resume is complete (all motion enabled and any previously commanded motion resumed), the Engine updates the MMI_path_command_status array for that Path with the results of the resume command returned by the HLC. The Engine also updates the MMI_path_status array for the Path with the current status for that Path returned by the HLC.

wPathID 1



Monitoring Transport System Status

This section describes how to monitor the basic components of the transport system. All examples provided reference Figure 2-11.

1. Connect to the High Level Controller for the transport system (refer to Connecting to the Transport System on page 2-2).

2. Using the Host Controller, examine the status array for the type of status being requested.

High Level Controller

To check the status of the High Level Controller examine the MMI_HLC_status SDT. The example below indicates that the High Level Controller is present and operational.

Node Controllers

To check the status of any Node Controller request the appropriate index from the MMI_node_controller_status SDT. The example below indicates that the Node Controllers are pres-ent and operational.

UpdateCount 2135

HLCState 3

ENetStatus 0

HLCConnectedStatus 1

SendError –*

* Error code from the Mitsubishi PLC.

ReceiveError –*

node_controller_index 1 2 3

UpdateCount 3465 3453 3652

Present 1 1 1

State 3 3 3



Nodes

To check the status of any Node request the appropriate index from the MMI_node_status SDT. The example below indicates that all Nodes are present, the type of the Nodes, that there are no vehicles in the Nodes, and that the switches are in their last requested position and operational.

Paths

To check the status of any Path request the appropriate index from the MMI_path_status SDT. The example below indicates that all Paths are present and operational, the number of vehicles on the Path, and that all communications is OK.

node_index 1 2 3

UpdateCount 21921 24841 18474

Present 1 1 1

NodeType 1 2 0

VehicleID 0 0 0

RequestedPosition 1 1 0

TerminusSignals 0 0 0

ReportedPosition 1 1 0

DeviceStatus 3 3 0

path_index 1 2 3 4

UpdateCount 63815 60814 64191 61397

Present 1 1 1 1

NumVehicles 2 0 2 0

PathState 2 2 2 2

PathMoveStatus 0 0 0 0





Vehicles

To check the status of any vehicle request the appropriate index from the MMI_vehicle_status SDT. The example below indicates that there are 4 vehicles present, the Paths they are on, that they are not moving, their position on the Paths, and that they are detected on the motor.

vehicle_index 1 2 3 4

UpdateCount 45730 45750 45680 45695

Present 1 1 1 1

PathID 1 1 3 3

DestPathID 0 0 0 0

Position 0.89 2.69 0.50 0.75

Velocity 0 0 0 0

Command 0x00 0x00 0x00 0x00

Flags 0000_0001 0000_0001 0000_0001 0000_0001

CommandedPosition 0.89 2.69 0.50 0.75

DestStationID 0 0 0 0



Motors

MagneMover LITE

To check the status of any MagneMover LITE motor request the appropriate index from the MMI_motor_status SDT (Path 2 shown). The example below indicates that there are 3 motors on the Path, communication is operating properly, and that there are no faults on any of the motors.

QuickStick

To check the status of any QuickStick motor request the appropriate index from the MMI_MMI_motor_status SDT (Path 2 shown). The example below indicates that there are 3 motors on the Path, communication is operating properly, and that there are no faults on any of the motors.

motor_index (Path 2) 1 2 3

UpdateCount 22181 22234 22178

PathPresent 1 1 1

MotorPresent 1 1 1

MotorType 2 2 2

NumBlocks_DriverBoards 1 1 1

SchedulerErrors 0000_0000 0000_0000 0000_0000

UpstreamComms 0000_0000 0000_0000 0000_0000

DownstreamComms 0000_0000 0000_0000 0000_0000

MotorOverall 0000_0000 0000_0000 0000_0000

MotorFaultData [0] 0000_0000 0000_0000 0000_0000

.

.

....

.

.

....

MotorFaultData [3] 0000_0000 0000_0000 0000_0000


UpdateCount 22181 22234 22178

PathPresent 1 1 1

MotorPresent 1 1 1

MotorType 1 1 1

NumBlocks_DriverBoards 5 5 5



SchedulerErrors 0000_0000 0000_0000 0000_0000

UpstreamComms 0000_0000 0000_0000 0000_0000

DownstreamComms 0000_0000 0000_0000 0000_0000

MotorOverall 0000_0000 0000_0000 0000_0000

MotorFaultData [0] 0000_0000 0000_0000 0000_0000

.

.

....

.

.

....

MotorFaultData [9] 0000_0000 0000_0000 0000_0000




Moving Vehicles

This section describes how to move vehicles in the transport system. To move a vehicle a des-tination must be provided as either a Position on a Path or as a pre-defined Station.

NOTE: If the Acceleration or Velocity values in a Move command are higher than the limit set in the Configuration File, the command is rejected by the HLC.

If the Acceleration or Velocity values are higher than the values for a specific motor, the value is overridden by the motor value while the vehicle is on that motor.

If a Move command is issued to a vehicle already moving and the command has a lower Acceleration than the previous command to that vehicle the command is rejected.

The numeric formats shown in the examples are used for clarity in the documenta-tion, the actual formats must be specified in GX Works2.

Direction of Movement

Vehicles can be moved either forward or backward on the transport system’s guideway. The direction of motion for a movement command is typically specified to ensure the vehicle moves as expected. Note that when bidirectional movement is specified it only applies to the initial selection of direction by the transport system, the vehicle does not change direction dur-ing its move.

Figure 2-12: Transport System for Motion Examples

Forward – Vehicles move downstream only, useful to implement a unidirectional loop. If the destination is not reachable (due to the Paths not forming a loop), the vehicle will not move.

Path 3

Path 4

Path 1

Path 2

Node 2

Node 3

Forward(Downstream)

1

2

Guideway

Vehicle

Node 1

0m 1.25m

1.75m 0m

.75m

1.5m0m Relay Node

Diverge Node

Merge Node

0m



Examples:

1. For Vehicle 1 in Figure 2-12 to reach the beginning of Path 3 it will move from Path 3 to Path 4, from Path 4 to Path 1, then from Path 1 to Path 3. Note that Vehicle 2 must move out of the way for Vehicle 1 to complete its motion.

2. For Vehicle 1 in Figure 2-12 to reach the beginning of Path 2 it will move from Path 3 to Path 4, from Path 4 to Path 1, then from Path 1 to Path 2. Note that Vehicle 2 must move out of the way for Vehicle 1 to complete its motion.

Backward – Vehicles move upstream only, useful to implement a unidirectional loop in the backwards direction. If the destination is not reachable (due to the Paths not forming a loop), the vehicle will not move.

Examples:

1. For Vehicle 1 in Figure 2-12 to reach the beginning of Path 3 it will move directly to that position.

2. For Vehicle 1 in Figure 2-12 to reach the beginning of Path 2 it will move from Path 3 to Path 1, from Path 1 to Path 2, then to the beginning of Path 2. Note that Vehicle 2 must move out of the way for Vehicle 1 to complete its motion.

Bidirectional – Vehicles can move either direction required to get to the destination in the shortest distance. Once movement is initiated, it will continue in that direction. If the destina-tion is on a Path other than the Path the vehicle is currently on, the forward direction takes pre-cedence for a transport system that is a closed loop.

Examples:

1. For Vehicle 1 in Figure 2-12 to reach the beginning of Path 3 it will move backwards directly to that position.

2. For Vehicle 1 in Figure 2-12 to reach the beginning of Path 2 it will move for-ward from Path 3 to Path 4, from Path 4 to Path 1, then from Path 1 to Path 2. Note that Vehicle 2 must move out of the way for Vehicle 1 to complete its motion.

Note that once the vehicle starts moving in a specific direction it does not change direction.



Move to Position

Use the MMI_B1_MoveVehicleToPosition function block to move a vehicle to a position on a specific Path using the defined direction of movement, acceleration/deceleration, velocity, and PID set.

To move the unloaded Vehicle 1 in Figure 2-12 forward to the beginning of Path 3, set the inputs to the MMI_B1_MoveVehicleToPosition function block as shown below. Note that Vehicle 2 must move out of the way for Vehicle 1 to complete its motion.

The HLC updates the MMI_vehicle_order_status array for the vehicle indicating the com-mand status for that vehicle.

If a polling rate is set for the Engine, the Engine updates the MMI_vehicle_status array at the specified update rate, which provides ongoing status for the vehicle.

wVehicleID 1

wDirection 1

wPIDSetIndex 0

rPosition 0.0

wPathID 3

rAccelDecel 1.0

rVelocity 1.0

VehicleID (array index) 1 2

LastOrderRcv_Num 181 n/a

LastOrderRcv_Type 0xB1 n/a

LastOrderRcv_Status 0x00 n/a

LastOrderAcc_Num 180 n/a

LastOrderAcc_Type 0xB1 n/a

LastOrderAcc_Status 0x00 n/a


UpdateCount 13415 n/a

Present 1 n/a

PathID 3 n/a

DestPathID 3 n/a



Once the movement is complete the HLC updates the MMI_vehicle_order_status array for the vehicle showing the movement was completed.

Position 1.027 n/a

Velocity 0.73 n/a

Command 0xB1 n/a

Flags 0000_0001 n/a

CommandedPosition 0.0 n/a

DestStationID 0 n/a











Move to Station

Use the MMI_B0_MoveVehicleToStation command to move a vehicle to a predefined station using the defined direction of movement, acceleration/deceleration, velocity, and PID set.

To move the unloaded Vehicle 1 in Figure 2-12 forward to Station 1 (at the beginning of Path 3), set the inputs to the MMI_B0_MoveVehicleToStation function block as shown below. Note that Vehicle 2 must move out of the way for Vehicle 1 to complete its motion.

The HLC updates the MMI_vehicle_order_status array for the vehicle indicating the com-mand status for that vehicle.

If a polling rate is set for the Engine, the Engine updates the MMI_vehicle_status array at the specified update rate, which provides ongoing status for the vehicle.

wVehicleID 1

wDirection 1

wPIDSetIndex 0

wStationID 1

rAccelDecel 1.0

rVelocity 1.0









UpdateCount 19655 n/a

Present 1 n/a

PathID 3 n/a

DestPathID 3 n/a

Position 1.027 n/a

Velocity 0.73 n/a



Once the movement is complete the HLC updates the MMI_vehicle_order_status array for the vehicle showing the movement was completed.

Command 0xB1 n/a

Flags 0000_0001 n/a

CommandedPosition 0.0 n/a

DestStationID 1 n/a










Transport System ControlEntering or Exiting Through a Terminus Node

Entering or Exiting Through a Terminus Node

This section describes how to move a vehicle on or off the transport system. Any vehicle entering or exiting the transport system must move through a Terminus Node, which allows vehicles to move on or off of a Path from equipment separate from the MagneMotion trans-port system or from one MagneMotion transport system to another. Refer to Movement Through a Terminus Node on page 3-17 for a description of all handshaking.

NOTE: Either the Engine must be set to poll node status, or the MMI_B5_StatusRequest function block must be used to update the Terminus Node status.


Vehicle Entry onto the Transport System

Figure 2-13: Terminus Node Entry Example

1. The Host Controller checks the status of the Terminus Node (refer to Figure 2-13) by referencing the appropriate index from the MMI_node_status array. The status shows the Node is clear for vehicle insertion (ENTRY_CLEAR = High, all other bits = Low).

node_index 5

UpdateCount 57563

Present 1

NodeType 4

VehicleID 0

RequestedPosition 0

TerminusSignals 0001_0000

ReportedPosition 0

DeviceStatus 0

Motor2m1m

3m

Vehicle

MagneMotion Transport System User’s Equipment

Motor

User’s Guideway

3.25m

Terminus Node(Node Type 4)Node ID = 5

Path 1Forward

(Downstream)



2. The Host Controller sets the ENTRY_REQUESTED signal High for the Terminus Node by setting the inputs to the MMI_B6_SetEntrySignal function block to indicate there is a vehicle on the user’s equipment ready to enter the transport system and to have the transport system assign a vehicle ID as shown below.

3. The Host Controller checks the status of the Terminus Node by referencing the appro-priate index from the MMI_node_status array. The status shows the Node is ready for vehicle entry (ENTRY_CLEAR = Low, ENTRY_ALLOWED = High, and ENTRY_REQUESTED = High).

4. The user’s equipment inserts the vehicle onto the Path at the Terminus Node and the Host Controller sets the ENTRY_REQUESTED signal low and requests the transport system to assign a vehicle ID by setting the inputs to the MMI_B6_SetEntrySignal function block as shown below.

5. The Host Controller checks the status of the Terminus Node by referencing the appro-priate index from the MMI_node_status array. The status provides the VehicleID assigned by the transport system and shows the Node is clear (ENTRY_CLEAR = Low, ENTRY_ALLOWED = High, and ENTRY_REQUESTED = High).

wNodeID 5

bSignalLevel TRUE

wVehicleID 0

node_index 5

UpdateCount 57564

Present 1

NodeType 4

VehicleID 0

RequestedPosition 0


ReportedPosition 0

DeviceStatus 0

wNodeID 5

bSignalLevel FALSE

wVehicleID 0



6. The Host Controller moves the vehicle out of the Terminus Node by setting the inputs to the MMI_B1_MoveVehicleToPosition function block to move the vehicle upstream to a position on the Path using the Vehicle ID previously assigned.

7. While the vehicle is moving through the Node the Host Controller checks the status of the Terminus Node by referencing the appropriate index from the MMI_node_status array. The status shows the Node is clear (ENTRY_CLEAR = Low, ENTRY_ALLOWED = High, and ENTRY_REQUESTED = Low).

node_index 5

UpdateCount 57565

Present 1

NodeType 4

VehicleID 3

RequestedPosition 0


ReportedPosition 0

DeviceStatus 0

wVehicleID 3

wDirection 2

wPIDSetIndex 0

rPosition 2.5

wPathID 1

rAccelDecel 1.0

rVelocity 1.0

node_index 5

UpdateCount 57566

Present 1

NodeType 4

VehicleID 0

RequestedPosition 0



8. If a polling rate is set for the Engine, the Engine updates the MMI_vehicle_status array at the specified update rate, which shows the vehicle has completed its movement.


ReportedPosition 0

DeviceStatus 0

VehicleID (array index) 3

UpdateCount 19535

Present 1

PathID 1

DestPathID 0

Position 2.5

Velocity 0

Command 0x00

Flags 0000_0001

CommandedPosition 0

DestStationID 0

node_index 5



Vehicle Exit from the Transport System

Figure 2-14: Terminus Node Exit Example

1. The Host Controller checks the status of the Terminus Node (refer to Figure 2-14) by referencing the appropriate index from the MMI_node_status array. The status shows the Node is clear for vehicle exit (ENTRY_CLEAR = High, all other bits = Low).

2. The Host Controller sets the EXIT_ALLOWED signal High for the Terminus Node by setting the inputs to the MMI_B6_SetExitSignal function block to indicate there is space on the user’s equipment for a vehicle as shown below.

3. The Host Controller checks the status of the Terminus Node by referencing the appro-priate index from the MMI_node_status array. The status shows the Node is clear for vehicle exit (ENTRY_CLEAR = High, EXIT_ALLOWED = High, all other bits = Low).

node_index 5

UpdateCount 57183

Present 1

NodeType 4

VehicleID 0

RequestedPosition 0


ReportedPosition 0

DeviceStatus 0

wNodeID 5

bSignalLevel TRUE

Motor2m1m

3m

Vehicle


Motor

User’s Guideway

3.25m

Terminus Node(Node Type 4)Node ID = 5

Path 1Forward

(Downstream)



4. The Host Controller moves the vehicle off of the transport system through the Termi-nus Node by setting the inputs to the MMI_B1_MoveVehicleToPosition function block to move the vehicle downstream to a position past the end of the Path as shown below.

5. While the vehicle is moving the Host Controller checks the status of the Terminus Node by referencing the appropriate index from the MMI_node_status array. The sta-tus shows vehicle #3 in the Node, EXIT_ALLOWED = High, and EXITING = High).

node_index 5

UpdateCount 57184

Present 1

NodeType 4

VehicleID 0

RequestedPosition 0


ReportedPosition 0

DeviceStatus 0

wVehicleID 3

wDirection 1

wPIDSetIndex 0

rPosition 3.25

wPathID 1

rAccelDecel 1.0

rVelocity 1.0

node_index 5

UpdateCount 57185

Present 1

NodeType 4

VehicleID 3

RequestedPosition 3.25


ReportedPosition 3.0

DeviceStatus 0



6. The Host Controller sets the EXIT_ALLOWED signal Low by setting the inputs to the MMI_B6_SetExitSignal function block as shown below.

7. If a polling rate is set for the Engine, the Engine updates the MMI_vehicle_status array at the specified update rate, which shows the vehicle has completed its movement and is no longer on the transport system.

8. Once the vehicle has been moved out of the Node and onto the user’s equipment the Host Controller checks the status of the Terminus Node by referencing the appropriate index from the MMI_node_status array. The returned status shows no vehicle in the Node, ENTRY_CLEAR = High, EXIT_ALLOWED = Low, and EXITING = Low.).

wNodeID 5

bSignalLevel FALSE

VehicleID (array index) 3

UpdateCount 2953

Present 0

PathID 1

DestPathID 0

Position 0

Velocity 0

Command 0x00

Flags 0000_0000

CommandedPosition 0

DestStationID 0

node_index 5

UpdateCount 57186

Present 1

NodeType 4

VehicleID 0

RequestedPosition 0


ReportedPosition 0

DeviceStatus 0


Transport System ControlShutting Down the Transport System

Shutting Down the Transport System

Whenever the MagneMotion transport system is being shut down it is important to ensure that the system is stopped, and powered down, correctly.

1. Suspend motion on all Paths using the MMI_B4_SuspendMovement function block, which causes all vehicles to come to a controlled stop (refer to Suspend on page 2-25).

2. Once all motion has stopped, issue a Reset for all Paths using the MMI_B8_Reset function block, which will clear all vehicle records (refer to Reset on page 2-19).

3. Turn off power to the motors.

4. Turn off power to the Node Controllers.

5. Turn off power to the Host Controller.


Transport System Control



Application Notes 3

Overview

This chapter provides examples and step-by-step procedures related to specific tasks using MagneMotion motors in a transport system.

Application Notes are provided for specific tasks within the operation of MagneMover® LITE and QuickStick® transport systems. These are simple step-by-step procedures and examples for each application covered. These procedures reference detailed information about the steps that is located elsewhere within this manual.

Included in this chapter are:

• Vehicle movement.

• Emergency Stop and Interlocks.

• Emergency Off.

• Moving through Switch, Shuttle, or Turntable Nodes.

• Movement through a Terminus Node, including all handshaking.

• Movement through a Gateway Node.

• Automatic Path Recovery for missing or new vehicles.

• Motor type reference.

• Node type reference.


Application NotesVehicle Movement

Vehicle Movement

All vehicles on a MagneMotion transport system are moved with a brick-wall headway between vehicles so that a safe stopping distance between vehicles is always maintained. This means that if one vehicle stops unexpectedly (e.g., an object falls on the guideway) any vehi-cle following it is able to stop without hitting the stopped vehicle. This movement profile may be overridden if required in special circumstances.

Vehicle Positioning

The location a vehicle is commanded to must allow the entire vehicle (as defined in the Con-figuration File) to remain on the transport system (over the motor). The only time any portion of a vehicle can be commanded to a location off of a motor is during vehicle insertion or removal through a Terminus Node. A vehicle commanded to a position that would cause any portion of the vehicle to leave the guideway will stop before it reaches that position to ensure no part of the vehicle leaves the guideway and it will never complete the Move command.

NOTE: Vehicle position is determined from the center of the magnet array attached to the vehicle.

Example: Commanding the 200 mm vehicle shown in Figure 3-1 to a position of 0 mm on the Path (starting at a Simple Node with no connecting Path) will cause the vehicle to stop at the 100 mm position as shown in the figure. The vehicle order never completes, and no Command Status for completion is sent as the order stays pending (the Obstructed bit in the Vehicle Sta-tus for the vehicle is set indicating that the vehicle can not move to complete the order).

Figure 3-1: Vehicle Positioning Example

Motor 1 Motor 31m0m

Motor 22m 3m

200mm

100mm

CL

Vehicle


Application NotesVehicle Movement

Safe Stopping Distance Movement

Standard vehicle control ensures vehicles always have a safe stopping distance. Figure 3-2 shows Acceleration, Velocity, and Position versus Time for the standard movement profile. Movement permission for a vehicle is granted as needed to keep a vehicle on its movement profile (solid heavy line) and provide a safe stopping distance (dashed heavy line).

Figure 3-2: Vehicle Movement Profile

Destination

Vlimit

-Alimit

+Alimit

Time

Time

Time

Pos

ition

Vel

ocity

Acc

eler

atio

n


Application NotesEmergency Stop

Emergency Stop

When using an NC-12 or Standard Node Controller, the Node Controller’s digital I/O can be connected directly to an E-Stop circuit. An E-Stop is a user installed button (typically locking) that can be pressed by an operator if an emergency situation arises to halt all motion on the specified Paths.

Initiating an E-Stop

The E-Stop is normally configured to operate through the NC-12 or Standard Node Controller, which requires no action from the Host Controller to initiate. When configured to operate through the Node Controller, the E-Stop circuit is wired into a digital input.

The E-Stop can also be configured to operate through the Host Controller, which requires the Host Controller to monitor the circuit, initiate the desired action when signaled, and initiate the recovery when signaled. Refer to Emergency Off on page 3-7.

Node Controller-based E-Stop

When the Node Controller detects that the E-Stop button is activated, it commands all Paths associated with that E-Stop to suspend vehicle movement. All motors suspend vehicle target requests and permissions and all vehicles come to a controlled stop and are held in position by the motors. Stopping time is dependent on vehicle load and stopping force available. If a poll-ing rate is set for the Engine or if a MMI_B5_StatusRequest function block issues a request, the Engine updates the MMI_path_status array for each Path showing the E-Stop is active.

NOTE: Power is not removed from the motors.

To check the status of any Path poll for the path status and inspect the appropriate index from the MMI_path_status array.

Host Controller-based E-Stop

Upon receiving an E-Stop command, the Host Controller must use the MMI_B4_Suspend-Movement function block to issue a Suspend command to the appropriate Paths. All vehicles will come to a controlled stop on the suspended Paths and are held in position by the motors. Stopping time is dependent on vehicle load and stopping force available.

CAUTION

Electrical Hazard

The E-Stop only executes the actions described, it is not thesame as an EMO (Emergency Off), which removes all powerto the transport system.


Application NotesEmergency Stop



If the E-Stop is configured so that it shuts off motor power when activated, the Host Control-ler must use the MMI_B4_SuspendMovement function block to issue a Suspend command, and then once all movement has stopped the power can be removed. Time to wait before shut-ting off power can be determined based on the Acceleration and Velocity configured for the transport system. Ensure the vehicles have sufficient time to come to a controlled stop.

• If only the motor propulsion power is shut off (motor logic and motor propulsion power must be wired separately), polling the MMI_path_status array will show an ‘Under-Voltage’ fault. When power is restored the fault is cleared.

• If both motor propulsion power and motor logic power are shut off, polling the MMI_path_status array will show a ‘Motor Not Responding’ fault. When power is restored the fault is cleared.

Recovering from an E-Stop

Once the events that necessitated the E-Stop have been resolved motion can be restarted. Note that to ensure proper startup the E-Stop must be cleared by releasing the button that was pressed.

Node Controller-based E-Stop

Once the E-Stop button is released the Host Controller must use the MMI_B3_ResumeMove-ment function block to issue a Resume command to the Paths that were suspended by the E-Stop. All vehicles on those Paths will resume motion based on all currently active move-ment commands.

NOTE: To check the status of any Path poll for the path status and inspect the appropriate index from the MMI_path_status array.

Host Controller-based E-Stop

If power was not removed from the motors, once the E-Stop button is released the Host Con-troller must use the MMI_B3_ResumeMovement function block to issue a Resume command to the Paths that were suspended by the Suspend command. All vehicles on those Paths will resume motion based on the currently active movement commands.

If power was removed from the motors:

• If only the motor propulsion power was shut off, once power is restored all vehicles on those Paths will resume motion based on all currently active movement commands.

• If both motor propulsion and motor logic power were shut off, once power is restored the motors must be restarted as described in Startup on page 2-22.


Application NotesInterlock

Interlock

When using an NC-12 or Standard Node Controller, the Node Controller’s digital I/O can be connected directly to an Interlock circuit. An Interlock is a user installed circuit that can be activated by another piece of equipment in the facility to temporarily halt all motion on the specified Paths.

Initiating an Interlock

When the Node Controller detects that the Interlock circuit is activated, it commands all Paths associated with that Interlock to suspend vehicle movement. All motors suspend vehicle target requests and permissions and all vehicles come to a controlled stop and are held in position by the motors. Stopping time is dependent on vehicle load and stopping force available. If a poll-ing rate is set for the Engine or if a MMI_B5_StatusRequest function block issues a request, the Engine updates the MMI_path_status array for each Path showing the E-Stop is active.



Recovering from an Interlock

Once the events that necessitated the Interlock have been resolved motion can be restarted by deactivating the Interlock signal.


Application NotesEmergency Off

Emergency Off

The equipment that uses a MagneMotion transport system may have an Emergency Off (EMO) circuit installed and configured by the user. This typically includes a locking EMO button configured such that pressing it will remove all power to the transport system (includ-ing power to the Node Controllers and possibly to the Host Controller).

Initiating an EMO

Upon loss of power all vehicles will slow to a stop. The amount of time it takes to stop is dependent on vehicle load and friction in the vehicle guideway.

Recovering from an EMO

Once the events that necessitated the EMO have been resolved the transport system can be restarted (refer to Startup on page 2-22). Note that to ensure proper startup the EMO must be cleared by releasing the button that was pressed before restarting the transport system.


Application NotesMovement Through a Switch, Shuttle, or Turntable

Movement Through a Switch, Shuttle, or Turntable

Switches, shuttles, and turntables allow a vehicle to move from the Path it is on to a different Path through a switching mechanism. In all cases, when movement from one Path to another Path is in the same direction (e.g., movement on all Paths is forward, or downstream, on each Path) no special considerations are required and the Node Controller manages control of the switching mechanism. When movement from one Path to another Path is not in the same direction (e.g., movement on one Path is forward, or downstream, and movement on the other Path is backward, or upstream) the movement must be configured as a pair of moves where each move is in only one direction.

NOTE: Even if a Move command is configured as bidirectional two moves are required as a vehicle can not change direction in the middle of a move.


Switch

A switch Node is used to enable vehicles to move from one Path to another. Switches are con-figured as either a Merge or a Diverge. The Paths in a Merge Node are referred to as Straight Entry, Curve Entry, and Merged Exit as shown in Figure 3-3. The Paths in a Diverge Node are referred to as Single Entry, Straight Exit, and Curve Exit as shown in Figure 3-4.

Forward Through a Merge Switch

Figure 3-3: Merge Switch Movement

Forward motion through a Merge switch (e.g., Path 1 or Path 3 to Path 2 as shown in Fig-ure 3-3) requires no special consideration and can be configured as a standard move from either of the Entry Paths to the Exit Path where motion can continue forwards (the table repre-sents the inputs to the MMI_B1_MoveVehicleToPosition function block).

Forward(Downstream)

Forward(Downstream)Path 2

Path 3

Straight Entry Path Ends(Path 1)

Merged Exit Path Begins(Path 2)

Path 1

Curve Entry Path Ends(Path 3)

Forward(Downstream)



Backward Through a Merge Switch

Backward motion through a Merge switch (e.g., Path 2 to Path 1 or Path 3 as shown in Fig-ure 3-3) requires no special consideration and can be configured as a standard move from the Exit Path to either of the Entry Paths where motion can continue backwards (the table repre-sents the inputs to the MMI_B3_ResumeMovement function block).

Reversing Through a Merge Switch

Reversing direction through a Merge switch (e.g., Path 1 to Path 3 as shown in Figure 3-3) requires two moves. The first move is forward from Path 1 to Path 2 and the second move is backward from Path 2 to Path 3 where motion can continue backwards (the tables represent the inputs to the MMI_B1_MoveVehicleToPosition function block).

NOTE: The first move order must move the vehicle far enough past the switch to clear the switching mechanism.

wVehicleID 4

wDirection 1

wPIDSetIndex 0

rPosition 1.5

wPathID 2

rAccelDecel 1.0

rVelocity 1.0

wVehicleID 4

wDirection 2

wPIDSetIndex 0

rPosition 5.75

wPathID 3

rAccelDecel 1.0

rVelocity 1.0

wVehicleID 4

wDirection 1

wPIDSetIndex 0

rPosition 0.25

wPathID 3

rAccelDecel 1.0

rVelocity 1.0



Once the MMI_vehicle_order_status array has been updated for the vehicle indicating that it has completed its motion, the second move can be commanded.

Forward Through a Diverge Switch

Figure 3-4: Diverge Switch Movement

Forward motion through a Diverge switch (e.g., Path 1 to Path 2 or Path 3 as shown in Fig-ure 3-4) requires no special consideration and can be configured as a standard move from the Entry Path to either of the Exit Paths where motion can continue forwards (the table repre-sents the inputs to the MMI_B1_MoveVehicleToPosition function block).

wVehicleID 4

wDirection 2

wPIDSetIndex 0

rPosition 5.75

wPathID 3

rAccelDecel 1.0

rVelocity 1.0

wVehicleID 4

wDirection 1

wPIDSetIndex 0

rPosition 1.5

wPathID 3

rAccelDecel 1.0

rVelocity 1.0

Forward(Downstream)

Forward(Downstream)Path 2

Path 3

Single Entry Path Ends(Path 1)

Straight Exit Path Begins(Path 2)

Path 1

Curve Exit Path Begins(Path 3)

Forward(Downstream)



Backward Through a Diverge Switch

Backward motion through a Diverge switch (e.g., Path 2 or Path 3 to Path 1 as shown in Fig-ure 3-4) requires no special consideration and can be configured as a standard move from either of the Exit Paths to the Entry Path where motion can continue backwards (the table rep-resents the inputs to the MMI_B1_MoveVehicleToPosition function block).

Reversing Through a Diverge Switch

Reversing direction through a Diverge switch (e.g., Path 2 to Path 3 as shown in Figure 3-4) requires two moves. The first move is backward from Path 2 to Path 1 and the second move is forward from Path 1 to Path 3 where motion can continue forwards (the tables represent the inputs to the MMI_B1_MoveVehicleToPosition function block).

NOTE: The first move order must move the vehicle far enough to clear the switching mech-anism.

Once the MMI_vehicle_order_status array has been updated for the vehicle indicating that it has completed its motion the second move can be commanded.

wVehicleID 4

wDirection 2

wPIDSetIndex 0

rPosition 5.75

wPathID 1

rAccelDecel 1.0

rVelocity 1.0

wVehicleID 4

wDirection 2

wPIDSetIndex 0

rPosition 5.75

wPathID 1

rAccelDecel 1.0

rVelocity 1.0

wVehicleID 4

wDirection 1

wPIDSetIndex 0

rPosition 1.5

wPathID 3

rAccelDecel 1.0

rVelocity 1.0



Shuttle

A Shuttle is used to enable vehicles to move between parallel guideways. The moving Paths in the Shuttle Node are called the Drive (static) and the Shuttle (dynamic) Paths. The Drive Path moves the Shuttle Path between the various Entry and Exit Paths, and the Shuttle Path sup-ports and moves the vehicles. The remaining Paths are all referred to as either Entry or Exit Paths as shown in Figure 3-5.

Figure 3-5: Shuttle Switch Movement

Forward Through a Shuttle

Forward motion through a Shuttle switch (e.g., Path 1 to Path 4 or Path 5 as shown in Fig-ure 3-5) requires no special consideration and can be configured as a standard move from the Entry Path to either of the Exit Paths where motion can continue forwards (the table repre-sents the inputs to the MMI_B1_MoveVehicleToPosition function block).

Backward Through a Shuttle

Backward motion through a Shuttle switch (e.g., Path 4 or Path 5 to Path 1 as shown in Fig-ure 3-5) requires no special consideration and can be configured as a standard move from

wVehicleID 3

wDirection 1

wPIDSetIndex 0

rPosition 0.125

wPathID 4

rAccelDecel 1.0

rVelocity 1.0

Drive Path(Path 2)

Exit Path Begins(Path 4)


Forward(Downstream)

Forward(Downstream)

Shuttle Path Begins(Path 3)

Entry Path Ends(Path 1)

Forward(Downstream)

Shuttle Path Ends(Path 3)



either of the Exit Paths to the Entry Path where motion can continue backwards (the table rep-resents the inputs to the MMI_B1_MoveVehicleToPosition function block).

Reversing Through a Shuttle

Reversing direction through a Shuttle switch (e.g., Path 4 to Path 5 as shown in Figure 3-5) requires two moves. The first move is backward from Path 4 to Path 3 (the Shuttle Path) and the second move is forward from Path 3 to Path 5 where motion can continue forwards (the tables represent the inputs to the MMI_B1_MoveVehicleToPosition function block).

NOTE: The first move order must move the vehicle fully onto the Shuttle Path (the vehicle must be far enough onto the shuttle to clear the guideway it had been on allowing the shuttle to move, this can be ensured by centering the vehicle on the shuttle).


wVehicleID 3

wDirection 2

wPIDSetIndex 0

rPosition 5.75

wPathID 1

rAccelDecel 1.0

rVelocity 1.0

wVehicleID 4

wDirection 2

wPIDSetIndex 0

rPosition 0.125

wPathID 3

rAccelDecel 1.0

rVelocity 1.0

wVehicleID 4

wDirection 1

wPIDSetIndex 0

rPosition 1.5

wPathID 5

rAccelDecel 1.0

rVelocity 1.0



Turntable

A Turntable is used to enable vehicles to move between multiple guideways. The rotating Path in the Turntable Node is called the Turntable Path. The remaining Paths are all referred to as either Entry or Exit Paths. A mechanism rotates the Turntable Path between the various Entry and Exit Paths as shown in Figure 3-6.

Figure 3-6: Turntable Switch Movement

Forward Through a Turntable

Forward motion through a Turntable switch (e.g., Path 1 to Path 3 or Path 4 as shown in Fig-ure 3-6) requires no special consideration and can be configured as a standard move from the Entry Path to either of the Exit Paths where motion can continue forwards (the table repre-sents the inputs to the MMI_B1_MoveVehicleToPosition function block).

Backward Through a Turntable

Backward motion through a Turntable switch (e.g., Path 3 or Path 4 to Path 1 as shown in Fig-ure 3-6) requires no special consideration and can be configured as a standard move from either of the Exit Paths to the Entry Path where motion can continue backwards (the table rep-resents the inputs to the MMI_B1_MoveVehicleToPosition function block).

wVehicleID 3

wDirection 1

wPIDSetIndex 0

rPosition 1.5

wPathID 4

rAccelDecel 1.0

rVelocity 1.0

Turntable Path Ends(Path 2)

Forward(Downstream)

Entry Path Ends

Exit Path Begins

Exit Path Begins Forward(Downstream)

Forward(Downstream)

Turntable Path Begins

Turntable Mechanism

(Path 2)

(Path 1)(Path 3)

(Path 4)



Reversing Through a Turntable

Reversing direction through a Turntable switch (e.g., Path 3 to Path 4 as shown in Figure 3-6) requires two moves. The first move is backward from Path 3 to Path 2 (the Turntable Path) and the second move is forward from Path 2 to Path 4 where motion can continue forwards (the tables represent the inputs to the MMI_B1_MoveVehicleToPosition function block).

NOTE: The first move order must move the vehicle fully onto the Turntable Path (the vehi-cle must be far enough onto the turntable to clear the guideway it had been on allow-ing the turntable to rotate, this can be ensured by centering the vehicle on the turntable).


wVehicleID 3

wDirection 2

wPIDSetIndex 0

rPosition 5.75

wPathID 1

rAccelDecel 1.0

rVelocity 1.0

wVehicleID 4

wDirection 2

wPIDSetIndex 0

rPosition 0.125

wPathID 2

rAccelDecel 1.0

rVelocity 1.0

wVehicleID 4

wDirection 1

wPIDSetIndex 0

rPosition 1.5

wPathID 4

rAccelDecel 1.0

rVelocity 1.0


Application NotesMovement Through a Terminus Node

Movement Through a Terminus Node

Terminus Nodes allow a vehicle to move to or from the MagneMotion transport system to a non-MagneMotion transport system. Handshaking between the High Level Controller and the Host Controller is used to insert and extract vehicles from a Terminus Node. Inputs are set by the Host Controller using the MMI_B6_SetEntrySignal and MMI_B6_SetExitSignal messages. Last recorded inputs and outputs may be viewed by examining the MMI_node_status entry for the appropriate Node ID which contains the signals. Refer to Entering or Exiting Through a Terminus Node on page 2-42 for a step-by-step example of the Terminus Node handshaking. A Terminus node entry and exit is supplied with MagneMotion’s Mitsubishi PLC TCP/IP Library.

NOTE: When an output state changes, if a polling rate is set for the Engine or if a MMI_B5_StatusRequest function block issues a request, the Engine updates the appropriate MMI_node_status entry.

Entry Handshake

This handshake is used for inserting a vehicle onto a MagneMotion transport system Path at a Terminus Node. The handshake is designed to let one and only one vehicle at a time be inserted at a Terminus Node without risk of collision (simultaneous insertions at other termini are allowed).

Once the vehicle enters the Terminus Node it will stop near the terminus unless a new vehicle order is given (which should be given only after the ENTRY_ALLOWED signal goes high).

Signal Descriptions

Signal Name Input/Output Description

ENTRY_CLEAR Output Signal from the High Level Controller that, last time it was checked, there is sufficient room to insert a vehicle at the terminus.

When the ENTRY_CLEAR signal is high, move-ment permission has not been allocated for a vehi-cle, it is only a signal that the entry space was clear the last time it checked. If a vehicle moves into this space in the meantime, or an error occurs, ENTRY_ALLOWED may not go high once entry is actually requested.

ENTRY_REQUESTED Input Signal from the Host Controller that a vehicle on the external equipment is ready for entry.

ENTRY_ALLOWED Output Signal from the High Level Controller that move-ment permission has been acquired for the vehicle and the vehicle may enter.



Entry Handshake Timing

Figure 3-7: Entry Handshake Timing

1. The High Level Controller notes that the Terminus Node is currently clear and sets the ENTRY_CLEAR signal High.

NOTE: If the status of the entry area changes the High Level Controller will change the ENTRY_CLEAR signal.

2. The Host Controller sets the ENTRY_REQUESTED signal High by setting the inputs of the MMI_B6_SetEntrySignal function block as shown to indicate that it has a vehi-cle ready to enter.

3. The High Level Controller sets the ENTRY_CLEAR signal Low and sets the ENTRY_ALLOWED signal High to indicate permission for the vehicle to enter the Path.

The vehicle is allowed to enter (remote equipment may push the vehicle in). The High Level Controller is now ready to accept a vehicle movement order for the vehicle.

NOTE: If a vehicle movement order is sent before the vehicle is inserted, the vehicle will start moving under that order as soon as it is inserted.

4. The Host Controller sees the ENTRY_ALLOWED signal is High and acknowledges the permission to enter by setting the ENTRY_REQUESTED signal Low by setting the inputs of the MMI_B6_SetEntrySignal function block as shown.

The Host Controller commands the remote equipment to insert the vehicle onto the transport system.

wNodeID 5

bSignalLevel TRUE

wVehicleID 0

wNodeID 5

bSignalLevel FALSE

wVehicleID 0

1 2 3 4 5 6

ENTRY_CLEAR (HLC Host Controller)

ENTRY_REQUESTED (Host Controller HLC)

ENTRY_ALLOWED (HLC Host Controller)



5. The HLC confirms that the entry request is over (ENTRY_REQUESTED is Low) and the vehicle has entered by setting the ENTRY_ALLOWED signal Low.

6. The HLC confirms that the vehicle entry is complete (ENTRY_ALLOWED is Low) and the Terminus Node is clear by setting the ENTRY_CLEAR signal High.

NOTE: The Host Controller must wait for the ENTRY_ALLOWED signal to be Low and the ENTRY_CLEAR signal to be High before sending another entry request.



Exit Handshake

This handshake is used for removing a vehicle from a MagneMotion transport system Path at a Terminus Node. The vehicle at the terminus must have been given an order to move beyond the end of the Path in order for the vehicle to exit (the vehicle will wait at the terminus for the appropriate handshake to take place before exiting). The destination in the order should place the entire vehicle (not just the center of the vehicle) beyond the end of the motor. The hand-shake is designed to let one and only one vehicle at a time to leave a Path terminus without risk of collision (simultaneous exits at other termini are allowed).

Signal Descriptions

Exit Handshake Timing

Figure 3-8: Exit Handshake Timing

1. When space is ready for a vehicle on the remote equipment beyond the Terminus Node of a MagneMotion transport system Path the Host Controller sets the EXIT_ALLOWED signal High by setting the inputs to the MMI_B6_SetExitSignal function block as shown to signal that it has space for a vehicle to exit.

Signal Name Input/Output Description

EXIT_ALLOWED Input Signal from the Host Controller indicating that the external equipment is ready to receive a vehicle from the Terminus Node (the motor is allowed to push the vehicle off the Path).

EXITING Output Signal from the High Level Controller that move-ment permission has been acquired for the vehicle and the vehicle is exiting.

wNodeID 5

bSignalLevel TRUE

1 2 3 4 5

EXIT_ALLOWED (Host Controller HLC)

EXITING (HLC Host Controller)



The Host Controller sets the inputs to the MMI_B1_MoveVehicleToPosition function block as shown to move the vehicle past the end of the Path (minimum distance past the end of the motor should be at least one vehicle length).

2. The High Level Controller notes that the EXIT_ALLOWED signal has gone High and has a vehicle which has begun exiting and sets the EXITING signal High.

3. The Host Controller acknowledges that a vehicle is leaving (EXITING signal has gone High) by setting EXIT_ALLOWED Low by setting the inputs of the MMI_B6_SetEx-itSignal function block as shown.

4. The High Level Controller confirms that the EXIT_ALLOWED signal is Low and the vehicle has left by setting the EXITING signal Low.

5. It is now OK for the Host Controller to set EXIT_ALLOWED High again when the remote equipment has space for another vehicle.

wVehicleID 3

wDirection 1

wPIDSetIndex 0

rPosition 3.25

wPathID 1

rAccelDecel 1.0

rVelocity 1.0

wNodeID 5

bSignalLevel FALSE


Application NotesMovement Through a Gateway Node

Movement Through a Gateway Node

Gateway Nodes allow a vehicle to move from one MagneMotion transport system to another MagneMotion transport system (note that these transport systems are typically sections of a larger transport system). Handshaking through the local subnet is used by the Node Control-lers responsible for each Gateway Node to pass vehicles from system to system.

NOTE: The definition of the Gateway Node in the Configuration File for each transport sys-tem must properly reference its matching Gateway Node in the other transport sys-tem to ensure proper vehicle transfer.

If the vehicle ID of the vehicle entering a transport system through a Gateway Node already exists in that system, entry is refused.

Figure 3-9: Gateway Node Movement

1. The Host Controller for the first transport system issues a vehicle movement order that moves the vehicle so the leading edge of the vehicle crosses the border of the Gateway Node. Once the vehicle has permission to enter the Node from the target system the move will continue through the Node.

The Node Controller in the second transport system responsible for the Gateway Node prepares to receive the vehicle by creating a vehicle record and changing the Node’s ownership status to the entering vehicle.

• If the vehicle ID of the vehicle entering a transport system through a Gateway Node already exists in that system, entry is refused and the vehicle will stop prior to the Node border.

2. The Host Controller for the second transport system monitors the Gateway Node’s sta-tus for a new vehicle ID. Once a new vehicle ID is detected, the Host Controller issues a vehicle movement order (Move to Position or Station) for the new vehicle.

• If no order is placed before the vehicle completes its transfer, the vehicle trav-els to the default destination defined in the Node Configuration File and stops.

Guideway

Downstream Gateway Node

Transport System 1 Exit Path Ends Transport System 2 Entry Path Begins(Path 1) (Path 1)

Motor

Forward(Downstream)

Upstream Gateway Node

Forward(Downstream)


Application NotesAutomatic Path Recovery

Automatic Path Recovery

Automatic Path recovery is a configuration setting that allows the removal of existing vehicles and the introduction of new vehicles on a Path without having to reset and start the entire transport system. It is configured through the Global Settings of the Configuration File (refer to the MagneMotion Configurator User’s Manual for MagneMover® LITE Transport Systems or the MagneMotion Configurator User’s Manual for QuickStick® Transport Systems).

NOTE: If Automatic Path Recovery is set to Off in the Configuration File, no action is taken to identify missing or new vehicles.

Use Automatic Path Recovery On Resume

Missing or new vehicles are identified on Resume only. This assumes that vehicle changes will only happen while motion is Suspended.

When motion on a Path is suspended and a vehicle is removed from the Path, the vehicle record is deleted when an MMI_B8_Reset is used to issue a Resume command to the Path. Additionally, any vehicles that may have been added to the Path while it was suspended are located and vehicle IDs are assigned to those vehicles.

The addition of new vehicles is usually followed by a command to move all vehicles to a startup station.

NOTE: If a vehicle is removed and motion is not suspended the vehicle record is not deleted and the phantom vehicle may impede the movement of other vehicles.

Use Automatic Path Recovery Always

Missing vehicles are deleted on vehicle removal. New vehicles are identified on Resume only. This assumes that vehicle additions will only happen while motion is Suspended.

When a vehicle is removed from the Path, the vehicle record is immediately deleted. Adding vehicles to the Path requires that motion on the Path be suspended and then an MMI_B3_ResumeMovement is used to issue a Resume command to the Path to locate the new vehicles and assign vehicle IDs.

The addition of new vehicles is usually followed by a command to move all vehicles to a startup station.


Application NotesMotor Types

Motor Types

The MagneMotion transport systems are a configuration of linear synchronous motors that are used to move and position material carriers (vehicles) in a controlled manner at various accel-eration/deceleration and velocity profiles while carrying a wide range of payloads with high precision.

The following types of motors are supported by MagneMotion’s Mitsubishi PLC TCP/IP Library for TCP/IP communications. Note that motors from different product lines can not be mixed in the same transport system.

MagneMover LITE

Figure 3-10: MagneMover LITE Motor

The MagneMover LITE motor consists of the motor with control electronics and an integrated rail (250 mm motor shown in Figure 3-10). Motors are mounted end-to-end on a frame with the rails on the motors connected together to create the guideway.

The vehicle used with the MagneMover LITE motors is a puck with an integrated magnet array that slides on the rails and is moved and tracked by the motor.

Magnet Array

Motor

Vehicle (Puck)Rail


Application NotesMotor Types

QuickStick

Figure 3-11: QuickStick Motor

The QuickStick motor consists of the motor with control electronics (500 mm motor shown in Figure 3-11). Motors are mounted end-to-end on a user-supplied frame with a user-supplied guideway.

The vehicle used with the QuickStick motors is user defined to ride on the user’s guideway, which is typically mounted to the frame the motors are mounted on, and is moved and tracked by the motor.

Magnet Array

Motor

User’s Vehicle

Guideway


Application NotesNode Types

Node Types

The following types of Nodes are supported by the MagneMotion transport systems. All Node types support bidirectional movement through the Node. Note that not all transport systems or communication protocols support all Node types.

Relay Node

A Relay Node is used to provide a simple connection where the end of one Path connects to the start of another Path. This is typically used to create a loop or a long continuous Path. The downstream end of one Path connects to one port on the Node Controller and the upstream end of the other Path connects to another port on the same Node Controller. This type of Node is used to break up large Paths, create a simple loop, or separate E-Stop zones. Refer to Fig-ure 3-12, where the shaded circle represents the Relay Node.

This Node type is supported by:

• MagneMover LITE transport systems.

• QuickStick transport systems.

Figure 3-12: Relay Node

Node Operation

• Normal vehicle clearances apply across the Node.

• Vehicles can queue across the Node.

• The vehicle’s move profile is maintained across the Node so the vehicle will cross the Node at a consistent velocity and acceleration.

Forward(Downstream)

GuidewayMotor

Relay Node

Entry Path Ends Exit Path Begins(Path 1) (Path 2)



Merge Node

A Merge Node is where the downstream ends of two Paths merge into the upstream end of a third Path. The three Path ends connect to 3 separate ports on the same Node Controller. This type of Node is used to merge Paths or create multiple loops. Refer to Figure 3-13, where the shaded circle represents the Merge Node.




In a QuickStick system, the Merge Node must incorporate a user-supplied mechanical switch to guide the vehicle from the appropriate entry Path. Digital I/O is provided on the NC-12 and Standard Node Controllers to interface with the switching mechanism.

Figure 3-13: Merge Node

Node Operation




Merge Node Forward(Downstream)

Straight Entry Path Ends

Guideway

Motor

Merged Exit Path Begins

Curve Entry Path Ends

(Path 2)

(Path 3)

(Path 1)



Diverge Node

A Diverge Node is where the downstream end of a Path splits into the upstream ends of two other Paths. The three Paths connect to 3 separate ports on the same Node Controller. This type of Node is used to split a Path or create multiple loops. Refer to Figure 3-14, where the shaded circle represents the Merge Node.




In a QuickStick system, the Diverge Node must incorporate a user-supplied mechanical switch to direct the vehicle to the appropriate exit Path. Digital I/O is provided on the NC-12 and Standard Node Controllers to interface with the switching mechanism.

Figure 3-14: Diverge Node

Node Operation




Diverge Node Forward(Downstream) Straight Exit Path Begins

Guideway

Motor

Single Entry Path Ends

Curve Exit Path Begins

(Path 2)

(Path 3)

(Path 1)



Turntable Node

A Turntable Node is where two or more Paths interconnect with a separate additional Path made up of one LSM on the turntable motor. The upstream ends of each Path leaving the Node, the downstream ends of each Path entering the Node, plus both ends of the turntable Path are connected to the same Node Controller. Refer to Figure 3-15, where the shaded circle represents the Turntable Node.



In QuickStick system, the Turntable Node uses an NSK rotary indexer to direct the vehicle to the appropriate exit Path. RS-232 I/O is provided on the NC-12 and Standard Node Control-lers to interface with the indexing mechanism.

Figure 3-15: Turntable Node

Node Operation

• Normal vehicle clearances apply across the Node only when the move is such that the turntable does not need to rotate.

• Vehicles can not queue across the Node.

• The vehicle’s move profile is maintained across the Node so the vehicle will cross the Node at a consistent velocity and acceleration only when the move is such that the turntable does not need to rotate.

Forward(Downstream)

Turntable Path Ends

Guideway

Motor

Entry Path Ends

Exit Path Begins

Exit Path Begins Forward(Downstream)

Forward(Downstream)

Turntable Path Begins

Turntable Node

Servo Turntable

(Path 2)

(Path 1)(Path 3)

(Path 4)



Terminus Node

A Terminus Node is used on a Path where vehicles move to or from non-MagneMotion equip-ment. Terminus Nodes may be located at either the upstream or downstream end of the Path. Refer to Figure 3-16, where the shaded circle represents the Terminus Node at the down-stream end of the Path.




Figure 3-16: Terminus Node

Node Operation

• Normal vehicle clearances apply on the MMI transport system side the Node.

• Vehicles can queue up to the Node.

• The vehicle’s move profile is maintained across the Node so the vehicle will handoff from the Node to the user’s equipment at a consistent velocity and acceleration. Note that once the vehicle exits the transport system the motors no longer provide any motive force.

Terminus Node Forward(Downstream)Path

GuidewayMotor


User’s GuidewayPath Ends

(Path 1)



Simple Node

A Simple Node is used to begin a Path that is not connected to anything else at the upstream end and where no vehicles enter or exit. The upstream end of the Path connects to a port on the Node Controller. Refer to Figure 3-17, where the shaded circle represents the Simple Node. Note that Paths can also start from other Node types.




Figure 3-17: Simple Node

Node Operation

• Vehicles can queue up to the Node.

Simple Node Forward(Downstream)Exit Path Begins

GuidewayMotor

(Path 1)



Shuttle Node

A Shuttle Node is used to enable vehicles to move between parallel guideways. The Paths in the Shuttle Node are called the Drive (static) and the Shuttle (dynamic) Paths. The Drive Path moves the Shuttle Path, and the Shuttle Path supports and moves the vehicles. The ends of all Paths in the Node must be connected to the same Node Controller. Refer to Figure 3-18, where the shaded circle represents the Shuttle Node.

Vehicles move from a standard Path and enter the Shuttle Path. The Drive Path then moves the Shuttle Path from the entry Path to a second, parallel, Path. The vehicle then exits the Shuttle Path at the second Path.

NOTE: The Shuttle Path is a motor that is attached to a shuttle, which is moved by the Drive Path motor.



Figure 3-18: Shuttle Node

Node Operation

• Normal vehicle clearances apply across the Node only when the move is such that the shuttle does not need to move.

• Vehicles can not queue across the Node.

• The vehicle’s move profile is maintained across the Node so the vehicle will cross the Node at a consistent velocity and acceleration only when the move is such that the shuttle does not need to move.

Shuttle Node

Entry

Drive Path(Path 2)



Vehicle

Forward(Downstream

Forward(Downstream

Guideway

Motor

Vehicle on Shuttle Path

Shuttle Path(Path 3)

Path Ends(Path 1)



Merge-Diverge Node

A Merge-Diverge Node is used where the downstream ends of two Paths connect to the upstream ends of two other Paths. A merge-diverge is created using two switches, where the common Path of each switch is connected together. The four Path ends connect to 4 separate ports on the same Node Controller. Refer to Figure 3-19, where the shaded circle represents the Merge-Diverge Node.



Figure 3-19: Merge-Diverge Node

Forward(Downstream)

Straight Exit Path Begins

Motor

Straight Entry Path Ends(Path 3)(Path 1)

Merge-Diverge Node



Forward(Downstream)

Straight Exit Path Begins

Motor

Straight Entry Path Ends

(Path 3)

(Path 1)

Merge-Diverge Node





Node Operation






Gateway Node

A Gateway Node is used to connect a Path on one transport system to a Path on another trans-port system, where each transport system has separate Host Controllers and High Level Con-trollers. Refer to Figure 3-20, where the shaded circles represent the Gateway Nodes.

NOTE: The Gateway Node must be defined in the Configuration File for each transport sys-tem, including identification of the Gateway Node in the other transport system.

Both Node Controllers connected to the gateway Node must be connected to the same network subnet.

The High Level Controller may run on the same hardware as the Node Controller (e.g., NC LITE), but may need to be on a different Node Controller depending upon the communications load.




Figure 3-20: Gateway Node

Guideway

Downstream Gateway Node

Transport System 1 Exit Path Ends Transport System 2 Entry Path Begins(Path 1) (Path 1)

HLC HLC

Host Controller

NC NC

Motor

RS-422

Ethernet

Ethernet

Forward(Downstream)

Host Controller

Ethernet

System 1 System 2

Upstream Gateway Node



Node Operation


• As a vehicle approaches the Gateway Node, the Node Controller requests per-mission from the target HLC to enter the other system. As long as the Path in the target system is operational and no duplicate vehicle ID exists, entry is granted.

• If entry is granted, the vehicle will continue to move through the Node.

• If entry is not granted then the vehicle will decelerate and stop prior to crossing the Node. The leading edge of the vehicle will stop at the Node boundary.

• Vehicles can queue up to and through the Node.

• If multiple vehicles are sent to the Node, vehicles can queue prior to, across, and through the Node. The queuing is similar to a Relay Node.


• The vehicle ID is maintained across the Gateway Node.

• If the destination is just beyond the Node, the vehicle will decelerate to follow the move profile in the same manner as on any Path.

• The default destination for the Gateway Node is set in the Node Configuration File for entering vehicles.

• The Node Configuration Files for the Gateway Node must have default desti-nation paths and positions defined. This become the default order for any vehi-cle entering the Node in either direction.

• The Host Controller can supersede the default position with a vehicle move-ment order as soon as the vehicle record is detected.

• Node Controllers coordinate exit and entry.

• The Host Controller does not control the access through the Gateway Node, this is done between the Node Controllers in the two transport systems involved. This eliminates the need to have entry/exit requests coordinated by the Host Controllers involved to move through the pair of Gateway Nodes.

• The Host Controller detects entering vehicle Gateway Node ownership via node status messages, providing early notification that a vehicle is entering.

• Once target requests are granted, a vehicle record with the current vehicle ID is generated and is accessible to the Host Controller.

• Once the vehicle record exists, the Host Controller can command the vehicle to a destination. This vehicle order is the same as any other vehicle order (Move to Position or Move to Station).


Application Notes



Protocol and Structured Data Type Reference 4

Overview

This chapter provides an overview of the command and response protocol for MagneMotion’s Mitsubishi PLC TCP/IP Library and details of each predefined function block and the mem-ory label interface. The control software provides a broad range of command options for the transport system. The control software also allows the user’s Host Controller to monitor, and be informed of, status changes within the transport system.

Included in this chapter are:

• Host Controller to HLC communications.

• HLC to Host Controller communications.

NOTE: This Protocol Reference reflects the version of the software indicated in Changes at the front of the manual. Specific builds of MagneMotion’s Mitsubishi PLC TCP/IP Library may not implement all of the features described in this manual. Refer to the Release Notes supplied with the Software CD for more information.


Protocol and Structured Data Type ReferenceIntroduction

Introduction

This chapter provides an overview of the control software communications between the Host Controller and the High Level Controller (HLC) and detailed information on the Function Blocks and the SDTs. The standard method of communication uses TCP/IP communication protocols (refer to Communications Protocol on page A-2).

NOTE: MagneMotion’s Mitsubishi PLC TCP/IP Library includes function blocks and SDTs that are not documented in this chapter, any such instructions are used by MagneMo-tion to support internal functions and are not intended for user use. Use only the function blocks and the SDTs documented in this chapter.

The communications protocol is provided for communications between the HLC and the Host Controller, established by means of TCP/IP connection. Only one device can be connected through this interface to the HLC at a time.

Example of Function Block Setup

The following are screen shots from the GX Works2 programming utility supplied by Mit-subishi showing an example of how to setup a function block that targets the MagneMotion High Level Controller when the function block is triggered. The function block shown in Fig-ure 4-1 is placed in the ladder logic diagram and the Label Registration dialog opens for con-figuration of the function block as shown in Figure 4-1.

Figure 4-1: Dialogue creating a Function Block

The Label name shows the default assigned by GX Works2. It may be changed to any conve-nient unique name.


Protocol and Structured Data Type ReferenceHost Controller to HLC Function Block Definitions

Host Controller to HLC Function Block Definitions

The function blocks shown in Table 4-1 are used to send commands from the Host Controller to the MMI Engine, which parses them into the proper structure for the HLC and then sends them to the HLC as asynchronous requests for the transport system to perform an action.

The function blocks shown in Table 4-2 should only be used as directed.

Table 4-1: PLC to HLC Function Blocks

Function Block Name Use Page

MMI_B0_MoveVehicleToStation As Required 4-4

MMI_B1_MoveVehicleToPosition As Required 4-7

MMI_B2_Startup As Required 4-10

MMI_B3_ResumeMovement As Required 4-12

MMI_B4_SuspendMovement As Required 4-14

MMI_B5_StatusRequest As Required 4-16

MMI_B6_SetEntrySignal As Required 4-19

MMI_B6_SetExitSignal As Required 4-21

MMI_B8_Reset As Required 4-23

MMI_B9_DeleteVehicle As Required 4-25

Table 4-2: Internal Function Blocks

Function Block Name Use Page

MMI_Engine One Instance 4-27



MMI_B0_MoveVehicleToStation

Type

Host Controller HLC

Purpose

This function block is used to move the specified vehicle to a specified station. The station and the Path it is on must be previously defined in the Configuration File.

NOTE: The High Level Controller and Node Controllers in the transport system must be in Operational mode and the Path the vehicle resides on, any Paths the vehicle will travel on, and the Path the vehicle has been commanded to must be in operational mode. If any component required to fill the order is not in operational mode, the command is rejected.


The Engine will generate a unique vehicle order number from 1 to 0xFFFFFFFF. A vehicle order number of zero is reserved and indicates that a given vehicle has not been given a command.

Function Block Descriptions

Figure 4-2: MMI_B0_MoveVehicleToStation Function Block

Note that only user accessed arguments are described below.

Name Class Data Type Range

EN VAR_INPUT Bit False, True

wVehicleID VAR_INPUT Word[Unsigned]/Bit String[16-bit] 1 - 65535

wDirection VAR_INPUT Word[Unsigned]/Bit String[16-bit] 0 - 2

wPIDSetIndex VAR_INPUT Word[Unsigned]/Bit String[16-bit] 0 - 15

wStationID VAR_INPUT Word[Unsigned]/Bit String[16-bit] 1 - 65535

rAccelDecel VAR_INPUT FLOAT (Single Precision) 0.001 - 24.0 (m/s^2)



Arguments

EN – Trigger to enable execution of the function block.

wVehicleID – The ID of the vehicle to move. The ID must be non-zero and must exist in the configuration.

wDirection – Indicates the direction to move the vehicle.

wPIDSetIndex – The PID set to be used for the vehicle movement.

rVelocity VAR_INPUT FLOAT (Single Precision) 0.001 - 4.0 (m/s)

ENO VAR_OUTPUT Bit False, True

wError VAR_OUTPUT Word[Unsigned]/Bit String[16-bit] 0x00 - 0xFF

Value Direction

TRUE Execution

FALSE Stop

Value Direction

0 Bidirectional – If the destination is on the same Path the vehicle resides on, the vehicle can move either direction required to get to the destination in the shortest distance. If the destination is on a Path other than the Path the vehicle is currently on, the forward direc-tion takes precedence for a transport system that is a closed loop.

1 Forward – Force the vehicle to move forward (downstream) only, useful to implement a unidirectional loop. If the destination is not reachable (due to the Paths not forming a loop), the vehicle is not moved.

2 Backward – Force the vehicle to move backward (upstream) only, useful to implement a unidirectional loop in the backwards direction. If the destination is not reachable (due to the Paths not forming a loop), the vehicle is not moved.

Value Direction

0 Use unloaded PID values.

1 Use loaded PID values.

2 - 15 Use the specified PID value set (defined in the Node Configuration File).




wStationID – The ID of the station for the vehicle destination, this must be defined in the transport system’s Configuration File. The ID must be non-zero and must exist in the configu-ration.

rAccelDecel – A positive number (in m/s2) defining the maximum acceleration and decelera-tion rate for the Move command (expressed as a single precision floating-point number). This value is checked against the limit in the Configuration File, and if higher the command is rejected. If this value is higher than the value for a specific motor, the value is overridden by the motor value while the vehicle is on that motor.

This value is system dependent, refer to Table A-2, MagneMotion Transport System Motion Limits, on page A-5.

rVelocity – A positive number (on m/s) defining the maximum velocity for vehicle movement during the Move command (expressed as a single precision floating-point number). This value is checked against the limit in the Configuration File, and if higher the command is rejected. If this value is higher than the value for a specific motor, the value is overridden by the motor value while the vehicle is on that motor.


ENO – Trigger output to indicate the function block is enabled (follows EN).

wError – Acceptance or rejection status of execution of the function block. Refer to Function Block Error Codes on page 4-62 for the meaning of the code.

Response

If the command is accepted by the HLC, a ‘Command Accepted’ response is returned and MMI_vehicle_order_status is updated. The command is then forwarded by the HLC to the appropriate Node Controller for execution. The Node Controller commands the appropriate motor to move the specified vehicle as directed, and MMI_vehicle_order_status and MMI_vehicle_status are updated appropriately. Once the command completes, MMI_vehicle_order_status is updated with a ‘Command Complete’ response.

If the command is rejected by the HLC, MMI_vehicle_order_status is updated with an error code indicating the cause of rejection.

See Also

MMI_B1_MoveVehicleToPosition on page 4-7MMI_vehicle_order_status on page 4-55MMI_vehicle_status on page 4-58



MMI_B1_MoveVehicleToPosition

Type

Host Controller HLC

Purpose

This function block is used to move the specified vehicle to a specified position, relative to the start of a Path.

NOTE: The High Level Controller and Node Controllers in the transport system must be in Operational mode and the Path the vehicle resides on, any Paths the vehicle will travel on, and the Path the vehicle has been commanded to must be in operational mode. If any component required to fill the order is not in operational mode, the command is rejected.


The Engine will generate a unique vehicle order number from 1 to 0xFFFFFFFF. A vehicle order number of zero is reserved and indicates that a given vehicle has not been given a command.


Figure 4-3: MMI_B1_MoveVehicleToPosition Function Block





wDirection VAR_INPUT Word[Unsigned]/Bit String[16-bit] 0 - 2

wPIDSetIndex VAR_INPUT Word[Unsigned]/Bit String[16-bit] 0 - 15

rPosition VAR_INPUT FLOAT (Single Precision) 0 - 41.0 (m)

wPathID VAR_INPUT Word[Unsigned]/Bit String[16-bit] 1 - 65535

rAccelDecel VAR_INPUT FLOAT (Single Precision) 0.001 - 24.0 (m/s^2)



Arguments


wVehicleID – The ID of the vehicle to move. The ID must be non-zero and must exist in the configuration.

wDirection – Indicates the direction to move the vehicle.

wPIDSetIndex – The PID set to be used for the vehicle movement.

rVelocity VAR_INPUT FLOAT (Single Precision) 0.001 - 4.0 (m/s)



Value Direction

TRUE Execution

FALSE Stop

Value Direction

0 Bidirectional – If the destination is on the same Path the vehicle resides on, the vehicle can move either direction required to get to the destination in the shortest distance. If the destination is on a Path other than the Path the vehicle is currently on, the forward direc-tion takes precedence for a transport system that is a closed loop.

1 Forward – Force the vehicle to move forward (downstream) only, useful to implement a unidirectional loop. If the destination is not reachable (due to the Paths not forming a loop), the vehicle is not moved.

2 Backward – Force the vehicle to move backward (upstream) only, useful to implement a unidirectional loop in the backwards direction. If the destination is not reachable (due to the Paths not forming a loop), the vehicle is not moved.

Value Direction

0 Use unloaded PID values.

1 Use loaded PID values.

2 - 15 Use the specified PID value set (defined in the Node Configuration File).




rPosition – The destination (in meters) of the vehicle, relative to the start of the specified Path (expressed as a single precision floating-point number). Zero position is defined as the mid-point of the vehicle at the beginning of the Path.

wPathID – The ID of the Path where the position is located. The ID must be non-zero and must exist in the configuration.

rAccelDecel – A positive number (in m/s2) defining the maximum acceleration and decelera-tion rate for the Move command (expressed as a single precision floating-point number). This value is checked against the limit in the Configuration File, and if higher the command is rejected. If this value is higher than the value for a specific motor, the value is overridden by the motor value while the vehicle is on that motor.


rVelocity – A positive number (on m/s) defining the maximum velocity for vehicle movement during the Move command (expressed as a single precision floating-point number). This value is checked against the limit in the Configuration File, and if higher the command is rejected. If this value is higher than the value for a specific motor, the value is overridden by the motor value while the vehicle is on that motor.




Response

If the command is accepted by the HLC, a ‘Command Accepted’ response is returned and MMI_vehicle_order_status is updated. The command is then forwarded by the HLC to the appropriate Node Controller for execution. The Node Controller commands the appropriate motor to move the specified vehicle as directed, and MMI_vehicle_order_status and MMI_vehicle_status are updated appropriately. Once the command completes, MMI_vehicle_order_status is updated with a ‘Command Complete’ response.


See Also

MMI_B0_MoveVehicleToStation on page 4-4MMI_vehicle_order_status on page 4-55MMI_vehicle_status on page 4-58



MMI_B2_Startup

Type

Host Controller HLC

Purpose

This function block is used to initiate the startup sequence for locating all vehicles on the specified Path. If the Path ID specified is zero, the startup sequence for locating all vehicles is executed on all Paths in the transport system.

NOTE: The High Level Controller and Node Controllers in the transport system must be in Operational mode.


Figure 4-4: MMI_B2_Startup Function Block


Arguments


wPathID – The ID of the Path where startup processing will execute, or zero to execute startup processing on all Paths in the transport system.







Value Direction

TRUE Execution

FALSE Stop




Response

If the command is accepted by the HLC, a ‘Command Accepted’ response is returned and MMI_path_command_status is updated. The command is then forwarded by the HLC to the appropriate Node Controller for execution. The Node Controller starts executing the Startup sequence on the specified Path(s), and MMI_path_command_status and MMI_path_status are updated appropriately. Once the command completes, MMI_path_command_status is updated with a ‘Command Complete’ response.

If the command is rejected by the HLC, MMI_path_command_status is updated with an error code indicating the cause of rejection.

See Also

MMI_B8_Reset on page 4-23MMI_path_command_status on page 4-50MMI_path_status on page 4-52



MMI_B3_ResumeMovement

Type

Host Controller HLC

Purpose

This function block is used to enable movement after it has been disabled with a MMI_B4_SuspendMovement command on the specified Path. If the Path ID specified is zero, movement is resumed on all Paths in the transport system. When the Resume is issued, motion based on all currently active movement commands will continue.

NOTE: If Automatic Path Recovery in the Configuration File is set to On Resume any new vehicles added to the transport system while movement was suspended are detected.

The Path specified must have completed startup. When resuming all Paths (Path ID of zero specified), all Paths must have completed startup.


Figure 4-5: MMI_B3_ResumeMovement Function Block


Arguments







Value Direction

TRUE Execution

FALSE Stop



wPathID – The ID of the Path where movement will resume movement, or zero to resume movement on all Paths in the transport system.



Response

If the command is accepted by the HLC, a ‘Command Accepted’ response is returned and MMI_path_command_status is updated. The command is then forwarded by the HLC to the appropriate Node Controller for execution. The Node Controller resumes movement of all vehicles on the specified Path(s), and MMI_path_command_status and MMI_path_status are updated appropriately.


See Also

MMI_B4_SuspendMovement on page 4-14MMI_path_command_status on page 4-50MMI_path_status on page 4-52



MMI_B4_SuspendMovement

Type

Host Controller HLC

Purpose

This function block is used to suspend all movement on the specified Path. If the Path ID specified is zero, movement is suspended on all Paths in the transport system. Vehicles imme-diately decelerate to a controlled stop. Previously commanded movement does not resume until a MMI_B3_ResumeMovement function block is executed. Note that the control loop is still enabled while movement is suspended holding all vehicles in place.

NOTE: A request to suspend movement on a Path can be issued at any time.


Figure 4-6: MMI_B4_SuspendMovement Function Block


Arguments


wPathID – The ID of the Path where movement will be suspended, or zero to suspend move-ment on all Paths in the transport system.






Value Direction

TRUE Execution

FALSE Stop





Response

If the command is accepted by the HLC, a ‘Command Accepted’ response is returned and MMI_path_command_status is updated. The command is then forwarded by the HLC to the appropriate Node Controller for execution. The Node Controller suspends movement of all vehicles on the specified Path(s), which decelerate to a controlled stop, and MMI_path_command_status and MMI_path_status are updated appropriately.


See Also

MMI_B3_ResumeMovement on page 4-12MMI_path_command_status on page 4-50,MMI_path_status on page 4-52



MMI_B5_StatusRequest

Type

Host Controller HLC

Purpose

This function block is used to request the status for the item specified in the Request Type. For each Request Type, the status can be requested for one specific item or for all items of that type.


Figure 4-7: MMI_B5_StatusRequest Function Block


Arguments




wRequestType VAR_INPUT Word[Unsigned]/Bit String[16-bit] 0 - 5

wID VAR_INPUT Word[Unsigned]/Bit String[16-bit] 0 - 65535

wMotorIndex VAR_INPUT Word[Unsigned]/Bit String[16-bit] 0 - 40



Value Direction

TRUE Execution

FALSE Stop



wRequestType – The type of status request.

wID – The ID of the item specified in wRequestType that status is being requested for, or 0 to request all elements of the specified type.

When wRequestType is ‘5’ (Motor Status), this field specifies the ID of the Path that the motor or motors reside on and wMotorIndex specifies the motor or motors on that Path.

wMotorIndex – This field is only referenced when wRequestType is ‘5’ (Motor Status), if it is included for any other Request Type it is ignored. The wID field is used to specify the Path the motor or motors reside in, or 0 to specify all Paths. This byte should be omitted for a Request Type of 0, 1, 2, 3, or 4 and set accordingly for request type 5.



Response

For a Request Type of 0, if the command is accepted by the HLC, MMI_HLC_status is updated.

For a Request Type of 1, if the command is accepted by the HLC, MMI_node_controller_sta-tus is updated.

Value Requests Status For

0 High Level Controller – The ID and motor index fields should be omitted and are ignored by the HLC if included.

1 Node Controller – The ID field specifies the Node Controller, the Motor Index field should be omitted and is ignored by the HLC if included.

2 Node – The ID field specifies the Node, the Motor Index field should be omitted and is ignored by the HLC if included.

3 Path – The ID field specifies the Path, the Motor Index field should be omitted and is ignored by the HLC if included.

4 Vehicle – The ID field specifies the Vehicle, the Motor Index field should be omitted and is ignored by the HLC if included.

5 Motor – The ID field specifies the Path the motor(s) are on and the Motor Index field specifies the specific motor(s) on the Path.

Value Description

0 All motors on the specified Path.

1 - 40 Individual motor index on the specified Path.



For a Request Type of 2, if the command is accepted by the HLC, MMI_node_status is updated.

For a Request Type of 3, if the command is accepted by the HLC, MMI_path_status is updated.

For a Request Type of 4, if the command is accepted by the HLC, MMI_vehicle_status is updated.

For a Request Type of 5, if the command is accepted by the HLC, MMI_motor_status is updated.

If the command is rejected by the HLC, the appropriate status SDT is updated with an error code indicating the cause of rejection.

If a request is made for a Request Type item that does not exist in the transport system, a status response message for the corresponding type is returned with the ‘Present’ flag set to 0 indi-cating no such item exists.

NOTE: The index must exist in the Global Label List, otherwise the PLC will fault.

• For example if Node Status is requested for a non-existent Node ID within the range specified by sdt_MMI_node_status, the MMI_node_status SDT is updated with the ‘Present’ flag set to zero indicating no such Node exists. However, if Node Status is requested for a Node ID outside the range specified by sdt_MMI_node_status, the PLC will generate an Operation Error when it attempts to write status information to an undefined index (refer to PLC Troubleshooting on page 5-3).

• For motor status, presence flags are included for both the Path ID and motor index (refer to MMI_motor_status).

See Also

MMI_HLC_status on page 4-33MMI_node_controller_status on page 4-44MMI_node_status on page 4-46MMI_path_status on page 4-52MMI_vehicle_status on page 4-58MMI_motor_status on page 4-35



MMI_B6_SetEntrySignal

Type

Host Controller HLC

Purpose

This function block is used to set and clear signals affiliated with vehicle entry (onto the trans-port system) through a Terminus Node, which is used to move a vehicle on or off a Path to or from user-supplied equipment. Refer to MMI_node_status for the current state of the signals. Refer to Movement Through a Terminus Node on page 3-16 for a description of handshaking using these signals.

NOTE: The Path the Terminus Node is affiliated with must be in the operational state. If not, the command is rejected.


Figure 4-8: MMI_B6_SetEntrySignal Function Block


Arguments




wNodeID VAR_INPUT Word[Unsigned]/Bit String[16-bit] 1 - 65535

bSignalLevel VAR_INPUT Bit False, True




Value Direction

TRUE Execution

FALSE Stop



wNodeID – The ID of the Terminus Node for the signal. The ID must be non-zero.

bSignalLevel – Specifies the level of the signal.

wVehicleID – This is the ID to use for the vehicle that will enter (when setting bSignalLevel High). The ID must be a non-zero integer which is not currently used for another vehicle, or 0 to have the transport system assign a vehicle ID. The MMI_node_status array contains the Vehicle ID the transport system issued when the Host Controller specifies a vehicle ID of 0.



Response

If the command is accepted by the HLC, a ‘Command Accepted’ response is returned and MMI_node_command_status is updated. The command is then forwarded by the HLC to the appropriate Node Controller for execution. The Node Controller sets the appropriate digital I/O bit as specified, and MMI_node_command_status and MMI_node_status are updated appropriately.

If the command is rejected by the HLC, MMI_node_command_status is updated with an error code indicating the cause of rejection.

See Also

MMI_B6_SetExitSignal on page 4-21MMI_node_command_status on page 4-42MMI_node_status on page 4-46

Value Signal

False Low (inactive), vehicle may not enter from the user equipment

True High (active), vehicle may enter from the user equipment



MMI_B6_SetExitSignal

Type

Host Controller HLC

Purpose

This function block is used to set and clear signals affiliated with vehicle exit (from the trans-port system) through a Terminus Node, which is used to move a vehicle on or off a Path to or from user-supplied equipment. Refer to MMI_node_status for the current state of the signals. Refer to Movement Through a Terminus Node on page 3-16 for a description of handshaking using these signals.

NOTE: The Path the Terminus Node is affiliated with must be in the operational state. If not, the command is rejected.


Figure 4-9: MMI_B6_SetExitSignal Function Block


Arguments




wNodeID VAR_INPUT Word[Unsigned]/Bit String[16-bit] 1 - 65535

bSignalLevel VAR_INPUT Bit False, True



Value Direction

TRUE Execution

FALSE Stop



wNodeID – The ID of the Terminus Node for the signal. The ID must be non-zero.

bSignalLevel – Specifies the level of the signal.



Response

If the command is accepted by the HLC, a ‘Command Accepted’ response is returned and MMI_node_command_status is updated. The command is then forwarded by the HLC to the appropriate Node Controller for execution. The Node Controller sets the appropriate digital I/O bit as specified, and MMI_node_command_status and MMI_node_status are updated appropriately.

If the command is rejected by the HLC, MMI_node_command_status is updated with an error code indicating the cause of rejection.

See Also

MMI_B6_SetEntrySignal on page 4-19MMI_node_command_status on page 4-42MMI_node_status on page 4-46

Value Signal

False Low (inactive), vehicle will not exit onto the user equipment

True High (active), vehicle will exit onto the user equipment



MMI_B8_Reset

Type

Host Controller HLC

Purpose

This function block is used to reset all motors on the specified Path. All movement on the specified Path(s) should be suspended using the MMI_B4_SuspendMovement function block before a Reset is issued. Once all vehicles are stopped the runtime code on the motors is restarted and all vehicle records for vehicles on the specified Path(s) are deleted. If the Path ID specified is zero, all Paths in the transport system are reset and all vehicles records deleted. After any Path is reset a MMI_B2_Startup must be executed on it to bring it to the operational state.

NOTE: A reset command is valid at any time with the exception of when the High Level Controller is in the initialization state.


Figure 4-10: MMI_B8_Reset Function Block


Arguments







Value Direction

TRUE Execution

FALSE Stop



wPathID – The ID of the Path to reset, or zero to reset all Paths in the transport system.



Response

If the command is accepted by the HLC, a ‘Command Accepted’ response is returned and MMI_path_command_status is updated. The command is then forwarded by the HLC to the appropriate Node Controller for execution. The Node Controller starts executing the Reset sequence on the specified Path(s), and MMI_path_command_status and MMI_path_status are updated appropriately. Once the command completes, MMI_path_command_status is updated with a ‘Command Complete’ response.


See Also

MMI_B2_Startup on page 4-10MMI_B4_SuspendMovement on page 4-14MMI_motor_status on page 4-35MMI_path_command_status on page 4-50MMI_path_status on page 4-52MMI_vehicle_status on page 4-58



MMI_B9_DeleteVehicle

Type

Host Controller HLC

Purpose

This function block is used to command a Node Controller to delete a vehicle record, and all related motors to delete any vehicle records with a matching ID. This command must be used very carefully. It is typically used only when a vehicle is physically removed from the guide-way because it is inoperable, or when a vehicle entry is cancelled. If a vehicle entry or exit is active for the vehicle, the entry/exit state machine is also cleared.


Figure 4-11: MMI_B9_DeleteVehicle Function Block


Arguments


wVehicleID – The ID of the vehicle to be deleted. The ID must be non-zero.








Value Direction

TRUE Execution

FALSE Stop



Response

If the command is accepted by the HLC, a ‘Command Accepted’ response is returned and MMI_vehicle_order_status is updated. The HLC deletes the vehicle from the Vehicle Record and sends the delete order to all Node Controllers to delete the vehicle from their Vehicle Records, and MMI_vehicle_order_status and MMI_vehicle_status are updated appropriately. Once the command completes, MMI_vehicle_order_status is updated with a ‘Command Com-plete’ response.


See Also

MMI_vehicle_order_status on page 4-55MMI_vehicle_status on page 4-58



MMI_Engine

Type

Host Controller HLC

Purpose

The MMI Engine manages the functionality of the MMI TCP/IP Interface. This routine is called in a Scan or Fixed Scan interval program. Setup a new program in the GX Works2 proj-ect for the transport system and establish that program as a Fixed Scan Interval program. The fixed scan interval should be selected based on the size of the processor, the size of the trans-port system, and the performance requirements.

NOTE: Instantiate only one instance of the MMI Engine per Project.

The Engine is responsible for the following functions:

• TCP control send state machine – de-queues and sends commands from the Host Con-troller to the HLC.

• TCP status send state machines – requests status of devices on the transport system as commanded.

• Automatic status polling – requests status of devices on the transport system as config-ured by the Poll Rates. Automatic polling can be disabled, and requests can be initi-ated by the Host Controller using the MMI_B5_StatusRequest function block. Status messages (if enabled) will not be queued while the HLC is disconnected.

NOTE: Status polling and the connection time-out use high-speed timers, which have a configurable timebase in the PLC parameters. Changing the high-speed timer period may affect the behavior of polling.

• TCP status receive state machines – receives and parses response from the HLC, and directs the data to the proper Global Label memory locations.

• Connection management – maintains the TCP connection to the HLC (refer to bCon-nect and tConnectionRetryTimeout).

• Creates unique vehicle order numbers for all vehicle commands.

• The Engine will not check the validity of command inputs or responses, unless other-wise stated.

The Engine also maintains all MMI Global Labels, including performing the following house-keeping tasks:

• On connecting or reconnecting (immediately after successfully establishing a TCP/IP connection with the HLC):

• Clear all device status memory (set to zero), command status will persist.

• Clear any unsent messages on reconnection.



• Start the Send queue state machine.

• Set the MMI_HLC_status bit HLCConnectedStatus to TRUE.

• On disconnecting (immediately after a TCP/IP connection is closed):

This could be as much as ~15s later if tConnectionRetryTimeout is disabled. If the connection is deliberately closed, e.g. setting bConnect FALSE, then it is immediate.

• Set the MMI_HLC_status bit HLCConnectedStatus to FALSE.

• On receiving a successful acknowledgement response to a MMI_B9_DeleteVehicle command, or successfully completing a Terminus Node exit sequence:

• Clear the MMI_vehicle_status memory at the corresponding vehicle index.

• On successfully completing a MMI_B8_Reset command:

• Update the MMI_path_status memory at the corresponding path index.

• Update all MMI_motor_status memory at the corresponding path index.

• Clear the MMI_vehicle_status memory for any vehicle that exists on the path that was reset.


Figure 4-12: MMI_Engine Function Block



bConnect VAR_INPUT Bit 0 - 1

iConnectionNo VAR_INPUT Word[Signed] 1 - 16

iStartingIOAddress VAR_INPUT Word[Signed] 0 - 65535

tHLC_PollRate VAR_INPUT Time 0 ms - 24d20h31m23s647ms

0 ms = Disable

tNodeController_PollRate VAR_INPUT Time 0 ms - 24d20h31m23s647ms

0 ms = Disable

tNode_PollRate VAR_INPUT Time 0 ms - 24d20h31m23s647ms

0 ms = Disable



Arguments

NOTE: Setting a poll rate to zero will disable polling for that poll rate.

bConnect – If TRUE, the Engine will try to initiate/maintain a connection. If FALSE, the Engine will disconnect.

iConnectionNo – The connection number of the Ethernet port on the PLC used to communi-cate with the HLC, as configured in GX Works2.

iStartingIOAddress – The Starting IO Address of the connection (0 - 0x0080 in increments of 0x0010), if utilizing an Ethernet Module, as configured in GX Works2. Not supported when using a built-in Ethernet connection.

tHLC_PollRate – The time period that the Engine will poll for HLC status. Setting the poll rate to 0 disables polling. The recommended poll rate is 500 ms1.

tPath_PollRate VAR_INPUT Time 0 ms - 24d20h31m23s647ms

0 ms = Disable

tVehicle_PollRate VAR_INPUT Time 0 ms - 24d20h31m23s647ms

0 ms = Disable

tMotor_PollRate VAR_INPUT Time 0 ms - 24d20h31m23s647ms

0 ms = Disable

wNodeControllerCount VAR_INPUT Word[Unsigned]/Bit String[16-bit] 1 - 65535

wNodeCount VAR_INPUT Word[Unsigned]/Bit String[16-bit] 1 - 65535

wMaxMotorCount VAR_INPUT Word[Unsigned]/Bit String[16-bit] 1 - 65535

wPathStatusCount VAR_INPUT Word[Unsigned]/Bit String[16-bit] 1 - 65535

wVehicleCount VAR_INPUT Word[Unsigned]/Bit String[16-bit] 1 - 65535

tConnectionRetryTimeout VAR_INPUT Time 50 ms - 24d20h31m23s647ms

0 = disable

1. The recommended poll rates shown are for a typical small project. The actual poll rates used should be based on the project complexity and needs.

The timer behavior that manages polling is dependent upon the high speed timer settings in the PLC parameters. For example, setting the high-speed timer rate to 10ms will result in polling times that are rounded to a nearby multiple of 10ms.

Setting the poll rates to zero will disable polling by the Engine. Poll rates can be changed during runtime. Status memory can be updated as-needed by executing the MMI_B5_StatusRequest Function Block.




tNodeController_PollRate – The time period that the Engine will poll for Node Controller status. Setting the poll rate to 0 disables polling. The recommended poll rate is 1 s1.

tNode_PollRate – The time period that the Engine will poll for Node status. Setting the poll rate to 0 disables polling. The recommended poll rate is 1 s1.

tPath_PollRate – The time period that the Engine will poll for Path status. Setting the poll rate to 0 disables polling. The recommended poll rate is 1 s1.

tVehicle_PollRate – The time period that the Engine will poll for vehicle status. Setting the poll rate to 0 disables polling. The recommended poll rate is 40 ms1.

tMotor_PollRate – The time period that the Engine will poll for motor status. Setting the poll rate to 0 disables polling. The recommended poll rate is 0 ms1.

wNodeControllerCount – The number of Node Controllers in the transport system. Used to clear the appropriate amount of status memory on connection to the HLC. This must be the same as the size of the MMI_node_controller_status SDT.

wNodeCount – The number of Nodes in the transport system. Used to clear the appropriate amount of status memory on connection to the HLC. This must be the same as the size of the MMI_node_command_status and MMI_node_status SDTs.

wMaxMotorCount – The number of Motors on the largest Path in the transport system. Used to clear the appropriate amount of status memory on connection to the HLC. This must be the same as the size of the second dimension of the MMI_motor_status SDT.

wPathStatusCount – The number of Paths in the transport system. Used to clear the appro-priate amount of status memory on connection to the HLC. This must be the same as the size of the first dimension of the MMI_motor_status, MMI_path_command_status, and MMI_path_status SDTs.

wVehicleCount – The number of Vehicles in the transport system. Used to clear the appropri-ate amount of status memory on connection to the HLC. This must be the same as the size of the MMI_vehicle_order_status and MMI_vehicle_status SDTs.

tConnectionRetryTimeout – Time-out value between HLC responses. If 3 consecutive time-outs occur, MMI_HLC_status is updated and the connection status to the HLC is declared dis-connected. Once disconnected, reconnect attempts will be made if bConnect remains TRUE. Setting the time-out rate to 0 disables time-out retry. Minimum value is 50 ms.

NOTE: Setting tConnectionRetryTimeout to 0 will disable active connection status poll-ing. With active connection status polling disabled, a disconnection to the HLC may take up to 15 seconds to register in HLC Status response memory.

See Also

MMI_send_queue on page 4-61


Protocol and Structured Data Type ReferenceHLC to Host Controller Status Memory Labels

HLC to Host Controller Status Memory Labels

The High Level Controller responds to the commands from the Host Controller, which were generated by the Engine and sent to the HLC. The responses to the commands are received by the Engine, which populates the Status Memory Labels.

The memory labels shown in Table 4-3 are updated by the Engine whenever the HLC sends an update. This happens when command states change, when polled by the Engine, or when an MMI_B5_StatusRequest function block is executed. The counters within the label can be used to determine whether the data is current. These are informational for the PLC for disseminat-ing status about the MagneMotion transport system as the PLC programmer sees fit.

NOTE: To reduce the amount of memory required for the Library, the memory labels are instantiated as global variables. This requires that all users adhere to a strict naming convention that matches the names exactly.

These global variable arrays must be sized according to the system configuration and treated as read only.

The SDTs shown in Table 4-4 are for internal use only and are provided strictly for reference.

Table 4-3: PLC Status Memory Labels

Label Name Data Type Used Page

MMI_HLC_status sdt_MMI_HLC_status 4-33

MMI_motor_status sdt_MMI_motor_status 4-35

MMI_node_command_status sdt_MMI_node_command_status 4-42

MMI_node_controller_status sdt_MMI_node_controller_status 4-44

MMI_node_status sdt_MMI_node_status 4-46

MMI_path_command_status sdt_MMI_path_command_status 4-50

MMI_path_status sdt_MMI_path_status 4-52

MMI_vehicle_order_status sdt_MMI_vehicle_order_status 4-55

MMI_vehicle_status sdt_MMI_vehicle_status 4-58

Table 4-4: Internal Memory Labels

Label Name Data Type Used Page

MMI_send_queue sdt_MMI_send_queue 4-61



MMI_HLC_status

Type

Host Controller HLC

Purpose

Reports the status of the High Level Controller. This SDT is updated as specified by the tHLC_PollRate or when requested using the MMI_B5_StatusRequest function block.

SDT Format

Field Descriptions

Arguments

UpdateCount – Engine-managed counter that increments when a status update is received from the HLC. Note that the counter will roll-over after it reaches it maximum value.

HLCState – Indicates the state of the High Level Controller.

SDT Name Type Array Array Dimension Limits

MMI_HLC_status sdt_MMI_HLC_status No —

Name Data Type Range

UpdateCount Word[Unsigned]/Bit String[16-bit] 0 - 65535

HLCState Word[Unsigned]/Bit String[16-bit] 0 - 3

ENetStatus Word[Unsigned]/Bit String[16-bit] 0 - 2

HLCConnectedStatus Bit 0 - 1

SendError Word[Signed] 0 - 65535

ReceiveError Word[Signed] 0 - 65535

Value State

0 MMI_HLC_status Initialized – The SDT has been initialized, but no data has been reported by the HLC.

1 Initialization – Loading the configuration file or unable to complete processing of the configuration file if the configuration has an error in it. Consult the High Level Control-ler log if it is unable to exit this state.



ENetStatus – A byte designating the status of communication via Ethernet Industrial Protocol with a PLC if the High Level Controller is configured to be controlled by a PLC.

HLCConnectedStatus – Status of the communication link to the HLC control port. This will be updated whenever the link status changes based on the tConnectionRetryTimeout setting.

SendError – Error code from the Mitsubishi Buffer_Send block on the command connection port. Refer to the Mitsubishi Q or L Ethernet Module documentation for details.

ReceiveError – Error code from the Mitsubishi Buffer_Recieve block on the command con-nection port. Refer to the Mitsubishi Q or L Ethernet Module documentation for details.

See Also

MMI_B5_StatusRequest on page 4-16MMI_node_controller_status on page 4-44

2 Degraded – The High Level Controller is unable to communicate with one or more Node Controllers in the transport system. Refer to the High Level Controller log for additional details.

3 Operational – The High Level Controller configuration is valid and successfully com-municating with all Node Controllers configured in the transport system.

Value State

0 Not configured – EtherNet/IP control is Not Configured

1 Link up – EtherNet/IP communication link is UP indicating the High Level Controller is connected to the PLC at the configured PLC IP address.

2 Link down – EtherNet/IP communication link is DOWN indicating the High Level Controller is unable to contact the PLC at the configured IP address or connectivity has been lost.

Value State

0 Ethernet link to the HLC is down.

1 Ethernet link to the HLC is up.

Value State



MMI_motor_status

Type

Host Controller HLC

Purpose

Reports the status of all motors in the transport system. This array is updated as specified by tMotor_PollRate or when requested using the MMI_B5_StatusRequest function block.

Reports the status of the motors, specifically fault information. The first index in this SDT array corresponds to a Path ID and the second index corresponds to a motor on that Path. Refer to Table A-1, MagneMotion Transport System Limits, on page A-5 for the maximum number of Paths and motors per Path for a transport system. This array should not be defined larger than the maximums shown in Table A-1.

NOTE: The index for each Motor on each Path must exist in the Global Label List, other-wise the PLC will generate an Operation Error when it attempts to write status infor-mation to an undefined index (refer to PLC Troubleshooting on page 5-3).

SDT Format

SDT Description

• Array indices correspond to Path ID and Motor number.

Field Descriptions


MMI_motor_status sdt_MMI_motor_status Yes minPathID..maxPathID*, 1..maxMotors†

* The SDT must specify the same range as specified in the Node Configuration File.† maxMotors is the motor count from the Path with the most motors.



PathPresent Bit 0 - 1

MotorPresent Bit 0 - 1

MotorType Word[Unsigned]/Bit String[16-bit] 0 - 2

NumBlocks_DriverBoards Word[Unsigned]/Bit String[16-bit] 1 - 10

SchedulerErrors Word[Unsigned]/Bit String[16-bit] Bits 0 - 7 are Flags



Arguments


PathPresent – Path status.

MotorPresent – Motor status.

MotorType – The type of motor returning the status information. When the Host Controller requests motor status for a non-existent Path, motor index, or both, this field is set to 0.

UpstreamComms Word[Unsigned]/Bit String[16-bit] Bits 0 - 7 are Flags

DownstreamComms Word[Unsigned]/Bit String[16-bit] Bits 0 - 7 are Flags

MotorOverall Word[Unsigned]/Bit String[16-bit] Bits 0 - 7 are Flags

MotorFaultData Word[Unsigned]/Bit String[16-bit](0..9) Varies based on the specified MotorType.

QuickStick - maxi-mum of 20 bytes

MM LITE - maxi-mum of 6 bytes

Value State

0 Path is not present (remainder of data in message is invalid)

1 Path is present

Value State

0 The motor specified by the Motor Index is not present on the specified Path (remainder of data in message is invalid).

1 The motor specified by the Motor Index is present within the specified Path.

Value Description

0 Invalid – This field is zero when the Path or motor being reported doesn’t exist (an error in the Host Controller’s request).

1 Motor type is QuickStick – The fault data for the motor is provided after the Motor Overall field and varies based on the motor.

2 Motor type is MagneMover LITE – The fault data for the motor is provided after the Motor Overall field and varies based on the motor.




NumBlocks_DriverBoards – For QuickStick motors, this is the number of blocks the motor contains. The overall motor and block fault data following has enough room for up to 10 blocks of two bytes of each block fault sets A and B. If the motor being reported has less than 10 blocks, the Host Controller should pay attention to the block fault data for the number of blocks the motor actually has indicated by this field and disregard the remaining block data.

For example, a QSHT 1000 mm motor will report 2 blocks and block faults A and B for blocks 1 and 2 are populated. Block faults A and B for blocks 3 through 10 in the remainder of the message should be ignored by the Host Controller.

For MagneMover LITE motors, this is the number of driver boards the motor contains. The overall motor and block fault data following has enough room for up to 4 blocks of one byte of fault data. If the motor being reported has less than 4 blocks, the Host Controller should pay attention to the block fault data for the number of driver boards the motor actually has indi-cated by this field and disregard the remaining driver board data.

Scheduler Errors – 1 byte of fault data for the motor’s task scheduler.

Value Motor Number of Blocks/Driver Boards

10 QS100, 1 m 10 blocks

5 QS100, 0.5 m 5 blocks

2 QSHT, 1 m 2 blocks

1 QSHT, 0.5 m 1 block

4 MM LITE, 1 m 4 driver boards

1 MM LITE, 250 mm 1 driver board

1 MM LITE, 125 mm 90° Curve 1 driver board

1 MM LITE Switch, Straight 1 driver board

1 MM LITE Switch, Curve 1 driver board

Bit Meaning

0 Scheduler Not Initialized

1 Scheduler Event Queue Full

2 - 7 Reserved



Upstream Communications – 1 byte of fault data for the motor’s upstream communications.

Downstream Communications – 1 byte of fault data for the motor’s downstream communi-cations.

Motor Overall – 1 byte of fault data for the motor’s status.

Bit Meaning

0 Connection Inoperative

1 Misc Communication Warning

2 Transmitter Buffer Full

3 UART Settings Corrected

4 - 7 Reserved

Bit Meaning

0 Connection Inoperative

1 Misc Communication Warning

2 Transmitter Buffer Full

3 UART Settings Corrected

4 - 7 Reserved

Bit Meaning

0 Motor Not in Operational Mode

1 Motor in Configuration Mode

2 Motor in Diagnostic Mode

3 Movement Suspended by Node Controller

4 - 6 Reserved

7 Motor Not Responding (Bit 7 is controlled by the Node Controller)



Motor Fault Data - QuickStick

Data reported for QuickStick motors. If the Host Controller requests motor status for a non-existent Path, motor index, or both, all bytes in this field are set to 0.

Note that QuickStick motors may not populate every block in the motor’s fault data. For such motors, the number of blocks the motor actually populates is indicated by the Number of Blocks field in the motor’s fault data.

Block n Faults A – 20 bytes of fault data (2 bytes per block), where each bit represents a fault.

Block n Faults B – 20 bytes of fault data (2 bytes per block), where each bit represents a fault.

Offset Item Bytes Range

12 Block 1 Faults A 1 Bits 0 - 7 are Flags

13 Block 1 Faults B 1 Bits 0 - 7 are Flags

.

.

.

Block faults can repeat for a total of 10 blocks

.

.

.

30 Block 10 Faults A 1 Bits 0 - 7 are Flags

31 Block 10 Faults B 1 Bits 0 - 7 are Flags

Bit Meaning

0 Inverter Disabled

1 Vehicle Not Located

2 Unexpected Slave Module Reset

3 In Diagnostic Mode

4 In Boot load Mode

5 Slave Module Not Responding

6 Soft Start Not Complete

7 Reserved

Bit Meaning

0 Over-Current Fault

1 Under-Voltage Fault

2 Over-Voltage Fault



Motor Fault Data - MagneMover LITE

Data reported for MagneMover LITE motors. If the Host Controller requests motor status for a non-existent Path, motor index, or both, all bytes in this field are set to 0.

Note that MagneMover LITE motors may not populate every driver board error slot in the motor’s fault data. For such motors, the number of driver board errors the motor actually pop-ulates is indicated by the Number of Driver Boards field in the motor’s fault data.

Master Board Faults A – 1 byte of fault data, where each bit represents a fault. Refer to the MM LITE Motor Fault table for detailed bit descriptions.

3 Motor Stall Detected

4 Slave Module Not Configured

5 Over-Temperature Fault

6 Hall Effect Sensor Fault

7 Slave Communication Fault

Offset Item Bytes Range

12 Master Board Faults A 1 Bits 0 - 7 are Flags

13 Master Board Faults B 1 Bits 0 - 7 are Flags

14 Driver Board 1 Faults 1 Bits 0 - 7 are Flags

.

.

.

Driver board faults can repeat for a total of 4 driver boards

.

.

.

17 Driver Board 4 Faults 1 Bits 0 - 7 are Flags

Bit Meaning

0 Reserved

1 Switch position fault

2 Propulsion power not ready

3 Under voltage fault

4 Over voltage fault

5 Over temperature fault

6 Over current fault

7 Configuration fault

Bit Meaning



Master Board Faults B – 1 byte of fault data, where each bit represents a fault.

Driver Board n Faults – 4 bytes of fault data (1 byte per driver board), where each bit repre-sents a fault. Note that MagneMover LITE motors may not populate every driver board in the motor’s fault data. For such motors, the number of driver boards the motor actually populates is indicated by the Number of Driver Boards field in the motor’s fault data.

See Also

MMI_B5_StatusRequest on page 4-16

Bit Meaning

0 - 7 Reserved

Bit Meaning

0 Estimated coil temperature too high

1 Under voltage fault

2 Over voltage fault

3 Over temperature fault

4 - 7 Reserved



MMI_node_command_status

Type

Host Controller HLC

Purpose

Reports the status of all Node commands in the transport system. This array is updated when-ever a Node related function is executed or when requested using the MMI_B5_StatusRequest function block.

This array must be sized to the maximum Node ID configured in the transport system. Refer to Table A-1, MagneMotion Transport System Limits, on page A-5 for the maximum number of Nodes per system. This array should not be defined larger than the maximum shown in Table A-1.

The MMI_node_command_status array is updated only in response to an MMI_B6_SetEntry-Signal or MMI_B6_SetExitSignal command sent from the PLC to the HLC. This SDT array can be used to handshake the Terminus Node commands so the PLC logic can know that the HLC received a Terminus Node command, and either rejected it with an appropriate error code, or accepted it for processing.

SDT Format

Field Descriptions

Arguments

Received_Count – Engine-managed counter that increments when a command is acknowl-edged as received by the HLC (status of 0x00 to 0x3F).


MMI_node_command_status

sdt_MMI_node_command_status

Yes minNodeID..maxNodeID*

* The SDT must specify the same range as specified in the Node Configuration File.


Received_Count Double Word[Unsigned]/Bit String[32-bit] 0 - 0xFFFFFFFF

Accepted_Count Double Word[Unsigned]/Bit String[32-bit] 0 - 0xFFFFFFFF

LastCmdRcv_Status Word[Unsigned]/Bit String[16-bit] 0x00 - 0x80



Accepted_Count – Engine-managed counter that increments when a command is accepted (status of 0x00).

LastCmdRcv_Status – Status (completed or failed) updated by the HLC upon completion of the command, see HLC Status Codes on page 4-63.

See Also

MMI_B6_SetEntrySignal on page 4-19,MMI_B6_SetExitSignal on page 4-21,MMI_node_status on page 4-46



MMI_node_controller_status

Type

Host Controller HLC

Purpose

Reports the status of all Node Controllers in the transport system. This array is updated as specified by tNodeController_PollRate or when requested using the MMI_B5_StatusRequest function block.

This SDT is an array indexed by Node Controller ID. Index 0 is not used since Node Control-ler 0 in the transport system is invalid. Refer to Table A-1, MagneMotion Transport System Limits, on page A-5 for the maximum number of Node Controllers per system. This array should not be defined larger than the maximum shown in Table A-1.

NOTE: The index for each Node Controller must exist in the Global Label List, otherwise the PLC will generate an Operation Error when it attempts to write status informa-tion to an undefined index (refer to PLC Troubleshooting on page 5-3).

The High Level Controller must be in the operational state.

SDT Format

Field Descriptions

Arguments



MMI_node_controller_status

sdt_MMI_node_controller_status

Yes minNodeControllerID.. maxNodeControllerID*




Present Bit 0 - 1

State Word[Signed] 0 - 3



Present – Equal to 0 if the Node Controller is not present (and remainder of message is invalid) or 1 if the Node Controller specified is present based on the system configuration.

State – Designates the state of the Node Controller.

See Also

MMI_B5_StatusRequest on page 4-16MMI_HLC_status on page 4-33

Value Description

0 MMI_node_controller_status Initialized – The SDT has been initialized, but no data has been reported by the HLC.

1 Initialization – Loading the configuration file or an error was detected in the configu-ration preventing the Node Controller from exiting this state. Consult the Node Control-ler log for additional details when a Node Controller will not exit the Initialization state.

2 Disconnected – The TCP connection from the High Level Controller to this Node Con-troller is down.

3 Operational – The High Level Controller connection to this Node Controller is estab-lished and the Node Controller is operational.



MMI_node_status

Type

Host Controller HLC

Purpose

Reports the status of all Nodes in the transport system. This array is updated as specified by tNode_PollRate or when requested using the MMI_B5_StatusRequest function block.

This SDT is an array indexed by Node ID.

This array must be sized to the maximum Node ID configured in the transport system. For example if the maximum Node ID is 4, this array must be dimensioned to 4. Refer to Table A-1, MagneMotion Transport System Limits, on page A-5 for the maximum number of Nodes per system. This array should not be defined larger than the maximum shown in Table A-1.

NOTE: The index for each Node must exist in the Global Label List, otherwise the PLC will generate an Operation Error when it attempts to write status information to an unde-fined index (refer to PLC Troubleshooting on page 5-3).

The High Level Controller must be in the operational state.

SDT Format

Field Descriptions


MMI_node_status sdt_MMI_node_status Yes minNodeID..maxNodeID*




Present Bit 0 - 1

NodeType Word[Unsigned]/Bit String[16-bit] 0 - 9

VehicleID Word[Unsigned]/Bit String[16-bit] 0 - 65535

RequestedPosition Word[Unsigned]/Bit String[16-bit] 0 - 8

TerminusSignals Word[Unsigned]/Bit String[16-bit] Bits 0 - 7 are Flags

ReportedPosition Word[Unsigned]/Bit String[16-bit] 0 - 8

DeviceStatus Word[Unsigned]/Bit String[16-bit] 0 - 3



Arguments


Present – Equal to 0 if the Node is not present (remainder of data in message is invalid) or 1 if the Node is present.

NodeType – The type of the Node for which status is provided (refer to Node Types on page 3-25).

VehicleID – The ID of the vehicle currently navigating this Node or 0 when the Node is idle and no vehicle is navigating the Node.

RequestedPosition

For a NodeType of 0, 4, 5, or 9 this byte is a 0.

For a NodeType of 1, 2, 3, 6, 7, or 8 this is the position the Node apparatus was last requested to move to or zero if no position.

Value Node Type Transport Systems

0 Relay Node MagneMover LITE, QuickStick

1 Merge Node MagneMover LITE, QuickStick

2 Diverge Node MagneMover LITE, QuickStick

3 Turntable Node QuickStick

4 Terminus Node QuickStick

5 Simple Node MagneMover LITE, QuickStick

6 Host Switch Node QuickStick

7 Shuttle Node QuickStick

8 Merge - Diverge Node MagneMover LITE

9 Gateway Node MagneMover LITE, QuickStick

Value Description

0 No switch present or position has not yet been requested

1 Switch position 1 (straight if merge/diverge)

2 Switch position 2 (curve if merge/diverge)

3 Switch position 3

4 Switch position 4

5 Switch position 5



TerminusSignals – Valid for NodeType 4 only. For all other Node types, the terminus signal bits are 0. These are the terminus signals for the Node where the bits have the following mean-ings.

ReportedPosition


For a NodeType of 1, 2, 3, 6, 7, or 8 this is the position the Node apparatus was last reported to be in or zero if no position.

6 Switch position 6

7 Switch position 7

8 Switch position 8

Bit Description

0 ENTRY_REQUESTED (last input state)

1 EXIT_ALLOWED (last input state)

2 - 3 Reserved

4 ENTRY_CLEAR (output)

5 ENTRY_ALLOWED (output)

6 EXITING (output)

7 Reserved

Value Description

0 No switch present

1 Switch position 1 (straight if merge/diverge)

2 Switch position 2 (curve if merge/diverge)

3 Switch position 3

4 Switch position 4

5 Switch position 5

6 Switch position 6

7 Switch position 7

8 Switch position 8

Value Description



Device Status


For a NodeType of 1, 2, 3, 6, 7, or 8 this is the status of the device affiliated with the Node (these are generic to cover any type of switch apparatus including generic digital I/O switches, electromagnetic switches, turntables, or a user provided switch.).

See Also

MMI_B5_StatusRequest on page 4-16MMI_node_command_status on page 4-42

Value Description

0 No Device Present

1 Initializing

2 Faulted

3 Operational



MMI_path_command_status

Type

Host Controller HLC

Purpose

Reports the status of all Path commands in the transport system. This array is indexed by Path ID. Note that an Index of 0 is not used since Path ID 0 in the transport system is invalid.

This array must be sized to the maximum Path ID configured in the transport system. Refer to Table A-1, MagneMotion Transport System Limits, on page A-5 for the maximum number of Paths per system. This array should not be defined larger than the maximum shown in Table A-1.

The MMI_path_command_status array is updated only in response to a command sent from the PLC to the HLC that changes the status of a Path.

This SDT array can be used to handshake the Path commands so the PLC logic can know that the HLC received a Path command, and either rejected it with an appropriate error code, or accepted it for processing. For Path commands that take significant time to complete execu-tion (startup and reset), this SDT array can be consulted to determine if the command com-pleted and whether it completed successfully or an error occurred.

SDT Format

Field Descriptions


MMI_path_command_sta-tus

sdt_MMI_path_command_status

Yes minPathID..maxPathID*



Sent_Count Double Word[Unsigned]/Bit String[32-bit] 1 - 0xFFFFFFFF

Received_Count Double Word[Unsigned]/Bit String[32-bit] 1 - 0xFFFFFFFF

Accepted_Count Double Word[Unsigned]/Bit String[32-bit] 1 - 0xFFFFFFFF

LastCmdRcv Word[Unsigned]/Bit String[16-bit] 0xB0 - 0xBA

LastCmdRcv_Status Word[Unsigned]/Bit String[16-bit] 0x00 - 0x80

LastCmdAcc Word[Unsigned]/Bit String[16-bit] 0xB0 - 0xBA

LastCmdAcc_Status Word[Unsigned]/Bit String[16-bit] 0x00 - 0x80



Arguments

Sent_Count – Engine-managed counter that increments when a command is sent from the Host.

Received_Count – Engine-managed counter that increments when a command is acknowl-edged as received by the HLC (status of 0x00 to 0x3F)

Accepted_Count – Engine-managed counter that increments when a command is accepted (status of 0x00)

LastCmdRcv – Last command received for a given path.

LastCmdRcv_Status – Status (accepted or rejected) updated by the HLC upon receipt of the command, see HLC Status Codes on page 4-63.

LastCmdAcc – Last command accepted for a given path.

LastCmdAcc_Status – Status (completed or failed) updated by the HLC upon completion of the command, see HLC Status Codes on page 4-63.

See Also

MMI_B0_MoveVehicleToStation on page 4-4MMI_B1_MoveVehicleToPosition on page 4-7MMI_B2_Startup on page 4-10MMI_B3_ResumeMovement on page 4-12MMI_B4_SuspendMovement on page 4-14MMI_B5_StatusRequest on page 4-16MMI_B8_Reset on page 4-23MMI_path_status on page 4-52



MMI_path_status

Type

Host Controller HLC

Purpose

Reports the status of all Paths in the transport system. This array is updated as specified by tPath_PollRate or when requested using the MMI_B5_StatusRequest function block.

This SDT is an array indexed by Path ID. Index 0 is not used since Path ID 0 in the transport system is invalid.

This array must be sized to the maximum Path ID configured in the transport system. For example if the maximum Path ID is 10, this array must be dimensioned to 10. Refer to Table A-1, MagneMotion Transport System Limits, on page A-5 for the maximum number of Paths per system. This array should not be defined larger than the maximum shown in Table A-1.

NOTE: The index for each Path must exist in the Global Label List, otherwise the PLC will generate an Operation Error when it attempts to write status information to an unde-fined index (refer to PLC Troubleshooting on page 5-3).

SDT Format

Field Descriptions


MMI_path_status sdt_MMI_path_status Yes minPathID..maxPathID*




Present Bit 0 - 1

NumVehicles Word[Unsigned]/Bit String[16-bit] 0 - 400

PathState Word[Unsigned]/Bit String[16-bit] 0 - 4

PathMoveStatus Word[Unsigned]/Bit String[16-bit] Bits 0 - 7 are Flags

UpstreamCommStatus Word[Unsigned]/Bit String[16-bit] 0 - 1

DownstreamCommStatus Word[Unsigned]/Bit String[16-bit] 0 - 2



Arguments


Present – Path status.

NumVehicles – The number of vehicles on the specified Path.

PathState – The current state of the Path.

PathMoveStatus – Bit field, when all bits are low (0), movement on the Path is enabled. When any bit is high (1), movement on the Path is suspended and the bits describe the reason for movement suspension.

Value State

0 Path is not present (remainder of data in message is invalid)

1 Path is present

Value Description

0 Initialization

1 Startup (locating vehicles)

2 Operational

3 Reset in progress

4 Programming in progress

Bit Description

0 Suspended by Suspend Path Command

1 E-Stop Active

2 Interlock Active

3 - 7 Reserved



UpstreamCommStatus – The state of the communication link at the upstream end of this Path.

DownstreamCommStatus – The state of the communication link at the downstream end of this Path.

See Also

MMI_B5_StatusRequest on page 4-16MMI_path_command_status on page 4-50

Value Description

0 Link OK

1 Link FAILED

Value Description

0 Link OK

1 Link FAILED

2 Link Not Configured (no physical connection configured)



MMI_vehicle_order_status

Type

Host Controller HLC

Purpose

Reports the status of all vehicle commands in the transport system. This SDT is an array indexed by vehicle ID. The MMI_vehicle_order_status array is updated only in response to executing an MMI_B0_MoveVehicleToStation, an MMI_B0_MoveVehicleToStation, or an MMI_B9_DeleteVehicle Function Block to send a command from the PLC to the HLC.

This array must be sized the same as the MMI_vehicle_status array. Refer to MMI_vehicle_status for more details. Refer to Table A-1, MagneMotion Transport System Limits, on page A-5 for the maximum number of vehicles per system. This array should not be defined larger than the maximum shown in Table A-1.

This SDT array can be used to handshake vehicle orders so the PLC logic can know that the HLC received a vehicle order, accepted/rejected it, and that the order completed (the vehicle arrived at the ordered destination).

SDT Format

Field Descriptions


MMI_vehicle_order_sta-tus

sdt_MMI_vehicle_order_sta-tus

Yes minVehicleID..maxVehi-cleID*



VehicleID Array index 1 - 65535

LastOrderRcv_Num Double Word[Unsigned]/Bit String[32-bit] 0 - 0xFFFFFFFF

LastOrderRcv_Type Word[Unsigned]/Bit String[16-bit] 0xB0, 0xB1, 0xB9

LastOrderRcv_Status Word[Unsigned]/Bit String[16-bit] 0x00 - 0x3F

LastOrderAcc_Num Double Word[Unsigned]/Bit String[32-bit] 0 - 0xFFFFFFFF

LastOrderAcc_Type Word[Unsigned]/Bit String[16-bit] 0xB0, 0xB1, 0xB9

LastOrderAcc_Status Word[Unsigned]/Bit String[16-bit] 0x00 - 0x80



Arguments

VehicleID – The ID of the vehicle for which order status is being reported.

LastOrderRcv_Num – The HLC writes the order number of the most recently received vehi-cle order (status of 0x00 to 0x3F) for the corresponding vehicle ID to this field. PLC logic can use this field for a particular vehicle to determine if an order was received by the HLC and optionally, to retry the command after a time-out (nominally 5 seconds) if the order number in the original order doesn’t match this field indicating the HLC never received the order.

NOTE: A LastOrderRcv_Num of zero indicates that a given vehicle has not been given a command.

The Engine generates a unique vehicle order number from 1 to 0xFFFFFFFF for each vehicle command. The vehicle order number counter will roll-over to 1 after it reaches it maximum value.

LastOrderRcv_Type – The HLC writes the order type of the most recently received vehicle order (status of 0x00 to 0x3F) for the corresponding vehicle ID to this field.

LastOrderRcv_Status – The HLC writes an acceptance or rejection status to this field upon receiving a new vehicle order from the PLC.

LastOrderAcc_Num – The HLC writes the order number of the most recently received and accepted vehicle order (status of 0x00) for the corresponding vehicle ID to this field when the order has been accepted by the Node Controller. PLC logic can use this field to know whether an order received by the HLC (LastOrderRcv_Num = order number for the most recently issued order) has been accepted or not. When this field matches LastOrderRcv_Num, the

Value Description

0xB0 Station Order

0xB1 Position Order

0xB9 Vehicle Delete Order

Value Description

0x00 The order number in LastOrderRcv_Num that corresponds to the matching order number in the last MMI_B0_MoveVehicleToStation or MMI_B1_MoveVehicleToPo-sition from the PLC is accepted.

0x01 - 0x3F The last order received from the PLC with the order number matching LastOrderRcv_Num has been rejected. Refer to HLC Status Codes on page 4-63 for the meanings of the rejection code.



PLC knows the command has been accepted by the HLC. This also implies the HLC has writ-ten a 0x00 to the LastOrderRcv_Status field.

NOTE: A LastOrderAcc_Num of zero indicates that a given vehicle has not been given a command.

The Engine generates a unique vehicle order number from 1 to 0xFFFFFFFF for each vehicle command. The vehicle order number counter will roll-over to 1 after it reaches it maximum value.

LastOrderAcc_Type – The HLC writes the order type of the last vehicle order type that was accepted (status of 0x00) for the corresponding vehicle ID to this field.

LastOrderAcc_Status – Status (completed or failed) updated by the HLC upon completion of the command, see HLC Status Codes on page 4-63.

See Also

MMI_B0_MoveVehicleToStation on page 4-4MMI_B1_MoveVehicleToPosition on page 4-7MMI_B9_DeleteVehicle on page 4-25MMI_vehicle_status on page 4-58

Value Description

0xB0 Station Order

0xB1 Position Order

0xB9 Vehicle Delete Order



MMI_vehicle_status

Type

Host Controller HLC

Purpose

Reports the status of all vehicles in the transport system. This array is updated as specified by tVehicle_PollRate or when requested using the MMI_B5_StatusRequest function block.

This SDT is an array indexed by vehicle ID. Index 0 is not used since vehicle ID 0 in the transport system is invalid.

Refer to Table A-1, MagneMotion Transport System Limits, on page A-5 for the maximum number of vehicles per system. This array should not be defined larger than the maximum shown in Table A-1.

NOTE: The index for each Vehicle must exist in the Global Label List, otherwise the PLC will generate an Operation Error when it attempts to write status information to an undefined index (refer to PLC Troubleshooting on page 5-3).

Vehicle status information for any vehicles located on Paths that are reset will be cleared.

SDT Format

Field Descriptions


MMI_vehicle_status sdt_MMI_vehicle_status Yes minVehicleID..maxVehi-cleID*




Present Bit 0 - 1

PathID Word[Unsigned]/Bit String[16-bit] 1 - 65535

DestPathID Word[Unsigned]/Bit String[16-bit] 0 - 65535

Position FLOAT (Single Precision) 0 - 41.0 (m)*

Velocity FLOAT (Single Precision) 0.001 - 4.0 (m/s)*



Arguments


Present – Vehicle status.

PathID – The ID of the Path where the vehicle is currently located.

DestPathID – The ID of the Path where the vehicle is headed. Equal to ‘0’ if the vehicle is not moving.

Position – The last reported position (in meters) of the vehicle, relative to the start of the spec-ified Path (expressed as a 32-bit single precision floating-point number). Zero position is defined as the midpoint of the vehicle at the beginning of the Path.

Velocity – The last reported velocity (in meters per second) of the vehicle on the specified Path (expressed as a 32-bit single precision floating-point number).

Command – If a Move command is in progress (not completed), this is the header of that command.

Command Word[Unsigned]/Bit String[16-bit] 0x00, 0xB0, 0xB1

Flags Word[Unsigned]/Bit String[16-bit] Bits 0 - 7 are Flags

CommandedPosition FLOAT (Single Precision) 0 - 41.0 (m)†

DestStationID Word[Unsigned]/Bit String[16-bit] 1 - 65535

* This is the value from the motor converted from the fixed point value used by the motor.† This is the value that was sent by the Host Controller.

Value State

0 Vehicle is not present (remainder of data in message is invalid)

1 Vehicle is present

Value Description

0x00 No command is in progress

0xB0 Move To Station

0xB1 Move to Position




Flags – Vehicle status indicators.

CommandedPosition – If a Move (to station or position) command is in progress (not com-pleted), this is the commanded position (expressed as a 32-bit single precision floating-point number) on the specified Path. If commanded to a station, this is the location of the station. Equal to ‘0’ if the vehicle is not moving.

DestStationID – The ID of the Station the vehicle is heading to when under a station order. This field is only valid when the Command field is 0xB0.

See Also

MMI_B0_MoveVehicleToStation on page 4-4MMI_B1_MoveVehicleToPosition on page 4-7MMI_B5_StatusRequest on page 4-16MMI_B9_DeleteVehicle on page 4-25MMI_vehicle_order_status on page 4-55

Bit Description

0 Vehicle Signal

0 – The motor does not detect the vehicle.

1 – The motor currently in charge of the vehicle detects the vehicle.

1 Obstructed Status

0 – The vehicle is not obstructed and able to acquire permission to move further.

1 – The vehicle is obstructed and unable to acquire permission to move further because of a vehicle in the way, a hardware fault, or movement is suspended.

2 Jammed Status

0 – The vehicle is making progress and able to acquire permission to move further.

1 – The vehicle is not making progress moving towards the position it has most recently been granted permission to move to whether that position is on the way to its final destination or the actual final destination (this can happen when a vehicle is held back by some external force including a foreign object jamming a vehicle on the guideway or even a human physically holding the vehicle back). The motor will continue to apply force on the vehicle to try and move it indefinitely.

3 Loaded Status

0 – The motors are using Unloaded PID values for closed loop control.

1 – The motors are using Loaded PID values for closed loop control.

4 - 7 Reserved



MMI_send_queue

Type

Host Controller HLC

NOTE: This SDT is for internal use only. The documentation below is only provided for ref-erence.

Purpose

The MMI Engine utilizes a Queue for sending messages to the HLC. This data needs to be stored on the PLC and be accessible to the Engine. For this reason, the Send Queue Memory is stored in the Library’s Global Label List.

NOTE: Any unsent messages in the Send Queue are discarded if the connection to the HLC is disconnected.

See Also

MMI_Engine on page 4-27


Protocol and Structured Data Type ReferenceFunction Block Error Codes

Function Block Error Codes

An error code is returned to provide status when a function block completes its execution. Table 4-5 lists the meaning of each error code.

Table 4-5: Function Block Error Codes

Value Status

0x00 Execution of the function block completed successfully

0x01 Execution of the function block was attempted, but the send queue was full (too many messages have been queued)


Protocol and Structured Data Type ReferenceHLC Status Codes

HLC Status Codes

A status code is returned to acknowledge the receipt, rejection, or completion of a Path com-mand, vehicle order, or Terminus Node command. Table 4-6 lists the meaning of each status code.

Table 4-6: HLC Status Codes

Value Status

0x00 Command Accepted

0x01 Command Rejected – Invalid Vehicle ID (specified Vehicle does not exist)

0x02 Command Rejected – Invalid Station ID (specified Station does not exist)

0x03 Command Rejected – Invalid Path ID (specified Path does not exist)

0x04 Command Rejected – Invalid Position (off Path)

0x05 Command Rejected – E-Stop signal active

0x06 Command Rejected – Interlock signal active

0x07 Command Rejected – Movement Suspended

0x08 Command Rejected – Startup sequence already complete

0x09 Command Rejected – Startup sequence already started

0x0A Command Rejected – Startup sequence not initiated/completed

0x0B Command Rejected – Invalid parameter(acceleration, velocity, direction, Path, Node, set signal, signal level)

0x0C Command Rejected – Initialization not complete

0x0D Command Rejected – Reset Active

0x0E Command Rejected – No vehicle record available

0x0F Command Rejected – Terminus Node busy

0x10 Command Rejected – Programming Active

0x40 Command Failed – Unable to acquire status from motors

0x41 Command Failed – Unable to complete (consult NC/HLC logs)

0x42 Command Failed – Timed out

0x80 Command Completed Successfully


Troubleshooting 5

Overview

This chapter describes the common difficulties that may be encountered when using MagneMotion’s Mitsubishi PLC TCP/IP Library. Included in this chapter are:

• TCP/IP Communications Troubleshooting.

• PLC Troubleshooting.

For assistance, refer to Contact MagneMotion Technical Support on page 5-4.


TroubleshootingTroubleshooting

Troubleshooting

TCP/IP Communications

This section describes the common difficulties that may be encountered when using TCP/IP communications, and general solutions.

Table 5-1: Initial Host Controller Communications Troubleshooting

Symptom Problem Solution

Vehicles do not move to the expected positions.

The Vehicle Order message may be configured incor-rectly.

Ensure the distance to the positions is measured from the start of the Path.

Ensure the correct Path is specified.

Vehicles do not cross a Gateway Node.

Path in the target system is suspended.

Issue a Resume command to the Path.

Wait for Interlock or E-Stop on the Path to be cleared.

Duplicate vehicle ID exists in the target system.

Ensure the Gateway Node is defined in the Configuration File such that there are no overlapping vehicle IDs.

Vehicles do not move. The motor may be unable to sense the magnet array on the vehicle.

Manually move the vehicle to a different position on the guideway, and re-start move-ment.

There may be a physical obstruction.

Ensure there are no obstruc-tions to vehicle movement.

The vehicle may be binding on the guideway.

Ensure the vehicle can move freely.

The Host Controller will not con-nect to the High Level Controller even though it did previously.

There is another device con-nected to the High Level Con-troller.

When the High Level Con-troller is available again, reconnect using the IP address previously used.

The IP address of the HLC has been changed.

Connect to the HLC using the Node Controller Web Inter-face to verify the address.

The network is not connected or there are network prob-lems.

Verify all network connec-tions.


TroubleshootingTroubleshooting

PLC Troubleshooting

This section describes some basic difficulties that may be encountered when using the Mit-subishi Q or L PLC, and general solutions.

Table 5-2: Basic PLC Communications Troubleshooting

Symptom Problem Solution

Link Para Error The Ethernet module is not configured correctly.

Verify configuration of the external Ethernet module, refer to Define the Integrated Ethernet Connection on page 2-4 or Define the Exter-nal Ethernet Connection on page 2-6.

Operation Error The sizes of the array index and the matching Engine input are not the same.

Ensure all array indices and matching SDTs are config-ured the same and are sized to match the Node Configura-tion File.


TroubleshootingContact MagneMotion Technical Support

Contact MagneMotion Technical Support

To help you receive the most value from the MagneMotion Support Specialists, have the fol-lowing information ready before contacting MagneMotion Technical Support.

1. Download and save the Node Controller and High Level Controller logs.

2. Record the serial numbers from the motors and Node Controllers.

3. Provide the location of the transport system.

4. Provide the name of the person to contact, e-mail address, and telephone number.

5. List any error codes received during the failure.

6. Prepare a detailed description of the events leading up to the error.

• How long has the equipment been in operation?

• Was any work done on the equipment prior to the error?

• What command was the equipment performing when the error occurred?

• List all actions taken after the error was performed. What were the results of those actions?

• Is there any other information that may assist our Specialist?

7. Contact MagneMotion Technical Support:

Main Office Technical Support

MagneMotion, Inc.139 Barnum RoadDevens, MA 01434USAPhone: +1 978-757-9100Fax: +1 978-757-9200

+1 [email protected]


Appendix

Overview

The following appendices are included to provide the user with a single location for additional information related to Host Controller communication.

Included in this appendix are:

• Communications protocol.

• File maintenance.

• Additional documentation.

• Transport system configuration limits.

Mitsubishi PLC TCP/IP Library User’s Manual A-1

AppendixCommunications Protocol

Communications Protocol

Communications Format

The High Level Controller supports communication with the Host Controller via TCP/IP over Ethernet. For details on the Ethernet TCP/IP protocol refer to the Host Controller TCP/IP Communication Protocol User’s Manual.

MagneMotion, Inc.A-2 990000628 Rev. A

AppendixFile Maintenance

File Maintenance

Backup Files

MagneMotion recommends regular backups of all files that may have been changed. Copies of all original and backup files should be kept at a remote location for safety.

Creating Backup Files

Backup files are not created automatically. It is the user’s responsibility to create backups of all files by copying them to safe location and naming them appropriately.

Restoring from Backup Files

Damaged files can be restored by copying the backup files into the appropriate locations and renaming them to their original name.


AppendixAdditional Documentation

Additional Documentation

Release Notes

The Release Notes for MagneMotion software include special instructions, identification of software versions, identification of new features and enhancements, and a list of known issues. The Release Notes are supplied on the CD with the software. MagneMotion recom-mends that this file be read before using the software.

Upgrade Procedure

The Upgrade Procedure provides the instructions for upgrading from one version of MagneMotion software to another. It also includes the procedures for upgrading files and drivers associated with the software. The Upgrade Procedure is supplied on the CD with the software.


AppendixTransport System Limits

Transport System Limits

Table A-1: MagneMotion Transport System Limits

Path Node Controller System

Motors 20 240*

* Limited by the number of RS-422 connections on the Node Controller (NC LITE – 4, Standard NC – 8, NC-12 – 12).

10,240

Node Controllers – – 64

Nodes 2 –* 128

Paths – –* 64

Stations 32 –* 2,048

Vehicles 50 384* 2,560

Table A-2: MagneMotion Transport System Motion Limits

Acceleration Velocity Thrust*

* Thrust at 25% duty cycle.Nominal Vehicle Gap for MM LITE is 1 mm for G3 and 1.5 mm for G4.2.Nominal Vehicle Gap for QS 100 and QS HT is 3 mm.Nominal Vehicle Gap for QS HT2 is 9.5 mm.

Payload

MagneMover® LITE 2.0 m/s2 2.0 m/s 6 N/cycle 2 kg [4.4 lb]†

† Single puck maximum payload is 1 kg, tandem puck maximum payload is 2 kg.

QuickStick® 100 24 m/s2 2.5 m/s 20 N/cycle 100 kg [220 lb]

QuickStick® HT 24 m/s2 4.0 m/s 40 N/cycle 4500 kg [9900 lb]

QuickStick® HT2 60 m/s2 2.5 m/s 225 N/cycle 4500 kg [9900 lb]


Appendix



Glossary

Block: See Motor Block.

Bogie: An structure underneath a vehicle to which a magnet array is attached. The structure is then attached to the vehicle through a bearing allowing indepen-dent rotation.

Brick-wall Headway: Space maintained between vehicles to ensure that a trailing vehicle is able to stop safely if the leading vehicle stops suddenly (‘hits a brick wall’).

Component: The main parts that form a MagneMotion transport system. Also called system components, these include Motors and Controllers.

Configurator: The application used to define and edit the basic operating parameters of the transport system stored in the Node Configuration File.

Controller: A device which monitors and controls the operating conditions of the equip-ment being monitored. In a MagneMotion transport system these include the High Level Controller, Motor Controller, Node Controller, and Host Control-ler.

Cycle Length: Cycle Length is the distance between the centerlines of two like poles on the magnet array.

Demonstration Script: A text file used with the NCHost TCP Interface Utility for test or demon-stration purposes to move vehicles on the transport system. Also called a Demo Script.

Design Specifications: The unique parameters for a specific MagneMotion transport system.

Downstream: The end of a motor or Path where a vehicle exits if it is travelling in the default forward direction. The vehicle typically enters the motor or Path on the Upstream end.

Downstream Gap: The physical distance from the end of the stator in one motor to the beginning of the stator in the next motor downstream on the same Path. This includes the Motor Gap.

E-Stop: See Emergency Stop.

Emergency Off: A user-supplied device that disconnects AC power to the transport system.

Emergency Stop: A user-supplied circuit with a locking button that anyone can press to stop motion in the transport system. It may be wired through the Digital I/O ports on the standard Node Controller.

Mitsubishi PLC TCP/IP Library User’s Manual G-1

GlossaryEMO

EMO: See Emergency Off.

Forward Direction: The default direction of movement, from Upstream to Downstream, on a MagneMotion transport system.

Global Directives: The Demonstration Script commands that define the general operating charac-teristics for all vehicles specified. See also Vehicle Directives.

Guideway: A component of the Track System that consists of rails or other devices in con-tact with the Vehicle, either through wheels or low friction runners on the vehi-cle, to ensure the vehicles are maintained in the proper relationship to the motors. In the MagneMover LITE system this is the integral rails mounted on the motors.

High Level Controller: The application in a Node Controller that communicates with the Host Con-troller. In a transport system with only one Node Controller, it runs both the Node Controller and High Level Controller applications.

HLC: See High Level Controller.

HLC Control Group: The portion of a multi-HLC LSM transport system under control of a specific HLC.

Host Application: The user’s software, running on the Host Controller, that provides monitoring and control of the transport system.

Host Controller: The user supplied controller for the operation of the transport system. The con-troller may be either a PC-Based Controller or a Programmable Logic Con-troller.

Host Control Session: A user session between an application running on the Host Controller (such as the NCHost TCP Interface Utility) and a High Level Controller that allows the user to issue commands to control all aspects of Transport System opera-tion as well as to actively monitor Transport System status.

Host Status Session: A user session between an application running on the Host Controller (such as the NCHost TCP Interface Utility) and a High Level Controller that only allows the user to actively monitor Transport System status.

ID: The software labels used to uniquely identify various components of the trans-port system to ensure proper execution of commands involving vehicle posi-tion, vehicle destination, and transport system configuration. ID types include vehicle and Path.

Interlock: A user-supplied circuit used to stop motion in the transport system. It is wired through the Digital I/O ports on the standard and NC-12 Node Controllers.

Keepout Area: An area of a Path where the motors will not allow a vehicle to enter unless it has permission from the motors to move past the area.

Logic Power: The power used for the controllers and signals. See also, Propulsion Power.

LSM: Linear Synchronous Motor. See MagneMover® LITE and QuickStick®.

MagneMotion, Inc.G-2 990000628 Rev. A

GlossaryPC-Based Controller

MagneMover® LITE: A MagneMotion linear synchronous motor with integrated guideways and vehicles (pucks) that enables quick, efficient conveyance of loads up to 1 kg on a single vehicle (2 kg on a tandem puck).

Magnet Array: The magnets attached to the Vehicle. It is the motor secondary, moved by the primary in the motor.

MM LITE: See MagneMover® LITE.

Motor: See LSM.

Motor Block: A discrete motor primary section (coil or set of coils) within a motor that can be energized independently. This section can contain only one moving vehicle during transport system operation.

Motor Controller: The controller for each motor that communicates vehicle positions and other information to the Node Controller. It is internal to the motor on MagneMover LITE and QuickStick 100 motors and external on QuickStick HT motors.

Motor Gap: The physical distance between two motors mounted end to end. This does not include the distance from the end of the stator to the end of the motor housing.

NC: See Node Controller.

Node: A junction defined as the beginning, end, or intersection of Paths. The differ-ent Node types are defined by their use: Simple, Relay, Terminus, Merge, Diverge, etc.

Node Configuration File: The XML file unique to the transport system containing the basic operat-ing parameters of the transport system. A copy of the Node Configuration File is uploaded to each Node Controller in the transport system.

Node Controller: The controller that coordinates vehicle movements along a Path or Paths of motors. The Node Controller is responsible for the motors on all Paths origi-nating from Nodes that the Node Controller is responsible for.

There can be multiple Node Controllers in a transport system each responsible for a subset of the Nodes within the transport system.

NRTL/ATL: Nationally Recognized Test Lab/Accredited Test Lab.

NRTL organizations have been recognized by OSHA in accordance with 29 CFR 1910.7 to test and certify equipment or materials (products).

ATL organizations have been evaluated by Accreditation bodies to ISO/IEC 17025 for testing and calibration laboratories.

Path: A designation for one or more motors placed end to end, which defines a linear route for vehicle travel. A Path begins at the Upstream end of the first motor in the series and ends at the Downstream end of the last motor in the series. All Paths must begin at a Node and the beginning of a Path is always the zero posi-tion for determining vehicle positions along that Path.

PC-Based Controller: The user supplied computer that provides control and sequencing for the operation of the transport system.


GlossaryPLC

PLC: See Programmable Logic Controller.

Position: A specific location on a Path, measured from the beginning of that Path, used as a vehicle destination. Position zero on any Path is defined as the leading edge of the first LSM in the Path.

A vehicle at a specific position has its midpoint over that location on the Path.

Power Supply: The equipment used to convert facility AC power to the correct voltages for the transport system.

Programmable Logic Controller: The user supplied dedicated controller consisting of Processor and I/O modules that provides control, sequencing, and safety interlock logic for the operation of the transport system.

Propulsion Power: The power used for vehicle movement. See also, Logic Power.

Puck: A pre-configured vehicle for use on MagneMover LITE transport systems. See also, Vehicle.

QS: See QuickStick®.

QuickStick®: A MagneMotion linear synchronous motor that enables quick, efficient con-veyance of large loads using user designed guideways and vehicles. Quick-Stick 100 (QS 100) motors move loads up to 100 kg (220 lb) per vehicle and QuickStick High Thrust (QS HT) motors move loads up to 4,500 kg (9,900 lb) per vehicle.

QuickStick® System: A group of specific components that contribute to a Transport System. These components include QuickStick® motors, Node Controllers, Motor Controllers (if applicable), Magnet Arrays, and other parts available from MagneMotion.

Single Vehicle Area: An area of a Path where only one vehicle may move at any time. Other vehi-cles on the Path must form a queue and wait before entering this area until the previous vehicle leaves the area. This option allows one vehicle to move back-ward and forward along a portion of a Path without interfering with any other vehicles.

Station: A specific location on a Path, measured from the beginning of that Path and identified with a unique ID, used as a vehicle destination.

Stator: The stationary part of the motor over which the magnet array is moved.

Switch: The mechanical guide for positioning a vehicle through merging or diverging guideway sections.

Sync Zone: An area where vehicle motion may be synchronized with other moving sys-tems through direct control of the motor by the Host Controller.

System Component: The main parts that form a Transport System. Also called components, these include Motors and Controllers.

Tandem Vehicle: A vehicle designed to carry larger loads that uses dual bogies (two magnet arrays on pivoting carriers linked to the vehicle) to provide enough thrust.


GlossaryZero Point

Track System: The components that physically support and move vehicles. For a Quick-Stick-based transport system, this includes a Guideway, one or more Quick-Stick® motors, and mounting hardware. For a MagneMover LITE transport system this includes the MagneMover® LITE components and stands.

Transport System: The components that collectively move user material. This includes the Motors, external Motor Controllers (if applicable), Track System, Node Con-trollers, Vehicles, cables, and hardware.

Upstream: The end of a motor or Path where a vehicle enters if it is travelling in the default forward direction. The upstream end of all Paths are connected to Node Controllers. The vehicle typically exits the motor or Path on the Downstream end.

V-Brace: The mechanical fixture used to align and secure MagneMover LITE guide rail sections.

Vehicle: The independently controlled moving element in a MagneMotion transport system. The vehicle consists of a platform that carries the payload and a pas-sive magnet array to provide the necessary propulsion and position sensing. All vehicles on Paths connected through Nodes must be of the same length.

The transport system constantly monitors and controls vehicle position and velocity for the entire time the vehicle is on the transport system. All vehicles are assigned a unique ID at startup and retain that ID until the transport system is restarted or the vehicle is removed or deleted.

Vehicle Directives: The Demonstration Script commands that define the individual movement characteristics for a specific vehicle. See also Global Directives.

Vehicle Gap: The distance between the bottom of the magnet array attached to a vehicle and the top surface of a motor.

Vehicle Signal: A motor software flag for each vehicle used to indicate if the vehicle is cur-rently detected on the transport system.

Vehicle Spacing: The distance between two vehicles on the same Path.

Zero Point: The position on the Upstream end of a Path that denotes the first part on which a Vehicle travels.


Glossary



Index

BBackup, A-3Backward Vehicle Movement, 2-37Bidirectional Vehicle Movement, 2-37

CCommunication Cables, identification, 1-4Computer Requirements, 1-7config.exe, see ConfiguratorConfiguration File, see Node Configuration FileConfigurator, description, 1-6Configure

Memory Map, 2-12MMI Engine, 2-12

Connect to High Level Controller, 2-2Contact MagneMotion, xviii, 5-4

DDemonstration Script, 1-7Diverge Node, 3-28

EEMO, 3-7Error Codes, 4-62, 4-63E-Stop, 2-28, 3-4Ethernet

configure PLC, 2-4, 2-6Node Controller address, 1-7

Exit Path, 2-42

FFlags

MagneMover LITE motor faults, 4-40motor downstream comm faults, 4-38motor status, 4-38


Flags (Continued)motor upstream comm faults, 4-38Path downstream comm link status, 4-54path movement status, 4-53path status, 4-53Path upstream comm link status, 4-54QuickStick motor faults, 4-39scheduler errors, 4-37terminus signals, 4-48

Forward Vehicle Movement, 2-36

GGateway Node

description, 3-35handshake, 3-22

Getting Started, 1-7

HHandshake

Terminus Node entry, 3-17Terminus Node exit, 3-20

High Level Controllercommands, 4-3connection, 2-2responses, 4-32status, 2-31

High Level Controller, identification, 1-4HLC, see High Level ControllerHost Communication Protocol, description, 1-2Host Controller, identification, 1-4

IImage Files

motor, 1-6Node Controller, 1-6

Interlock, 3-6

I-1

IndexJ

JJam Status, 4-60

LLabels, SDT, 4-32Load Status, 4-60

MMagneMotion

contact, xviii, 5-4Customer Support, 5-4

Magnet Array, identification, 1-4Manual

chapter descriptions, xviconventions, xivprerequisites, xiiirelated manuals, xvii

Memory Map, configure, 2-12Merge Node, 3-27Merge-Diverge Node, 3-33MMI Engine, configure, 2-12MMI Library, description, 1-5MMI_B0_MoveVehicleToStation, 4-4MMI_B1_MoveVehicleToPosition, 4-7MMI_B2_Startup, 4-10MMI_B3_ResumeMovement, 4-12MMI_B4_SuspendMovement, 4-14MMI_B5_StatusRequest, 4-16MMI_B6_SetEntrySignal, 4-19MMI_B6_SetExitSignal, 4-21MMI_B8_Reset, 4-23MMI_B9_DeleteVehicle, 4-25MMI_Engine, 4-27MMI_HLC_status, 4-33MMI_motor_status, 4-35MMI_node_command_status, 4-42MMI_node_controller_status, 4-44MMI_node_status, 4-46MMI_path_command_status, 4-50MMI_path_status, 4-52MMI_send_queue, 4-61MMI_vehicle_order_status, 4-55MMI_vehicle_status, 4-58Monitor

motor status, 2-34node controller status, 2-31Node status, 2-32

I-2

Monitor (Continued)Path status, 2-32transport system, 2-31vehicle status, 2-33

Motorsidentification, 1-4limits, A-5MagneMover LITE, 3-24monitor, 2-31QuickStick, 3-25reset, 2-19startup, 2-19status, 2-34, 4-35

Move Vehicles, 2-36Movement

permission, 3-17terminus node, 2-42to position, 2-38to station, 2-40

NNCHost TCP Interface Utility, description, 1-5NCHost.exe, see NCHost TCP Interface UtilityNetwork, identification, 1-4Node Configuration File

create, 1-7description, 1-6

Node Controlleridentification, 1-4limits, A-5NC LITE, identification, 1-4NC-12, identification, 1-4Standard, identification, 1-4

Node Controller Web Interface, description, 1-5node_configuration.xml, see Node Configuration FileNodes

Diverge, 3-28Gateway, 3-35limits, A-5Merge, 3-27Merge-Diverge, 3-33Relay, 3-26Shuttle, 3-32Simple, 3-31status, 2-32Terminus, 3-30Turntable, 3-29

MagneMotion, Inc.990000628 Rev. A

IndexV

Notes, xv

OObstructed Status, 4-60

PPath Recovery, 3-23Paths

exit, 2-42limits, A-5resume, 2-28startup, 2-22status, 2-32, 4-52suspend, 2-25Terminus Node, 2-42

Positionsmove to, 2-36, 2-38order, 4-7

Power Cables, identification, 1-4Power Supply, identification, 1-4

RRelay Node, 3-26Reset Transport System, 2-19Resume Paths, 2-28Resume Vehicle Movement, 2-28

SSafe Stopping Distance, 3-3Safety Alert Types, xvShuttle Node, 3-32Simple Node, 3-31Software Types, 1-5Startup

Paths, 2-22transport system, 2-19

Stationsmove to, 2-36, 2-40order, 4-4

Stations, limits, A-5Status Codes, 4-63Status SDTs, 4-32Suspend Paths, 2-25


TTerminus Node

description, 3-30enter, 2-42exit, 2-46handshake, 3-17

Text FilesDemo Script, 1-6Track File, 1-6

Track File, description, 1-6Track Layout File, description, 1-6track_file.mmtrk, see Track Filetrack_layout.ndx, see Track Layout FileTransport System

components, 1-4MagneMover LITE, 1-1, G-3monitor, 2-31positions, 2-36QuickStick, 1-1, G-4reset, 2-19software, 1-5startup, 2-19

Turntable Node, 3-29Type Files

magnet array, 1-6motor, 1-6

VVehicle Limits, A-5Vehicle Movement

backward, 2-37bidirectional, 2-37forward, 2-36resume, 2-28startup, 2-22suspend, 2-25

Vehicle Positions, 2-36Vehicle Signal, 4-60Vehicles

new, 3-23remove, 3-23status, 2-33

Velocity, 4-59

I-3

IndexX

XXML Files

magnet array type file, 1-6motor type file, 1-6node configuration file, 1-6Track Layout File, 1-6

I-4
MagneMotion, Inc.990000628 Rev. A

Date post:	06-Mar-2018
Category:	Documents
Upload:	dohanh
View:	218 times
Download:	3 times

Mitsubishi TCP/IP Library User’s Manual - · PDF filefor a Q or L Series Mitsubishi PLC...

Documents