Mark-

MrPLC Member
  • Content count

    299
  • Joined

  • Last visited

Everything posted by Mark-

  1. Mitsubishi FX3u Ethernet options...

    Neverov and Theuns, thank you.  
  2. Understanding 3E frame for FX5U PLC over SLMP

    Ummm the byte count starting at 9 to 21(inclusive) is 13 bytes.... so not sure what you are saying. If the binary read works the binary format is correct. You can download our demo of PeakHMI, use the "Q" Ethernet drive to read/write different areas of memory, use Wireshark to see the data packets. Assuming no difference for FX5, not tested here.  
  3. Understanding 3E frame for FX5U PLC over SLMP

    Hello, Here is a breakdown of 3E to a Q, writing Y12. I "think" it is correct.  
  4. Thanks for the response. All working now. The "open settings" in the "FX Configuraior" had not be configured correctly.
  5. Hello, I have an FX3u-16MR/ES, FX3u-ENET (version 1.0), using GX Works2 Version 1.596W (Trial version). Using FX Configurator-EN (version 1.0), the IP address of the FX3u-ENET is set and I can ping it with success. GX Works2 fails to communicate with the PLC, via Ethernet, and all other software capable of communication with the PLC fails when using Ethernet. I read one PDF about creating a new module under “Special Module...”. The only module listed is “AnyWireASLink”. Perhaps that is a limitation of the trial version. The document had “FX3u-ENET-L”. FX3u-ENET and FX3u-ENET-L seem to be different? Any ideas? Thanks, Mark
  6. Yeah the "keep-alive" at the TCP level and the "watchdog/keep-alive" at the CIP level are different. I guess the first question is why keep a polling/response type connection active/open unless it is used. That was rhetorical. Leave the TCP level to itself and only work at the CIP level because that is what is timing out. Did you retry the "List identity" command?  
  7. I was going to write a bunch of stuff but decided at least one more test was needed. With no other connection to the PLC, issue the register session and forward open. Then doing nothing. How long before the PLC drops the connection?  
  8. Vista support for NS-Runtime

    Are you asking someone to commit a crime?
  9. OK, I asked because the specification is where I find solutions to most returned error codes. Word search (and patience) is your friend.
  10. You are welcome. Do you have the CIP specification to read?
  11. I do not know if that is the issue. I see the result "connection in use or duplicate forward open" and know I code so the connection serial number is unique across all connections.
  12. Are you using a different connection serial number?  
  13. You are welcome. You can use other port number yes. Is the slot (controller) part of the connection path?
  14. Ping from PLC

    And to add not all devices support/reply to "ping" request.
  15. DF1 Protocol For Bit Read

    You are welcome. From the DF1 manual: For higher addresses, setting this byte to FF expands this field to three bytes total. Use the second and third bytes for the expanded file address (low address byte first).
  16. You are correct. Two reads, both using the same CIP sequence count value (1). The controller sees a duplicate read and responds with the same reply as the first message.  
  17. > The problem we are facing is the PLC doesn't send out a response of more than 240 bytes, You are only requesting data for 11 reals. Ask for more tag data and I assume the device will reply with more data, up to the requested specified buffer size, in the large forward open request.
  18. A WireShark capture file, not a screen capture. Not the size request for the forward open. The actual data sizes in the read service request. Repeat the actual WireShark capture file from register session to unregister session. > I guess there is a limitation on the number of Multiple service packet requests? No.  
  19. Post a capture file. Screen shots do not show the data size you are requesting.
  20. DF1 Protocol For Bit Read

    There exist a finite number of reasons a command does not work. 10 02 01 29 0F 00 40 00 AB 02 20 85 FF 00 00 00 01 00 01 00 10 03 26 4B  
  21. DF1 Protocol For Bit Read

    > I'm just trying to understand the variation and how/why commands are changing. I assume you are reading the specifications? Do you have a binary file 32 in the the PLC?
  22. DF1 Protocol For Bit Read

    10 02 01 29 0F 00 40 00 AB 02 03 85 FF 00 00 00 01 00 01 00 10 03 82 CF 10 02 01 29 0F 00 40 00 AB 02 03 85 FF 00 00 00 02 00 02 00 10 03 36 CF The first line is bit 0 and the second is bit 1. The mask clears the other bits of the element.