[FEATURE] - CIP listening server

[Fryj2841]

Type of Feature Request

• [x] missing feature
  • [ ] feature available in another library: please specify
• [x] change to API
• [ ] enhancing a current feature
• [ ] removal of a broken/unsupported/etc feature
• [ ] other: please specify

Feature Description The ability to listen for incoming cip connections from a plc such as a data table write would allow for process driven logging / data hand off.

I'm thinking this could be either a new API / driver or an addition to the existing logix driver. The new tool would need to utilize the data types from a logix connection to decode the basic cip data as it comes in from the plc.

Example:

A process triggers an event based on plc code. The plc code sends up a message with required data to the pc. The pc unpacks the data and uses it to do some heavy computations the plc cannot handle and then sends down the solution using the existing LogixDriver.write().

Possible Solution I started looking at developing this using a basic tcp socket listening server that then utilizes the logix driver for encoding and decoding but haven't gotten very far.

[KaungMAung]

Before adding this feature, I think we can implement it as in below. Use one of the tags in PLC as a trigger tag. It will be normally OFF/False. PLC code can turn ON the tag if it wants to do data transfer for heavy computation. And use pycomm3 code to monitor that trigger tag periodically. Once Trigger Tag is ON, pycomm3 will query/read the necessary data set from PLC, do heavy computing, write back results into PLC, finally, Turn OFF back Trigger Tag. PLC can wait for Tigger Tag to be OFF in order to determine whether the process is done.

[Fryj2841]

Kaung,    I can do some testing here to see if I can get fast enough response times doing the below mentioned method but im not sure it will work in this instance.  I want to implement this into a lumber mill where we need to have the handoff as quick as possible.  As the lumber is moving through timing points on the line at anywhere from 15-20ms per point.  Some lines require us to have solutions back down to the plc within 40-60ms.  Im worried that if we put the overhead in of monitoring a trigger tag may eat into my limited timing window. Like I said I will give it a try and share the results. Regards,Jarith FrySent from my T-Mobile 4G LTE Device -------- Original message --------From: Kaung Myat Aung @.> Date: 8/27/23 17:59 (GMT-08:00) To: ottowayi/pycomm3 @.> Cc: Fryj2841 @.>, Author @.> Subject: Re: [ottowayi/pycomm3] [FEATURE] - CIP listening server (Issue #295) Before adding this feature, I think we can implement it as in below. Use one of the tags in PLC as a trigger tag. It will be normally OFF/False. PLC code can turn ON the tag if it wants to do data transfer for heavy computation. And use pycomm3 code to monitor that trigger tag periodically. Once Trigger Tag is ON, pycomm3 will query/read the necessary data set from PLC, do heavy computing, write back results into PLC, finally, Turn OFF back Trigger Tag. PLC can wait for Tigger Tag to be OFF in order to determine whether the process is done.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[KaungMAung]

HI Fry, Yeah, We also have a similar kind of implementation but not as time-sensitive as yours. The lowest period I tried is 10ms. So,

1. A process triggers an event based on plc code. (PLC activate trigger Tag). The PLC code sends up a message with the required data to the pc. (PC query required data) --> (10+10 ms)
2. The PC unpacks the data and uses it to do some heavy computations the plc cannot handle. -->(Maybe less than 10ms?)
3. and then sends down the solution (and Turn Off back Trigger Tag) using the existing LogixDriver.write(). (Another ~10-20ms) Just my two cents of thought. Thanks and Rgds, Kaung

[KaungMAung]

To make it faster, we can query required data together with Trigger Tag, so that we can reduce response time faster. Attached is i am using pycomm3 and query 100 tags INT data arrary. it took only like ~3ms. So, we can definitely can go with 5/10ms period 1. PLC activate trigger Tag based on event. PC query Required data + Trigger Tag every 10ms. (~5-10ms)

2. If Triggered, The PC unpacks the data and uses it to do some heavy computations the plc cannot handle. -->(Maybe less than 10ms?) and then sends down the solution (and Turn Off back Trigger Tag) using the existing LogixDriver.write(). (Another ~10ms)

[jbolognini]

Another common technique is to load the data to be consumed into a first-in-first-out (FIFO) UDT array using the FFL instruction. When there is data available on the FIFO, the PLC turns on a data_produced bit. The PC monitors this bit and when it is true, consumes the first record on the FIFO stack, then writes a 1 to data_consumed_handshake. This triggers the PLC to pop off that record, and the process repeats with a new record in the first position until the buffer is empty. The additional handshaking may add a small delay but ensures that all data records are received by the PC before discarding them. The buffer will allow the PC to "catch up" if it gets behind due to lag. Depending on the processor memory and the payload size, a significant store and forward buffer can be implemented to make sure no data is lost. This can be combined with the previously mentioned technique of reading the trigger with the top record to shorten the data transfer latency,