Slow communication speed

Forum Home Forums Communicating with Devices Modbus Slow communication speed

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #4316
    baharsahin
    Participant

    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 = 0

    Data refresh rate in web is 500 ms

    #4317
    manjey73
    Participant

    To set the settings property is an extraordinary interview after sending the command.

    Also change the poll method to group, where possible

    #4318
    baharsahin
    Participant

    Could 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?

    #4319
    manjey73
    Participant

    Then 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.

    #4320
    baharsahin
    Participant

    I 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.

    #4321
    Mikhail
    Moderator

    In 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.

    #4325
    baharsahin
    Participant

    I 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?

    #4326
    manjey73
    Participant

    Yes, 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.

    #4329
    Mikhail
    Moderator

    Logs and screenshots needed.

    #4334
    baharsahin
    Participant

    I will change the translate table and my input channels accordingly and check the speed again

    #4341
    baharsahin
    Participant

    Hi,

    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!

    #4342
    Mikhail
    Moderator

    Good!

Viewing 12 posts - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.