Comms Failure Alarm on Modbus TCPIP

[peterjung]

Firstly I want to say a huge thanks you to Archie for a great programme and for making it free and accessible.  Secondly I want thank Archie and rbelknap for helping me out with developing my first Advanced HMI application.

With their help I have almost finished but there is one further thing I would like to try and implement.  This application is to create a simple test interface to connect to two PLC’s with separate comms set ups.

I would like to be able to light a basic indicator if comms to either of the PLC’s should fail.

I read on the other thread the two suggestions one of using a Watchdog Timer and the other frankly I didn’t understand at all.

I well understand the principle of a Watchdog but in practice how would you implement this on the HMI side?  Does a timer have to be created and controlled in VB?  If so any hints on how to do this?

Or, considering that I am using ModbusTCPIP is there a better (easier?) solution I can consider?

See below for my (almost) finished HMI – you can see the orange indicators that I would like to illuminate in the case of a comms. failure.

Once again….any help offered is very much appreciated!

[rbelknap]

Peter,

Your welcome.  Lets see if I can help with this one.

Archie has already built in CommError code to the ModbusTCP driver.
Go into the code window for the form.
At the top of the window there are 2 pulldowns.

In the left one pick ModbusTCPCom1(or whatever you called it)
In the right one you will find the ConnectionEstablished event and the CommError event.

If you select them VS will create the sub routines and attach them to the driver.
You would need to do this for each comm driver.

In the routines you would just need to write the appropriate code to change the color of the indicator for whatever condition the comms are in.

Good luck

[peterjung]

Hi rbelknap

Thanks again for your input!  Ok I can get as far as...

"In the routines you would just need to write the appropriate code to change the color of the indicator for whatever condition the comms are in."

 

As you can no doubt tell I really have very limited knowledge of VB .... however I have just found the link to the video tutorials for VB absolute beginners....that's me!  I am going to try and see what I can learn from these....

Are there any other resources for VB particular to Advanced HMI that may be available?  I would really like to try and figure some of this out form myself!

Thanks

[Godra]

Hi peterjung.

The best resource for VB particular to Advanced HMI should be the code behind any and all components of the Advanced HMI itself.

You might need to learn VB basics first in order to understand some of the code (Archie is probably the only person who understands the whole code since it's his project).

To help you out with your current project, here is a short explanation of what you should do:
1) Observe all the properties of any of the controls you are placing on the form
2) Try to understand what any of the controls is capable of doing and how it responds to any change made to any of its properties - all these changes can be performed in the properties window while in the Designer mode

A specific example would be the BasicIndicator control that you want to use and here is how you can go about making it work (the assumption for this explanation is that Color3 property is currently irrelevant and that SelectColor3 property is always set to False):

  a) Observe Color1 and Color2 properties of this control (Color1 is always active if the SelectColor2 and SelectColor3 properties are set to False)
  b) Set the colors as per instructions in the attached picture (Color3 might eventually be used depending on your future needs)
  c) Switching between Color1 and Color2 is actually controlled by one property only -> SelectColor2
  d) If SelectColor2 is set to True then it will show Color2 as active ... if set to False then Color1 will be active
  e) Since you want these changes to be associated with ConnectionEstablished and CommError events of the driver itself, switching the state of the SelectColor2 property from True to False and vice versa needs to be done thru code within these events (see the attached picture with code)

The attached code example also shows how to go about writing a code for a timer tick event (after you place a timer on the main form then just double click it to access the code page). BasicIndicator3 round control is placed on the form to show it.

Try to analyze everything suggested above and also pay attention to attached pictures.

[peterjung]

Godra

Thank you so much for your very concise and clear explanation!  Very helpful indeed!  It gave me a bit of Eureka moment in understanding events….

One final small niggle…. following from Archies explanation about how to write to a bit on two separate PLC’s I am now trying to sort out a momentary button I had set up as a toggle function…


I tried this in the code :

Private Sub MomentaryButton4_Click(sender As Object, e As EventArgs) Handles MomentaryButton4.Click
        If ModbusTCPCom1.Read("01027") = 0 Then

            ModbusTCPCom1.Write("01027", 1)
            ModbusTCPCom2.Write("01027", 1)
        Else
            ModbusTCPCom1.Write("01027", 0)
            ModbusTCPCom2.Write("01027", 0)
        End If

End Sub

But seems I am doing something wrong in trying to read from address 01027 in the first line…..

Any pointers….

Thanks again

Peterjung

[Godra]

If I use your original code then the error shows suggesting that conversion from string "False" to type "Double" is not valid (see the attached picture) indicating that that the value read is of a Boolean type, which is True or False.

So, in the first line you should use False instead of 0:

Code: [Select]

If ModbusTCPCom1.Read("01027") = False Then
Even if you leave the button output type to MomentarySet instead of Toggle, your code should still perform the switching/writing correctly. This since you are only using the button's Click event, regardless of its output type, and it's the code that does writing to PLCs not the button itself.

[MrPike]

Hi Godra, just wondering how you made these events work?  I was trying to use these in a similar project awhile back when Archie, informed me they didn't work.  Not sure if this link to the post works  http://advancedhmi.com/forum/index.php?topic=1012.0.  I'm using 399a but I am not doing direct read/writes with the driver just using the standard AHMI controls.

Anyway, I was hoping you could share , thx

[Godra]

Hi MrPike.

My approach to these events was purely logical and never before tested with a PLC (since I don't have one available).

Just now, I did a test with a simulator program (ModRSSim) and ModbusTCP driver's CommError event appears to be working fine.

ModbusRTU driver's ConnectionEstablished event seems to be implemented in the code but I have not tested it yet.

ModbusTCP driver's ConnectionEstablished event doesn't appear to be implemented properly but is possible to make it work by modifying the ModbusBase.vb file:

In Region "Events" go to Line 728, as it shows on my computer, inside the very first sub which is Protected Sub ProcessDataReceived add the following code immediately below this line "If PDU.ExceptionCode = 0 Then":

Code: [Select]

RaiseEvent ConnectionEstablished(Me, e)
So, that part of the code should now look like this:

Code: [Select]

If PDU.ExceptionCode = 0 Then
                RaiseEvent ConnectionEstablished(Me, e)
                If Not Requests(TIDByte).IsWrite Then
                    '* Extract the data

There has to be at least one control on the form that has one of the PLCAddress fields populated to initiate the ModbusTCP driver communication between AHMI and the PLC. The driver alone doesn't seem to be establishing a communication with PLC until a data is requested by a control.

The modified code appears to be working fine with ModbusTCP driver but Archie might suggest whether this approach is correct.

From that other post you mentioned, I can see that you were using DataReceived event which is somewhat similar to my suggestion. This event does actually suggest that communication has been established.

[Godra]

Tried V399d as it is, without changing any code, and it appears that both ModbusTCP driver events work fine.
There seems to be a new event "ConnectionClosed", present since version 399b.

Also, while using com0com paired ports for testing AHMI with ModbusRTU driver on COM11 and with ModRSSim as slave on COM1, here is what happens:

1) ModbusRTU driver seems to be considering connection established as soon as the application is started (probably after opening COM port and regardless of whether the slave is connected on the other end - the 1st attached picture shows this).
2) Once the slave was connected and then disconnected, the driver noticed the latter and raised the CommError event
3) After the slave was connected again, the driver didn't seem to have noticed that to raise the ConnectionEstablished event (the 2nd attached picture shows this)

This was a simple test with 4 BasicIndicator controls placed on the MainForm, 2 controls per driver - square shaped responding to driver events through code and round shaped responding to 00001 address in the PLCAddressSelect2 field (see the attached picture).

Here is the code that was used (the same pattern was used for either driver):

Code: [Select]

Private Sub ModbusRTUCom1_ComError(ByVal sender As Object, ByVal e As Drivers.Common.PlcComEventArgs) Handles ModbusRTUCom1.ComError
        Me.BasicIndicator1.SelectColor2 = False
        Me.BasicIndicator1.SelectColor3 = True
    End Sub

    Private Sub ModbusRTUCom1_ConnectionEstablished(ByVal sender As Object, ByVal e As System.EventArgs) Handles ModbusRTUCom1.ConnectionEstablished
        Me.BasicIndicator1.SelectColor2 = True
        Me.BasicIndicator1.SelectColor3 = False
    End Sub

    Private Sub ModbusTCPCom1_ComError(ByVal sender As Object, ByVal e As Drivers.Common.PlcComEventArgs) Handles ModbusTCPCom1.ComError
        Me.BasicIndicator3.SelectColor2 = False
        Me.BasicIndicator3.SelectColor3 = True
    End Sub

    Private Sub ModbusTCPCom1_ConnectionEstablished(ByVal sender As Object, ByVal e As System.EventArgs) Handles ModbusTCPCom1.ConnectionEstablished
        Me.BasicIndicator3.SelectColor2 = True
        Me.BasicIndicator3.SelectColor3 = False
    End Sub
It might be possible that the ModbusRTU driver needed more time to recognize all the events (which wasn't the case with ModbusTCP driver).