#3 Incorrect address in response to write coil

open-later
Conrad Braam
None
9
2009-11-05
2009-11-04
Sensei TG
No

Sending a message containing:

06 7D 00 00 00 06 01 05 00 01 FF 00
Transaction: 0x067D
Protocol: 0x0000
Length: 0x0006
Unit ID: 0x01
Function: 0x05
Address: 0x0001
Data 0xFF00

Returns the response:

06 7D 00 00 00 06 01 05 00 00 FF 00
Address: 0x0000 (when it should be 0x0001 according to protocol)
Others: Identical, good

Discussion

  • Conrad Braam
    Conrad Braam
    2009-11-04

    Hi, I will have to re-test for this, I'm not sure why this happens, I just verified a bug in the RTU protocol implementation that looked similar, and this feature has not changed in ages.

    I'm also a bit new to using this tracker, so give me a moment to get this defect assigned.

     
  • Conrad Braam
    Conrad Braam
    2009-11-04

    • status: open --> open-accepted
     
  • Conrad Braam
    Conrad Braam
    2009-11-04

    OK, I've assigned the bug to myself now. (status should change to open)

     
  • Conrad Braam
    Conrad Braam
    2009-11-04

    • assigned_to: nobody --> zaphodikus
    • status: open-accepted --> open-later
     
  • Conrad Braam
    Conrad Braam
    2009-11-04

    Cannot reproduce - I would do 1 more thing though:
    Check that your master is using an incrementing transaction number inside the ethernet frame, if not, then you may have a out of sync response. If it is using an incrementing Transaction number field, I need to know more about how you produce this problem.

    What version simulator are you using?

     
  • Conrad Braam
    Conrad Braam
    2009-11-04

    • status: open-later --> open-rejected
     
  • Sensei TG
    Sensei TG
    2009-11-05

    Yes, it does have an incrementing transaction number and the responses were not out of sync. I went through the network traffic log manually to locate the error after noticing that our master rejected the answer. I also compared your tool with others, as well as real slave devices. Yours was the only one that responded in this manner using this master implementation.

     
  • Conrad Braam
    Conrad Braam
    2009-11-05

    Thanks for the bug logging, as you notice I'm new to this bug logging system, so this is a learning thing for me too. (I am not impressed with the system, but it's free.)

    OK, it does look like a bug (I assume you are using Wireshark or other sniffer) I will need time to get some master simulation code running again (I no longer do this kind of thing) - Thank you for your patience. I'm changing this bug state and will probably get some work done on it this weekend.

     
  • Conrad Braam
    Conrad Braam
    2009-11-05

    • status: open-rejected --> open-later
     
  • Sensei TG
    Sensei TG
    2009-11-05

    No worries, I'm new to this system as well

    Yep, I'm using WireShark to monitor traffic. I'm just reporting the bugs out of courtesy - most people just drop the issue and move on to other software without letting the author know that there might be a problem. I hate that :)

    Since yesterday I'm debugging my master towards another (commercial) simulator and a couple of physical slaves - but yours is the only (good) freeware one I've seen and freeware is where my heart is... so just drop a line if you need more information or testing done - I'd love to help in any way I can.

     
  • Conrad Braam
    Conrad Braam
    2009-11-05

    Thank you.

    I wrote this program about 10 years ago, and stopped maintaining it when I got a new job outside of SCADA/HMI 4 years ago. I hope we can resolve this bug at least, because that forces the guys with commercial products to stay honest. I mainly program embedded these days, and have gotten rusty on most of the PLC stuff.

    I'll update the bug once I have a proper test-bed going on this one or find something else that will help us solve it.

     
  • Conrad Braam
    Conrad Braam
    2009-11-05

    • priority: 5 --> 9