Forum Home › Forums › Communicating with Devices › Modbus › Slow communication speed
- This topic has 11 replies, 3 voices, and was last updated 7 years ago by
Mikhail.
-
AuthorPosts
-
October 1, 2018 at 7:52 am #4316
baharsahin
ParticipantHi,
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 #4317manjey73
ParticipantTo 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 #4318baharsahin
ParticipantCould 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 #4319manjey73
ParticipantThen 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 #4320baharsahin
ParticipantI 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 #4321Mikhail
ModeratorIn 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 #4325baharsahin
ParticipantI 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 #4326manjey73
ParticipantYes, 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 #4329Mikhail
ModeratorLogs and screenshots needed.
October 3, 2018 at 4:53 am #4334baharsahin
ParticipantI will change the translate table and my input channels accordingly and check the speed again
October 4, 2018 at 8:34 am #4341baharsahin
ParticipantHi,
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 #4342Mikhail
ModeratorGood!
-
AuthorPosts
- You must be logged in to reply to this topic.