About a week ago, I was given the opportunity to work on a startup with a customer who works in the world of automated foaming. As with any other job, the preliminary overview of the project is often where the scope of the project is determined. One of the most critical things a customer can possess is documentation to their machines, it reduced both the time and effort required on the engineering side of the startup.
In this particular case, however, all of the documentation was written in the Swedish language. The drive itself had extensive documentation in the form of manuals that were written in English, but there were no actual machine documents written in English.
The customer had taken the liberty to do a good chunk of translation regarding the essential documents, but as you know, even documentation written in the English language can be hard to understand if you weren’t one of the original engineers.
On projects such as these, I typically like to spend a day or two with my head completely in the program – in this case with the Google Translator at my side. The two most fundamental aspects I was looking for? The homing sequence and the foam gun sequence (as they desired changes to the way the gun operates).
This is the order of operations I took, and it may help some of you out in the future:
- Gather all of the documentation specific to the job.
- Gather the requirements of what the customer desires and write them down.
- Gather all of the tools that will help you break the language barrier (human translators or robot ones)
- Dig out the I/O list if it is included in the documentation (if it is not, build the list yourself manually)
- Translate that list to the proper language
- Cross reference your I/O list to your documentation to seek out a homing sequence in the program
- Use this as your starting point, as your homing sequence is typically the building block of your program.
- Next, target the section of the program (referencing the I/O related to it) the customer wants changes too or is having issue with.
This is an excellent starting point for any troubleshooting of PLCs or Motion Controllers outside of your language barrier. After two days of research and properly building my own documentation – I was able to get the machine running (not without headaches of course) in about one 8 hour day.
Even though the documentation was in a completely different language, this job would have taken weeks had there been no documentation at all – this truly is a testament to the importance of having documentations for your systems – even if that documentation is in a completely different language.