For students to be sufficiently prepared for real world work, learning hardware communication by practicing with Hardware-in-the-Loop (HIL) is crucial to understand how to properly run simulations with systems that are actually deployed. But for this to happen, quirks and bugs should be found out so that students don’t waste their learning time debugging unnecessarily. This project aimed to solve some of the bigger bugs encountered in this student project, namely not being able to use newer versions of MATLAB with the hardware, and having delay between sending and receiving signals so that controlling a simulated system became inefficient.
The project involves two pieces of hardware and the software running on them. A PLC which is an industrial computer used for heavy machinery, and a Speedgoat which is a specialized computer for real-time simulations, running MATLAB/Simulink. These two pieces connect and send their data back and forth, but it is the part where they connect that didn’t work for newer MATLAB versions. In the end, it turned out that the solution was to set the PLC as passive and allow all incoming communication, having the Speedgoat establish the connection between them. This was slightly strange as having the PLC establishing the connection had worked in older versions, but with this new method both old and newer versions worked.
The second problem was a delay that appeared between sending and receiving data between the Speedgoat and the PLC. To optimize the system an optimal configuration was to be found, and this was configuring the simulation time of the MATLAB/Simulink model, and the cycle time of the PLC. The criteria for optimal were the ability to send large amounts of data, with as small of a delay as possible. I first found that the lowest I could get the delay was around 40 ms, close to the expected minimum based on the structure of the system, using different configurations and data sizes. Then I found what configuration could send the most amount of data without increasing the delay, as it turned out that there was a clear correlation between the amount of data sent and the delay. In the end it was found that the ideal configuration was having MATLAB run a simulation time of 10 ms, and the PLC run with a sampling time of 15 ms, at which point the system could reliably send 512 bytes of data. At this size you could reliably send 128 independent values between the two computers.
This project has taught me even more about HIL systems and the communication between the parts used to simulate the problem. Understanding the behaviour of both hardware and communication is crucial if you want to debug or optimize a system, so that the results can be predictable and the experiences valuable. I got a better understanding of what issues could occur when trying to get two pieces of hardware to run smoothly together, and how to get them to understand each other. As an engineer it is always exciting to problem solve in new systems and learn to understand them. And through understanding new systems I can continue building my own library of experiences.