Pycomm3 vs Pylogix Connection speed

[AndrewStuhr]

Hello good sir!

I was recently writing to a single tag with Pycomm3. It was taking a while, sometimes 6 seconds, which I attribute to a busy network with other active connections to the PLC. I tested writing to the tag with Pylogix, and it was consistently faster, with a worst case of 1 second.

I'm pretty sure this time difference comes from time to create the connection, not the time to perform the write. Do you know why Pylogix's connection speed is faster, and whether there's any parameters to use when connecting with Pycomm3 to speed up the connection time? I tried "init_program_tags=False", but that didn't change the speed.

As always, thanks for making this sick library.

[ottowayi]

You're correct in that it's not the write taking longer, but the initial connection setup. That's because pycomm3 uploads the full tag list (and optionally program-scoped tags too) after the initial EtherNet/IP connection is established, pylogix does not have that overhead. One goal I have is to make pycomm3 the easiest and fully featured library, but that comes at a cost of higher startup times. The main benefit (and feature most libraries are lacking) is full structure (AOI, UDT, etc) reading and writing. The tag and data type definitions allow those structured types to just work from a user perspective. You can just feed in any tag name into a read/write method and it will make it work as best it can, without needing to worry about the type, size, etc. It also allows the driver to be more intelligent when it builds the EIP requests. For reading tags, it can accurately track the size of the response and will automatically split up the tags across multiple requests to stay within the protocol message size limits. Also, for example, if an AOI is too large to fit into a single response, the driver will automatically issue fragmented requests to read the tag. Which is a different service than a typical tag read.

There probably is a way to have it grab the tag definitions on demand instead of up front, but I haven't worked on anything like that yet. It's recommended that you don't open and close the driver between every request, because of this delay. It's best to use the same connection and leave it open until you're done. This can be an issue though, especially for small gui utilities, since the driver doesn't maintain the connection. Periodic requests must be made or the PLC may close the connection on it's end. I chose not to add request scheduling, heartbeats, etc partly due to extra complexity and also to let users decide how they want to that to work and not just how I want it to.

But, if you're infrequently reading/writing or don't want to worry about having to maintain a persistent connection, you can share the tag definitions between drivers so only one has to have the initial overhead time.

For example:

# in some startup or app initialization code, get the plc tags and save them
def app_init(self):
    with LogixDriver(self.ip) as plc:
        self._tag_definitions = plc.tags

# and then in some method that reads a bunch of tags, pass those saved definitions to the new driver
def read_tags(self):
    with LogixDriver(self.ip, init_tags=False) as plc:
        plc.tags = self._tag_definitions
        results = plc.read(*self.tag_list)

Hopefully that explains some things. It's a good question that I don't think I've really explained before, thanks for asking.

[AndrewStuhr]

Thanks! Yep I'll keep the connection open to minimize the overhead time.

[AndrewStuhr]

Circling back to this thread: do you have any recommendations for keeping the connection open? Reading an arbitrary tag every 60 seconds? Any thoughts would be helpful. Thanks!

[ottowayi]

Yeah, you should be able to do any tag or something like get_plc_time or get_plc_name. I don't remember exactly what the timeout is, but once a minute should be fine.

[Xiadais]

Seconded that it would be a really nice feature from a performance standpoint (for GUIs and other on-request applications) to be able to construct the tag definitions on-demand, as required by read and write requests, instead of preassembling the entire thing. It sounds like it would be quite the major change, though.

[ottowayi]

Yeah, I agree. I would like to make loading on the tag list optional and lazy load the definitions as needed or allow user specified ones in an easy way. It's difficult to get right currently b/c everything is just a dict without clear indications of what fields are required and what aren't or how to create them. I plan on redoing all of this in v2, including making the tag definitions dataclasses so it's easier to construct them manually. Unfortunately, I have no timeline on v2 other than I'm working on it as I get time to.