Bryll

FX3U stop executing code

13 posts in this topic

Anyone here that noticed that the FX3U can stop executing some parts in the code ? I'm now up to two systems that stopped executing the code. (FX3U 16MT/DSS + ENET P502 + 485BD) First system stopped when an electrician tampered with the main power switch when everything was up and running. No errors or fault to be read from the PLC. Power and Run LED are lit. I was able to access it via a remote connection and go online. Second system stopped its Modbus communication (FX3U-485BD) on channel 1. Everything else was good. No one touched the system, at least they say so. Mitsubishi Modbus communication blocks was used for this function. No errors or faults in this one either. I had to reload the program to the PLCs to get them up and running again. Didn't even recompile before I reloaded the software. They are both running at the moment.

Share this post


Link to post
Share on other sites
Hi Bryll, Based on details, you've shared, can guess only ... In particular, it may occur due to mistakes in algorithm of communication driver.

Share this post


Link to post
Share on other sites
Inntele, On the second unit, yes. But the first unit mentioned stopped executing the entire program. The PLC was in run mode, run LED lit and GX IEC dev indicated the same when checking online too. Didn't have the time to check to much, the customer was jumping up and down when waiting for the equipment to start up. He got hold of me at an airport on my way home.

Share this post


Link to post
Share on other sites
Once more, Bryll. There was a problem with PLC: the PLC is in Run mode, but the 'machine' doesn't work properly (or doesn't work at all). You've checked an error code, all is OK. You had not a time to find in what is a problem and reboot the PLC remotely, then it went to work. Is my description of your actions correct? Then I answer. There are two kind of problem, that can lead to this effect: 1) A mistake in algorithm of communication driver, due to which the communication is stopped. And when the communication is stopped, the control sequence is stopped too. The 'machine' is stopped, while the PLC is still in Run. 2) A mistake in control program, due to which some operand in some command go out of user area range to system area range and the command modify it. In some case it may lead to system error, in some other to break the control process without any visible events. In both cases these are bugs in user program and not bugs in PLC firmware. Edited by Inntele

Share this post


Link to post
Share on other sites
Inntele, I hear you, and I'm willing to agree with you. That was my first guess too. Was able to check all the system memories for the Modbus communication on the second one, had a bit more time on that one. They had the values and statuses they should. Got another one yesterday afternoon with problems. This one stopped communicate with the HMI and the distributed I/O connected to the ENET-P502 unit. The ENET unit indicates open ports to HMI and distributed I/O. No error LED at all is lit. I could access the network remotely via a connected laptop and Team Viewer and ping the HMI and the I/O unit. The PLC don't answer at all. I double checked with the service guy at the plant that there was no error led lit. This unit has been in operation 24-7 for the last four years.

Share this post


Link to post
Share on other sites
Then obviously the problem has another root than it was described by me above.If to answer onto the initial question. No, I didn't face with faults in operation of FX3U PLC. I'd glad to help you, but it's difficult to repair TV set by phone call.

Share this post


Link to post
Share on other sites
I'm writing a bit late, but I have to agree with Inntele on one point: I've never experienced any problems with the FX3U PLC. However (point2), when they say that "no-one touched the system", I would be sceptic... I've never heard of this kind of problem before, and never experienced it myself.

Share this post


Link to post
Share on other sites
Hi Kaare, It was not my replica :)

Share this post


Link to post
Share on other sites
I agree with you guys, and I am a bit suspicious about the feedback from the end users. They will never admit that they tampered with the system, just blame the programmer. The FX3U is the system we use quite often, and experienced just these two issues with the FX3U system during the last 8 years. I had earlier one FX3U-ENET that retired itself, and now perhaps a second one. The first one did lit up its error LED's, this second one not. Will check the second one today to see if it's broken. The replacement was received by the customer yesterday afternoon. Edited by Bryll

Share this post


Link to post
Share on other sites
Just finished checking the FX3U-ENET unit. Laptop -> SC-09 -> FX3U, not possible to connect to the ENET unit. All LED's on the unit indicating normal operating status, except no action on RX or TX. Not possible to ping the unit, and the HMI can of course not read anything from the PLC. But, it started up normally after a reboot. What do you guys think, some external problem or programming problem ?

Share this post


Link to post
Share on other sites
Are you using any port open/close instructions directly in the code, or is everything setup via FX ConfiguratorEN? Is there any code at all executing towards the ENET module at this time, or is the CPU blank?

Share this post


Link to post
Share on other sites
The CPU is not blank. What I use that can control the ENET unit is: "FX3UModbusTCPClient" from the library "FX3UModbusTCPClient_V210". "FX3UModbusTCPDeviceRange" and "FX3UModbusTCPServer" from the library "FX3UModbusTCPServer_V210". These libraries was supplied by Beijer. Everything in my code is according to their examples, why change something that's supposed to work

Share this post


Link to post
Share on other sites
Well, some those FB's requres some sequence logic (the client FB's). I'm not saying that you've done something wrong in your code, but I've never had any of those FB's failing. And when rebooting the PLC the code is back to initial sequence (hence any failing sequence would have been resetted). Hard to know what is happening then...

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