News:

  • March 23, 2023, 07:18:37 AM

Login with username, password and session length

Author Topic: Ecomm100 Problem  (Read 10971 times)

amos

  • Full Member
  • ***
  • Posts: 37
Ecomm100 Problem
« on: November 13, 2007, 02:20:30 PM »
   I have a DL06 set up as a Modbus TCP Master to communicate to 7 Modbus Slaves. The all communicate fine. The problem is that I can't connect with Direct Soft. If I cycle the power to the 06 it will work for a while until the ECOM100 receives a timeout error then strange things happen. To work around that problem I installed another ecomm to connect to the 06 with direct soft. I have version 5.2. This seem to be a problem with the ECOMM100, otherwise everthing work OK. I would like to know if that is problem, or what else I could try? I can't understand what is happening because I can see the ECOMM in netedit but can't make a link to it.
                             

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2109
  • YKPAIHA
    • ATU, Inc.
Re: Ecomm100 Problem
« Reply #1 on: November 13, 2007, 05:22:30 PM »
How often are you polling the slaves? I am not sure what the priorities are in servicing the requests from Directsoft, but could it be possible that the polling rate is so high that the module never has time to link with Directsoft? I know there has to be some sort of limit. You did say that adding a second ECOM modules allowed you to link up.

amos

  • Full Member
  • ***
  • Posts: 37
Re: Ecomm100 Problem
« Reply #2 on: November 13, 2007, 06:03:07 PM »
   I only use the other ecom to connect with direct soft. I use the ibox instruction driven by sp1. It polls all the nodes in about half a second.

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2109
  • YKPAIHA
    • ATU, Inc.
Re: Ecomm100 Problem
« Reply #3 on: November 13, 2007, 06:11:10 PM »
Do you have any delay between polls or do you poll consectively through the slaves 1-6 and then back to 1 without any delay?

Greg

  • HostTech
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 662
  • Hmmm...
    • Host Engineering, Inc.
Re: Ecomm100 Problem
« Reply #4 on: November 14, 2007, 09:11:21 AM »
Since you can see the module in NetEdit, this just means that the Ethernet side of things is working. I also venture to say since your Modbus TCP communications is continuing to work that the PLC side of things is also working.

Some questions:
(1)  Your question revolves around using just 1 H0-ECOM100 for the Modbus TCP mastering and connection to DirectSOFT, right?
(2)  Does installing the 2nd H0-ECOM100 for a dedicated DirectSOFT link fix all the issues?
(3)  In NetEdit, does the CPU Test pass for the 1st H0-ECOM100?
(4)  What error do you get in DirectSOFT when you try to make a link to the 1st H0-ECOM100?

It also may be interesting to find out exactly what is going on on the network as a whole by using Wireshark (free Ethernet sniffer) to log a sample of the telegrams when you are trying to make a link. Of course, this would require a hub (not a switch) for the sampling.
There are two types of people in the world; those that can extrapolate from incomplete data sets.

amos

  • Full Member
  • ***
  • Posts: 37
Re: Ecomm100 Problem
« Reply #5 on: November 14, 2007, 09:56:01 PM »
"Do you have any delay between polls or do you poll consectively through the slaves 1-6 and then back to 1 without any delay?"
Yes that would be the case.

(1)  Your question revolves around using just 1 H0-ECOM100 for the Modbus TCP mastering and connection to DirectSOFT, right?
Yes I am wondering what is happening. If the link is comunicating without any errors than I could conect with DirectSoft until there are a few timeout errors, after that I cant make a link anymore.

(2)  Does installing the 2nd H0-ECOM100 for a dedicated DirectSOFT link fix all the issues?
Yes it does almost. The only problem was I couldn't conect to the PLC.

(3)  In NetEdit, does the CPU Test pass for the 1st H0-ECOM100?
  Yes
(4)  What error do you get in DirectSOFT when you try to make a link to the 1st H0-ECOM100?
    I'm not at the PLC now so I can't answer. When i tried to make a new link I got as far as selecting the ECOM module.

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2109
  • YKPAIHA
    • ATU, Inc.
Re: Ecomm100 Problem
« Reply #6 on: November 15, 2007, 12:16:52 AM »
Just for an experiment if your application requirement allows this, try adding a delay at the point in time that you finish communicating with Slave 6  and before polling Slave 1.
Start at 500ms and see if you can link up. If so, back it off from there and see how small you can make the delay without having a link timeout. Use a fast timer. If it works, you may want to try adding a shorter delay between every poll, rather than one longer delay.

MikeS

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 253
    • Host Engineering, Inc.
Re: Ecomm100 Problem
« Reply #7 on: November 15, 2007, 10:49:24 AM »
what i suspect is going wrong is that you're getting errors & retrys in the modbus communications that are hogging the tcp/ip stack, which is causing some problems when the directsoft comm comes around.

you said the modbus comm portion of your program is essentially an sp1 contact and the netwx iboxes. is your program looking at the individual success and error bits from the netwx iboxes?

the way i've done these polling programs using iboxes is:
    do the first ibox
    wait on success or error to come on
    if error - increment ibox_1_error_cnt ( optionally stop here or enable next ibox )
    if success - increment ibox_1_ok_cnt & enable next ibox
 --
    repeat for each node
 --
    last ibox success enables first ibox again

this chaining method makes sure each node's activity (good or bad) is reported

this method also has the advantage of giving you a convenient place to insert some delay timers if needed
Good design costs a lot. Bad design costs even more.

amos

  • Full Member
  • ***
  • Posts: 37
Re: Ecomm100 Problem
« Reply #8 on: November 16, 2007, 06:39:47 PM »
you said the modbus comm portion of your program is essentially an sp1 contact and the netwx iboxes. is your program looking at the individual success and error bits from the netwx iboxes?
   Yes I have a counter for both error and success. In 48 hours I got on some nodes at the most 2 errors some had none.

the way i've done these polling programs using iboxes is:
    do the first ibox
    wait on success or error to come on
    if error - increment ibox_1_error_cnt ( optionally stop here or enable next ibox )
    if success - increment ibox_1_ok_cnt & enable next ibox
--
    repeat for each node
 --
    last ibox success enables first ibox again

this chaining method makes sure each node's activity (good or bad) is reported
   I tried your suggestion and it works. I can still make a link after a few timeouts. I taught the IBox instruction is supposed to take care or the enable bits?   

this method also has the advantage of giving you a convenient place to insert some delay timers if needed
   Didn't bother with the timers it works fine without them.

          Thanks Everybody for the help.   Amos

amos

  • Full Member
  • ***
  • Posts: 37
Re: Ecomm100 Problem
« Reply #9 on: November 17, 2007, 09:59:49 AM »
   It looks like I posted to soon it still does the same thing. Also installed some timers at the last IBox with a 1 second delay it still doesn't work. It's OK it works when using the other Ecom to connect.

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2109
  • YKPAIHA
    • ATU, Inc.
Re: Ecomm100 Problem
« Reply #10 on: November 18, 2007, 10:52:23 PM »
You say that you made the changes and it worked then it doesn't work.
Can you give more information of what happened? Were you able to connect?
Can you post the part of the program that you are doing the polling?
What brand of Network Switch are you using?

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3483
    • Host Engineering
Re: Ecomm100 Problem
« Reply #11 on: November 19, 2007, 10:13:07 AM »
Make sure you have the most recent firwmare.  Run NetEdit3 and click on File->Live Update to get the latest and greatest firmware, then upgrade your ECOM100 module if needed.

amos

  • Full Member
  • ***
  • Posts: 37
Re: Ecomm100 Problem
« Reply #12 on: November 20, 2007, 03:14:59 PM »

You say that you made the changes and it worked then it doesn't work.
Can you give more information of what happened? Were you able to connect?
   No   It says  Error connecting to PLC!
                     Error:
                     Ext Error:
Can you post the part of the program that you are doing the polling?

This is the code.
PLC 06

// Rung 1
// Address 0
ECOM100 K0 K4 V1400 V1401 V1402

// Rung 107
// Address 1504
STR C1000
ECWX K0 V510 K21 VC300 K1 C0 C400 C401

// Rung 108
// Address 1610
STR C400
INC V400

// Rung 109
// Address 1613
STR C401
INC V401

// Rung 110
// Address 1616
STR C400
OR C401
RST C1000
SET C1001

// Rung 111
// Address 1620
STR C1001
ECWX K0 V511 K29 VC320 K1 GY20 C402 C403

// Rung 112
// Address 1726
STR C402
INC V402

// Rung 113
// Address 1729
STR C403
INC V403

// Rung 114
// Address 1732
STR C402
OR C403
RST C1001
SET C1002

// Rung 115
// Address 1736
STR C1002
ECRX K0 V512 K2 V5670 K32 V4000 C404 C405

// Rung 116
// Address 1842
STR C404
INC V404

// Rung 117
// Address 1845
STR C405
INC V405

// Rung 118
// Address 1848
STR C404
OR C405
RST C1002
SET C1003

// Rung 119
// Address 1852
STR C1003
ECWX K0 V513 K3 VC40 K1 GY20 C406 C407

// Rung 120
// Address 1958
STR C406
INC V406

// Rung 121
// Address 1961
STR C407
INC V407

// Rung 122
// Address 1964
STR C406
OR C407
RST C1003
SET C1004

// Rung 123
// Address 1968
STR C1004
ECRX K0 V514 K4 TA0 K16 V4100 C410 C411

// Rung 124
// Address 2074
STR C410
INC V410

// Rung 125
// Address 2077
STR C411
INC V411

// Rung 126
// Address 2080
STR C410
OR C411
RST C1004
SET C1005

// Rung 127
// Address 2084
STR C1005
ECRX K0 V515 K5 V2400 K16 V4200 C412 C413

// Rung 128
// Address 2190
STR C412
INC V412

// Rung 129
// Address 2193
STR C413
INC V413

// Rung 130
// Address 2196
STR C412
OR C413
RST C1005
SET C1006

// Rung 131
// Address 2200
STR C1006
ECRX K0 V516 K6 V6033 K16 V4300 C414 C415

// Rung 132
// Address 2306
STR C414
INC V414

// Rung 133
// Address 2309
STR C415
INC V415

// Rung 134
// Address 2312
STR C414
OR C415
RST C1006
OUT C1007

// Rung 135
// Address 2316
STR C1007
ECWX K0 V517 K7 VC60 K1 GY20 C416 C417

// Rung 136
// Address 2422
STR C416
INC V416

// Rung 137
// Address 2425
STR C417
INC V417

// Rung 138
// Address 2428
STR C416
OR C417
RST C1007
SET C1010

// Rung 139
// Address 2432
STR C1010
ECRX K0 V520 K8 TA0 K16 V4400 C420 C421

// Rung 140
// Address 2538
STR C420
INC V420

// Rung 141
// Address 2541
STR C421
INC V421

// Rung 142
// Address 2544
STR C420
OR C421
RST C1010
SET C1011

// Rung 143
// Address 2548
STR C1011
TMR T30 K10

// Rung 144
// Address 2552
STR T30
RST C1011
SET C1000

// Rung 145
// Address 2555
STR SP1
RST C400 C421

Another Question
Where could I find information on the timeout settings for Modbus TCP. I have looked in the manual and can't find anything. Also slave timeout what is that for? Factory default is 20 sec.
   Thanks Amos

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2109
  • YKPAIHA
    • ATU, Inc.
Re: Ecomm100 Problem
« Reply #13 on: November 20, 2007, 03:45:49 PM »
The only thing that I can see that may be a problem (I'm not really sure if it is) is that you could have 2 WX boxes active on the same scan or at a minimum 1 WX active on all scans. When 1 completes the next one is activated but not really allowed to be scanned in the inactive state. The effect would be that you are never at the bottom of the program when the ECOM module is not being called to do something. Try reversing the program flow. Start polling at the bottom of the program and work you way up. That way when a WX instruction is completed, the ladder ends with no active WX instruction until the next scan.

jsatkanpak

  • Newbie
  • *
  • Posts: 8
Re: Ecomm100 Problem
« Reply #14 on: January 11, 2008, 06:04:39 PM »
We've found that in high-traffic situations there is definitely a "sweet spot" for polling speed.  Too fast and the communications breaks down -- too slow and the update rate is unacceptable.  We started using a 100ms polling rate and have had excellent results.  We use Modbus/TCP-to-DeviceNet a lot through AnyBus protocol converters and it's been a great solution.