waynes

Continuing with Gambit’s comment; are you using Profibus or some other fieldbus for the inputs? Local I/O should be fine, but you would need a DP2 file for Profibus devices as an example. Further to that, you will need to update the autorefresh for the I/O devices to get a cyclic update from the fieldbus.   

The project opens just fine with me. The CPU used is the Q13UDV. Have a look if your version supports this CPU. This project also has a PB92V card at IO 0x0080. I am using GX Works2 version 1.580E.  

Shubham, You should download the manuals for the products you are using and read through it first to get an understanding of how it works. As for the software, I believe that it is bought software and that it cannot be simply provided. All information provided by Gambit thus far is correct.  

Also do not use inputs X1 nor X2.

Unfortunately Mits isn't really good at using function blocks (this is of course in my own experience). You will find that you use much less memory/ steps if writing it in ladders/ steps, instead of FB's. The CPU you have chosen is too small (capacity size) and a larger CPU would be needed.

A long dead time is typical in process plants, but the incoming raw water wouldn't change too much inside a minute. I like the way of adding an offset and applying a weight to the SP, but would it not be easier to use the flow rate as a feed forward factor. In other words, tune it at a flow rate of x. Calculate the delta in flow rate and apply the change to the dosing pumps on the output of the PID, instead of the SP.

You can try Adroit. Pricing is fair and includes a 1 hour runtime demo.    www.adroit.co.za  

Hey Paolo, You are right that two characters (2 bytes) are stored in each D register (word - 16 bits). The remainder of the characters are stored in sequential D registers. Mitsubishi does not have 32 bit registers as far as I know. 

I love these little CPU's for their awesome instructions and the speed at which one can develop; but, when it comes to comms, it is a bit lacking.  We tested this situation with a FX5U and the issue went away. I assume that the bus between the cards is faster in the newer CPU's. It is a pity that you are disappointed with the FX5U; will have to do a few experiments myself first.

The one thing the configurator does do is to re-init the card after you changed the parameters. Try connecting from your VB.NET app and watch the error history inside the configurator. I think it is under the diagnostics button, error history. The error code will tell you what the exact issues is.  I have picked up issues on the FX3U and ENET cards and inspected it with Wireshark. This PLC does tend to make incorrect sequence numbers (in the header) and also re-transmits at times. I think it has to do with the PLC scan time and acyclic nature of the ENET card. Somewhere there is an issue, especially if the PLC has a longer scan time (>50ms) and there are multiple clients connected to it. As an example, I had the local support connect a PLC and GOT (HMI). They immediately saw the same results that I did. Try the FX5U; apparently it sorts most communication issues out. 

Thank you for the replies. We had a look at replacing the FX3U with the FX5U; but there is no stock available... Our time was limited so we decided to use an Omron 1-wire communication instead.  I have come to the conclusion that the Mitsubishi FX3U PLC simply is not designed to operate reliably over wifi or even fixed Ethernet. It is disappointing to see this as I have been a huge Mitsubishi fan for a very long time.

Good day fellow PLC ninjas! I have a question/ concern which I would love your opinions on. We have 3 FX3U PLC’s+ENET cards. Two of the 3 PLC’s move around in an EMS trolley. The other is a ‘base station’ with a GOT2000 connected via Ethernet. Base PLC IP = 192.168.1.11 HMI IP = 192.168.1.31 Carrier 1 IP = 192.168.1.61 Carrier 2 IP = 192.168.1.62 I have programmed the base PLC to use Active communication; we are using fixed buffer communication to send and receive data to/ from the Carriers. The carriers are set up as Fullpassive ‘slaves’. This part works well and the update time changes (using a counter in the base station) from 1s to 100ms (because it enters a different work station).  My issue is the following: using a network sniffer (WireShark), I pick up plenty of re-transmits and sequence number errors coming from the base PLC’s ENET card. This is troublesome and causes delays when the update time is required to be fast (100ms). I am sending and receiving 10 words of data. The wifi seems stable, and there is minimal noise in the area. The power has been turned down and the antennas used are suited well for the application. The antennas are at a similar height to minimize possible loss of signal. I have LOS (line-of-sight) to the carriers at all times; to at least one of the antennas (I am using 802.11n). Has anyone picked up issues or found settings which can be used for comms over wifi? I can easily do this using a S7-1200 Siemens PLC and have done so using 12x S7-1200 clients and 2 AP’s with 1 base PLC. I have also successfully done this using 8xFX3U client with a System Q base PLC. My suspicion is that the delay in reading and writing to/ from the BFM in the ENET card is causing this. I am not sure that if I change to a FX5U will help. The communication cards on the Mitsubishi PLC’s seem very limited. Does anyone have any technical details on the access times between the CPU and communications cards’ BFM? Help is as always, appreciated.

This instruction, together with index registers, makes for very exciting coding possibilities.

All the -/- does is invert the output of the logic preceding it. It is well documented in the PLC programming manuals.

Thank you. Now you could use special relays SM53/SM402/SM403 to create a little program to set the preset value (BFM #0,1 for CH1 and BFM #20,21 for CH2) to the last encoder value before the power failure. The manual contains the detail on how to set the preset encoder value (Chapter 5.4).