Time to read/write to PLC is 10-20ms. Is this normal? about pylogix HOT 12 CLOSED

I need to read 300 tags and write to 500 tags in one step. This means the read takes 3 s and the write close to 10 s. These are individual tags (input and output tags) not part of an internal PLC tag array.

Thank you

from pylogix.

This is a Rockwell PLC

from pylogix.

That is definitely possible when reading/writing unique tags each time.

When a tag is accessed for the first time, 2 exchanges happen. First, the data type is requested, then the value is requested. Once the data type is known, we can just request the the value. This adds a little overhead when the tag is read for the first time. Doing this makes it easier on the user because they don't have to specify the data type up front.

In my tests, 20ms is a bit high, I get around 9 or 10 ms on the first read (which would be every read for you). I'm typically testing on a wireless network, you may get a little better performance when using a wired connection.

Out of curiosity, what is the specific part number of the PLC you are working with?

from pylogix.

from pylogix.

Thanks for the feedback, I'll look into your results.

Have you tried grouping your tags in lists to read? For example:

tagGroup1 = ['tag1', 'tag2', 'tag3', 'tag4']
values = test.Read(tagGroup1)

This would save you some time with each read. For now, you just need to ensure that you don't exceed the ~500 byte packet limit. This doesn't help you with writes though, but will cut some time with the reads.

from pylogix.

Ok, I did some quick testing. I used wireshark to measure times. I was testing over a wireless network.

1000 individual reads of unique tags took ~14 seconds
breaking up the 1000 tags in to lists of 10 tags and reading the lists took ~8 seconds
edit: For my threads, I did 10 threads, each reading 100 individual tags, it took ~3 seconds.

Regarding reading individual tags and using your suggestion on FastRead made no difference for me, as I would have expected, removing those ~12 lines of code would be irrelevant in CPU time scale.

from pylogix.

from pylogix.

The 500 byte limit is in the CIP specification for this type of data exchange. I think some controllers can support larger packets, but I wanted to stick with what any controller would support.

Mapping the tags to an array is definitely a good way to get the time down. I should have mentioned that option first, a lot of people don't like modifying their PLC programs though (understandably).

The reason working with arrays is a lot faster is because you send one packet to get the data type of the tag, then one request for the values, the controller responds with however many packets it takes to get the values to you. You can fit quite a bit of information in a packet, so there are far fewer socket exchanges. Run wireshark and compare the difference.

I was thinking that I may be able to make a change where you could specify the data type up front and save the time it takes to request the data type.

from pylogix.

from pylogix.

I finally pushed a change today that allows you to specify the data type when reading/writing. This will eliminate the request for the data type the first time a unique tag is read. It is an optional parameter and technically only needs to be provided on the first read of the tag (though it can be specified any read after without issue).

from pylogix.

from pylogix.

Yeah I did catch that. Putting the data into arrays and reading/writing is the most efficient. I ended up making the change anyway since there are people that may not have the luxury of being able to do what you did.

Dealing with arrays will still be much faster than utilizing the change that I made.

from pylogix.