Introduction
A new method of integrating with Mitsubishi lifts has been developed in the GPP software.
The integration complies with the Mitsubishi integration document “specification of communication between E-LIP and access control system” 2015/08/23
The development allows the GuardPointPro software to send lift floor information over TCP/IP to the E-LIP controller.
The E-LIP controllers then send the floor commands to the Lift panel (Gates), enabling the authorised lift buttons for few secs.
Requirements
GuardPointPro v3.2.237 with ACM Module and a PC with network connection to the E-LIP
The latest Version of GuardPoint Pro can be downloaded from here
Configuration
Actions/Processes/Global reflexes
The integration uses the actions/processes and global reflexes part of GuardPoint Pro to dictate when to send the lift commands. you will need to understand the logic of actions/processes and reflexes before learning how to set up the lift integration.
The Action - Would be the task which is triggered, for example: open all the doors, print a report, arm a group of inputs.
The process - This is a container or folder which can hold a group of actions and also dictates the order in which they are triggered.
The Global reflex - This defines what event should trigger the process ie an access granted, start of alarm etc.
Actions/processes and reflexes are commonly used within GuardPoint Pro for tasks such as open all the doors in the event of an alarm, Schedule an import of cardholders, automate a backup, arm a group of inputs from a reader.
To learn more about actions/processes and reflexes please see: https://sensoraccess-gpp.zendesk.com/hc/en-us/articles/115000587711-GuardPointPro-Actions-Process-s-Global-Reflex
The "Send Mitsubishi command" to socket action
A new action type called “Send Mitsubishi Command to socket” has been added in the actions window. This action defines the list of floor number to send and also the IP address of where this list of floors should be sent.
The Fields within this action are:
Gate/reader number - (select a number from 1 – 255)
Parameter 1 - Defines the IP address and port number of the E-lip panel (syntax must include the TCPletters for example "TCP:192.168.1.80:60173")
Parameter 2 - Is the header (fixed to 4C 41 00 00) sent with each lift commands.
The Floor selection: up to 255 floors can be selected with the option of choosing the front or rear doors of the lift
Please refer to the following Mitsubishi documentation for full command explanation:
Specification of Communication between E-LIP and Access Control System. attached to this article
The Mitsubishi health check
It is important that the Mitsubishi lift receives data from the access control software every 30 mins even if the lift is not being used. If no data is sent from the access control system after 30 mins the E-Lip panel will disconnect from the access control software. To keep informing the lift that the access control system is still live we can send a small amount of data - a "health check":
The action type should be "Send Message to communication port".
The communication Setting is the IP Address and Port number of the E-lip panel - (syntax must include the letters TCP for example "TCP:192.168.1.80:60173").
The command line field should contain the data "11 00 00 00" which is the Mitsubishi health check data.
This action should then be associated to the scheduler global reflex to schedule the health check data to be sent at certain times:
The E-lip Emulator software
For testing the lift commands from the access control system without the need of having a physical lift the Mitsubishi E-LIP emulator software can be used.
by clicking the start button the emulator software will wait for a connection from the access control system. Once data has been you can check if the data complies with the correct syntax to what the lift is expecting.
By clicking the details button you can see what floor numbers are being sent in the command:
The Emulator application is attached to this article: E-LIP-Emulator.zip
GuardPoint Pro optimisation
To prioritise the events received from the reader used for the lifts the controller's polling frequency can be adjusted so that the lift controller networks are polled more frequently than the other readers in the building.
For example increasing the controllers networks "waiting for delay" to 200ms on controller networks which do not contain lift activation readers and keeping the controller network which does have lift reader at 50ms would mean the lift readers would be polled 4 times more frequently than the other readers.
Comments
0 comments
Please sign in to leave a comment.