AlfredoQuintero
Lifetime Supporting Member
Hello. This is for motion experts, and EtherNet/IP and DeviceNet system integrators.
I am more into communication and I sometimes need to advice customers in their application as it relates to communication.
This one customer has submitted their EtherNet/IP adapter capable motion device to us to do a preliminary conformance test to assess whether the device can pass official test at ODVA Test Service Provider.
I am discussing with this customer the behaviour of their device, and although I cannot find a clear violation of the CIP specs., I think their device behaviour is not good (or could be better), yet I do not have good explanation to convince the customer.
Moreover, the EtherNet/IP conformance test, at least as far as I can understand the test specification, would not check the behaviour I describe below and the product could pass conformance and be released with the current behaviour, which I think will cause a lot of after sales support nightmares for my customer.
The communication interface is provided by one of the largest third-party embedded modules makers. The module has its own processor, embedded switch and MOD and NET status lamps.
My problem with the way this module is configured.
After power ON, when a LAN cable is connected to either of the RJ-45 jacks, if the baud rate is recognized and there is no address conflict detected, the NET STS flashes green (no problem with this as there is no IO communication), but the problem is that the MOD STS lamp also flashes green, which is the "standby" status of the module, as per CIP specification terminology. The operational status of the module is solid green for MOD STS lamp. The reason I say this is a problem is because if the scanner is connected to the network the device will initiate IO communication normally, meaning in this device the flashing green status is equivalent to operational status.
For example the Rockwell 1743-AENTR device, if you do factory reset to the device will startup with the MOD STS flashing green because the number of slots of the chassis is reset to zero and this will be different to the actual IO modules connected to the backplane; consequently the response to forward open request will be error response with extended status 0x0010 (mode or sate of module does not allow object to perform requested service).
There is nowhere I can find in the CIP spec that says that a device in standby status should not be able to successfully respond to forward open requests, and this is why I cannot make a strong case.
I am concerned that end users who are familiar with CIP will see a module status flashing green and think there is a problem, when for this particular device there is actually no problem.
The customer and my colleagues seem to think something like "who cares about this if the product can pass the ODVA conformance test and the product can be registered."
And yet, I fell I need to press this point to my customer strongly so they do the necessary (and minor) changes in the application to reflect a more reasonable behaviour for their device.
If you were able to read down to this point, thanks a lot, and if you can provide advice will be most welcome.
I am more into communication and I sometimes need to advice customers in their application as it relates to communication.
This one customer has submitted their EtherNet/IP adapter capable motion device to us to do a preliminary conformance test to assess whether the device can pass official test at ODVA Test Service Provider.
I am discussing with this customer the behaviour of their device, and although I cannot find a clear violation of the CIP specs., I think their device behaviour is not good (or could be better), yet I do not have good explanation to convince the customer.
Moreover, the EtherNet/IP conformance test, at least as far as I can understand the test specification, would not check the behaviour I describe below and the product could pass conformance and be released with the current behaviour, which I think will cause a lot of after sales support nightmares for my customer.
The communication interface is provided by one of the largest third-party embedded modules makers. The module has its own processor, embedded switch and MOD and NET status lamps.
My problem with the way this module is configured.
After power ON, when a LAN cable is connected to either of the RJ-45 jacks, if the baud rate is recognized and there is no address conflict detected, the NET STS flashes green (no problem with this as there is no IO communication), but the problem is that the MOD STS lamp also flashes green, which is the "standby" status of the module, as per CIP specification terminology. The operational status of the module is solid green for MOD STS lamp. The reason I say this is a problem is because if the scanner is connected to the network the device will initiate IO communication normally, meaning in this device the flashing green status is equivalent to operational status.
For example the Rockwell 1743-AENTR device, if you do factory reset to the device will startup with the MOD STS flashing green because the number of slots of the chassis is reset to zero and this will be different to the actual IO modules connected to the backplane; consequently the response to forward open request will be error response with extended status 0x0010 (mode or sate of module does not allow object to perform requested service).
There is nowhere I can find in the CIP spec that says that a device in standby status should not be able to successfully respond to forward open requests, and this is why I cannot make a strong case.
I am concerned that end users who are familiar with CIP will see a module status flashing green and think there is a problem, when for this particular device there is actually no problem.
The customer and my colleagues seem to think something like "who cares about this if the product can pass the ODVA conformance test and the product can be registered."
And yet, I fell I need to press this point to my customer strongly so they do the necessary (and minor) changes in the application to reflect a more reasonable behaviour for their device.
If you were able to read down to this point, thanks a lot, and if you can provide advice will be most welcome.
