Host Engineering Forum
General Category => ECOMs and ECOM100s => Topic started by: Controls Guy on July 06, 2011, 08:44:58 PM
-
I have an application where a 260 with an ECOM is a Modbus/TCP slave to an MMI, with the same port being used for commissioning and troubleshooting with DirectSoft, and on this particular unit, we will also be talking to 1 or 2 scales that can do Modbus/TCP as slaves. The MMI hits about four times a second and collects a couple hundred words, plus the occasional small transaction for a button press or setpoint change. I could probably slow the MMI down a little. Is it feasible to do all this with one ECOM or should I use a second one? And how does bandwidth work again with more than one ECOM in the rack? The scale feedback is controlling the addition of recipe components, so I don't want a lot of latency, or I'll overshoot. I'm leaning towards a second ECOM, but then I'm out of open slots and should probably add another base, so if I'm pretty sure it would work, I'd just as soon not.
-
PLC scantime will greatly affect the answer. We can do as many as three simple memory accesses per scan. The large number of words might take two accesses to get them all.
Adding a second ECOM slows down the PLC a bit, but doubles the number of transactions per scan.
No faster than you are needing data for the MMI, I'd say you will be fine...but...I don't want you mad at me if it isn't fast enough. ;)
-
For this app, I'd expect 15-20ms range on scantime at worst, and I might be able to time slice some of it as well.
One aspect I'm concerned about is mixing PLC master transactions (to the scale(s)) with slave transactions (from the MMI master). How does one go about coordinating and optimizing that?
-
Optimize based on necessary latency. Make the "fast as possible" be that. Make the things that can be "as slow as possible" do that. The more "as slow as possible" you have, the faster your "fast as possible" will be.
If EVERYTHING is "fast as possible" - it won't be (finite resources).
I used to work for a company that designed multi-sample medical diagnostic equipment. One of the operating mode flags for a specific sample was "stat" - i.e. run this patient's set of tests ASAP, and it would put it at the front of the queue. However, EVERY doctor would flag EVERY test as STAT, because, of course, their patients are more important than every other doctor's patients. So guess what happens - they all run at the same priority as if NONE of the tests were STAT. ;D
-
That still doesn't address the question of mixed master and slave transactions, which is what I've been trying to get at. The PLC can't proactively prioritize transactions it's not scheduling, so what control if any can the PLC exert in this situation? And further, what are the architectural features of an ECOM with DL CPU that allow master and slave transactions to coexist on the same port at all, when you don't (or if you can't) do anything explicit in the PLC? (Buffers, etc.)
-
The ECOM has no control over what a remote master is doing, but I assume that you do. The backplane transactions are still scan synchronous (done at the bottom of the ladder scan), and the 260 can do 1, 2, or 3 incoming transactions per scan, based on the type of transaction.
The outgoing transactions initiated by the 260 can only handle 1 pending outgoing transaction at a time. These transactions have no affect on the mechanism of the incoming transactions, only from the standpoint of the response buffer (i.e. collisions, but highly unlikely on a non-saturated network, but the chip has built-in collision handling).
Hence, I would make your masters poll at a "just fast enough" rate. If they are event based, then that will probably work out best for the ECOM. However, if the events occur at the rate of about once a millisecond, you'll probably end up losing some packets, let alone respond fast enough.
-
As Mark said, the incoming and outgoing mechanisms are different. As many as three per scan incoming, and one pending outgoing. Is that enough comm? Can't answer that. The 15ms to 20ms scan time is probably the biggest influence on the outcome, and won't be tremendously helpful.
-
The ECOM has no control over what a remote master is doing, but I assume that you do.
Yes and no. I can slow down the acquisition rate (probably), but I'm in the same boat as the PLC in the sense that I can't coordinate events, some of which I don't know about.
These transactions have no affect on the mechanism of the incoming transactions, only from the standpoint of the response buffer (i.e. collisions, but highly unlikely on a non-saturated network, but the chip has built-in collision handling).
That's what I'm concerned about. By "collision" do you mean literally, with bytes coming over the wire simultaneously, or does the term also include the more general sense of transactions overlapping, with receptions entering the buffer out of order? I've seen from the MMI's point of view a delay of 50 ms or so between a request and its response. If that's typical, I could easily see a case where an MMI master request arrives between a request by the PLC to one of the scales, and the corresponding response.
Does the PLC have the ability to look ahead down the buffer and rescue a response that has been cut in front of by another reception, or just request the next response be spit out of the buffer, processed and discarded? If it has to do them strictly FIFO, can it process the MMI request, and then get the next transmission out of the buffer, which is the scale response, and still be able to process that without crashing the ECxX?
-
As Mark said, the incoming and outgoing mechanisms are different. As many as three per scan incoming, and one pending outgoing. Is that enough comm? Can't answer that. The 15ms to 20ms scan time is probably the biggest influence on the outcome, and won't be tremendously helpful.
So if I'm understanding you, incoming and outgoing aren't capable of getting in each others way, other than with an (unlikely) outright bytes-on-the-wire collision, which seems like a rare and recoverable event. Is that correct? Do most switches have a buffer per port so they can store and forward, if they get two transmissions for the same recipient at the same time?
As far as the scan time, that's just a guess, may be conservative, and may be able to be managed by allocating tasks to be done over more than one scan.
And if you can handle at least one incoming and one outgoing transaction per scan (or even one or the other per scan) that should be plenty of bandwidth for the amount of information. I was mostly worried about management issues and the possibility of bring the bandwidth effectively to almost nil. If that can't happen, I'm not too worried.
-
From a physical layer sense. 50ms is a long time in Ethernet speak, so that isn't an issue. If you have a video camera broadcasting data constantly on the same network, that will definitely saturate your network.
There is a physical queue, but these are fast, and I think interrupt driven in the ECOM modules. The 260 master requests get processed in a different area of backplane "shared RAM", so the 260's request's responses will not get "hung up" based off the remote requests.
As long as you don't have BROADCASTS occuring CONTINUOUSLY (e.g. some security cameras), or just a A SUPER FAST Modbus Client, you should be okay. Funny, I think DirectSOFT will be your "fastest" client (it tries to read things as fast as possible). Modbus/TCP has built-in error detection/handling with retries, so your HMI should be okay, but check its error log to see if you lose any packets when DirectSOFT is doing ladder or data view status.
-
No, no "streaming" content. Just the cyclic requests from the MMI, event driven MMI stuff (writes from buttons or setpoint changes, these write on change-of-state only), DirectSoft, and cyclic requests to the scales. I haven't seen the scales' memory map but I can't imagine it's more than 20 words or so, so a fairly small transaction, and several times a second is probably sufficient to avoid overshooting when mixing the batch.
Sounds good. I'd rather not add another rack if I don't have to.
Oh, and we've done the same MMI with DirectSoft over the same ECOM in the past, so I know we have enough gas for those two. The scales (and attendant issue of mixed master/slave) are the only new wild card added to the mix.
-
Yes, as much as we like selling hardware, we really want to help customers solve their problems - I think you should have no problems with your current setup (one ECOM100 module).
There's one customer out there that carries an ECOM module with his laptop, and he just plugs in the ECOM module to his 205 base as a designated port for his DirectSOFT debugging sessions. ;D
-
Two actually, unless you were talking about me. ;D
-
It's YOU! Ha! That's funny! It's a small world (queue the children)...
-
We ended up going with two ECOM-100's, one slave for MMI and programming, and one master polling the scales. Thing goes like a bat out of hell. Thanks!
-
In this same application (one ECOM for MMI/programming and one for Modbus mastering of two MT scales), there is another 260 with an ECOM controlling another related machine. It would be cool if there were a way to link the two peer PLCs....
So my question is, if I were to add a periodic exchange of a few words of data between machines (probably via ECRX and ECWX from the dual-ECOM machine I've already described to the other machine's single ECOM), what would be the least intrusive way with respect to existing bandwidth usage? Add it to the ECOM that is currently slave only? Or add it to the one mastering the scales?
And...if I add it to the one mastering the scales, how do I allocate bandwidth between master requests to the scales and to the other machine? IOW if I want to talk to the scales as fast as possible and only slip in one ECRX and one ECWX to the other machine every second or something like that, how do I do that?
It boils down to how the transparent token passing works between ethernet Iboxes. When a box is done with the token, the next energized box in ladder scan order snaps it up? So I can do what I want by having the scale ECRX's energized continuously and only energizing the inter-machine calls once a second? Is that how it works?
Actually the same question applies to adding it to the MMI/programming one. How to throttle bandwidth consumption and execution frequency so as not to gum up the works too much for the existing uses.
-
KISS principle - stick it in the SINGLE ECOM'd 260 and have it poll once per second with one ECRX and one ECWX. Those requests would appear not much different than if you stuck DirectSOFT session on the dual ECOM'd PLC with no status (we poll for the PLC mode once ever 2 seconds, so it's a little different).
Even though the "application layer" is master/slave, Ethernet is wonderful in that it allows peer-to-peer at the physical and network layers.
-
If I need to do it from the other end, the dual ECOM machine, what is the best way? And can you do a little explicit tutorial on the token passing?
-
Attached is the basic flow chart for every "token passing" instruction (CTRIO clients, NETCFG clients, and ECOM100 clients).
Note that most of the ECOM100 clients have TWO tokens, a "higher level" token and a lower level "RX/WX" token. The ECRX/ECWX IBoxes ONLY need the "lower leve" "RX/WX" token. The other instructions attempt to get the "high level" token FIRST, then once it has that, it then tries to get the "RX/WX" token NEXT. This way, your ECRX/ECWX can FLY while the ECEMAIL instruction is waiting 60 seconds for your yahoo EMail server to respond to its SMTP requests.
There is actually a 3rd token, the PLC "slot busy SP" bit itself (not a token really, but more of a "guard"). Basically, NEVER mix EC* and NET* IBoxes with RAW RX/WX, always use the ECRX/ECWX and NETRX/NETWX IBoxes with the ECOM100 and NETCFG Configuration IBoxes
-
If you want to run it deterministically, run it on the 2nd PLC like I said.
Otherwise (i.e. you just need it to run approximately once per second), do the following:
STR SP3 // one minute SP
PD C100 // one-shot
STR C100
ECRX
ECWX
It doesn't matter where you stick it with a bunch of "as fast as possible" ECRX/ECWX IBoxes, it will eventually run. You could stick some interlocking logic on all your "as fast as possible" to make sure they never request the token whenever the C100 ECRX/ECWX is trying to get the token, but that's just advance interlocking mechanisms dealing with events, nothing to do with the IBox token passing - i.e. make sure none of the other "as fast as possible" IBoxes are actually "as fast as possible" by having them NOT have power during the time when
C100 turns ON to when the Done bit of the STR C100 ECWX comes on.
-
If you want to run it deterministically, run it on the 2nd PLC like I said.
Otherwise (i.e. you just need it to run approximately once per second), do the following:
STR SP3 // one minute SP
PD C100 // one-shot
STR C100
ECRX
ECWX
It doesn't matter where you stick it with a bunch of "as fast as possible" ECRX/ECWX IBoxes, it will eventually run. You could stick some interlocking logic on all your "as fast as possible" to make sure they never request the token whenever the C100 ECRX/ECWX is trying to get the token, but that's just advance interlocking mechanisms dealing with events, nothing to do with the IBox token passing - i.e. make sure none of the other "as fast as possible" IBoxes are actually "as fast as possible" by having them NOT have power during the time when
C100 turns ON to when the Done bit of the STR C100 ECWX comes on.
Actually, that is wrong. You'll have to write your own token passing mechanism because the ECRX/ECWX IBoxes are written such that once they are in the "home" state, and they have power flow, they attempt to get the token - there is no way of stopping the ECRX/ECWX from trying to get the token once you want it to try to get the token.
Therefore,
1. If you truly want determinism of this once per second synch, do it from the other PLC
2. If you just need to synchronize approximately once per second, just do the simple PD C100 example
3. If you are a masochist, and don't want determism the easy way (option 1) ;D, write your own token passing mechanism in ladder logic for ALL of the EC* IBoxes in the dual ECOM100 PLC.
-
Attached is the basic flow chart for every "token passing" instruction (CTRIO clients, NETCFG clients, and ECOM100 clients).
So obviously the "return token to config Ibox" step can be done within a scan (presumably by setting some bit in the config box's workspace) and grabbed by another Ibox farther down in the ladder on that same scan. Otherwise without any explicit arbitration, only the Ibox highest in ladder would EVER execute.
So my interpretation is this, and please tell me if I'm correct: Only when a box is energized and scanned does it decide it "wants" the token. It then checks for availability, and takes it if available. Once in possession of the token, the energized state is no longer relevant; the box will run to completion and return the token even if deenergized during the transaction. Is that right?
If so, my thought on throttling the inter-PLC comms is then equivalent to yours: Leave the scale comms continuously energized and on the expiration of the one-second recycling timer, latch a bit that enables the ECRX/WX to the other PLC. The success or error bit of the second box unlatches the enable bit and returns to exclusive polling of the scales.
(The other machine is technically not my machine although I probably have the authority to alter the program sufficiently to enable this exchange if I want to do it that way. If not, I want to be sure I can do it from my machine.)
-
Token mechanism: there is one bit in the configuration IBox workspace, and one bit in each individual Client IBox workspace. The "test if I have the token" is basically a check on the client IBox's workspace. The "test if token is available" is a check on the configuration IBox's workspace.
Your interpretation is not correct. On first scan, or on the scan after the client ECRX/ECWX IBox finishes, it sees if it has power flow - that means it WANTS the token. It Goes to the state that says "I want the token". That is latched. It does not latch the "I want the token" after it has the token. It latches the "I want the token" immediatley after it "wants the token".
If it doesn't need to be EXACTLY at a 1.000 second interval, my PD C100 on the SP3 contact is good enough because the ECRX/ECWX to the other PLC will INTERNALLY LATCH that it NEEDS THE TOKEN.
Here's the macro-ized mnemonics of the ECRX instruction. This may help or not help, but I really don't want to get into disecting it too much...
// ECRX (ECOM Read Network)
// P1 - ECOM#
// P2 - Workspace Register
// P3 - Slave ID
// P4 - "From" Slave Element
// P5 - Number of Bytes
// P6 - "To" Master Destination Element
// P7 - Success Bit
// P8 - Error Bit
// Workspace Bits reflect the STATE - at most 1 bit should be ON in the Workspace register (values 0, 1, 2, 4)
// P2 == K0 (no bits) - Home
// P2.*0 - WaitForRXWXToken
// P2.*1 - WaitForRXWXNotBusy
// P2.*2 - WaitForDone
// TEMPs
// B7710.0 - power flow upon entering IBox
// B7710.1 - when in WaitForDone state and Slot NOT Busy nor Slot Error at Top of Scan (success)
// B7710.2 - when in WaitForDone state and Slot Error at Top of Scan (error)
// B7710.3 - power flow when RX is executed but the SlotBusy SP bit does NOT come on (wrong slot)
// Save off Enable state into TEMP BIT
OUT B7710.0
// On First Scan, reset state machine to HOME state (Workspace = K0)
// Cannot reset success/error bits on first scan due to E471 Duplicate Coil error
// Do not allow anything else to occur on first scan
STR SP0
LD K0
OUT %P2
// If at Home state, and have power flow, clear the error and success bits, and go to WaitForRXWXToken state
STRE %P2 K0
AND B7710.0
RST %P7
RST %P8
SET %P2.*0
// If at WaitForRXWXToken state and not on first scan, and RX/WX Token is available,
// get the RX/WX Token and go to WaitForRXWXNotBusy
STR %P2.*0
ANDN SP0
ANDN %ECOM.RXWXTokenInUse
SET %ECOM.RXWXTokenInUse
SET %P2.*1
RST %P2.*0
// This completion logic must be BEFORE the RX rung, otherwise it appears to be
// done IMMEDIATELY! Duh!
//
// Top of Scan Status:
// --------------+----------------+-----------------------------------------------
// ECOM.SlotBusy | ECOM.SlotError | Result
// --------------+----------------+-----------------------------------------------
// 0-not busy | 0-no error | DONE, SUCCESS
// --------------+----------------+-----------------------------------------------
// 0-not busy | 1-error | Done, Error
// --------------+----------------+-----------------------------------------------
// 1-busy | 0-no error | not done, keep waiting
// --------------+----------------+-----------------------------------------------
// 1-busy | 1-error | not done, but error - REPORT AS DONE, W/ERROR
// --------------+----------------+-----------------------------------------------
//
// When we are in the WaitForDone state, if the slot is flagged as busy from the top of scan,
// and there are no slot errors at the top of scan, stay in this state (no logic for this).
// Otherwise, we are moving to the Home state as success or failure:
// Success:
// STATE == WaitForDone AND ECOM.SlotBusy is FALSE AND ECOM.SlotError is FALSE; B7710.1 will be on
// iff when this is true, set the Success bit
// Failure:
// STATE == Wait AND AND ECOM.SlotError is TRUE; B7710.2 will be on iff when this is true,
// set the Error bit (actually, this must be done as common logic towards end of logic)
// Common logic for transitioning to Home state is at end
STR %P2.*2
ANDN %ECOM.SlotBusy
ANDN %ECOM.SlotError
OUT B7710.1
SET %P7
STR %P2.*2
AND %ECOM.SlotError
OUT B7710.2
// Do the RX when the port is not busy.
// If the STATE == WaitForRXWXNotBusy and the Slot SP is NOT busy, then do the RX.
// Set the STATE variable to WaitForDone.
STR %P2.*1
ANDN %SPSlotBusy
LD %ECOM.Slot_MSByte
ORD %P3 // slave ID
LD %P5 // number of bytes
LDA %P6.o // master destination address in V memory
RX %P4 // slave source address
SET %P2.*2
RST %P2.*1
ANDN %SPSlotBusy // if the SlotBusy SP is OFF, then we are RXing to an EMPTY slot!
OUT B7710.3
// Common ERROR logic - when RX completed in error or when tried to RX to an empty slot
STR B7710.2
OR B7710.3
SET %P8
// Common DONE logic - set state to Home (K0), give up RX/WX Token
// Do this when RX completed successfully, when RX completed in error, or when tried to
// RX to an empty slot
STR B7710.1
OR B7710.2
OR B7710.3
LD K0
OUT %P2
RST %ECOM.RXWXTokenInUse
// restore original power flow
STR B7710.0
OUT B7710.0 // this eliminates the E464 errors by having a complete rung
-
OK, got it. That's exactly what I needed to know. Thanks! :)
-
Attached is a state diagram for the PLC ladder logic of the ECRX instruction