MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About PLC_guy_in_Yokohama

  • Rank
  • Birthday 04/21/65

Profile Information

  • Gender Male
  • Country Japan

Recent Profile Visitors

1502 profile views
  1. communicate with PLC melsec Q (mitsubishi)

    Hello hieutran8969: First of all, although I have some experience with Melsec, I do not recognise the QJ71EIP71 part number. There is a module which has the QJ71E71-100, which allows a Melsec Q processor to communicate with Ethernet devices. The manual is below. The QJ71E71-100 does not support EtherNet/IP, so writing a Melsec program which could read or write ControlLogix tags is quite an undertaking. I would redcommend that you consider using a gateway such as Softing's echcollect which has built-in support for both Melsec and Rockwell. The echocollect is a Melsec TCP client and a CIP client, and has a configuration tool that allows for programming collect tables which read datablocks from one PLC and writes onto the other, relatively painlessly. You can find more information of this product here: I hope this is helpful.
  2. S7-1500 FW v 2 / Profinet issues non-Siemens devices

    Hello: Has any body encountered Profinet IO cyclic communication establishment problems between the latest S7-1500 PLC with firmware 2.0 or later and non-Siemens Profinet devices which had previously passed conformance testing campaigns? Thanks for your comments.    
  3. Soft-resetting QJ71E71-100 after parameters changes

    As I said before, if I succeed developing a LUA dissector for Mesec TCP, my next step will be to share this with the world.
  4. Soft-resetting QJ71E71-100 after parameters changes

    Oh, it is a personal geekish self-challenge. This is a LUA script for a Wireshark dissector for Melsec TCP. I want to be able to read a Wireshark trace that decodes Melsec TCP frames, just like it is possible for Siemens messaging, Profinet, Ethernet-IP, EtherCAT and so many other protocols. This will be helpful for support of my customers who could analyze their traces and just send me the information without me having to go there. But I am not sure I will succeed. I have never done this before.
  5. Soft-resetting QJ71E71-100 after parameters changes

    Hello kaare_t: Thanks for your note. I hope this project of yours is going well. Things here too have change for the better. The new initialization parameters have apparently solved the C032 error, as they have not reported me the issue. The UDP support on the INAT card is not yet delivered, but it seems it will not be necessary. It seems the customer is satisfied with the solution as they are considering setting up similar systems in other factories. I very much appreciate all your advice. If there is any update on the one issue of this discussion I will post it, for sure. If I succeed with my LUA script for Mlesec TCP I will also post this. And if there is anything I can do to help you (which I doubt as you are orders of magnitude more knowledgeable than me on Melsec technology), I will do my best to try to be of help. Rgds.
  6. Soft-resetting QJ71E71-100 after parameters changes

    Something else we were advised on top of the initial settings shown above is to use, for the operational settings, instead of "ping" it is better to use "Keep Alive". I am translating the report from the Mitsubishi systems engineer. i want to make sure I understand the meaning, but it seems according to my preliminary understanding of this report that the "ping use" is required for older Melsec A PLCs, but that from the Q series onwards, the socket stack was improved and the "Keep Alive" does a better job on the maintenance of TCP connections. I will get back to this but if you have some insight on this issue, such insight may help me understand better the report.
  7. Soft-resetting QJ71E71-100 after parameters changes

    Hello: Yesterday it was a long day at the factory. A colleague found out this piece of advice in a Mitsubishi support site: After I disconnect the RJ45 cable from the QJ71E71-100 it needs ca. 30 sec. until the QJ71E71-100 reacts and closes the own TCP/IP port. I have seen that it is possible to change the "Initial timer settings" in the Ethernet parameter. Do you can recomment (CC-Link) - KS02502"Yes, for standard application we recoment normally this timer values: TCP ULP timer = 8, TCP zero window timer = 4, TCP resend timer = 4, TCP end timer = 6, IP assembly timer = 2, Response monitoring timer = 8, Destination existence confirmation starting interval = 20, Destination existence confirmation interval timer = 4, Destination existence confirmation resend timer = 3." They are using those settings at the moment and I do not know if there are problems. The INAT gateway is refreshing about 80 words in about 700 msec, so it is not a huge load of data.
  8. Wireshark dissector for Melsec TCP

    Hello Mark: Thanks very much for your offering. I will contact you through your website. I will delete this post after I get your e-mail. I am interested in developing like a LUA dissector for Melsec. I am not sure whether I will succeed, but if I do I intend to share it with the world. Rgds.
  9. Soft-resetting QJ71E71-100 after parameters changes

    Hello kaare_t: Thanks very much for this information. i have not got any new reports from the factory of more problems. Will let you know. The E71 card is a new one. This is a new machine. So all the modules have been purchased recently. By the way, I am curious since you have so much experience with Melsec (although maybe if I search in the forum i can get this information), how do you normally communicate Melsec processors with PLCs from other vendors, such as Siemens or Rockwell. In this particular project, the requirement was to exchange like 100 words of data every second or so. The INAT gateway was the only solution that could do this. Other things like using Profibus can handle just barely this amount of data but require a lot of byte-swapping and logic to move data from the memory to the Profibus buffers of both PLCs to and from the actual memory where the data resides, whereas the INAT gateway does not require changes in the PLC programs. This device can read and write data from (in the case of Melsec) the required D area, for instance. I am curious to know how you tackle these kind of requirements. Thanks.
  10. Soft-resetting QJ71E71-100 after parameters changes

    Hello. I have a few updates: 1) I talked to Mitsubishi Technical support about the Wireshark warning "ETHERNET FRAME CHECK SEQUENCE INCORRECT". This error happens only in the ACK handshaking. Mitsubishi says that the Wireshark does not understand the byte stuffing mechanism of Melsec. Melsec sends 64 bytes and needs to add some extra bytes that Wireshark does not understand. This is not causing any problem between INAT and Melsec. it is more of an issue for the end customer and the additional clarification that needs to be done to the customer. if only Mitsubishi could contact and have Wireshark corrected so we do not have this warning. 2) For two nights in a row INAT was communicating with the Melsec without errors. We are not sure what caused the error C032 before. The test keeps running. 3) After convincing the customer to give a try to the UDP setting, we change the settings of the INAT gateway and Melsec to UDB, but the INAT does not send any request to the Melsec. I contacted Softing technical support and they verified the same result. This issue is being investigated, so for the moment the UDP option is not available.
  11. Soft-resetting QJ71E71-100 after parameters changes

    Thank you very much for this information. I am actually going to see the customer shortly, so this is very helpful. I do want to point out that the error C032 was never experienced in the test system, and the difference between the test system is the number of IO cards. The real application has many more than the test system and even in the real application the error will not happen when the SCADA system, which uses a fiber optic backplane module, is not connected. I did the analysis of the Wireshark trace on the other side of the network using a Wireshark dissector and I have found that the other PLC is polling for the same data block up to three times per second, which is pointless because this is shorter than one Melsec logic scan. So I have to suggest that the traffic in the client side (which is the other side of the INAT) be reduced, but still your advice is valid, with regards to the use of UDP on the Melsec side of INAT. I will post how it goes here. Thanks very much.
  12. Soft-resetting QJ71E71-100 after parameters changes

    Hello again: The installation at the customer site is experiencing error C032 about once a day. I am hypothesizing that the reason why the machine builder did not experience this issue when the machine based on other maker PLC was being tested is because in the test system the melsec processor had only the E71 card in the backplane, and thus the only thing the Melsec was doing was basically handling the communication through the E71. The actual system has many other IO cards in addition to E71, including some analogue IO, some fiber optic network for the control level communication between Melsec processors and what I think is happening is that occasionally the Melsec communication between E71 and the INAT gateway does not get enough attention causing some events to be missed and thus error C032. The customer has a program that will clear this error, but is not happy about it. I am trying to convince them to switch to UDP, because from the beginning the application includes some hart beat logic that checks that both PLCs communication is kept working, hence the TCP overhead to verify communication is not really needed. The other option would be to decrease the traffic between the INAT gateway and the Melsec, but this would not ensure that error C032 will be fixed, I am afraid.
  13. Soft-resetting QJ71E71-100 after parameters changes

    Hello. I have a bit of an update with regards to the FCS issue. I tried with another INAT gateway which is a bit different. I found that the Wirehasrk reports the same FCS warning, whether I set the E71 to the standard Ethernet V2.0 setting or the optional IEEE802.3. When you have amde traces of E71 cards communication, do you get them without the FCS warning?
  14. Soft-resetting QJ71E71-100 after parameters changes

    Thanks. I find that the pairing option is useful because it defines the send and receive buffers, so I will try this. Will also try no confirmation. The advice of port number 0xFFFF is extremely useful. I would have not figured this out myself. The test results may take a while, but I will post them when I have them. Rgds.
  15. Soft-resetting QJ71E71-100 after parameters changes

    Hello again: I am working on the UDP settings. I am unsure about the correct open settings for the QJ71E71-100. What would you advice for UDP settings in the case of the: - Fixed buffer communication procedure: Procedure Exist / No procedure - Pairing Open: Enable/disable - Existence confirmation: Confirm / No confirm Thanks.