Do-more H2-DM1E Ethernet/IP "Cyclic communications"

[CMDRMOORE]

I have been able to communicate and set up several devices with the Explicit communications.
I know that Implicit communications is not(yet?)possible.
I have one device, an Epson RC robot that will accept Explicit communications, but it also has its' I/O port monitoring with "cyclic" communication.
Is Cyclic the same as implied or is it possible to use the Explicit command running on a 0 interval to poll the I/O port information?
Perhaps I do not understand what "cyclic" means.

[BobO]

I have been able to communicate and set up several devices with the Explicit communications.
I know that Implicit communications is not(yet?)possible.
I have one device, an Epson RC robot that will accept Explicit communications, but it also has its' I/O port monitoring with "cyclic" communication.
Is Cyclic the same as implied or is it possible to use the Explicit command running on a 0 interval to poll the I/O port information?
Perhaps I do not understand what "cyclic" means.

Not certain, but yes I would bet cyclic is implicit. EIP explicit uses TCP, whereas implicit uses UDP for the I/O data. UDP is faster and I certainly wouldn't use TCP for I/O as the first choice (all of Host's protocols are UDP-based), but there is a ton of Modbus/TCP I/O that does exactly that. As long as the comms don't negatively affect the device your are talking to, set the time to 0 and let it rip.

We are planning to add implicit master and slave in a future I/O module.

[CMDRMOORE]

Thank you for your timely reply.

I have been using Explicit communications with a Keyence Product. NU-EP1 with an array of 16 LV-N10 amplifies.
Each Amplifier is an instance. So far they seem to send their Detect/No detect with no problems or noticeable delays.
16 EI boxes running on the same rung as continuous with 00 00 000 delay. Am I actually chancing missing a state change from one of the instances?

I was going to try the attribute for the cyclic memory area and read the 16 inputs as a word or all 32 words and use the bits from that word, but if that word only comes over UDP, it probably woun't work.
Thanks again.

[BobO]

There is always a risk of missing events with remote I/O, and for event-centric functions (like scanning a bar code), vendors will generally implement the comms as an arm/operate/report protocol. Not familiar with your device, be that is definitely a question I would want answered.

[aside]
When we developed the original CTRIO, that was a major concern of ours. Since the Koyo PLC wasn't accessing the module synchronously, and because
it could take many scans before the entire memory map was exchanged with the PLC, we implemented a handshake interface. Drove users and tech support crazy because it was 'hard', but once the PLC code was correct, it always worked...even from a remote base. We could have done it 'easy', but would have risked creating flakiness that might only show up once in 10000 operations. We were able to hide the details from the user through IBoxes and Do-more instructions, so it's painless now, but there are definitely some products out there that insist on 'easy', even if it makes for an unstable product.
[/aside]