pturmel

EDS files document what is in the device.  Changing the EDS yourself doesn't magically make those parameters/assemblies/features exist in the device.  You even say: I don't see why you would guess this.  One product is from HMS Networks and the other is from Mitsubishi themselves. The HMS device is exposing a set of parameters in CIP classes 0x29 and 0x2a that are well-defined in the CIP spec.  The Mitsubishi EDS documents many vendor-specific class object parameters that are not.  I suspect you will only succeed if you purchase the full-featured interface from Mitsubishi.

Can you swap the v6 and v7 units to see if it is a physical difference?

You necromancer, you. Do note that Omron NJ/NX only respond to services 0x4c, 0x4d, and 0x4e.  In my experiments for my Ignition driver, they did not support services 0x52 and 0x53 for fragmented transfers, and will therefore be unable to bulk transfer structured data types larger than can fit in a large connection, and they only support large connections a bit under 2000 bytes.   Hmm. Not so sure about 0x4e, now.  Will have to experiment some more.

Interesting.  I should probably make a wizard to do this with my Ignition driver.

First, IPv6 doesn't have wide support among PLCs, so anything that is going to talk to a PLC needs to use IPv4. Second, DHCP servers can be configured to hand out dynamic addresses in one range, but offer specific IP addresses to specific MAC IDs in a separate range.  With this approach, no laptop or guest system will clash with an IP address reserved for an OT device.  Many PLCs can use DNS names instead of IP addresses in their configurations, too. (All modern Rockwell stuff can do this.) That said, I'd still set static IP's on critical systems.  There's no reason your IT department needs DHCP to have a complete DNS picture.  That's what zone files are for.

Interesting.  No longer shown as available for download with my integrator toolkit (but I have it activated for the current year).  You should talk to your Rockwell distributor.  I know they have formal channels to handle this kind of situation.

A Rockwell distributor can still sell you a license to Studio 500.  Might be cheaper to get a local integrator to use their toolkit to extract and convert the program for you. /:

* I can't remember the last time I plugged into one of these, but I'm pretty sure it was a USB-to-serial converter to a Windows 7 VM.  Probably before I switched from Prolific-based converters to FTDI-based USB-to-serial converters (better hardware support across many PLC types). As for the toggle button: * Absolutely.  It's purpose is to make it possible to re-establish programmer connections on the models with a single serial port, where that single port needs to talk a custom protocol to something else in normal operation. * Yes. * If your process needs that custom protocol, it won't run while you have the comms overridden.

That would be rather easy in Ignition's Vision client with the Paintable Canvas.  (For "easy" varying with Java Swing and Jython skills....)

I applied standard boolean transformations to simplify the logic, similar to transforming an algebra equation.  Karnaugh maps work well, too.

By standard, there are long timeouts for TCP sessions after close before the ports can be re-used.  There's a socket option that can be used when creating a socket to permit immediate re-use after close.  Please show your code for how you are creating your connection.

No, that combination of set and reset coils doesn't follow changes to SW2 and SW3 while SW1 is on.  (Why would you use set and reset for pure combinatorial logic?  Needless complication that just confuses ordinary people.) { The comment I replied to here has been deleted.  }

FWIW, I think this is the simplest implementation:  

If really as shown (and there's no reason to think differently), those inputs are not convertible.  They are sinking, with shared negative common.  You will need another (different) module, or add an interposing relay.

Failing shorted is common. Yes, likely fried.

I should note that this is no longer true.  The relatively new 850E and 870E added this capability.

Attribute reads are service code 0x0E.  Symbol reads are 0x4C (established and documented by Rockwell for Logix, but implemented by Omron in the NJ/NX family, too).  Netbiter would have to have a new driver to perform CJ-specific services for its memory types.

Never heard of them. Please report back with your experiences.

Ok.  Looks like a bust.  The netbiter doc shows only attribute get or symbolic tag get, but you are trying to read the unit's data table.  That requires service code 0x1C or 0x1D, which is custom to Omron.  Per §9-2-1.

Where is the documentation for class C4 in the PLC? (Which doc number?)

Never heard of them.  Docs?

I was specifically addressing use of this module.  An NJ501 can also host the EtherNet/IP traffic with its built-in port.  I've worked with an application where an -EIP21 was added to an NJ501 to add total connection capacity, and to get past the 600 byte buffer limit of the NJ's built-in port.

Probably. I know it can be done with the CJ1W-EIP21 attached to an NJ501, where the tag sets involved are given explicit assembly numbers, are limited to 500 bytes, and the Rockwell PLC is the scanner.  (Logix PLCs do not implement adapter mode for external scanners.)  I have no experience with the CJ family itself, so I cannot help there, but I suspect it can be done. There are hints that producer/consumer tags might also be made to work, but I don't know about that.

When you have the data, fault, and uncertain bits mashed into a data type like that, it will always occupy multiples of 32 bits.  In this case, wasting 29 of every 32 bits.  If you replicate the pattern in your buffered copy, you can use the COP instruction to grab the whole array as-is.  There's nothing that will efficiently copy the bits while rearranging them into adjacent bits of an INT or DINT like the older devices.

I would simply subtract B from A to get the delta as D. Then I would determine if outside the deadband by checking (D>DBpos) || (D<DBneg). DBpos and DBneg being constants, preferably.  The latter being negative. Then motor control is: if outside deadband and Dsign is off, run forward. If outside deadband and Dsign is on, run backward. Where Dsign is the high bit of the delta value. (Or vice versa, per your setup.) The above is best when the motor control is "run" and "direction".  If the motor control is "run forward" and "run reverse" as separate coils, you can use the halves of the deadband check directly.