PLC_guy_in_Yokohama

Soft-resetting QJ71E71-100 after parameters changes

35 posts in this topic

Hello: New to this forum and not so new but not so good either with Melsec. I have succeded connecting the Melsec Q through QJ71E71-100 to a non-Mitsubishi Melsec client. During the testing it became clear after quite some pain that after changing parameters such as fixed buffer parameters for data exchange, the PLC requires a power cycle, because the reset of the PLC does not change the paramters of QJ71E71-100. Hence, I am trying to figure out one program do do this task. I may have not been so diligent and this information may already be available at som Mitsubishi resource. I can read Japanese, in case this is only available in Japanese. Useful advice will be thouroughly appreciated.

Share this post


Link to post
Share on other sites
Hi, I'm not sure if this works, but have you tried BFM#1F / b15 = 1 (then wait for it to get 0 again)? This is supposed to re-initialize the Eth module, but I've never tried it before myself. You could try this. However, I must ask: You say that you need to reset the module after changing fixed buffer parameters, but which parameters are you changing? It's not supposed to need a reset after changing buffer memories, so which parameters/buffer memories are you changing when you need a power cycle? You say that a CPU reset does not work. What do you mean? A remote reset of the CPU does the same as power-cycling the CPU Why do you need to re-initialize the module during runtime?Please test the BFM explained above, and if possible please also answer my questions above. I have never had this problem before since I download the E71 parameters together with the rest of the CPU parameters the "first time", then I never need a power cycle again since I don't change the PLC parameters or the E71 parameters.
1 person likes this

Share this post


Link to post
Share on other sites
Hello Propeller Head: I am so very grateful for your concern and for having responded to this inquiry. I just feel my decision to join this group was so good. You are right, my description was not too complete. I was not sure I would a reply like yours. But you have motivated to further the discussion. I hope it is useful for both of us and other forum members. What you sugest actually what I have thought to do as it is documented in the technical documentation (sh080009r) that bit BFM#1F / b15 = 1 is user settable and the system resets it. I was kind of looking for confirmation from someone. Hence thanks. I will test and let you know. it has been a while since I have worked with Mitsubishi and I am struggling to come with a rule to determine the starting offset for the memory buffer of a QJ71E71-100 which is not on the first slot of the backplane. It has to be documented somewhere, but for the other modules I only know the number of bits in the X/Y IO port, but not the amount of buffer memory that the GX Developer reserves. Advice on this is also appreciate. OK, now onto your questions: 1) Which parameters: We are using a non-Mitsubishi Melsec client, a gateway that can transfer data to other PLCs to develop some machine-to-machine communication in certain application. You are right the parameters for the fixed buffers need not to change, as long as you know what the right parameters are. Enter me and my colleagues, and since we do not know what the right paramters are we need to tweak. For example, we are using "Unpassive" buffers for which one has to indicate the TCP port. lets say the Melsec client was configured with a different TCP port so you eityher change the client or change the port for the buffer within QJ71E71-100. This is of course only needed for the development and commissioning stages. But for us it was painful in front of the end user, trying to get the thing to work, writing the GX program and nothing worked until someone accidentally powered the PLC off and when it was powered on again everything worked, and despair and sadness turned into elation and bliss. 2) If you reset the CPU, I tell you my experience. Let's say the original program had the first buffer configured to port 5000h but you realize you needed 4000h instead. You change the parameter in the opening settings, check click OK and write the program to the PLC. You start the diagnostics and you see this port is still 5000h, of course. Then reset the CPU without powering off. When the CPU is back and you call the diagnostics, you will see the port is still 5000h, instead of the required 4000h. I am absolutely sure about this. me and my colleages saw this many times. But if you cycle power, then when the diagnostics comes online you see 4000h, as needed in this example. 3) Why, as I explained before, due to the settings for the communication. Of course we do not expect this will be needed in normal operation. But since this gateway is a client of the Melsec, it is plausible that someone will want to retrofit this in a running factory, so again, during commissioning this may be needed. This is very unusual but we would not want to reset a processor running a factory if retroffting this gateway to get data for another PLC from another vendor. One more thing after this very long post of mine. We have discovered something very important. The so-called initial settings for a fixed buffer have some default values in the GX Developer which were very helpful to raise the blood pressure of several engineers for many hours, including mine. You see, in this application the QJ71E71-100 is a server, all the communication is initiated by the Melsec client, in this case this gateway. The parameters and their defaults are: 3.1) "Destination existence conformation starting interval": Default is 1200. This multiplied by 500 msec or ten minutes. 3.2) "Destination existence conformation interval timer". Default is 20. This multiplied by 500 msec is one second. 3.3) "Destination existence conformation resend". Default is 3 times. What happens is if the RJ45 cable is disconnected or there is a power down of the Melsec client (in our case this gateway, but it could be a SCADA or something) then if you check the diagnostics of the unpassively configured buffers, the ports that the QJ71E71-100 remain unchanged. Then in this condition you reconnect the melsec client and there is not communication. We did some wireshark traces and I am not so sure of the meaning. In some cases the QJ71E71-100 is responding to different TCP ports and of course the client does not get communication. And also the Ethernet diagnostics was showing TCP ports different than what Wireshark was reading. Our conclusion as that the QJ71E71-100 was not releasing resources because it was not noticing or, it was taking too much time to realize that the client connection had failed. Two of my colleagues had an insight and we changed the above parameters to very small values, like 1, 1 and 1. With this setting (after powering off the processor, by the way), when the RJ45 cable of the gateway or the PLC is disconnected, the diagnostic shows the TCP ports that the QJ71E71-100 granted to the gateway go from some value to zero in about 5 seconds. And then when reconnecting the RJ45 cable, everything works!! E V E R Y T H I G W O R K S ! ! !I need to further study the Mitsubishi documentation, because somewhere this must have been documented. And I need to reassure my customer these values are OK, in spite of being so different from the defaults. it looks like these are the defaults that were required in other times, whend Ethernet was starting to go into the shopfloor. I cannot imgine a situation in which it is necessary to wait 30 minutes to realize that there was a connection failure. Anyways, thanks for the help so far, and if you managed to get down here, thanks again for your concern and effort.

Share this post


Link to post
Share on other sites
Thanks for the detailed explanation of your system and challenges! Let's get to the cases: 1. BFM#1F/b15 - Remember to also set the correct values in the other bits (like you set up in GX Developer when configuring the module) 2. Regarding X/Y IO's - I'm not sure I understand exactly what you mean, but to explain a little: -X/Y IO's are starting points of the modules (not the BFM's). In GX Developer, under IO Settings you can actually specify which start IO you want for each module. The easiest place to visually see it is to assign the start IO's manually. -The HeadAddress is the start IO (used for TO/FROM instructions, or direct addressing in MOV instructions) minus the "last zero" -The BFM are the same even if the start IO is different. The only thing that the start IO affects is where the X/Y's are placed. E.g. if the start IO is 20 (hence HeadAddress=2), the TO/FROM will need "2" in the "HeadAddress of module", while the IO's will have addresses ranging from X20-X3F (in an E71 module) 4. Reset CPU - Yes, if you put the CPU from "RUN->STOP->RUN", nothing will get re-initialized, but if you hold the switch in "Reset" for a couple of seconds it will reset like a power cycle. However, I do understand your issues with this. Please try to re-initialize the module using the BFM above and let us know what happens (as I said, I'm not completely sure if this works, but let's try) - but do remember to also set the other parameters in BFM#1F correctly according to your application. When it comes to the timers in the E71, I must say that you should test this a lot. Setting timers that low might cause problems if you for example run the communication via a router, or several switches, or communicate the SCADA and PLC on different VLAN's (note: NOT Wlan) in a more complex IT environment. I have also experienced what you are talking about, but most often the E71 detects the communication loss almost at once (at least quick enough). So in essence I would test the default values a lot first, try to close/open your connection manually if your GX Developer application detects a cable loss (are you using a custom Eth protocol, or are you using the MC protocol in the E71)? If you have wireshark traces, it would be interesting to see what happens in the scenario you are describing (disconnected-reconnected eth cable). Could you, if you still have problems, upload the trace file (.zip it first) in the forum? To summarize: Try the BFM#1F and let us know what happens. If it doesn't work we'll have to look more into it. Regarding the timers, as mentioned please explain what kind of protocol you are running. If still problems, upload wireshark trace.

Share this post


Link to post
Share on other sites
Again, thanks a lot. I feel I cannot say thanks enough, and I do not want to sond too effusive, but I am so very grateful you are doing this. Thanks to you I am a little bit less ignorant of Melsec communication. So the BFM is a buffer memory that is associated with the start of the XY memory. I thought there ware kind of independent, like the IO port and shared memory in the ISA bus specification, that is why I was wondering how they are related. Now I understand from you that for each starting offset of a Melsec module there is a BFM, starting from zero each time. This is very helpful indeed. I think it helps in this forum for newbies like me who want to learn to be candid and not ashamed of looking like the newby I am, so you can expect further revelations of my ignorance in the comming lines. Your advice will be very appreciated. I can see why resetting the BFM#1F/b15 does not work. The documentation does have the complete program to restart the QJ71E71-100. Many years ago I amanged to program a Melsec A for communication with a different Melsec client. This is way too complex for my application, and this customer is hundreds of kilometers from me. That would be perhaps the last option to try for me. The network architecture is very simple in this case. the PLC network in this factory is based on Melsec fiber optic network. The QJ71E71-100 is connected directly with one cable to the QJ71E71-100. So we have no routing issues to be worried about (I hope) if we change the timeout settings. And the protocol being uses is Melsec TCP. By the way, do you know if there is any Melsec TCP dissector (such as a LUA program)? I once asked the mitsubishi tech support here for a wireshark dissector, but I was told there is none. It would be so much more helpful to understand the actual Melsec. I see all the messaging as TCP packets. I am uploading the traces. The file comms-echo&melsec_after-melsecpower(short).pcapng is the normal communication case, after the PLC was restarted. This is before we changed the timeout paramters. In this file, lets say frame 21, the client device (192.16.8.3.200) destination port is 20482, and frame 34 the Melsec which is 192.168.1.1 is responding from this 20482 port to the correct destination. On the other hand, as the file no-comms-echo&melsec(short).pcapng shows, lets say fram 7 the client is sending from port 5080 to port 20480, but the Melsec is responding to the correct ports but there is actually no communication at this time, and in my wireshark there is an indication of "Ethernet farme check sequence incorrect". Not sure what this means. Again, thanks a lot and have a good evening. (I am not sure how to upload data. i will post this while I figure out, as I do not want to loose this explanation. I will updload the data with the traces shorlty...)

Share this post


Link to post
Share on other sites
Hello again. I figured this one out. the traces are attached herewith. Rgds.Melsec_issues_traces.zip

Share this post


Link to post
Share on other sites
I'm not exactly sure why you experience the FCS, but try setting the frames to IEEE802.3 just for testing. I'm also a bit "in the dark" here, but we'll have to try something. I've never experienced that long recovery times. Also: Could you upload your project?? If not, can you remove all the code, and just upload the project parameters (remove all your programming code, but post the rest)? EDIT: Here's a picture of the frame settings. Edited by kaare_t

Share this post


Link to post
Share on other sites
Hello: I do not have this Melsec project because this is the customer's 8end-user) project. I am sorry that I forgot to take that one screnshot. I have to ask my customer (the machine builder7s representative) if he remembers which setting it was that the customer is using. I would imagine the customer would use the default settings, but let me double-check. This may take a while. When we monitor the Ethernet diagnostics, shortly after disconnecting the RJ45 cable the port allocated to the Melsec partner (the gateway) changes from whatever it is the allocated port to zero. After the port changes to zero and the RJ45 cable is reconnected, the communication is reestablished. With the default settings of 1200 x 500 msec with three retries, the allocated port does not change to zero, and the communication is not reestablished. Do you think it would make sense to ask mitsubishi tech support about the FCS problem? I did not succeed posting an image file. i get the error that I am not allowed to use the extension for the image file in this forum. I tried JPG and PNG. not sure how to add images such as you did in the above post.

Share this post


Link to post
Share on other sites
Hi, First, are you using the Mitsubishi MC protocol, or do you have a custom protocol of any kind?? This is very important to know, I have assumed that you are using MC protocol. What equpment is "on the other side" of the PLC? For the image, just .zip it and upload the .zip file. I'll download it and open it locally.

Share this post


Link to post
Share on other sites
hello: I am using a gateway called echochange from Softing (formerly INAT as shown in the Wireshark traces). This device is a Melsec TCP client. I am not sure about the differences between MC protocol. I would assume Melsec TCP is a subset of the MC protocol. unfortunately, the Wireshark does not decode Melsec TCP because there are no dissectors available that I am aware of. I created a separate topic in the forum asking for Melsec dissectors for Wireshark, but so far no response. Thanks.

Share this post


Link to post
Share on other sites
OK, we really need the pictures of all the parameters for the Ethernet module (including port settings etc.). Preferably a project example, or an empty project with just the PLC/Ethernet parameters.

Share this post


Link to post
Share on other sites
hello: This project is very close to what is working in the factory, at least from an Ethernet communication point of view. Rgds.Melsec_TCP_problem_System.zip

Share this post


Link to post
Share on other sites
Set Existance Confirmation to KeepAlive (if version number in module is 05051 or higher) - see picture I would recommend to modify the timing values a little, see picture. Be careful to set too low values, and always take care that "starting interval timer" is greater than "interval timer". Do the remote unit support UDP protocol? If so I would strongly recommend it. That way you don't have to worry about lingering ports (like you experience when you cannot connect to the module after failure) and you'll have a better efficiency in your network (less overhead in UDP)I would, as mentioned, check if the unit supports Melsec UDP protocol. The Melsec protocol has a built-in CRC so there's actually no need for the additional overhead that TCP produces... If possible just modify the parameters in the E71 module to suit the remote unit. Let us know how it works out...

Share this post


Link to post
Share on other sites
Thanks very much indeed for all this advice. Yes, the remote gateway does have support for UDP, although we have not yet tested. My customer is working on a simulation system for this and I will have him test all this and of course, I will inform you our results, because it is the very least I can do after providing me all this advice. I really hope this experience can be of benefit for you and other forum readers. I am unable to paste thumbnails directly onto the message as you do, hence I attach the file of the remote gateway's configration software.

Share this post


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

Share this post


Link to post
Share on other sites
Hi, Try UDP. I'm mostly using the UDE/UDV CPU these days with the built-in eth port, so I'm not sure if I remember at once. I'm pretty sure the following will work. Where the red line is (IP address), insert the address for the remote gateway. Transmission target port no = FFFF (this means that it will accept any source port from your gateway).

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Hi, I'm just making some points below regarding your last post: C032: No, it has nothing to do with the number of IO modules on the backplane. The C032 is an error that is handled locally inside the E71 card. So even if the Q-Bus was running low (which it does not!), it has no impact on this error code. Basically this error indicates that something is wrong between the two ethernet devices, and has nothing to do with the communication between the E71 and the Q-CPU. C032 is a problem with the remote device not responding to a TCP mechanism - "ACK" - which is a small handshake. This is actually pretty critical since "ACK" is one of the simplest ways of checking connectivity in TCP. UDP: You can safely switch to UDP! First of all, it already implements CRC's and retries etc. Second you would in either case (TCP or UDP) need to have heartbeat in your real program to ensure that everything is OK in the program sequence. In this case, as long as you are running Melsec protocol, it is a waste of bandwith to use TCP. INAT traffic: Actually it could be that the INAT device doesn't handle the high load of the ethernetwork. I have never experienced the E71 to go into error because of high traffic loads, however I have seen other products from different vendors that don't handle high traffic loads. So basically I really doubt that the E71 doesn't handle high-load traffic, but I would be more doubtful regarding the INAT device (without saying it's their fault of course). You could decrease the traffic a little bit, but this will be done from the INAT. Something like "Resend interval" or "Request interval" or something like that should indicate how often after a succesful reception the device should ask for new data again. But note that other systems often just request new data as soon as their previous request has been received.I've been thinking about this a bit, and when I think about it I've never actually used TCP for the Melsec protocol since it is essentially pointless. That is probably why I've never experienced this problem before. However I've worked a lot with TCP and UDP (and Mitsu systems), hence I understand your challenge! That said, I've done a little research on your timers in the parameter pages, and they now look fine (as I sent them to you in the screenshot). I really don't know why Mitsu ships the modules/software with that insane deafult settings. Again, get the customer to use UDP. If the customer wants to complain, ask directly for any reason why they want to use TCP instead of UDP. There is absolutely no reason at all to use TCP in this application and/or environment.

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Hi, I wasn't aware of this, but that was very good information!! C032 still has nothing to do with the load of the internal Q-bus. C032 simply reflects a TCP mechanism and still is between the INAT and E71 card ("on-the-wire") That was very sad, and strange news. TCP or UDP has nothing to do with the Melsec protocol so they obovoiusly have a big problem with the ethernet chip in their unit(s). Melsec is, as you might know, simply the application layer of the stack, so TCP or UDP really don't affect the Melsec protocol itself...One question; how old is the E71 card? Is it a brand new one, or is it an old one that has been laying in an office for years?? Alternatively what is the serial number of the device? The reason I'm asking is that many years ago, Mitsu actually had a problem with one series of the E71 cards.

Share this post


Link to post
Share on other sites
Hi again, I suddenly remembered that you modified the TCP ULP Timer in the parameters for the E71 card. The problem with C032 could be that this timer is too low. If the problem persists, try to set it one value higher than what it is now.

Share this post


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

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