IvanBratanov

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.