Forum Home › Forums › Communicating with Devices › Modbus › Slow communication speed
- This topic has 11 replies, 3 voices, and was last updated 5 years, 5 months ago by Mikhail.
-
AuthorPosts
-
October 1, 2018 at 7:52 am #4316baharsahinParticipant
Hi,
My PLC and Rapid SCADA are communicating through modbus tcp. I have one active device with 480 input channels to read. One communication session takes 10-11 seconds. When I send a command to one of these parameters from web, it takes 4-5 seconds to write to PLC. I can see the new value in web 10-11 secs after I send the write command from web. I think 10-11 secs is too long. How can I make this communication faster?
Thank you in advance!
Delay after request cycle = 100ms
request after device command = checked
In Request Sequence part of the communication line;
Time and Period = 0 ( I tried Time = 0 and changed Period but it did not affect)
Timeout = 500
Delay = 0Data refresh rate in web is 500 ms
October 1, 2018 at 10:28 am #4317manjey73ParticipantTo set the settings property is an extraordinary interview after sending the command.
Also change the poll method to group, where possible
October 1, 2018 at 10:32 am #4318baharsahinParticipantCould you please explain this in more detail : To set the settings property is an extraordinary interview after sending the command.
All possible parameters are in an element group. So, I think they are being polled together?
Is there any other way to change poll method to group?
October 1, 2018 at 10:38 am #4319manjey73ParticipantThen it turns out that you have everything right. 480 parameters this is clearly more than Modbus can allow with a single request. Try to separate the query groups so that the parameters you change are often in separate groups. That is to make a logical separation.
October 1, 2018 at 10:42 am #4320baharsahinParticipantI guess it is not reading 480 parameters at once because all these 480 parameters are seperated in different Element Groups. I have 1 element group with 46 parameters, the others have parameters less than that.
October 1, 2018 at 3:29 pm #4321MikhailModeratorIn my opinion, you should try to make as less groups as possible to increase speed. Even if you don’t need all registers in a group, it’s better to have one bigger group than several small.
Max. size of a group may depend on a particular device. You should do experiments to find it out.If you provide link to a screenshot of the Modbus template, it will help.
October 2, 2018 at 5:28 am #4325baharsahinParticipantI have some registers that have different parameters on each bit. For example 1001 (holding register) has 16 bits and each is a different parameter. Since I could not enter an address like 1001.08 to the address part, I am reading this register 16 times with different register names and then I am entering a formula on input channels part.
If I can read this register once and create 16 different parameters with different names, it may be faster. Will doing this configuration affect and How can I do this?
October 2, 2018 at 6:37 am #4326manjey73ParticipantYes, the register should be read once and then on the basis of the input channel of this register to apply the formula GetBit in settlement channels. You really spend a lot of time on the same type of reading.
October 2, 2018 at 5:00 pm #4329MikhailModeratorLogs and screenshots needed.
October 3, 2018 at 4:53 am #4334baharsahinParticipantI will change the translate table and my input channels accordingly and check the speed again
October 4, 2018 at 8:34 am #4341baharsahinParticipantHi,
It turned out that my device cannot reply more than 50 requests at once. Thats why I made my groups with 50 elements.
Also I read the 16 bits register with holding registers function once and assigned the same register to 16 input channels with different names and by using formula, I got 16 different bits of that register and assigned them accordingly to the input channels. Now the speed is OK.
Thank you very much for your help!October 4, 2018 at 2:13 pm #4342MikhailModeratorGood!
-
AuthorPosts
- You must be logged in to reply to this topic.