Power up issue Anybus X-gateway


Hi Deryck

Please see below the video of the error happening.

I also tried to unplug the Profibus cable but it doesn’t have any effect in clearing the error. I was not yet able to log into mysupport.hms.se support system. It says the case doesn’t exist and I wasn’t able to set up the logging information. I have more videos but I think they are to big to provide here. Thanks


Here is the video of unplugging the Profibus connector and then unplugging the 24V power to reset the error:


Hello @astoneye,

I have been trying to recreate this scenario with hardware in our lab but have not been successful.

When this typically occurs is the Gateway and the slave device being powered on at the same time? Perhaps the slave module is being in an initialization state when the Master tries to connect and this is causing the fault. Does the Slave device provide any details about an errors?



Hello Deryck

Yes, the gateway and the slave device are powered on at the same time. So you are right the master and the slave device are in an initialization state the error occurs. The slave doesn’t provide any details about an error and I am not able the read any diagnostic out of the slave because there is no running master in that situation. The interesting thing is it happens randomly in about 5 of 6 power-ons it works just fine.


Would you be able to monitor some start up to see if there is a difference in the slaves boot up process when it works compared to when it does not?

Do you have any way to log the Profibus network traffic so we can compare a bootup when it works with when it does not?

One work around would be to enable the control word and utilize that to control the Master interface. When you detect an issue you could send a reset command to reboot the device.



Hi Deryck

Thanks you for your response. Unfortunately I do not have a tool to log the traffic on the Profibus network. So I can’t really see any difference on the slave boot up process. There are basically 2 status LEDs. They either turn green after booting up or stay red when there is no connection to the master.

I tried the workaround with the control word a couple weeks ago. But I did not get it to work. I couldn’t get the gateway to perform a reset. I would need to sent the reset command over the EthernetIP network. I will try to spend some more time on the workaround you proposed. Thanks


Hi @astoneye,

Let me know if you have any questions about using the control word. Keep in mind once you enable it it will be taking up the first 2 bytes of data shifting your network data down.

Section 2.4 of the X-gateway User Guide covers using the control word.



Hi Deryck

The 2 extra bytes was one part of the problem when I was trying last time. I should be able to enable the control word only on the EthernetIP side, right? One the Profibus side I already have a control/status word of the DP/DP coupler enabled and I want to avoid another 2 bytes shift if possible. I going to do some test soon and I will provide any update here. Thanks



To control the master you would want to enable the control word on the master setting in ACM x-gateway. This will then add the 2 bytes to the Ethernet IP side for the control word and status word. Meaning this will shift data read in or written out of the Profibus side down by two bytes on the ethernet IP side.



I enabled the status/control word on the EthernetIP side. Since that the Profibus side went into stop mode and shows a red MS LED. The EthernetIP side seems to exchange data but no communication on the Profibus side. Any advice?


Enabling the control and status word on the ethernet/IP side is going to pass the status of the ethernet/Ip side over to the profibus side. This will not be useful in your application.

This shifts the IO coming from the profibus side down two bytes so you would need to take this into account from the PLC application side.




Does this mean that the reset can only be controlled from the master (Profibus) side? If so this would not work in this case because I don’t have access to the PLC on the Profibus. I can only control the EthernetIP side.


You enable the control word on the Profibus master but it shows up on the slave interface so you will write to it from that side. So when it is enabled you can write a 1 to bit 7 to trigger a reboot. You could also try toggling the master from idle to run using the master mode bits.



Hi Deryck

I was finally able to configure the status/control word in our configuration. I am able to control the master from the slave side (EthernetIP) and also to perform a reset. Unfortunately it didn’t solved the problem. After a couple power-ups the gateway was frozen up again and when I tried to perform the reset over the EthernetIP bus it just ignored it. It looks like the gateway hangs itself up in the boot process and its not able to communicate. After removing the power everything worked fine again. I also tried to reset the gateway a couple times over the control word and I was able to recreate the same situation. So not only a power-up also a reset can cause this issue.


Hi Astoneye,

I am checking with my colleague in Sweden regarding this. I was not expecting that that device would not be responding to the reset. To verify it sounds like the the reset option works until it “locks up”. Are you still able to read and write data from the Ethernet/IP side when it is in this state?



Hi Deryck

I appreciate all your assistance on this topic. Yes, that’s correct the reset works flawless except the situation it looks up. I can’t really say if reading or writing data to/from the EthernetIP side works in this state. I don’t see a way to test it because there is no communication on the Profibus side where I could receive it. On the other side all LEDs except the GW status on the Ethernet side are green (see video) and the EthernetIP scanner is not reporting an error.


Bootscreen after lock-up


After rebooting the device it shows the log entry above

Best regards,



Hi Astoneye,

Thank you for your patience with this issue this is unfortunately an odd issues.

To confirm once you had the control word enabled you were setting the profibus master into run mode. This is no longer done automatically once the control word is enabled.

From the administrator section of the hyperterminal menu can you download the firmware? To do this go in to the administrator mode and then press 1 to upload. Once the upload is started go to Transfer and select receive file in hyperterminal. Set the destination then protocol to Ymodem and start the transfer. This will copy a log.txt file into the set directory.

Please upload the file for me to review.



Hi Deryck

Yes since I am using the control word the Profibus master doesn’t go automatically in run mode. I putting it in run mode with setting the 2 mode bits in the control word. This happens after the PLC on the EthernetIP is booted up. So during booting up the PLCs the Profibus is on idle. Which is a nice thing and I thought that just will fix my problem. But unfortunately it didn’t after about 10 power-ups it locked up again.

I was able to download the log file from the administrator menu and attached it to this email.


Best regards,

log.txt (2 KB)


My colleague is questioning if these could have been cause by something else. To verify can you clear the logs and check if the only come back after the error occurs.

Can you verify that you can not read and write from the Ethernet side of the device? If you can not this might indicate the issue isn’t the Profibus master with the issue and we might need to investigate other parts of the configuration having issues.

Where we have not seen this issue before but it is happening at multiple locations for you it might be helpful to gather some info on each of the setup and see if we can find any correlations with the setup. Do you have any installations that are not have the issue? It might might help to compare the setups to see if we can track down what is different. What would be important here would be what Firmware is on all of the anybus device, Serial numbers, info on the Bus configuration. If we can identify what is common among the setups with the issue this should help us identify the root cause.



I actually did that before I did the test. I thought if I want to catch the case it would be the best to clear the log file first. The log file I sent you shows two entries the first one happened during power-up and the second entry happened when I caught the situation with the reset (setting the bit in the control word).


Best regards,