2. Hi, I’m
GAUTAM MANOHARAN
Control Systems and Automation
Motion Solutions Australia Pty Ltd, Huntingdale
As a company, we support Motion Controllers, Drives, Motors, Linear
Systems and Actuators, Robotics and Telematics
Provide custom services such as software, hardware and mechanical design
Previous collaboration produced the successful MC8000 for beamlines in
conjunction with the Australian Synchrotron
3. When we started
Several middle level layers between the GUI and the robot actuation
Fairly complex task’s complexity was compounded by the sheer volume of
poorly documented DHS source code
Even simple operations were made extremely complex because of the
enormity of the source code
Moreover, poor documentation made debugging, time consuming and
hard to follow
This made it almost impossible to find the problem in a reasonable
amount of time, when a failure occurs
4. When we started
Several middle level layers between the GUI and the robot actuation
Fairly complex task’s complexity was compounded by the sheer volume of
poorly documented DHS source code
Even simple operations were made extremely complex because of the
enormity of the source code
Moreover, poor documentation made debugging, time consuming and
hard to follow
This made it almost impossible to find the problem in a reasonable
amount of time, when a failure occurs
5. Typical Epson Robot
The Epson Scara Robot used in MX lines, uses a PC based controller called
RC620+. The RC620+ uses a programming language called SPEL+
In a typical application, all the code required for the robot motion is
written in SPEL+ code. The interaction to higher level layers (typically
HMIs) is kept to a minimum.
As an example, if we wanted the robot to move to point X, turn on an
output and move to point Y, we can write all that code in a function in
SPEL+ on the Epson Controller and simply call that function from the HMI.
6. Initial Architecture Review
The inherited architecture, unlike the typical robot application, each move
was called from higher layers and each I/O was activated from upper
layers.
This created unnecessary communication overheads and made the
debugging, time consuming because when it doesn’t perform the
intended work or stops midway through a sequence it gets hard to track
So Matthew Dorhauer from Motion Solutions Australia and Mark Clift
realised that a complete redevelopment of source code with good
documentation was necessary for ease of use and maintainability.
9. Challenges – Refactoring and
Translation
The DHS Visual C++ based windows service contained about 20,000 lines
of code and SPEL+ layer had some 10,000 lines of code.
This had lots of branches and nesting, illegible variable names and
redundant paths
10. Challenges – Refactoring and
Translation
The DHS Visual C++ based windows service contained about 20,000 lines
of code and SPEL+ layer had some 10,000 lines of code.
This had lots of branches and nesting, illegible variable names and
redundant paths
Solution:
Large A3 size drawing books to make flow charts and algorithms, so
everything related to a task fits in one/two large pages.
Experience of Mark Clift was very helpful.
11. Challenges – SPEL+
Lack of Pointers, Eval Functions in SPEL+
Solution:
Fortunately, SPEL+ provides 3 dimensional arrays and this application
required a maximum of 3 dimesions
[Cassette Position][Puck, Row][Port, Column]
Eval functions issue was handled by Mark Clift in the Networking part of
SPEL+ Code
12. Challenges – High Power mode on the
Robot
There were some instances where the robot had to be operated in high
power mode for certain manoeuvres, especially, U-angle rotations.
Running the Robot in High power mode is dangerous during development
and testing
There were two crashes while I was developing the robot SPEL+ code.
https://www.youtube.com/watch?v=OwnvfMnoKYo
13. Challenges – High Power mode on the
Robot
Solution:
Work in a supporting team with supporting team leaders – Tom-Caradoc
Davies, Jason Price and Mark Clift.
Take videos while testing . Daniel Eriksson and Robbie Clarken had setup
gimbal cameras and video recording system which were very useful to
track what had happened
Track the process and fix the bug. Direct SPEL+ level motion commands
helped to easily track the problem and make the necessary change.
14. Challenges – Force Sensor
The most convoluted problem of all
The force sensor is being used in different applications of the MX robot. So
changes to the force sensor for one application would affect another
application
The force values received from the force sensor has to be taken at the
right time and with the right thresholds because a low threshold value
would sense a touch in clear space (due to noise), whereas a high
threshold value would not sense a touch until it overpresses the
sample/cassette
Further, speed and acceleration of the robot also affects these threshold
values and distance from reference point to where the touch is sensed.
Once we add LN2 these issues are highly exacerbated.
15. Challenges – Force Sensor
Solution:
Have Mark Clift on your side
We used different statistics to check the stability of the force values.
A touch the same spot routine was run to monitor the stability of force
values
Different strategies were employed to use the force values – for example,
force was noted before the touch and after the touch and then decision
was made with the two values.
16. Benefits
This new architecture makes diagnostics far much better and efficient. The
SPEL+ environment provides debugging tools for diagnosis, investigation
and resolution.
The SPEL+ code can be ported to new Epson controllers easily. So no
worries on compatibility.
Easy to add new features or make changes because Robot Manufacturer
EPSON’s actual intention of handling the motion tasks by SPEL+ code is
satisfied.
17. Experience
We started with the project without knowing whether this translation was
possible because of the huge convoluted Visual C++ managed code which
had to be refactored and translated to SPEL+
Only in week 4 meeting we agreed that it looked possible
With consistent support from the team (Especially, Tom-Caradoc Davies,
Jason Price, Mark Clift, Robbie Clarken and Matthew Dorhauer) this SPEL+
translation was possible
18. Thank you
It was a great pleasure and fun to work with you all
I look forward to further collaborations between Australian Synchrotron
and Motion Solutions Australia to build amazing machines.
