KRC2 EIP Config

the telnet screenshot shows that node 4 is offline and all values are zeroes.

is the gateway itself configured?

does the configuration match your robot settings?

i only see that it is a node 4 and baud rate is 125kbps but not the role (master or slave) or size of IO blocks.

Quote

Unfortunately, I have no idea how the existing configuration was set up. Apparently there's no functionality built in to let you read from the comm card... It should have been fairly simple, though, as it was just talking to one EA7 HMI panel. I was able to pull the EDS before breaking the config so I think it should work, but I keep getting comm errors (device not ready: status 65 & error on read/write of EthIPDRV). It's just using a generic EDS that I added 50 bytes of IO to.

iosys.ini:

My additions are just the "IOBK" and "PLC" lines underneath [ETHERNETIP].

I do not understand what you mean there.

why are you adding two connections at once on a system you are not very familiar with or where information is lacking?

there are plenty of settings that need to be made and all need to be correct so keep it simple and only add ONE node... when this one is ok, then add the next one etc.

when working with EIP on KRC2 i always used my own Ethernet switch (separate from the plant network) and only connect things i really need (and gradually add more things if needed).

for example if making connection to PLC i would connect 4 cables to the ethernet switch (and nothing else):

1. PLC (or whatever product need to be setup to talk to KRC via EIP)

2. Laptop (required for setup and diagnostics, not used in operation)

3. KRC onboard ethernet (required to configure and transfer settings to EIP card, not used in operation)

4. KRC EIP card (required to communicate to PLC)

next i would choose network settings for each node and IO size to be exchanged.

then i would choose roles (Which side is master, which is slave) since setup is a bit different when roles are reversed.

and then, configuration can begin...

once the setup is complete and working, next node would be added (IOBK for example) and process would be repeated etc.

once everything is setup and working on local network, then laptop and KRC onboard Ethernet port would be disconnected.

remaining Ethernet cables would be connected to the regular Ethernet switch (plant network).

Don't have access to robot so following document was created using my recollection and some screenshots that i had. Therefore correctness or completeness cannot be guaranteed but for the most part it should be correct and point out things to pay attention to:

oh and yeah, this should be obvious but just in case:

IO size of the instance must match on both ends even if expressed in different units.

On KRC side allocation is done in bytes.

On AB PLC there is no byte but SINT is a same size (also 8 bit).

Although not necessary, it is a good idea to keep the same units.

for example if one side is set to 16 BYTEs, the other node could use either 16 BYTEs, or 16 SINTs or 8 WORDs or 4 DWORDs or etc.

Personally I prefer to use bytes for fieldbus. This is the because recalculation is not needed and diagnostics tend to be simpler (the raw values are same on both ends even when they use different endianness).

Hmmm... bummer...

I would say start from scratch and keep it simple. Do not mix things up, focus on ONE thing:

If you want to pursue DeviceNet - good. Make a thread JUST about DeviceNet.

If you want to pursue EIP- also good. Make a thread JUST about EIP setup.

When everything is piled up in one thread, nothing will get done even if it takes very long.

And make a connection diagram, with configuration of each side.

Make sure that everything you try is detailed to a point that others could replicate it.

Quote from jyimg

I think the DeviceNet issue is a conflict between the MFC and the gateway's functionality (not sure it supports a master on both sides?), but we'll do some more digging and see what happens.

DN is a bus that has strict rules -- one Master, up to 255 Slaves on a single bus.

Since the KRC2 MFC-card DN driver can only act as a Master, the Gateway would have to be configured to act as a Slave on its DN side. IIRC, the Gateway can be configured to act as either M or S.

your DeviceNet topology is not a bus. this would be the first thing to look at. note cable lengths, cable types (trunk/drop) and location of terminators.

next check DNet hgateway configuration. DNet side must be configured as DNet slave, have unique macid and operate at same baud rate as rest of the DNet.

Quote from jyimg

Here's a pic of the network, in any case:

Where are your DeviceNet terminating resistors on that diagram? They should be located at the ends of the longest cable distance between any two nodes. (and remember, two -- no more, no less). Looking at your diagram, I would guess Nodes 2 and 5 (or Node 2 and the Gateway, depends on cable length of each branch). Remember, DN has a total cable length limit, a trunk cable length limit (defined by the distance between the terminators), and a limit for each branch (anything from a T that doesn't end in a terminator).

Quote from jyimg

Pic of dnShow:

Have you tried a dnWho? That should query the bus and show a report of every node that reports back, with enough details to set their entries in the DEVNET.INI file. Any node set to the correct baud rate should respond to the dnWho command.

in my experience most of the problems are due to bad wiring.

if wiring is correct, it is possible to make fieldbus work - even rookie will be able to get there just by playing with parameters.

but...

but when wiring is not correct, it is impossible to make the bus work regardless what settings you try.

also, i would add that you are not serious about getting this to work or you would be reading applicable documentation and considering advices of those trying to help you.

terminating resistors are not optional. they are REQUIRED and NEED to be placed at the ends of the BUS.

what you have described is NOT a bus.

so you want this to work, you really need go ahead and check it out:

1. find WHERE the terminating resistors are placed

2. MEASURE length of each cable section

3. draw an EXACT topology of the whole thing INCLUDING lengths of cable sections.

4. check connections at the node that is not working (DNet has 4 conductors + shield. is this really connected correctly?)

5. check node settings of the non-working node and compare with master.

about wiring... there are two DNet cable types - thick and thin.

thick cable is really thick (like a thumb). this is preferred (superior performance) type of cable but it is not cheap or easy to work with.

thin cable is thin (like a pencil). this is cheaper, more flexible and usually easier to work with but this degrades performance which means bus length and bus speed are to limited.

the long cable section between the terminators is called a TRUNK (like a tree trunk). normally this is the place for thick cable.

the branches are short cables that connect node to the TRUNK. Branch segment is called DROP. Sometimes drop may be split into further branches. However this is not preferred. ANY non-zero length of the drop or branch is ruining bus performance and at some point part of the bus. Failure to observe lengths means that part of the bus or even complete bus may be UNUSABLE.

If the part of bus is communicating, this does not mean that things are perfect. It simply means that nodes are able to overcome distortions - presently. But that may be a very delicate balance, close to the point of instability. Adding another cable to such bus may tip the balance and some or all of the nodes may not be able to communicate.

The thing is that each DROP should be really as short as possible (zero meters) to call this a bus. In practice drop length may be non-zero. Depending on size of network, bus speed etc. it may be ok to use drops that are up to certain length. Specification may tolerate something like 3m or even 6m or so (whatever the specification states).

Consider following examples:

top case is a true bus - just one cable and properly terminated. Any nodes would be connected directly to the trunk.

next is less than ideal bus but - much more practical. drop lengths are present but they are short.

the last case is unacceptable configuration since it contains drops with excessive cable lengths.

Quote from jyimg

Honestly, I didn't see anything resembling the resistors but I didn't really look for them. I would guess they might be plugged into two of the field blocks...? The existing nodes still seem to work fine, so I would assume the resistors are okay?

If the existing nodes and dnWho work, your resistors are probably ok, but it can't hurt to check. Termination comes in 3 different types on DN:

1. some modules have internal termination resistors that can be connected or disconnected using the same DIP switches used for setting the MAD ID.

2. On the circular 5-pin connectors (your Ts probably look like this), there can be big thumb-sized terminators that look like a 5-pin circular connector that's caped off

3. On the 5-pin Phoenix connectors (like the X801 on the KRC's MFC card), you'll usually find a regular old resistor like you might buy at Radio Shack back in the day, stuck into the screw terminals for the CAN+ and CAN- lines.

Each Terminator should be 121 ohms, with 4% tolerance or better. If you power down the DN bus and use an ohm meter at any point on any branch of the bus, you should see 60 ohms between CAN+ and CAN-, plus or minus 2, maybe 3 ohms. The failure I see most often is someone leaving one or both terminators off, or adding more than two.