Joe Tauser

The default timer, type TD, has contacts that close when it times out and they stay closed until power is removed from the timer or it is reset with an -® coil referenced to the timer's address. I would look at the timed pulse for this application, type TE. This timer closes it's contact immediately for the preset amount of time, and then goes off until power is removed from the timer. If the timer is re-triggered while it is "busy", it will not restart. Set the timer's preset for the amount of time you want to debounce the limit switch input, and trigger the timer with that input. Then use the timer's contact in your program. Look at the Help topic Timers(T) for a good explanation of all the timer types and how they work. Joe T.

Cara- Don't tell me you guys follow the European "we all take a month off in summer" policy. (BTW - to all of you who do this - I am extremely jealous) And that "normal work" thing - can I buy some of that? Joe T.

I've attached a screen shot to this post. It happens when I try to look at "New Forum" or "Snap- in I/Os" in this section. Joe T.

Apparently, I don't have permission to view some of the topics in this forum. I'll ask my mom. Joe T.

This is not an easy request, but the problem has come up with several of my customers multiple times. The typical PLC user is not experienced with communication. We have Modbus function blocks for every type of communication, and they individually work great. The problem I have run into with users is you have to write a quasi-driver to use them. Specifically, you have to write logic to handle the interference between reads and writes, and if you're harvesting data from multiple non-contiguous registers or data types from a single slave the timing logic can get really messy. It gets even more complicated with multiple slaves. I propose a data-type table containing slave ID, register address (the real Modbus one, not the -1 offset we currently use), table length, integer or long data type, Unitronics target address, a polling rate for reads, and an MB to trigger writes. Multiple writes could be triggered by the same MB. The handshaking between all these activities would be transparent to the user. This is how every HMI screen I've ever worked with does it. The user never sees the gymnastics behind the scenes to coordinate the multiple read and write requests. Joe T.

I'm working on a V120->V130 conversion. Somehow, the !Start-Up display got assigned ID 158 and another screen got ID 2. When I power up the PLC, it shows the screen with ID 2. I can not delete this display, nor can I re-assign it's ID. What's under the hood here? Joe T.

Kurt, What model PLC are you using? You're going to want a second serial port to talk to the display. It's really hard to troubleshoot a serial communication application if you can't go online and look at it run while you're trying to talk to your device. The best way to get started is to load the Protocol example file into your PLC and connect another computer to the second port and look at what's happening with Hyperterminal and another Unitronics programming cable. You should see the strings on the screen that you're sending. This will help you get the serial communication parameters set up. Joe T.

So now we have the ability to create our own little areas. I will be most interested to see how this new user power evolves.