- This topic has 1 reply, 2 voices, and was last updated 2 years ago by
.
-
Posts
-
Hi Mik,
My production setup is on V5. I have run into this issue for months, the solution without changes in RS is to apply hard rate limiting.( in this case the ScadaServer tcp client is my app which push data to output channels)
Though I hard limited the update rate in my code, the command handling might be an aspect where RS could consider to improve.My client app writes to one PLC station at a constant rate over a shared modbus bus line, which has several PLC connected. The machine PLCs are Mistubishi Fx series, their Modbus module has a maximum rate of 19.6k,
– When the command overrun happens, by the time I notices, the command queue is pilled up with commands which takes more than 3 minutes to finish after I disconnect my client app.
– During the event no data is queried for other PLCs on the same line, data updates seems simply stoped for them. I can not see queries to them in detailed log.
– It seems that this happens more often if some PLC on the same bus went offline. I suspect the retries might contribute to this.I think, to the user, this is about dealing with one type of signals that requires in-sync update, not micro control of queue size, full queue strategy etc.
Some type of commands are preferred to be treated in a lossy way. If it failed, it should be ignored, and continue with the latest command.
instead of queuing them up and without missing any single command.
Out of sync signals could cause serious issue in machine control, equally dangerous as missing command in some case.Hope this could help generating some ideas for improvement in V6 or future development.
- You must be logged in to reply to this topic.