Dear all,
we use a device which can be read and written through something like GET/POST requests. Currently reading from that device takes like forever and exceeds the cycle time of our RevPi Core 3+. We could just increase the cycle time to one or two seconds, but that makes the system too slow.
As I am making good experiences with the ModbusMaster and looking into the Serial Gateway I am wondering if there is something similar for Ethernet. Is there a device which can be programmed to send and read data via ethernet (GET/POST requests) and stores that data in the process image?
If yes, how would I need to configure that device?
If no, is there a workaround available?
Best, Robert
Reading ethernet device
Re: Reading ethernet device
Hi Robert, have a look at Node-Red and HTTP Requests. Alternatively you could just write a Python script.
-
- Posts: 58
- Joined: 03 Dec 2019, 10:29
Re: Reading ethernet device
Hi Dirk,
we are already using GET and POST requests in Python, but they take too much time. So for us it is not a problem of the code, but rather of the communication which takes too long. Thus, we hoped that there is maybe something like the serial gateway for ethernet, which we could program. Do you have something like that?
Best, Robert
we are already using GET and POST requests in Python, but they take too much time. So for us it is not a problem of the code, but rather of the communication which takes too long. Thus, we hoped that there is maybe something like the serial gateway for ethernet, which we could program. Do you have something like that?
Best, Robert
Re: Reading ethernet device
Hi, the interesting thing is what minimum delay do you expect for the request/response. So I don't expect this will be faster using another communication device.
Instead maybe there are other influences that "waste" time. Some ideas: DNS, routing, the server itself takes long, concurrent access.
You could test the minimal delay via a point to point connection without any other devices on the Ethernet segment and try it again.
Instead maybe there are other influences that "waste" time. Some ideas: DNS, routing, the server itself takes long, concurrent access.
You could test the minimal delay via a point to point connection without any other devices on the Ethernet segment and try it again.