EZ-Touch HMI questions

[rpoet]

All,
I know that AutomationDirect no longer sells the EZ-Touch line of HMIs, but I have a few questions concerning a surplus AutomationDirect EZ-S8C-F I picked up.

-I am planning on connecting the HMI to a DL-06 and three GS1 drives (and possibly more later) through RS485 (two-wire). I'd like to use a DB15-m to RJ11 adapter on the HMI and a HD15-m to RJ11 adapter on port 2 of the PLC to connect to the GS1's with the 10-port RJ11 distro block, part # ZL-CDM-RJ12X10. I'd like them all on one network so I can take advantage of the higher coms speed on port 2 of the PLC. Everything will be in one cabinet, and cable lengths will be short. Assuming I use MODBUS coms, does anyone see any problems with this setup? Can the HMI and the drives coexist on one network with the PLC?

-Where can I buy raw 6 cond. cable, similar to the cable used to build AD's RJ11 cables? It's a cinch to make my own RJ11 cables, but I'd like not to use the flat telephone-style cable, as it's hard to work with if crossover cables are needed.

I have need to display the degrees of rotation of a turntable. HMI will be receiving the value from an absolute encoder, and I'd like to use something line a circular analog graph, but I can't find a way to display a full circle. At this point, I'm thinking of drawing a static circle, and using visibility bits to display dots every 30 degrees around the circle, and display the exact degree reading in a box in the center of the circle. Not my favorite idea, but that's it so far. Any other ideas?

I double-posted this thread to AD's tech support site, in hopes of reaching a larger audience.


Thanks for the help,

rpoet

 

[rpoet]

All,
After more research, the only potential issue I may have is that I believe the EZ-Touch screens must be the MODBUS master. Will this cause issues with me attempting to write to the drives from the PLC? If this ends up being an issue, what might the fine folks here suggest?


Thanks,

rpoet

 

[bernie_carlton]

If you wish to connect a number of items using MODBUS the indeed one must be acting as the MODBUS master. Though the EZTouch could connect to the programming port of the PLC with the second port reserved as a MODBUS port with the PLC as master reading from and writing to the drives. The machines we make use this arrangement most of the time, though we are using Allen Bradley Powerflex 4 drives the concept is the same.

I could see your wish for RS485 if the display is to be a considerable distance from the PLC though AD sells an RS232 to RS422/RS485 convertor which would allow you the distance you need (if my assumption is correct) and still leave the second port free.

 

[Steve Bailey]

There can only be one master device on a Modbus network. Use Port2 for communications between the PLC and the drives. Use Port1 for the HMI. If you're careful about managing the PLC addresses that the tags in the HMI use, the 9600 baud limitation on Port1 won't hurt too badly.

 

[geniusintraining]

I can help with the cable.... send me an email to [email protected]

I am sure that Steve and Bernie are correct but you can also check here for more info on the EZTouch screen http://www.ezautomation.net/forum/

I just bought a screen myself, I have not had time to hook it up to anything (or get the software)

 

[rpoet]

GIT,
Thanks for the help with the cable. There's an email coming your way.

Steve,
As far as I've been able to find, there's no way to force the EZ-Touch to be a MODBUS slave. Am I right? (I suppose that having the HMI be a slave might be a problem in terms of getting info to and from it).

Bernie,
Distance will not be a problem, so using RS232 from HMI to PLC will be fine. While I understand why AD fixes the PORT 1 coms settings (you're is always able to get into the PLC, even if you goon the PORT 2 settings), it gets rather annoying when this type of application comes up. Too bad there isn't a way to get PORT 1 to communicate at a higher baud rate.

How badly will 9600 baud affect the lag on the touchscreen? There will be 30-ish discrete tags, and 6 single-word memory addresses.

I know ethernet would solve all these problems, but for this project, I can't justify a module that costs as much as the PLC

Thanks for your help, gents.

rpoet

 

[rpoet]

Gents,
Another question:
In the interest of not having to swap cables every time I need to test new programming, can I program the PLC via PORT 2 with RS485 2-wire? that port will be connected to three GS1 drives as well, as I mentioned earlier. I'd assume that if I get the baud rates to match (in this case, I'll be using 19.2K-baud to talk to the GS1 drives) I can program as well.

I realize I'll need to use a USB to RS485 converter, but I happen to have one laying around.

Thanks for helping me not spend my $$$ and time the wrong ways.



Sincerely,

rpoet

 

[Steve Bailey]

I'm not aware of any HMI that can be configured as a slave for any serial communications protocol. It's because of the way HMIs typically manage their communications. They only request the data required to update the screen being displayed and any overhead data required by the application. Overhead data would include things like alarms and PLC control registers. Since the HMI needs to be able to issue an alarm alert regardless of which page is displayed, it has to update any alarm tags as often as possible. The same is true of PLC control registers. In order for the PLC to tell the HMI to display a specific page, the HMI must read the "page display" register as often as possible.

That leads into how you can optimize communications. There is a limit to how many registers the HMI can read from the PLC at one time. If the HMI has to read data in PLC registers V123 and V124, it can ask the PLC for four bytes of data starting at V123. If, instead it needs data from V123 and V1234, that's going to require two transactions, one to get two bytes of data starting at V123, the second to get two bytes of data starting at V1234. In addition, if you need data from discrete bits in C memory, that will be another transaction. If you manage your PLC memory so that everything the HMI needs to read from the PLC is in contiguous blocks of memory, you'll achieve the best possible update rate.

The sequence of events that happens when the HMI requests data from the PLC is as follows:
1. HMI assembles data request
2. HMI transmits request to PLC
3. PLC validates message checksum and decodes request
4. PLC fetches data
5. PLC assembles response to HMI
6. PLC transmits response to HMI.
7. HMI validates response checksum and decodes response.
8. HMI passes received data to tags.

The baud rate only affects steps 2 and 6. If you can update the HMI with only a single data request, you probably won't be able to detect any difference between 9600 baud and 19200 baud.

 

[rpoet]

Steve,
Thanks for the quick reply. That's a great explanation; I'm going to file that one away for future reference and teaching. I will make sure to use contiguous blocks of registers for speed.

All,
Any feelings on whether I can program the PLC with RS485 2-wire on PORT 2?


Thanks,

rpoet

 

[Steve Bailey]

In the interest of not having to swap cables every time I need to test new programming, can I program the PLC via PORT 2 with RS485 2-wire?

I don't think so. There's a note in the catalog that says "RS485 is for Modbus RTU only". You can't program the PLC using Modbus RTU protocol. For programming, the port has to be set up for K-sequence protocol. What I don't know is if there is a way to use the ladder logic to switch the port setting between RTU and K-sequence. Maybe Bernie knows for sure.

 

[bernie_carlton]

This is only a guess but I don't think it's the protocols as much as RS485 has receive and transmit on the same wires but at separate times with time delays. The K Sequence AFAIK doesn't have the 'turn around' stuff built into it. The switching of protocols (and other parameters for that matter) which can be done from ladder won't overcome the lack of the ability to handle the R/T sharing.

If you have a free slot an ECOM module works wonders.

 

[rpoet]

Gents,
Thanks for all the advice. Looks like I'm stuck with programming via PORT 1 with RS232. Not really a bad thing; I was just hoping to avoid swapping cables.

Thanks again.

-rpoet

 

[Steve Bailey]

Warning! Unsubstantiated speculation!

I'm wondering if rpoet could make up a special cable, running the RS485 wires from the PLC to the drives and the RS232 wires from the PLC to the PC running DirectSoft. When you switch programmatically between protocols you also switch from RS485 to RS232. Presumably the PLC will ignore any signals from the RS232 lines when it is using RS485 and vice versa.

Of course, when you're using K-sequence/RS232 you're not simultaneously communicating with the drives over RTU/RS485, so I don't know if you've gained much over swapping cables. You could have have DirectSoft (Port2) and HMI (Port1) communicating simultaneously or DirectSoft (Port1) and Modbus RTU (Port2) simultaneously, but never all three simultaneously.

 

[David_Emmerich]

Why not use Ethernet...just put in 5 port switch and it should all talk nicely...JMO

David