Host Engineering Forum
General Category => ECOMs and ECOM100s => Topic started by: PLCGuy on July 08, 2010, 06:27:31 AM
-
I have a ECOM100 (DL260) using modbus to a bridge which will convert to EthernetIP. What do I use to communicate from the DL260 to the bridge. I see ECOM100 CONFIG, NETWORK CONFIG, NETRX, NETWX, ETC. Some ask for slave ID, Port Number. I was going to use MRX but that looks like serial, I want tcp/ip. The help file is not that great. Sorry to who wrote that. Can't it be made simple with less choices. One choice for serial and one for tcp/ip? :)
-
To use:
1. Use NetEdit to make a Peer-to-Peer Configuration for Modbus TCP in the ECOM100. Chose Device number (doesn't matter what number except it will be used in a step below this one).
2. Put ECOM100 IBox at the top of your ladders.
3. Use ECRX to read, ECWX to write.
4. The ECRX/ECWX parameter Slave ID must match the Peer-to-Peer Configuration's Device number you chose above.
5. The Addressing you choose for writing to and reading from Modbus TCP registers must use a mapping designation as shown in this document (http://www.hosteng.com/FAQFiles/ECOM100%20Server%20Client%20Mapping.pdf (http://www.hosteng.com/FAQFiles/ECOM100%20Server%20Client%20Mapping.pdf)).
-
For now I am sticking with the old way. I used the sp136 sp137 with LD K701, LD K20, LDA O40620 WX V0. With that I can actually see if it is working using counters tied to SP136 Sp137. With The Iboxes I can only look at the lights on the port and I do not see any activity when using the iboxes. The succeed fail bits do nothing in the ibox. Sometimes the old ways work better. Using the ladder method has always worked for me. Oh I did set switch 7 but still not work.
-
I won't argue with you, but I will say that the IBox is just a ladder macro. Inside the IBox is the LD, LD, LDA, WX instructions plus some very nice you-can't-get-this-wrong logic to supply you with Success and Error. If these bits are not coming on, then there is something set wrong somewhere because, IMHO, IBoxes make everything MUCH easier.
I assume you are wanting to write C-bits (C400 thru C637) to Holding Register (offset 0) using FC16. I also assume your H2-ECOM100 is in Slot 7 and you have a Peer-to-peer configuration in the H2-ECOM100 to do Modbus TCP for Device ID = 1. With all this in mind, the params for the IBoxes would be something like:
ECOM100 IBox
ECOM100# = K0 (anything you want, just has to match parameter below)
Slot = K7
Status = V400 (anything you want, just no overlapping)
Workspace = V401 (anything you want, just no overlapping)
Msg Buffer (65 WORDs) = V402-V502
ECWX IBox
ECOM100# = K0 (must match the one above)
Workspace = V503 (anything you want, just no overlapping)
Slave ID = K1 (this must match the Device # you configured in the Modbus TCP peer-to-peer Device #)
From Master Element (Src) = VC400 (i.e. V40620)
Number Of Bytes = K20
To Slave Element (Dest) = TA0 (i.e. V0)
Success = C0 (anything you want)
Error = C1 (anything you want)
Now this is equivalent to your ladder logic. And you can count C0s and C1s for successes and errors. If these never come ON, then most likely you have some overlap in the params, or the IBox is not getting executed, or it is in a Stage and left hanging, or it is in the process of timing out.
-
Greg I wonder if the problem is the slave#. In the peer-to-peer it is Device ID= 0 not 1. Is this wrong? I haven't had a chance to try changing it. The ladder is working fine, but I hate to give up on something that i know should work. It will just bother me.
-
Okay Greg explain this one. I found the problem. I had the counters counting success/errors before the iboxes. Once I moved them after the ibox rungs, all was good. So do ALL iboxes have to be at the beginning? And it did not matter if Device ID was 0 or 1.
-
Greg I wonder if the problem is the slave#. In the peer-to-peer it is Device ID= 0 not 1. Is this wrong? I haven't had a chance to try changing it. The ladder is working fine, but I hate to give up on something that i know should work. It will just bother me.
As I pointed out in my post, the Device # of the peer-to-peer config must match the Slave # of the ECWX IBox; doesn't matter what it is.
Okay Greg explain this one. I found the problem. I had the counters counting success/errors before the iboxes. Once I moved them after the ibox rungs, all was good. So do ALL iboxes have to be at the beginning? And it did not matter if Device ID was 0 or 1.
No, all IBoxes do not have to be at the beginning. The ECOM100 IBox needs to be at the top of the scan, but the ECWX can be anywhere you like. It matters what the Device ID is if it doesn't match the configuration of the peer-to-peer. In order to explain what is happening, I would have to see your program. For instance, sometimes, an experienced user will mix and match the "old" way with the IBoxes, like still use the SP bits to trigger the IBox.
-
I created a ECOM Stage. The first rung had the succeed bit tied to a counter. The 2nd rung has the error bit tied to another counter. The 3rd rung was the ECOM100 Ibox. The 4th rung was the ECWX Ibox. There was no action on the succeed or error bits. I removed all previous ecom rungs I was previous using. So I first deleted the counter rungs and it started to work. I put them back and nothing worked again. Finally I moved the counters to the end of the stage after the iboxes and everything worked. At first I thought the counters at the beginning were not working because maybe at the end of the scan they were not being read so I went to the RJ45 jack and saw no activity. Also in data view the bits were off. But everything is good with the bits and counters after the Iboxes. Darn now I forgot the other thing I tried, I think I took the counters and put them in another stage that was always on and everything worked. It was only when I put the status bits and counters in the same stage before the iboxes, nothing worked. How clear is all of this? Before you ask, yes I did a search on every counter and bit to make sure they were not used anywhere else.
-
The 3rd rung was the ECOM100 Ibox. The 4th rung was the ECWX Ibox
Did these rungs have any sort of conditioning bits other than SP1 (Always On)?
-
I do not have any bits on the ibox rings. I noticed some boxes require sp1 bit to compile and some do not.
-
When you had the two counter rungs before the IBox did you use an SP1 in the rung going to the IBox to get it to compile as a seperate rung?
-
Nope. So I have the ECOM100 on a rung. It will not allow the sp1 bit on the rung. I put the sp1 bit on the ECWX and on the rung for ECRX. That fixed the problem where the success/error counters could be placed. This seems to relate to greg's original comment about the stage hanging up. By putting the sp1 bit on the rung what does that do to make it work right. If needed, why does it let u compile with no error. The ECOM100 box pops up a reminder window about switch 7 on the ecom card being set. Do other Iboxes need the same type pop up box for reminders or hints?
-
I wasn't thinking about the ECOM100 command. But the other ones, if placed after a conditioned rung without a condition of its own compiles into he previous rung. This enforces what actually happens when executing in the DL world. It doesn't know 'end of rung' or 'start of rung'. If you have a previous rung in ladder or an individual stage then this rung inherits the 'truth' which had been determined at the 'end' of the previous rung. It actually runs as if a continuation of the previous rung which is why Directsoft redraws it that way.
So if it had redrawn as a single rung then the ECWX or ECRX would only execute if the conditions were true.
[Corrections - my computer is a terrible speller.]
As a note, as I understand it, the STRx instructions effectively begin a new rung by pushing the previous rungs 'truth state' on to the binary stack ans start with their own 'true' state. Which is why the STR SP1 serves the purpose.
-
...what b_carlton said...
Plus, normally the ECOM100 IBox should not be in a Stage, unless that stage is never disabled; it needs to execute every scan. Also, if you execute ECRX/ECWX in a Stage, make sure you do not disable the stage without first getting a Success or Error bit.
-
It is in a stage that is always on and never goes off. So in understanding what is being said, I did need the sp1 on the ECRX and ECWX rungs? But why did they compile without error? If there was an error when it tried to compile I would have found the problem much more easily. It sounds like the ECRX ECWX need to have a bit of some sort on their rung. When I try to add a bit on a rung that the Ibox does not need, such as ECOM100,an error pops up saying I can not do that. The reverse should happen, if the bit is needed a message should also pop up.
-
I think IBoxes might be an exception to the rule about needing to start every rung with a contact. The IBoxes are simply macros representing a bundle of calls the processor actually has instructions for. There is no "ECWX" instruction in the CPU. That's what I had assumed that they were, and couldn't figure out why PLC's with updated firmware were needed to use them, since essentially it's just Directsoft lying to the programmer (or at least giving him the executive summary) of what's in the PLC. Mark said that the reason new firmware was required was to provide for the inclusion of extra NOP rungs to delimit the range shown in Directsoft as an IBox. Point being, maybe that NOP is serving to force a rung break like the SP1 contact does. I know I can enter a rung with an Ibox and it doesn't gripe if there's nothing on the rung ahead of the IBox. You can omit the SP1 on the first rung in a subroutine, for example, because there's the SBR box immediately upstream and the mnemonics aren't such that it looks like a continuation of the previous rung.
-
The firmware had to be updated to provide a new mnemonic that marked the IBox. It doesn't DO anything during execution but on connecting to a programmed CPU which has an IBox instruction the group of instructions get read as an IBox and not just a group of instructions.
The important point is, do the group of instructions (seen on exporting with expansion enabled) have a 'contact' in them that does the same thing as a STRx at the beginning of a rung? If so then any conditioning logic in front of an IBox would be lost.
-
The firmware had to be updated to provide a new mnemonic that marked the IBox. It doesn't DO anything
Bernie is correct. All they are is a NOP opcode with a value in the lower word other than 0. The IBox Configuration instructions like ECOM100, NETCFG, CTRIO CAN NOT have any input logic - they run every scan - and MUST run every scan - and should NOT be in a Stage, unless that stage is ALWAYS enabled FOREVER.
Most other output instructions typically need input logic to set their state. However, THE FIRST RUNG IN A SG allows for a simple OUT or TMR or output rung because the top of the boolean stack in an enabled stage, immediately after the SG instruction has the value of TRUE, and it similifies the logic:
SG S0
OUT Y0 // drive output Y0 in this stage
STR X0
JMP S1 // transition to S1 (and hence turn OFF Y0) when X0 turns on
In order to support this capability, most instructions that require input logic we flag as "MAY have input logic" for the one case where it appears in the rung IMMEDIATELY AFTER the SG instruction.
Rungs are edited automically, not at the "program" level, so we cannot know when you are wanting to drive the output because you are then going to insert an SG instruction immediately before this non-input logic rung. If we had an offline syntax check, we would make sure that these non-input logic rungs ONLY appeared where they are "ladder logically" valid.
However, since there are handheld programmers, and some programs are written with GOTOs and can technically be represented in a ladder diagram, but do not execute based on "power flow" conditions (vs. mnemonic instructions).
If you entered these valid instructions in a handheld programmer:
STR X0
OUT Y0
NOP
OUT Y1
these would appear as 3 separate valid rungs in DirectSOFT, and Y1 will appear as a rung tied to the power rail. However, it will be ON when X0 is ON, and OFF when X0 is OFF.
The PLC is just executing assembly language instructions - the CPU has no concept of a "rung". Ladder logic rungs are a concept that is "manufactured" by DirectSOFT. DirctSOFT does its best to enforce ladder logic rules, but there are definitely holes between what is "acceptable", what is "valid" and what is "good practice".
-
I did get it all to work, sorta. I have my receive from the robot starting on GX0. My wx starts on GY0 to the robot. the wx to robot is fine. When I turn on GY0 the robot sees it and so does my GX0! Why does GX0 turn on. I have a scanner (EthernetIP) in there. The plc is doing modbus TCP to a gateway then to the EthernrtIP Scanner. What gives? Also GY1 turns on GX1, etc
-
Not sure what you mean exactly; a little vague. How do you know GX0 is following GY0? Are you doing a WX GY0 (which uses FC15 to write to Modbus Coil 1) and then using RX GX0 (which uses FC02 to read from Modbus Input 10001)? If so, then the loopback you are seeing must be happening either at the gateway (doubtful), or at the EthernetIP Scanner (more likely). The ECOM100 would not write to GX0 on its own.
-
Or the robot echoes its command registers to part of the input range. I've seen slave devices do that before. I've also done it myself in PLC's where the MMI used on the project was such that if you read a certain register and the MMI thought it knew the value because it had just set it itself, it would just show the value it was already aware of, which would create a false impression if the setpoint transmission had failed. To make it a true echo all the way from the other end of the wire, I copied setpoints to a different register range and read those registers in the MMI.
-
Yes Greg I believe it is happening at the scanner. I do not know what to put in the info boxes. It wants word size and input address and output address. The input and output sizes are 2 to 16 and then the starting address has to be a number 0 to 255 which includes the size number. Same for the ending address. Very confusing. Both are set to 0. I can not get any help on this from the vendor. I'm ditching the HMS Anybus and going to try a ProSoft Unit. If all fails, We are just going to add terminator I/O close to the robot run the cable and call it a day. Put a Ethernet module in the terminator I/O run it to the PLC ECOM100 and be done with it. Wait a minute It has to go to a ERM or somthing, not to a ECOM100? I do not have room for another card. Maybe I can expand the DL205 base with a D2-EM then just run a cable. Cheaper too.
-
If it is a T1H-EBC100, it can be mastered by an ERM using our own protocol, or it can be mastered by the ECOM100 using Modbus TCP. Of course, using ERM is much easier.
-
I got the problem solved by buying a bridge from ATA. They have really tech support. What was nice about the ATA unit was the way they set up the modbus side. They took a big chunk of input 404000 and a big chunk of output 400001 on the modbus side. I might have that backwards. Then on the other side I specified the instance with the length. That info was supplied by Denso. It turned out to be io mapping of the RS5000. Input instance was 101, length 32 and output instance 100, length 32. In the plc it was WX V7640 RX V4. I could not use V0 cause they use the first few for status stuff. Works perfectly. They did have a reversal bit choice, which I picked. I now have a simple, cheap way to communicate with EthernetIP (AB). The gateway was like 650 bucks. It did not require any RSLinx or RSNetworx! This is a big door open for us in that we can communicate cheaply and reliably to any manufacture that only supports AB.