IvanBratanov

You deffinitely need Delta USBACAB230 cable. It is a USB-to-RS232 converter and will fit to the COM1 port of the PLC (the mini-DIN8 round port on the front panel of the PLC).

upload the isp file here so we can see the PLC program you created.

https://www.deltronic.ru/content/files/AS300_PM_EN_20161122.pdf https://cms.esi.info/Media/documents/78160_1459437169235.pdf   Everything is described there. For the PLC see chapter 9.

Before creating the calculations he has to set the inputs of the PLC for the right mode - 4-20mA, current mode. Next he should choose that the register of the A/D input being selected shows the current value only instead of an average by default. Next he has to convert the input A/D value to L/s. This is called a conversion ratio. For example if the full scale range of the input A/D value is 0-2000 for 4-20mA and the flow range of the flow meter is 0-100 L/s it means that the conversion ratio is 20. Without it it will be impossible to calculate the flow in L/s. And only now can he start writing the program. The program should create a 1-second virtual gate. The 1-second time is the sampling frequency. It may be shorter or longer but the accuracy of the measurement will depend on that - lower sampling frquency, larger error. On every pulse of the gate an internal register should take the current value of the flow meter. It should be converted to L/s and added to the intermediate sum. On each program scan the sum should be compared to the desired value and if it is equal or more, the process ends.   And that's just a rough description. Doing this in real is more than specific. As you can see its not so easy to recreate that in a program. It will be the most easiest thing for me to write the program instead of the author of the topic but thats not the point. Thats why I asked him if he has some expirience with the A/D programming and with the ladder programming at all. As I said its not an easy task at all and without any basic knowledge it will not be achievable.

If so then how familiar are you with the ladder programming? Do you have any expirience with the Delta PLCs? Because if you are a newbye in this area it will be very difficult for you to create a program. If you haven't had any previous expirience with the analog A/D and D/A then you should first start study it and when you are known enough then start creating programs. This is not an easy task.   I'm creating industrial projects with Delta IA products more than 20 years already and even for me there are sometimes minor difficulties.     Take a look at this video:   https://www.youtube.com/watch?v=LeiNCEBpceY

So 20SX2 series has analog input channels which support input voltage and input current modes. You can find the connections of the inputs in the user manuals. Anyway I don't believe that the level of water in a tank should be measured by a flow meter. I think that a level meter should be used. Flow meter is used when a rate of water delivery is measured, not water level. If you're using flow meter anyway to get the water level you should take a lot of things in mind - the initial level of the water, the moment and the average values of the meter diring the intake process, the time, the values of the flow (how many mA are equal to how many liters/s). In this variant there's a high percentage of miscalculation of the level due to the listed circumstances.  Using a level meter instead of flow meter will provide correct results in real time measurements because it's values are reffered directly to the water level itself without the need to make intermediate calculations in order to get the level from the flow.   Is it necessary to use flow meter? Could you use level meter instead?

What kind of Delta PLC do you intend to use?

You should use Windows XP (for example with Oracle Virtual Box). I found and downloaded Secreen Editor 1.05.86, but it's driver does not work on platforms different than WIN XP. The app is very old and its hard to use it with modern OS. 1.05.86 works with DOP-A series (tested on DOP-A57GSTD).

Perhaps you should first clarify a lot of things - what type is the PLC, what type is the scanner, what type of intarface and protocol do you intend to use.... such things. None of us here is a diviner and giving an answer without info is a hard thing.....

Like in the last post I checked back, this time whether you've mentioned what kind of machine do you use this servo in? You haven't do that. Giving more details about the problem in the early beginning of the conversation will clarify a lot of things and the people answering will spare themselves a lot of suggestions and speculations.   Of cource if the machine is a CNC router for example or something with frequent and precise postioning such protocols will not help a lot - if RS-485 and PLC link were good enough no one would ever try to develop such things as CANopen or EtherCAT. My applications are far not so complicated as that, so it helps me in my cases.    PLC link is a method of continuous sharing of registers of master and slaves in real time. Data to be read from the slaves is copied in real time to a group of special registers of the Master PLC and the data to be written in other group is copied to the slaves as well. Using of PLC link avoids using of single MODRD and MODWR instructions which require opening and completing data reading or writting thru the channel by flags. Of cource as I mentioned above the complexity of the machine you're using the servos in should determine the interface and the protocol used to operate them. 

I can't remember the exact length of the line but it is no longer than 1m - PLC and servo driver are in the same cabinet, it just does not need more. Anyway I don't use such command method in my projects anymore - VFDs and servos are connected in the same Delta PLC link network and all the commands can be given by a simple twisted pair line. So high frequency side effects are in the past. I would recommend you to do the same.   "the issue in my application has largely been caused by the length of cable from PLC to drive, which in my Delts DVP applications has all been quite long."   I checked back the topic from the very beginning, but never noted you to say something about the line's length untill now. Seems that the problem here is similar to the one with the length of the line between a VFD and AC motor. 

I've never used such extra diodes in my projects and they still run perfectly. My last servo-containing project was DVP-EH3+ASD-A2. No diodes of any kind were attached to the outputs and it still works like it should. Not only ES3, but every Delta PLC manual recommends such additional diodes when it is about frequent on/off. Perhaps such problems appear when certain conditions are met at the same time, I'm not sure.

Reading and writting I/O points of PLC from HMI is a basic elementary feature, one of the most easiest things you can do, it should not make troubles if both devices are OK and properly connected.  As I mentioned above, reading inputs registers will work if screen objects are properly set - for example input X5's screen object (the lamp in your case) should be multistate type object and should read condition of register X5 of the PLC via the RS-485 link. TP04 series is alphanumerical screen model, I would use DOP-107BV graphic screen model. I've used it already in my projects many times, it's cheap and reliable basic HMI and has more features and is more comfortable. I think it will be more suitable for education purposes. You could write here if you have future difficulties....    

So if there was a problem with the RS-485 link between the PLC and the HMI, none of the I/O points could be readen or written. If only few inputs are unable to be readen, the problem should be in the screen objects representing the inputs (the lamps). If inputs X0-X1 are readable and X2-X7 are not, perhaps you should compare the properties of the lamps reading the status of X2-X7 with those reading X0-X1. If it still does not work, try the following: You may also try to change the data format. I'm creating projects based on Delta IA equipment and I'm always using Modbus RTU 8N2 data format (you used Even parity check instead). You may also try higher baudrate. Be sure that both device have same settings (except station address of cource:)). Try 8-bit mode as well (add SET M1161 instruction to the initial rows of the PLC program).   I don't believe that the problem is in the PLC but try to check if X2-X7 are OK (LEDs of X2-X7 should lit when they are activated). You may also create a test PLC program like the one attached here. Y0 output will be ON when some of the X2-X7 are ON. If the Y0 LED lits when activating X2-X7 inputs, PLC is OK.

If you are able to connect panel to the PLC then the link is OK. I didn't get what are you trying to do - activating outputs and reading inputs of the PLC from the panel?