[MELSEC MX Controller]Rising to the challenge of integration

Part 2: Organizational changes accelerate development

Once the decision had been made to adopt a general-purpose microprocessor, development of the next-generation controller began. However, the project hit a roadblock right from the start. The team could not decide on the manufacturer of the vital microprocessor. After looking at five or six potential microprocessors, it was easy enough to narrow it down to two, but the decision kept going back and forth between these final candidates.

One reason was a difference in thinking about cache memory. Generally, a larger cache memory capacity makes it easier to achieve high speed. Because integration would increase the computational load, the project team initially regarded the microprocessor cache size as a key selection criterion, but some team members began to question whether this should be prioritized.

One of those who raised doubts was Shingo Kusakabe, the engineer responsible for motion control software design. In the next-generation integrated controller, microprocessor cores would be allocated to each type of control (sequence control, motion control and so on), and high speed would be achieved through distributed processing. With this configuration in mind, Kusakabe began to question whether the decision should really be based on cache capacity alone. Comparing the two possible microprocessors, there were differences in cache configuration and management methods, which could have a greater impact on processing speed than the cache capacity.

In the next-generation controller, processing is distributed across cores to achieve high speed

To help them choose between the two suppliers, the project team built dozens of test boards equipped with each of the microprocessors, and even developed firmware and got several users to conduct tests. After going through this long selection process and initially deciding on one supplier, Kusakabe found an issue that sent them back to square one. This made the project team realize that it would be impossible to bring out the full benefits of integration with conventional ways of thinking.

Minimizing customer maintenance requirements

Another reason why the decision between microprocessor suppliers kept going back and forth was the issue of heat. Microprocessors generate heat, and keeping this within an acceptable range is important to maintain the stability of a system.

The issue of heat can be addressed relatively easily by installing a suitable heat dissipation mechanism. In fact some of Mitsubishi Electric’s competitors’ controllers are equipped with cooling fans for this purpose. However, fans have a limited service-life and need to be replaced regularly, which involves stopping the equipment where the controller is installed. This is why Mitsubishi Electric PLCs have never had fans, as this feature reduces maintenance requirements. For the new controller, the hardware development team led by Daiki Harada wanted to retain this principle of avoiding fans, to save customers from the trouble of replacing fans and sourcing replacement parts.

Without a fan, the product would have to rely on a heat sink to dissipate heat naturally. However, general-purpose microprocessors generate more heat than ASICs, which means they require larger heat sinks. This in turn, impacts the size of the controller’s housing. It was already clear that the new controller would be larger due to the integration of the previously separate sequence control and motion control units. Given the number of functions being integrated, the housing would have to be at least the size of a three-slot MELSEC iQ-R base unit, possibly even larger. However, Harada and his team were convinced that “four slots would be too big; for customer convenience, a three-slot size had to be the target.

The shape of the heat sink was optimized to fit into a three-slot size housing

The team performed repeated thermal simulations to optimize the shape of the heat sink and layout of components to fit into a three-slot housing. This solved the size issue and determined which microprocessor should be used.

At last, everything was in place so the team could begin development using the general-purpose microprocessor.

Entry-level model developed in parallel

Development got underway on the next-generation controller once the microprocessor decision was made. At the same time, Mitsubishi Electric started to consider expanding the existing product range with an all-in-one controller equivalent to the MELSEC iQ-F series. Although the initial idea of developing an integrated controller stemmed from the need for multi-axis control, it was clear that many users would prefer an integrated controller even if they did not require multi-axis control. To cater to such users, it was decided to develop a new entry-level integrated controller.

For historical reasons, the iQ-F series was developed at the Himeji Works in Hyogo, even though the Nagoya Works is Mitsubishi Electric’s headquarters for FA equipment development. Hiroki Sōki was assigned to the Himeji Works as a new graduate. Working on development of the iQ-F series, he was frustrated that PLCs were being developed in two different places.

“Even collaborating on a single document was a challenge,” he says.

The iQ-F series development team was transferred to the Nagoya Works and Sōki moved with them. Developing the entry-level model while sharing resources with the next-generation controller meant that cooperation between the teams was more vital than ever.

“Merging with the team at Nagoya Works made collaboration easier. Without that consolidation, development might not have progressed,” says Sōki, who went on to play a key role in the development of the entry-level integrated controller.

The iQ-F series development team transferred to the Nagoya Works, accelerating organizational integration

Organizational restructuring was also on the horizon in the field of motion control – the mission of the next-generation controller. Because motion is provided by servos, motion control had previously been developed by the servo department, independently of PLC development. Even in the autumn of 2019, as work began to integrate sequence and motion control for the next-generation controller, the two organizations remained completely separate, despite both being based at the Nagoya Works.

In early 2020, it was decided that the motion control hardware and software development departments were to be transferred to the PLC development department, making it easier for the team to cooperate on the next-generation controller.

“At that point, there was no room for mistakes anymore,” recalls Sugiyama, who had taken on the role of project team leader. He knew that the company executives were backing the project by announcing this merger, but at the same time, he felt under even greater pressure.

The key to meeting customization requirements

A general-purpose device like a PLC needs to have a system of continuous functional improvement. The challenge was how to achieve this for the new controller.

One solution was the adoption of the general-purpose microprocessor, which was expected to deliver processing performance gains through continuous improvements in operating speed. But this alone could not fully satisfy the need for functional enhancement. The benefit of increased operating speed (frequency) is precisely that it continuously improves computational (processing) performance.

Although it is possible to improve functionality by upgrading firmware, the development resources at Nagoya Works would only allow for one or two upgrades a year, implementing a limited number of functions at a time. This would not be enough for users who require frequent version upgrades tailored to their own equipment.

The solution to this challenge came from none other than the field they were aiming to integrate with: motion control.

In some motion control products, a system for providing additional software in the form of “add-ons” had already been developed. It was agreed to incorporate this system into the new controller. If the controller’s core development team could just provide the add-on framework, then the actual development of add-ons could be outsourced to local teams.

In July 2020, the project team decided to make add-on functionality available. They provided a software development kit (SDK) for add-on development to co-creation centers in China, Europe, the US, and India, along with the necessary training programs, aiming to accelerate customization tailored to individual customer requirements.

However, having international stakeholders involved in development of the next-generation controller suddenly made project management a lot more complex. Collaboration between teams in different regions was not easy, so to keep everyone on the same page Sugiyama arranged frequent opportunities for information sharing, with meetings eventually being held every few days.

This proved to be effective, and development of the next-generation controller progressed smoothly. But in late 2021, just when they seemed to be on track to launch the product on schedule, a new problem emerged. The use of a general-purpose microprocessor, which the product team had struggled with in the early stages, was once again causing concerns.