samuraipanda

fx5u error lights on and cannot connect to gx work

8 posts in this topic

I have a fx5u plc connected to 2 keyence sr 1000 qr code scanners using plc link. On random times the plc error light will light up and all ethernet connection will be disconnected and i cannot connect to the plc with gx works 3. If i put the plc in stop mode tho i can connect to the plc. I do not know what error code is causing this because each time i connect the error code is missing. The problem starts when the plc is in run mode. Can anyone help me with this as this is a persistent bug that keeps on happening in my system?

Edited by samuraipanda

Share this post


Link to post
Share on other sites

Hello and welcome to the forum.

How did you implement PLC Link? Are you sure that you're not using MC Protocol?

So the error LED is lit on the PLC, but there's nothing in the error log when you connect? And you need to put it in stop mode before you can connect? Correct? Is it possible for you to upload your program here on the forum? If that's not possible, please take a complete screenshot of the Ethernet configuration -> "External Device Configuration". Also; which firmware are you running on the CPU, and which version GX Works3 are you using?

And by the way: You really don't see anything in the Event History when you finally can connect to the CPU? You can find this under "Module Diangistics (CPU) -> Event History".

Edited by kaare_t
Event History question

Share this post


Link to post
Share on other sites
5 hours ago, kaare_t said:

Hello and welcome to the forum.

How did you implement PLC Link? Are you sure that you're not using MC Protocol?

So the error LED is lit on the PLC, but there's nothing in the error log when you connect? And you need to put it in stop mode before you can connect? Correct? Is it possible for you to upload your program here on the forum? If that's not possible, please take a complete screenshot of the Ethernet configuration -> "External Device Configuration". Also; which firmware are you running on the CPU, and which version GX Works3 are you using?

And by the way: You really don't see anything in the Event History when you finally can connect to the CPU? You can find this under "Module Diangistics (CPU) -> Event History".

Hallo kaare_t

You are right i am using mc protocol sorry for my mistake.

Let me explain the whole system the fx5u plc is communicating to 2 keyence sr 1000 using mc protocol, 1 q-series plc using udp and a scada application using modbus tcp. We have issues where the fx5u plc will suddenly disconnect its ip would be missing and gx works cannot connect. We then have to put the plc in stop mode to be able to connect using gx works. When we put the plc on run the error happens again. This has happen several times in random occasions witch makes it hard to troubleshoot.

Sometimes stopping the plc and re writing the program will fix the problem temporarily.

Attach is the program.

In the program block scanner is where we did the program for the 2 keyence sr 1000

In the program block coms is where we did the program for the udp communication settings.

I am using gx works 3 version 1.0472. 

As the plc firmware i dont know.

pc 20180121 sore.gx3

Edited by samuraipanda

Share this post


Link to post
Share on other sites

I see. What would be really helpful is the PLC Error log. My guess is that the error that is active (when you cannot connect to the PLC using GX Works3) disappears when setting the PLC into stop. But it will (should) be present in the log. Here's what you do:

  1. On the top-selection in GX Works3, select "Diagnostics"
  2. Select "Module Diagnostics (CPU Diagnostics)" -> Here you can also find the FW version in the upper left corner of the window, please post it.
  3. Select "Event History"

This will bring up a list of all previous errors (and warnings etc.). You can also create a csv file of the errors (bottom right corner in the history) and post it here. That would be helpful.

Share this post


Link to post
Share on other sites
12 hours ago, kaare_t said:

I see. What would be really helpful is the PLC Error log. My guess is that the error that is active (when you cannot connect to the PLC using GX Works3) disappears when setting the PLC into stop. But it will (should) be present in the log.

Here are the error log in csv and a screen shot of the fw version. It would seem that the udp communication between the fx5u and the q series plc is to blame. As if we would stop the q series plc the error will stop. But if we put the q series plc back in run mode the fx5u plc will revert back to its error state. That is as far as what i observed 

PLC Error Log.csv

fw version.PNG

Share this post


Link to post
Share on other sites

I see that you've used SM409 - 10ms cyclic signal (5ms ON / 5ms OFF) to trigger the socket communication. This is not a good idea. You need to create a small sequence, that interlocks so that you don't try and send data before the previous transmission was sent with or without success. I normally also interlock together with receive if it's a two-way communication (with the Q-CPU): Send data, wait for answer, then send data again after successful reception.

Share this post


Link to post
Share on other sites
6 hours ago, kaare_t said:

I see that you've used SM409 - 10ms cyclic signal (5ms ON / 5ms OFF) to trigger the socket communication. This is not a good idea. You need to create a small sequence, that interlocks so that you don't try and send data before the previous transmission was sent with or without success. I normally also interlock together with receive if it's a two-way communication (with the Q-CPU): Send data, wait for answer, then send data again after successful reception.

Thank you very much i copied the program from the examples in the manual. I should have done more research beforehand. I do think i got what you mean but is there any example code that i can study from? And other then that is there any other probable cause? And what is triggering those warnings in the log?

Edited by samuraipanda

Share this post


Link to post
Share on other sites

Hi,

Here are some comments to the code in the picture, referring to network no:

  1. EnableComms starts the "sequence control", and if not already active it will activate the sendstatusbit
  2. Whenever sendstatusbit goes high, it will give one pulse to the sendpulse bit
  3. When sendstatusbit is high, and the sendinstruction is complete, it will reset the sendstatusbit and start sequence again
  4. NOTE: I've replaced the timer-bit with the sendpulse bit so that it will give only one pulse for each send, and only when the instruction is available for a new transmission

Also mark that you've used the same connection for receiving data. If this is a send/receive connection where you are supposed to receive data before sending new ones then you should implement receive-routine before triggering a new send... If you need to send/receive data independant you should create two different connections in the setup. The setup you have is similar to a sequence where you expect an answer from the remote node before triggering a new send... Something like the following (not in a picture):

  1. Send data to remote node
  2. rst send signal
  3. Wait for receive data from remote node
  4. Receive the data from remote node
  5. process data from remote node
  6. Trigger new send data to remote node

So depending on which process we are looking at you need to select your route.

Also, you should implement some kind of error-check (timeouts, no connection and so on)

You could also download the latest firmware from Mitsu website for your CPU. You will need a SD card for the update process if you choose to do so.

sequence.PNG

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now