Connection Error with BRX over ethernet

[ksasikumar]

Hello!
I am seeing a connection error on a BRX PLC I am using when trying to connect to the Do-More Designer Software. This is a PLC which previously had a stable connection. I have made sure the cable is tightly connected on both ends (at the PLC port and the computer port). I have also swapped out the ethernet cable twice, and still see the issue persisting. The connection drops repeatedly, and then the Do-More software freezes and then crashes. I have to use the task manager to end the program and restart it. This has been going on consistently over a few days. The connection does seem to be fine physically - I can ping the PLC's IP address and get fast responses. This makes me wonder if there is an issue with the software itself? I have updated the software to Do-More v2.9.4 as well.

Has anyone seen this before? I am attaching a video of how the connection drops in and out.

[franji1]

Click on that panel in the status bar and that shows the Link Info page.  I'm going to guess it's full of timeouts, but let us know if there's anything else getting logged.

What is your Link's timeout setting?  Click on the Link in the Launch Pad's Link pane and hit the Edit button, then hit the Protocol tab.  Default is 100ms w/1 timeout.

Also, what is your PLC scan time?  When online, go to PLC->System Information dialog.  The scan time stats are in left middle group.

[ksasikumar]

- Yes, its all timeouts. Its saying "task code error response" - I have attached a picture as well.

- Link Timeout is 100ms with 1 timeout.

- PLC Scan times:
    - min: 1.5ms
    - avg: 1.6ms
    - max: 5.5ms

[franji1]

Says "Uses VPN".  Are you using a VPN?  VPNs add some random amount of delay.  You may want to bump up your timeout.

Try pinging it to see the network delay - not sure if pinging works through VPN.

Has your connection changed/hardware/VPN/remote location changed since you noticed timeouts starting?

[franji1]

I take that back.  These are not timeout errors.  You aren't even getting retries.

They are protocol errors.  You are probably monitoring something that is invalid, like an array index out of bounds, e.g. X[V0] where V0 is 23456.

Try turning all status OFF.  See if the comm errors go away.

Then one-at-a-time, turn a specific view's status ON, EXCEPT for Ladder View.  If you don't see any issues with Data View, Trend View, Whatever View, then try it with Ladder.

Now Ladder View is VIEWPORT AWARE, meaning it will only do status of the logic in the window.  Hence, you may scroll and errors go away, or errors show up (this is why I asked to do Ladder View LAST just to eliminate the "static" status views).

[ksasikumar]

"Uses VPN" is just a description that was added, the connection itself is not using the VPN.

The connection has not changed recently, so I'm not sure why the link is timing out. Ping response time is 1ms.

[franji1]

Can you explain the ladder view/status ?

Ladder does status of the elements in the view port.  So if you have 5 rungs of 10 contacts and 5 coils, the Ladder View will request status of those 15 elements.  As those elements change status, they are reflected on the ladder status.

As soon as you change the contents of the view, whether by scrolling or Find or XRef or changing zoom level or levels of documentation (e.g. turn on/off nicknames, descriptions, rung comments), communication status requests will STOP then RESTART with the new elements contained within the new rendering of the logic within the Ladder View.

[ksasikumar]

Actually I did notice these errors popping up when I scroll/stop scrolling!
It is only occurring when I scroll when the Ladder Status View is on.
So is there a way to resolve this?

[franji1]

Actually I did notice these errors popping up when I scroll/stop scrolling!
It is only occurring when I scroll when the Ladder Status View is on.
So is there a way to resolve this?

Figure out the exact rung, actually the exact element, that you are trying to do status on.  I thought it would be an array reference, but when I tried that, I do not get a comm error, just a PLC warning.

Trial and error.  Once you get a screen to report errors - change the zoom to the max 225% to limit the status viewport even more.  Then figure out what instructions and/or elements may be causing the errors.

[ksasikumar]

So I've narrowed it down to 2 rungs of one subprogram in the entire program. These lines are for reading a file and then using JSON parse on the text from this file. Please see the attached image

[ksasikumar]

I found that one of the user defined memory types were out of range. I have edited the data type's configuration and am going to try running the program again. For now, I am not getting an error when scrolling with statuses on.

[franji1]

I found that one of the user defined memory types were out of range.

Can you provide details on this?  The instruction should NOT have allowed a data block (built-in or user) that was out of range.

Please provide the instruction and all parameters.  The best way to do that is to copy the instruction to the clipboard, then paste it in a forum post - definitely remove all the SYSCONFIG details (just the instruction mnemonics will be good enough).

[ksasikumar]

I was using a user defined memory block (string type) to store each line of the text file in the FILEREAD instruction. The string block's size was 100, but the file had more than 100 lines, hence causing an error, out of index I think.

[franji1]

Yeah, I just duplicated it.  String Status is slightly different than other elements, so doing an array reference of a string causes a task code error (what you are seeing in the Link Info dialog).

The PLC is also issuing a warning "Array index out of bounds - $IndexError (ST129)" for the PLC side being unable to access MyString[V0] when V0 is beyond the MyString block size.

So my initial hunch was close (i.e. X[V0] where V0 equals 23456), it's just that with String elements, e.g. SL[V0] where V0 equals 64, it also reports a Taskcode error response, hence the flashing red ERROR Comm Link status bar panel.

Glad you figured it out!!