Zamora

MXComponents - Decting connection failure in C#

4 posts in this topic

Good day, 

I am working on a program in C# that talks to a PLC using MX Components, connecting directly to a Q Series CPU Module (Q03UDE) through the built-in Ethernet port.

The basic function is working already, but I would like to handle the case that the connection to the PLC fails, either by a PLC disconnection (cable damaged, PLC power off, etc...) or when the C# program attempts to connect to the PLC but the PLC is not turned on. Right now, if I try to connect to a PLC that is turned off, the program just freezes and stops responding, so I have to stop it manually. If the PLC fails, the program also simply freezes.

How can I handle this case? For example, an automatic disconnection or setting a timeout for the Open( ) connection attempt. 

My code looks like this: 

int nReturnCode;
int nStationNumber = Convert.ToInt16(cbStationNumber.Text);

MitsubishiLib.ActLogicalStationNumber = nStationNumber;
nReturnCode = MitsubishiLib.Open();

if(nReturnCode == 0)
            {
                btnConnect.Enabled = false;
                btnDisconnect.Enabled = true;
                btnReadChannel.Enabled = true;
                btnWriteChannel.Enabled = true; 
                pbConnectionStatus.Value = 100;
            }
            else
            {
                MitsubishiLib.Close();
            }

I think I could use nReturnCode to handle the error, but I can't figure out how...

Thank you for your help! 

Edited by Zamora

Share this post


Link to post
Share on other sites

Perhaps it has improved over the years but we gave up on MX Component about 10 years ago for similar reasons (think this was on version 3).  We found that it just wasn’t reliable when communications fell over – usually because the guys on the shop floor had turned the machine off/on. If I remember correctly we ended up having the PLC send a watchdog value that incremented once a second. We had the PLC Mx communication on one thread, and another monitoring thread checking for the watchdog value to change over time. If the watchdog value didn’t change then the monitoring thread killed the Mx thread and started a new one up. Not ideal by any means but it sort of worked ok.

We moved on to using kepserverex OPC and later to getting the data via the HMI (as it saves the cost of an OPC Sever and can also cache the data for when the PC is down).

Edited by Nightfly

Share this post


Link to post
Share on other sites

Thank you for replying, Nightfly. 

1 hour ago, Nightfly said:

 We had the PLC Mx communication on one thread, and another monitoring thread checking for the watchdog value to change over time. If the watchdog value didn’t change then the monitoring thread killed the Mx thread and started a new one up. Not ideal by any means but it sort of worked ok.

I was thinking of doing something similar but the idea didn't convince me too much either. Besides, I still have the problem that, when the user attempts to connect to a PLC that is tuned off, the program simply freezes... 

I will try looking into kepserverex OPC. Unfortunately, simply using an HMI isn't enough of a solution for us, since we are actually using the PC as an intermediary to facilitate the communication between a PLC and a Robot.

Share this post


Link to post
Share on other sites

 

Quote

I still have the problem that, when the user attempts to connect to a PLC that is tuned off, the program simply freezes... 

You could always ping the PLC first to see if it is online?

When you say it freezes what do you mean? Are you creating the Mx instance on the GUI thread - if so that’s probably why it is freezing. Stick it in a separate thread and it can hang all day if it wants and it won’t affect the GUI.

If you are just wanting the PLC and Robot to talk to each other have you considered using a protocol converter?  We have used the Beijer Box 2 range quite a lot for such things (the base model we get for just over £200) and it includes drivers for around 80 different protocols. There are other similar devices (Red Lion for example) but we prefer these because you can add your own C# code to it (to cache data etc).

 

 

 

 

Edited by Nightfly

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