3.58 - Comms are super unstable

[mturley]

I installed 3.58 and built a little project using it.  I am building this and running it on the same laptop that is running RSLogix 5000 without issue online with the PLC.

First off (not comm related), the Selector Switch component doesn't allow sizing.  You have to go manually change the size property.

Next, if you hit the selector switch once, it will work.  Hit it again after a second, all is OK.  But press it like 4 or 5 times in a row and it will then show the wrong state (the PLC tag will be on, but selector is off, or vis versa).

Then the selector text will randomly display comm errors, then recover.  The errors I have seen in the text are "Read failed result = -20.  No data returned.", "No response form PLC(21). Invalid value.", and "Object reference not set to an instance of an object."

So the selector button doesn't look very promising, but the comms gets much worse when I try to poll tags in the PLC for cycle counter and "running" state.  So I built a loop that pauses 1/2 sec, then reads the running state and cycle count.  I get he following errors on the tag reads:

- cycle count will occasionally return "True" rather than a number.
- "running" will return "False" (or Not "True") when the tag is latched up and the testing is still running in the PLC program.  If I read again immediately after the first "False" read, it will come back correctly as "True".  This bit is absolutely latched up in the PLC.
- No response from PLC(21).
- Read failed result = -20.  No data returned.
- Exception type MFGControl.AdvancedHMI.Drivers.PLCDriver.Exception was thrown.

It appears this is not ready for primetime, and is definitely not usable by me in its current state.  Are there any other comm settings besides those on the EthernetIPforCLXCom1 properties?

[Archie]

When you are resizing the selector switch, are you pulling by a side or by a corner? The selector switch has a locked aspect ration so Visual Studio only allows sizing by using the corner handles. Depending on the speed of your computer, it may also appear to be delayed in resizing. You just have to hold the mouse for a second or 2 for it to catch up.

Do you have both PLCAddressValue and PLCAddressClick set to the same address? If not, the switch can get out of sync with what is in the PLC.

How are you polling tags?

[mturley]

On the selector switch, I am pulling on the corner.  I now see the multi-second delay before it takes effect.  Other buttons just start sizing almost immediately.  Guess I didn't wait long enough.

I currently have the click and value for the selector both set to the same tag.  When I tested it now it is in sync.  I must have had a time earlier when I didn't have the value tag entered.  I will try this again some more later, but it appears to be working now.  When testing this again, I did get all 3 comm errors on the selector that I indicated above.

Here is my polling code:

        Do While Not testComplete
            Try
                Application.DoEvents()
                Threading.Thread.Sleep(500)
                If PLCReadTag("program:Acuman.AcuPT_b_CycleCont_On") = "False" Then ' now, wait for the continuous test latch bit to go off
                    ' EIP Driver seems to like to return wrong value, so lets make sure
                    If PLCReadTag("program:Acuman.AcuPT_b_CycleCont_On") = "False" Then
                        testComplete = True
                    End If
                End If
                If mAbort Then ' or abort to be hit
                    testComplete = True
                End If
                If Not testComplete Then
                    LB_MultiRunProgress.Text = "Tests: " & PLCReadTag("program:Acuman.AcuPT_c_Cycles.Acc")
                Else
                    LB_MultiRunProgress.Text = ""
                End If
            Catch ex As Exception ' the comms errors often, and would normally bail out of here, so just keep going for now
                ' MessageBox.Show(ex.Message)
            End Try
        Loop

    ' read a single PLC value
    Private Function PLCReadTag(ByVal tag As String) As String
        Dim rtnVal As String()
        rtnVal = EthernetIPforCLXCom1.Read(tag, 1)

        Return rtnVal(0)
    End Function


I have seen the "Tests: 1" label count up for a while, then show "Tests: True".  The polling loop would always bail within a minute thinking it read "False" for the on bit until I added the double check

I attached the PLC rung for the ...CycleCont_On bit.

[Archie]

The sleep(500) can be causing the communication problem. If the sleep is on the UI thread, it will lock the thread up during the sleep period. Although the driver runs on a background thread, it syncs it's responses back to the UI thread, which means it must wait for the sleep to be over. Timeouts for the Ethernet drivers are very short, in the range of 300ms

The DoEvents can also cause unexpected results and should really be avoided if at all possible. The piece of code below will show how it can trigger an event that has not completed and change the variables unexpectedly. Looking at the code, you would only expect to ever see "In Click0" or "In Click1000000", but it is not the case when you rapidly click the button.

You can get better results by either using subscriptions or using the BeginRead along with the DataReceived event.

Code: [Select]

Private i As Integer

Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click
     Me.Text = "In Click" & i

     For i = 0 To 1000000
        Application.DoEvents()
     Next

     Me.Text = "Out Click"
End Sub


[alanls1]

Not to beat a dead horse....  But  I generally try to use the "Event" to evaluate something.

    For instance. if I put a "BasicLabel" on the form named BasicLabel1  (hidden on the form or not).

      I would use the following "Event" to evaluate or call another event etc.

EXAMPLE:
    Private Sub BasicLabel1_TextChanged(sender As Object, e As System.EventArgs) Handles_ BasicLabel1.TextChanged

          try
               if BasicLabel1.Value = 1 then

                  DoThisOtherStuff
                  end if

                Catch ex as Exception
           End try
       End Sub

I try to minimize Loops and sleeping threads..... 

Also I continuously referring back to MSDN for Good Coding Practices.. Using good naming conventions and practices is 1/2 the battle.

http://msdn.microsoft.com/en-us/library/vstudio/h63fsef3.aspx

Good luck....

[mturley]

Archie,

Will do on the sleep.  I will restructure to use a timer to do the UI update and check for test completion.  I will report back after that.  For the DoEvents(), I wanted the UI to be responsive.  I do not have the issue you illustrate because my button is not reentrant, I disable it on click.  But it certainly can be a problem if button presses are reentrant, and in other cases as well.

After my app starts, I hit a button to set the number of test cycles, then start the PLC cycling.  On startup, my app is doing nothing until I hit the button.  So ignoring the polling for the moment till I change it, the selector switch continues to error just sitting there after startup.  It will just randomly get the above listed comm errors.  If you start pressing the selector it will error quicker and more often.   

Also, the selector switch value changed event does not work correctly.  If I have the value changed event implemented, it will go off like only once for every 8 or 10 presses of the selector.

[Archie]

Are you by any chance on an Ethernet network that also has some Ethernet/IP adapters such as point IO? These things can take a lot of bandwidth and the HMI gets low priority possibly causing timeouts. I checked the timeout and it is 300ms. You can use Wireshark to see the request/response time to see if it is getting close to the 300ms. On a network with no load at all it will typically be less than 10ms.

Using a timer should work much better than a loop because it will allow you to eliminate both the Sleep and DoEvents.

The ValueChanged may only be triggering because it's update is based on the PollRateOverride of the driver. If you could click 2 times every PollRateOverride cycle, then the event will never fire because it would be back to the value by the time it compared for a change.

[mturley]

Archie,

Wireshark appears to show that I get about 10 msec turnaround (assuming I am reading it right),  then it just randomly goes bad.  I have attached a screen shot when it went bad.  In this case I was polling with timer events at 250 msec (no more Sleep/DoEvents).  The PLC is .152 in the screen capture.  I sampled all network traffic for 30 seconds and Wireshark said 65 packets/sec and 9.5K bytes/sec on average.

I continue to see the errors I have indicated above, and when the one in the screen capture occurred I received a "False" back from the PLC tag read to see if the test was in progress.  At this point I had only done about 40 cycles out of 500 that the PLC was working on.  I can get the comms to error as well when not polling by just clicking the selector switch over and over 10 - 20 times either slow, or fast.

For the value changed event, I never get it if I click the selector, wait a couple seconds, click it again, and do that like 10 times.  If I click the selector fast I will finally get 1 value changed event if I click it 10 or 15 times.

[Archie]

It looks like the response time is averaging about 10ms. At packet 379 to 381 there was a response in less than 3ms. That is assuming those request/response are a pair. Immediately after that the requests stop for about 3.5 seconds in which it then opens a new session (packet 399). Any idea what happened there? It's almost like the process was killed without closing properly.

Drill into the packets 379 and 381 down to the following:

Ethernet/IP->Command Specific Data->Item Count->Type ID: Connected Data Item->Sequence Count

Make sure they are the same sequence count.

[mturley]

Well CRUD - Or maybe not!

I hadn't saved the WireShark log, so I went to create a new one and check it out.  Since it has been very simple to get comm errors I thought that would take about a minute to do.  Now, it won't error.  I have pressed the selector 500+ times, and run the polling as well without error.  I have seen some retries because of comm timeout, but no errors.

Only change was that I rebooted the laptop a couple times this morning - figures.

Still have no value changed events happening for the selector.  I see if the comm issues reappear in the next few days.

[Archie]

I did a quick test without connecting to a PLC just to verify the event triggers. I added a SelectorSwitch and a Button, then added this code:

Code: [Select]

    Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click
        SelectorSwitch1.Value = Not SelectorSwitch1.Value
    End Sub

    Private Sub SelectorSwitch1_ValueChanged(sender As Object, e As System.EventArgs) Handles SelectorSwitch1.ValueChanged
        Me.Text = SelectorSwitch1.Value
    End Sub
The event fires every time I click the button.

Later today I'll connect to a PLC and try it out.

[mturley]

I get the same result with another selector (no PLC tag) and a button, the value changed event always fires.  Still only 1 in 10 or 1 in 20 on my other selector. 

So I took the other selector and deleted it, then added a new one.  Set it up with PLC tag for click and value, and "toggle".  The selector indicator knob itself moves every time and shows the correct state, but the value changed event only fires off occasionally.

[mturley]

Well I figured out when the comms go south.  It is anytime that RSLinx is running.  Comms were fine until I went online with the PLC, then they went bad again.  They stayed bad after I shutdown RSLogix and recovered once I dumped RSLinx.

[Archie]

I get something very similar, except RSLinx is the one that always stops working for me. I run RSLinx and RSLogix in a virtual machine. After much working with an AdvancedHMI project, RSLinx will stop working and I have to restart the virtual machine to get it to re-establish communications.

[Archie]

I get the same result with another selector (no PLC tag) and a button, the value changed event always fires.  Still only 1 in 10 or 1 in 20 on my other selector. 

So I took the other selector and deleted it, then added a new one.  Set it up with PLC tag for click and value, and "toggle".  The selector indicator knob itself moves every time and shows the correct state, but the value changed event only fires off occasionally.

This problem was found and fixed. Version 3.59 will have it fixed