Ethernet DAQ - Adavantech ADAM6000 (6017) - DL-250-1

[Acadien]

I am having trouble getting information on to my PLC from and Advantech ADAM-6000 analog input module http://www.advantech.com/products/Model_Detail.asp?model_id=1-23HX45&BU=&PD=ADAM This is my setup:
PLC: [DL250-1][H2-ECOM100 (SLOT 7)] I.P. 192.168.10.2/255.255.0.0
ADM-6017: 8CH AI MODBUS START AT 40001 I.P. 192.168.12.33/255.255.0.0

I tested the modbus link over TCP/IP with modscan and I am able to get the good information from the module.
In NetEdit I configured the H2-ECOM-1000 peep-to-peer section with the ADAM module being node 2.

This is my reading logic

     sp136 (comm busy special relay)   
|---|\|------------------------------[LD K0702]----|  { chassis 0, slot7, node 02}
                                              |---[LD K16   ]----|  {read 16 bytes - 8 words}
                                              |---[LDA O40001]-|  {read from 40001}
                                              |---[RX V7000]---|  { place starting at v7000}

Is there an IBox I should be using instead of RX?
It seem to try to read by looking at sp136, but at the end sp137(comm error) comes on, is there a way to see what the error was, perhaps in NetEdit?

[Acadien]

More Questions:
On the first LD (K0702) 07 should go into the upper Byte and 02 in the lower byte
should I accully input :
   DEC: { 0    7} {  0   2}
   BIN: 0000 0111 0000 0010
->BCD: 1794  -> LD K1794 ?

Also I will try LDA O15530 (= V7000 in BCD?) and RX V0

[Greg]

Hi Acadien,

I'll try to address all the issues that I see and answer your questions:

• Did you select Modbus TCP as the protocol in the peer-to-peer configuraiton of the H2-ECOM100?
• Your 1st LD instruction is correct (LD K0702); meaning: Base 0, Slot 7, ID 2.
• Your LDA O40001, however, is incorrect. This LDA is where you want to store the received data that you get back from your analog module. So, based on your comments, it should be LDA O7000 or something like that, to store the 8 words starting in V7000.
• Your RX V7000 will execute an FC03 - Read Holding Registers, starting at Modbus address 43585 instead of 40001. This instruction should be RX V0. (See attached .PDF file for clarification).
• You can use IBoxes instead of the logic you have; but the logic you have will work just fine. The IBoxes are ECOM100 (at the top of your ladders to tell the other IBoxes you have an ECOM100 installed); and the ECRX which you would basically use like your ladder logic you already have. If you need help understanding those 2 IBoxes you can read the Help in DirectSOFT v5.x, or ask here!
• Currently there is no easy way to read the error that was caused by the failed RX.

Hope that helps!

[Acadien]

Thanks, I got it to work
LD K0702 - LD k16 - LDA O7000 - RX V0 (which changes to TA0) because of the automatic mapping to timer accumulator T0.

I will change my logic to the I boxes, since I keep getting a ECOM100 comm failure, where the card completely freezes and need a reboot.

[Greg]

Great! Let us know if you still have trouble with the ECOM100 giving you comm errors.

[Acadien]

I've change my logic to use ECOM100 and ECRX. Do you have any suggestions about watchdogs, I am looking for a bit to toggle that would reset the ecom100 card, after multiple comm errors for example. Can the CPU monitor the comm card for any trouble, other that sp166/7 bits?

[Greg]

If you are using the ECRX IBox, then you don't have to "know" or "worry" about the SP-bits. Those SP-bits are "taken care of" by the Success and Error bits. So if you put Success = C0 and Error = C1, for example, then you can not only monitor whether a particular ECRX was executed with/without error by C1 but you could count the number of successfully completed transactions as well by counting C0's.

Also, there are not any bits to toggle that would reset the ECOM100. Are you saying that after getting multiple comm errors that the ECOM100 locks up and must be power-cycled or something? 

[Acadien]

My new logic worked for about 30 hours, and then the ECOM100 card crashed and needed a reboot. I also have a C-more (EA7-TBC) on the same network that talks directly yo the PLC. It's polling time is currently set to 0msec, perhaps it is a little bit too fast, and not giving a chance to the ECOM100. I have included both my programs (sorry for the little documentation in the .prj file)

[Acadien]

3 total system crashes in less than a week, The manual says I should replace the ECOM100 module.

[Greg]

Sorry Acadien for the delay.

I'm studying the files you sent. But also, is it possible for you to use Ethereal (http://www.ethereal.com) to sniff the network and capture:

• A sample of your working network
• A sample of your network after the ECOM100 fails
• Possibly catch the failure in the act?

Also, what are the versions of the booter and firmware for the ECOM100s that fail?

[Acadien]

It is not really possible to use Wireshark (formerly Ethereal) The plc is in a water pumping station

Also, what are the versions of the booter and firmware for the ECOM100s that fail?

booter: boot100_4_0_165.bin
Firmware: h2ecom100_4_0_1253.bin

[Greg]

Those are the latest firmware/booter files.

In looking at our H2-ECOM100 firmware history you can see that we have had instances when using Modbus TCP of the H2-ECOM100 turning on its fatal red light. However, to the best of our knowledge we have fixed all those issues. Barring your problem being a new Modbus TCP issue similar to those, then your issue may be related to noise.

If your problem is a new Modbus TCP issue, then we would really need a trace to figure out what is going on. So, does "nearly impossible" mean it is impossible?

If your problem is related to noise, then, of course, here are some things to check:

- Good installation practices:
  (1)  Use good quality Ethernet cable.
  (2)  Move the noisier cables (HV lines, drive cables, motors, etc.) away from the Ethernet cabling.
  (3)  Noisier modules (relay output modules) should be moved as far away in the base as possible from the ECOM100s.
  (4)  Don't route discrete I/O wiring in the same channels as Ethernet and analog cables.
  (5)  Pay close attention to the entire system's grounding strategy and layout (a schematic may be helpful here).
  (6)  Attention to detail is important. Some of the simplest things can be the source of the greatest improvements.

- Electrical noise on Ethernet cabling is very critical
- Noise can also be conducted via power supply (especially in a DL205 PLC system).
- Radiated noise is problematic for ECOM100s (VS ECOMs) because of the higher frequencies of operation.
- Radiated noise can also come from noisy I/O modules in the base next to the ECOM100 (the noisiest we've seen is by a relay module switching 220 vac next to an H2-ECOM100).
- All noise is additive, so efforts in all areas will result in a more robust system.

Does any of this help?

[Acadien]

I'm pretty sure it's a Modbus Issue, since the network is quite happy {doesn't crash; tested over 2 months} when I disable the logic I use to scan my ADAM Module. I increased the modbus timeouts by using Netedit on the peer-to-peer tab. I will setup a Wireshark monitoring Laptop to monitor the traffic.

[Acadien]

After much fussing I was able to properly install a wireshark monitoring laptop (I had to install and old HUB in order to capture all the traffic). I fixed a couple of issues coming from the Adavantech module and the Mirktotik routerboard. However I cannot, slow down the UDP traffic coming from the C-more panel destined for the DL-250-1 PLC. Here is a sample
TIME SOURCE DST PROTOCOL INFO
14:33:49.708 192.168.10.3 (c-more) 192.168.10.2 (PLC) UDP SourcePort:1060 DstPort 28784
there is also the reply from the PLC this happens every miliseconds. This is continuous traffic.
I changed the polling time inside the C-more, but noting changes.
I included a short wireshark file (just remove the .txt extension that is needed for the forum post.)

[Acadien]

I also see the UDP traffic between my PC and the PLC while I am connected to it. It looks like something inside the DirectNet protocol that continuously sends UDP Traffic. I have turned off the Operator Interface and instructed the opertors to simply turn on the OI breaker when they need to view or change setpoint inside the PLC. This should validate my UDP-crash theory if the system works for more that 3 days. I have also update my OI to the latest firmware.