IvanBratanov

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? 

Another company's HMI will be set using their own software, including Arduino but that's quite another story. Regarding Delta's HMI, this is the way you should walk on. You don't need to use other way than the one above to get everything it offers. Delta isn't a well known brand but everyone who is using it states it is a good one.    Anyway if you want to use HEX address mode using other master device you should primarily start using it. Delta's HMI will not help you there. Delta's engineers have created all the devices of the brand to be used together with minimum efforts although other brands are widely supported as well.    As for the PLC communication, those are the settings for Modbus RTU communication. Using generic HEX address communication must be determined by the settings of the master device which we already know is not Delta.

The HMI settings should be like that if you want to connect to DVP-SS2: In the "Extra" window you should choose RTU, because it is ASCII by default. Using other variants to connect Delta HMI to Delta DVP (perhaps) will not work. You even don't need to. All the capabilities of both devices could be achieved by the link shown above. If you're using other master device then things will be quite different of cource but here it should be just like that. Connecting Delta HMI and Delta PLC is the most easiest thing you can imagine regardless of the interface or the protocol. You didn't say which model HMI is that. If it's COM ports are located on a single D-SUB connector, there are different modes. Post here the model of the HMI so I could see it's datasheet.   Why do you need HEX address mode?

Yes, true. I'm unable to attach pics as well. That's why I uploaded my photos on external server and posted links to the pics here. Perhaps site admins should see what's wrong. It will be good to post photos here so others could see them. I'll send a message to the staff so they could see what's the problem......

You have to set both devices (PLC and HMI) under same settings so they are able to communicate each other, only addresses should be different (0 for HMI and 1 for PLC). It works, proven by me many times. My last project consists of DVP28SS211R and DOP-107BV which communicate thru RS-485, 8N2, 38400, RTU. It works fine and fast. You have to check the pins as well (D+ to D+ and D- to D-). It's not possible to use PLClink connection between PLC and HMI, it's usable when have PLC-PLC, PLC-VFD, PLC-servo.   You better show me some pics of the devices used.

You may take a look at the communication wizard window in WPLsoft: As you can see, settings contain baudrate, communication format, triggering condition (to be executed once at first scan by M1002), the station address (it should be 1 for slave) and hold communication settings of the channel (M1120) so you can use it untill the PLC is running. After completing the settings WPLsoft creates a small ladder program automatically at the beginning. This is how it should look in your case (COM2, RTU mode, 9600, 8 E 1, station address 1):    

It seems hard for me to give an answer about ISPsoft. I've never used it but things there are quite different than in WPLsoft (which I'm using from the very beginning). Perhaps HWCONFIG app should contain what do you need. There should be some page with the COM ports settings. COMMGR is for program upload/download COM port configuration only.   If you're using Delta HMI, DOPsoft will set HMI as master anyway (address 0), so it will be the master device by default. So the only thing you have to do will be to set the PLC address 1.    

First of all, which software do you use? ISP or WPL? I'm using WPLsoft and there's a connection wizard which configures any port as you wish. All you have to do is tell him the baudrate and the communication format. What kind of master device do you intend to use?

I think this is rather a sequencer than a PLC. I think it activates outputs in sequence which is different than the PLC basic principles. You may replace this device and even some of those connected outside to it (timers for example) with an ordinary PLC. To do that first thing is to find out how does it work. I was unable to find any user manual. I don't know if it's in working condition or not. If operable you could measure the output signals and draw a time chart.     

I have only been working with Delta for 15 years. In my practice there were few moments when other brands were necessary to be used in a single projets but they were  extremely rare. I've never had such situation where differemt brands were necessary to be used in same project and were not compatible. At least there is something that is unifying different brands' products and those are the standards, but anyway every manufacturer uses production tricks so the user would buy only his products.     There are other ways to control a servo amplifier - analog inputs, RS-485. If using of high speed pulse trains is not applicable here you may use other way to do it.

Time to look both PLC's outputs thru a scope if you doubt that as a reason. You don't have to buy one but аsk sоmе friend to serve you with his one.     As you can see those are only lolgical conclusions by me. I couldn't suggest something else based on what has been said so far.  

No, I don't. My expirience with Inovance is very poor, but the only thing I'm sure about is that Inovance is uding the same positioning instructions as Delta. So if there's some incompatibilty between them there's nothing else I could offer you. I do have a scope although it's rarely used. By the way the shape of the pulses couldn't be any other than rectangular because the output transistors of the PLC could have only 2 states - open snd closed. Without any other circuitry is not possible to make another shape of the output signal (if there isn't any noise involved of cource!). Something else you can do is to check the settings of the servo. For example Delta DVP has special register for multiplication of the input pulses' frequency. Check if Inovance servo  has something as well. Check also if the problem occurs only at high frequency pulses transmission - you may check at very slow speed just to see if the problem is not because of high speed transmission phenomena.

If you suspect problems with signal (shape or whatever else) then you have to check the signals characteristics of both PLCs by dual channel oscilloscope. The positioning instructions used by both brands are the same. 

I'm operating with Delta PLCs and Delta Servo drives only. I've never had experience (and troubles) with Inovance servo. All instructions bothering high speed pulse trains in DVP work perfect when combined with Delta servo. Why do you have to get your life harder with Inivance? Just use Delta on both ends and everything should be fine......

Hi, it's not clear what are you trying to do. First you say Modbus RTU, then you're showing screenshots of Modbus ASCII. It's not clear what is this My end device. Is this a VFD? If yes, what kind of brand and model? What kind of software you're using - WPLsoft or ISPsoft?    I didn't get almost anything, perhaps others too..... Please clarify what are you trying to do so we can help you.

Hi and good day to you! I'm creating industrial projects based on Delta Industrial Automation equipment. Projects work very good, no complains yet. Recently clients asked me if there is a possibility to connect a PC viewer somehow (VNC or something) to a HMI<->PLC RS-485 connection so they could monitor and control the HMI from the PC. I've done projects based on Ethernet PLC and HMI (Modbus TCP/IP), there is not problem to connect VNC to such network using a switch or a router. The problem is when devices don't have Ethernet interface. Is there any possibility to connect PC to such interface, using RS-485<->Ethernet adapters perhaps.....?    Thank you!