Bandwidth and playing nice in a multi-use application

[Controls Guy]

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.

[franji1]

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.

[Controls Guy]

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?

[franji1]

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

[franji1]

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.

[franji1]

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) , write your own token passing mechanism in ladder logic for ALL of the EC* IBoxes in the dual ECOM100 PLC.

[Controls Guy]

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.)

[franji1]

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...

Code: [Select]

// 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


[Controls Guy]

OK, got it.  That's exactly what I needed to know.  Thanks!   

[franji1]

Attached is a state diagram for the PLC ladder logic of the ECRX instruction