Host Engineering Forum
General Category => ECOMs and ECOM100s => Topic started by: Acadien on April 04, 2007, 07:45:54 AM
-
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 (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?
-
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
-
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!
-
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.
-
Great! Let us know if you still have trouble with the ECOM100 giving you comm errors.
-
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?
-
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? :o
-
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)
-
3 total system crashes in less than a week, The manual says I should replace the ECOM100 module.
-
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?
-
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
-
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?
-
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.
-
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.)
-
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.
-
My ECOM100 failed again, without the C-more on the network. So I am back to the Modbus theory, the only problem my wireshark capture did not show anything usefull, it stopped recording about 4 hours before the crash. I have ordered a new ECOM100 card to replace the existing one.
-
I cannot download the file you posted. When I do and try to open it in Wireshark, I get "The capture file appears to be damaged or corrupt. (pcap: File has 3932160-byte packet, bigger than maximum of 65535)".
Was the capture supposed to show a crash?
Also, we have seen crashes with Modbus TCP on older firmware and have fixed them. So, it is possible that there is another such crash that we need to fix. I doubt it is the ECOM100 hardware that is the problem. But a capture showing the crash would certainly tell the tale.
-
Unfortunately, the data capturing laptop stop capturing about 4 hours before the crash. It had been recording for 2 1/2 days. I am thinking of replacing the ADAM module with a DL06 with an Analog input card and another ECOM100 module for communications. I will install another laptop running Linux ans start another capture run. Is the continuous UDP traffic from the c-more normal?
-
Please keep us informed of your findings. I was about to start a project using the exact same equipment, but given your troubles I am now hesitant to do so. The question then becomes do I avoid the DirectLogic PLC or the Advantech I/O?
-
I have ordered equipment to attack my problem on two fronts. First, I will replace all my UTP-Cat5 cables with Sheilded TP cat5e, properly install and ground them as I would Shielded analog twisted pair (i.e. one end of the drain grounded an the other floating) this should eliminate most of the noise. The other "front" will be the replacement of the ADAM module with a DL-06 PLC + 4Ch AI module and ECOM100. This was actually my first idea in the pre-design of the system, the DL+AI+ECOM was more expensive that the ADAM-6017 module. I will still communicated with the ECOM but I will not be using Modbus TCP/IP. It will be at least 2 week until I can confirm all is well, one week to install and one week of "wiresharking". It is my understanding that the ECOM100 is more susceptible to noise that the ECOM. If this works out and is a noise issue I will have learn a great deal. I don't mind replacing the ADAM module with a PLC, although more expensive, it will be more usefull for other monitoring activities. From reading the specs, the DL-06 CPU is very similar to the DL-250-1 (PID, Float etc..).
-
From reading the specs, the DL-06 CPU is very similar to the DL-250-1 (PID, Float etc..).
Actually, it is even closer to the DL-260 CPU:
- more memory than the 250-1
- more instructions than the 250-1
- faster PLC scan times than the 250-1
-
This is an update on the ADAM Vs ECOM trouble I was having. I am happy to say my communication network is working fine now, I have removed the ADAM module from the system and sold it on e-bay ;D. I now only use ECOM100 to ECOM100 communication and everything is going fine. I never found out what the exact problem was with the ECOM100 and ADAM not playing well together.
-
Acadien,
This is a long time in coming, but I may have some good news. It depends upon whether it is relevant still.
We were finally able to duplicate these weird types of errors after working on this for a very long time and we discovered some definite bugs in the ECOM100 firmware in the area of the TCP stack (thus, Modbus TCP). After extensive testing and also some field testing, we believe we have fixed all these mysterious lockups. Firmware with these fixes is available for download using NetEdit Live Update.
H0-ECOM100 v4.0.222 (or later)
H2-ECOM100 v4.0.1444 (or later)
H4-ECOM100 v4.0.1444 (or later)
Just wanted you to know in case you were still seeing rare lockups.
-
Thanks I will update the modules firmware next week (I have a never-update-anything-on-Friday rule). I ended up replacing the ADAM module with a DL-06 with a H0-ECOM100 card. This setup has never failed. I am glad you found a Modbus related bug, since we are planning as expansion of our system to connect to a generator and a drive. I am sure it was difficult to catch, I had a laptop running wireshark for a few days, and of course the comms never failled.... I can now reconsider Modus over IP using the Ecom's. Good job guys.