Shorter IO Respond Time

Hi community,

We are currently working on opzimizing the overall I/O response time using Nodka I/O Coupler
( Model : AL-1219 )

Our target to acheived a total round-trip I/O response time ( Send Output SignalRead Input Signal ) of <= 1ms.

During our testing, we discovered the average round-trip response time is about 4.8ms. Based on AL-1219 hardware manual, the digital input hardware features a fixed Input filter of typically 3ms. By deducting this hardware filter time ( 4.8ms - 3.0ms ), we estimate the remaining network communication and processing take approximately 1.8ms.

In order reach our 1ms target, I would gladly appreciate some insight into the following quesitons:

  1. Are there any method to shorten or bypass the 3ms digital input hardware filter ?
  2. Is the reaminign 1.8ms communication/processing overhead dependent on PC performance?

Any advice, parameter configurations, or best practices from your experience would be highly appreciated.

Thanks

1 Like

Hi @Frank12,

  1. Other than switching higher performance hardware, its unlikely that you’ll find a way to configuring it for better performance. I could imagine a scenario where you might disable a subset of the 16 available inputs to improve evaluate of the rest, but it would be detailed in the AL-1219 manual if so. I don’t see a little * in that manual picture which would lead me to be believe it can be improved.

  2. Your output module is also going to take some hardware specified time to realize it’s output based on control Signal. You can’t expect sample sample response from Output to Input. So you’ll be adding a sample to this time as well. Plus the intend to send may well fall at the worst possible time. So worst case is effectively 2 samples. Average case is 1.5 samples. (1.5ms at 1kHz, 750us at 2kHz, 375us at 4kHz.).

You can adjust your sample rate to see some improvement though your biggest gains will be hardware related.

Hi @jacob,

Just wanted to add on, I would like to seek some clarification regarding IOPoint (specifically output):

For output.Get(), how is the output result determined/retrieved from output.Get()?

  • Is it based on when RapidCode API sends out the command for output or based on the signal retrieved from hardware’s output?
  • Additionally, if the corresponding hardware output is not configured or not physically connected, what value would output.Get() return in that scenario?

The reason for asking is that we are currently evaluating input/output response times and would like to accurately determine the timing between:

  • The output command being issued by RapidCode
  • The output being processed by the IO module/driver
  • The actual output state being reflected in hardware

Any clarification on how output.Get() or input.Get() behaves would be greatly appreciated.
Thank you very much for your support and guidance.

Hi @gregory,

output.Get() will reflect the RMP memory location associated with the IOPoint created. This will be intended output on the next sample. It doesn’t reflect that actual state of the Output. Some IO does provide its output value as feedback. For that hardware, you can see the Output state as Input value from the node.

  • Output command will go out every sample. The only delay is were the request happens relative to the sample process.
  • Output processing is determined by how the EtherCAT node interacts with its ESC. Effectively how frequently it reads the network traffic. (Check the manual on this.)
  • output state is determined by hardware specifications. The manual should tell you how long it takes to energize or otherwise realize its ideal state.

input.get() should be updated every sample from whatever the IO placed in its Exchanged values in the ESC.

1 Like