Typhoon HIL Forum - Recent questions and answers in Communication protocols

Answered: Inquiry on UDP Communication Usage and MAC-Related Changes in Typhoon HIL 2025.4

Thu, 15 Jan 2026 16:42:36 +0000

Hello,

You are correct — in newer versions, the UDP communication module includes an option to configure the MAC address, more precisely the last digit of the MAC address.
This option was not available in previous versions.

There was a bug in earlier versions related to MAC address handling, which we fixed by introducing this new feature. This change may have affected backward compatibility; however, since the functionality worked correctly before, there is no reason it should not work again once everything is properly configured.

Based on the fact that everything was working correctly before, it is clear that you have a good understanding of how UDP communication works. Therefore, there is nothing specific we need to advise you on in this regard.

It is only necessary to configure the last digit of the MAC address again.

Please override the last digit of the MAC address as follows:

Enable “Override last digit in MAC address”

If you were using eth port 2, enter 5 in the “Source device MAC address” field

If you were using eth port 3, enter 6 in the “Source device MAC address” field

If you were using eth port 4, enter 7 in the “Source device MAC address” field

If you continue to experience issues with UDP communication, I recommend using Wireshark as a debugging tool to verify the communication and confirm that the MAC address is set correctly.

Answered: Supervision over ethernet communication protocols

Mon, 05 Jan 2026 15:27:05 +0000

Hello Alejandro,

To answer the first question, currently there is no way to actively monitor the amount of sent messages other than monitoring elapsed time and dividing it by the sample time at which messages are sent from the send block. The UDP send and TCP send blocks also have a status function which returns how many messages weren't sent in case that is useful in your case. Perhaps you could also count received messages on the server which receives them.

As for defining IPs in the model initialization script there seems to be a bug currently so this cannot be done. One workaround is to have the send blocks be in a subsystem that way you can use the pre_compilation code in the mask editor to define IP addresses. I will attach an Example model so you can get a better idea of how this can be done.

Answered: SPI slave - no response to write/read frames

Mon, 29 Sep 2025 07:11:32 +0000

Hi Niall,
In case you issue is not resolved yet, you can try running the attached model using your master input. Check the GPIOs in capture/scope to confirm if the MISO is generating data. You can try the same configuration as I have used below.
Recently, the SPI component has been upgraded with more advanced parametrization, so I recommend you to use this model for Typhoon HIL Control Center Version 2025.3.
Typhoon has also added a new example model for SPI Default_return which can also be used to understand the configuration of the block.

Schematic file

Answered: ISO 15118-20 integration with EV digital twin package

Mon, 22 Sep 2025 12:51:59 +0000

Hi Jeremy

Thank you for reaching out.

At the moment, the ISO 15118-20 component is available in the schematic editor, but we have not yet completed its integration within the EV digital twin package (please note that the EV twin is provided as a separate paid toolbox).

That said, you can still use the EV twin with ISO 15118-2 for bi-directional charging. To do so, simply enable the option in the mask to allow negative current (this same option is also available in the ISO 15118-20 component). With this setting, you won’t need to use certificates for V2G operation.

If you would like to work directly with ISO 15118-20 I recommend that you use our example model for EVCC and substitute the -2 component for the -20.

Let me know if you would like to have access to an example model with the certificate files.

Best regards,

Answered: MODBUS communication issue

Fri, 15 Aug 2025 15:09:59 +0000

Hello, I've tried to reproduce the issue you are facing on a simple model that contains a Modbus Client with settings you provided. In this model, values are set on two SCADA Inputs, and read on the Modbus Server tool, while input values (sent from Modbus Server tool) are read on the output probes of Modbus Client.

Connection was established between pyModSlave tool and Typhoon HIL Modbus Client, and it is possible to both read values on the Modbus Client outputs and receive the sent values on Modbus Device.

Were you able to resolve this issue? Can you please share more details about your model and setup? What HIL device are you using? Is it connected to PC using USB or ethernet cable? Is this the only request on the Modbus Client you set? Are the register addresses overlapping any other addresses on the Modbus Client or Modbus Device? Are there any warnings or errors raised on the Modbus Device you are using?

Answered: Setting Up Aurora Link via SFP Simulation Link on HIL606 for Non-Egston PHIL Amplifier

Mon, 19 May 2025 14:56:47 +0000

Hello Ziad,

the setup should be straightforward. HIL and amplifier are connected via SFP, and SFP components that you mentioned are added to the model in order to establish communication between devices.

No custom firmware/software is needed, but if you are to utilize both SFP ports on HIL606, you are limited to using firmware configuration 4 as it is the only standard configuration that supports SFP Simulation Link on both ports. In this case each SFP port would have it's own SFP Send and Receive component in the model, describing the TX/RX payload for each Amplifier.

Also, there is a Typhoon HIL documentation page dedicated specifically to SFP Simulation Link. You can check it out for a detailed description of all SFP components and the protocol in general.

BR,

Aleksandar

Answered: Feasibility of Using Typhoon HIL as EtherCAT Slave with 100 µs/200 µs Cycle Time external master

Wed, 14 May 2025 11:19:21 +0000

Hi Shamsher,

Typhoon HIL documentation notes that the update rate of the variables in the EtherCAT Slave component is approximately 2 ms.

For clarification, when an EtherCAT Master operates with a 200 µs cycle time, the EtherCAT Slave device still functions correctly. This can be confirmed by the successful transmission and reception of EtherCAT frames and observed in a Wireshark capture.

However, due to limitations of the current hardware platform and the EtherCAT Slave model implementation, the device cannot process all date changes in real time. As a result, the current EtherCAT Slave implementation cannot support updates rates below 2 ms.

BR,
Dusan