PLC_guy_in_Yokohama

Soft-resetting QJ71E71-100 after parameters changes

35 posts in this topic

Normally I would use ModbusTCP (or in worst case RTU). ModbusTCP/RTU can handle ~120words/~1920bits in one single telegram, and as far as I know all major PLC/HMI vendors and OPC/SCADA providers can handle Modbus communication. In the Q-series card (QJ71MT91 for TCP and QJ71MB91 for RTU), setting up the ModbusTCP server (slave) is easy, and in the first place you actually only need to enter the desired IP address, and all the D's, M's, R's are already mapped to corresponding Modbus device addresses. If you want the PLC to poll data from a preipheral device (ModbusTCP client), you can define up to 64 mappings in the configurator against one or multiple peripheral devices. Note that large amounts of data goes slow on RTU (which follows the RS485/RS232 standard with a maximum transfer rate of 115200kbps). Modbus has an open and freely downloadable specification (http://modbus.org/). That is why all major vendors have implemented it. It is easy to implement, can handle pretty large amounts of data (well, nothing compared to CCLinkIE but that's a different story....), and is completely free to implement for anyone. On RTU there's no need for a custom hardwarechip (like Profibus....), hence any standard 232/485 chip can be used. TCP wise it's the same; a normal EthernetIP chip can be used. It's actually an easy protocol to make too, there are even C# classes freely available on the internet if you want to implement your own solution into a custom computer program. A different approach if you only use Mitsubishi equipment and already have an ethernet card is simply to use fixed buffers, but I always find it easier to use Modbus since you don't have to take care of mapping the data. As a last point; the QJ71MT91 can be both a server (slave) and a client (master) at the same time, hence one PLC can both handle incoming requests from other devices and at the same time initiate requests to other equipment.

Share this post


Link to post
Share on other sites
Hello: Yesterday it was a long day at the factory. A colleague found out this piece of advice in a Mitsubishi support site: https://nl3a.mitsubishielectric.com/fa/nl/service/knowledgebase?m_culture=en&category_id=13&sstr=&HTTP_REFERER=https%3A%2F%2Fnl3a.mitsubishielectric.com%2Ffa%2Fnl%2Fcontact&form_name=faq_search 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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sorry for my late response, I've been very busy with a project! Regarding the Ping/KeepAlive I don't understand why Mitsu recommends one over the other. For newer equipment KeepAlive is normally used, but it really doesn't matter performance wise. KeepAlive is just a different stack option than Ping, and it may be that the older cards (A-PLCs) didn't support KeepAlive. Newer equipment may, or may not support KeepAlive, but as long as you have both options you can choose whichever you want. I would also suggest to use the timing settings recommended from Mitsu, then it's easier to get support if you "follow" their recommendations. How is the project going right now? Any progress? What about UDP? What about the C032 error?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Great to hear! But I do have one question for you, if I may ask: What are you going to do with LUA (what is the purpose of making a LUA program/script)?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Nice! Let us know if you run into problems, I'm not a specialist in LUA but all programming is interesting... If possible, please also share trace-decoder if you achieve it.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
On 11/5/2015 at 2:56 AM, PLC_guy_in_Yokohama said:

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.

How can I help? I am interested as well :-)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now