Too Many Choices

[Controls Guy]

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.  

[b_carlton]

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.

[franji1]

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

[PLCGuy]

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

[Greg]

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.

[Controls Guy]

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.

[PLCGuy]

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.

[Greg]

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.

[PLCGuy]

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.