Announcement

Collapse
No announcement yet.

Click Send (0-broadcast) and Receive (Modbus ID 2)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts


  • Click Send (0-broadcast) and Receive (Modbus ID 2)

    I am working on a Master Slave network using the RS485 (Port3) at 19200 baud.

    I will have an unknown number of slaves so I want to broadcast (modbus ID 0) in the Send command because all the slaves require the same information from the master. I then want to interlock and decide which slave I should send the Receive command to (this could be 1 to 22 slaves so I will have 22 Receive commands). Right now I just have 1 master and one slave and have one Send and one Receive command.

    I have it all wired and I know the comms are working as I have tested the interlocking Send and Receive in 2 ways. One method was Send to Modbus ID 2 and Receive Modbus ID 2. This works perfectly as expected. The interlock works and no errors are counted.

    I then changed the Send command to Broadcast (modbus ID 0) and left the Receive command as is to modbus ID 2.

    The broadcast always reaches its slave but the Receive command is very intermittent and takes 5-13 seconds to update and the error bit for the Receive command is firing as I have it next to a counter and can view the count value rising.

    Any ideas why I cannot Send a broadcast then immediately receive modbus from specific slaves?


  • #2
    What are you settings on the receive? Term char or fixed length? Is is sensitive to the scan rate? Are you just getting a partial message, not the complete message? I think I have a similar issue where the first 1-2 bytes is not received.

    Comment



    • #3
      With the Click Modbus serial communications, there are times that a delay needs to be placed between Writes and Reads. Put a one second in just to test. If it is successful, drop the time delay until the problem re-appears.
      This communication problem has been discussed in this forum several times.

      Comment



      • #4
        I put 100ms between Send and Rec and that works better. I did not need the delay when the mod id was 2 for both send and receive. I recreated the Interlocking example from the users manual page 4-31 and it worked great. I only needed a delay after changing Send to Broadcast so that is why i was concerned. I played with modbus timeouts in the setup box for port 3 and that made things slightly better but still lots of errors from the receive command after the broadcast command.

        Comment



        • #5
          I will have an unknown number of slaves so I want to broadcast
          Will this 'unknown' number of slaves change from one first scan to the next first scan? If NOT, you could query each slave on a Master first-scan-memory to get a population list.

          then want to interlock and decide which slave I should send the Receive command to (this could be 1 to 22 slaves so I will have 22 Receive commands).
          Then you would no longer have an unknown number of slaves and could have your send/receive routines always know the participants and could skip any unresponsive nodes.

          IF you would have intermittently connected nodes, query each slave during 'non-communication intensive' time - and update your 'participants' table.

          Your 'Participant query' is only significantly impacted if a node does not respond. The timeout can be set to 100mS, so if NO NODES respond, this would equate to 2.2 seconds. If any single node does not respond, you are only out ~100 mS( plus overhead.)


          I played with modbus timeouts in the setup box for port 3 and that made things slightly better but still lots of errors from the receive command after the broadcast command.
          I would tend toward a slightly slower 'multiple send' scenario and away from a problematic 'broadcast/receive' transition.
          This would significantly raise the number of SEND instructions.

          I will get with one of my cohorts. He has a few small networks that he is doing a similar process.

          [EDIT : He is using Ethernet.]
          Last edited by kewakl; 01-05-2018, 04:42 PM.

          Comment

          Working...
          X