Internet PLC Forum

I'm using an optical sensor to detect a gizmo on a part elevator.  Depending on the mode of operation (e.g. loading or unloading) the PLC will either be looking for the sensor to turn off or on to decide when to stop the elevator.  The gizmo is a little floppy so it can cause the optical sensor to oscillate between states at the edge of detection.  So clearly a de-bounce circuit is required.  One that de-bounces both transitions.

The attached image is what I'm using and it works but I'm always interested in finding more elegant/efficient ways to do things.  Have I made this more complicated than necessary or is this about the best that can be done?

Edit: By the way, the 2 second setting for the timer is just to make it easier to watch the behavior.  The actual timer is 100ms

I think I've narrowed down the cause of a frustrating issue we've been having with our machine where a motorized axis would complete a move yet our PC-based control software would never detect that the move was complete.  It seems that on occasion STEPMOVEABS will successfully finish a move but the move complete relay never gets set (which is what our PC-based control software is monitoring).  By the way, this isn't related to the issue described here since we are definitely moving.

I narrowed it down to the PLC by capturing the serial communications between the PLC and the PC.  One of the commands in the PC software's update loop is to read a bank of relays (host command RR) which contains the move complete relay and the response clearly shows that the relay is not changing state.

My communications log captured 1255 sent commands that result in STEPMOVEABS, the last one of which failed to set the move complete relay.  That's many more moves/shift than a machine would typically make in a production environment but it's still concerning since I think it's reasonable to expect it to never happen.

Could the fact I'm reading the state of that relay many times a second via the RR command sent via RS232 be interfering with the PLC's ability to set it once a STEPMOVEABS is complete?  That sort of conflict would certainly explain why it seems so random.

BTW, we are using FMD88-10 PLCs.  If there's any other info that might be useful let me know.

I'm looking for some advice on how to accomplish the following in ladder logic:

I have 3 inputs that are being used to command the PLC to move to 1 of 8 predefined positions.  I'm trying to figure out a robust way to respond to those inputs.  Ideally I want to make sure that whatever external system is controlling the inputs has plenty of time to make its changes before I start to move.  For example if the inputs are currently "0,0,0" and the external system is in the process of changing to "0,1,1" I don't want to initiate a move while the inputs are in the intermediate state of "0,0,1".

Currently I just have a 1s timer that checks the state of the inputs but that still leaves the possibility that I check the state while the inputs are in the middle of changing.

The best way, in my opinion, would be for a timer to start when the system sees an input change and the PLC won't initiate the move until the timer expires.  However there are a total of six events that could trigger the timer (3 inputs, either on or off).  I have no idea how to design this using ladder logic.

I'm really impressed by the features included with the new F-series PLCS.  You guys really outdid yourselves.  Ethernet?  Two RS-485 ports?  Direct stepper driving?  Separate ground for I/O banks? (edit: Wow, and ZigBee support)

Unfortunately we no longer make the product that we used to buy TriPLCs for but we would have instantly replaced the MD888+ with the F2424.

We'll definitely keep this in mind for future projects.

Is there by any chance a control code to reverse the "color" of the text on the MD-HMI (i.e. light text, dark background)?

Alternatively, do you have a link to a spec sheet for the display on your MD-HMI?

(I put "failure" in quotes because the PLCs are still working as far as I can tell.)

We fried the resistor located next to the COMM1 port on two T100MD888+ PLCs recently (both part of the same machine).  I had done this once before on a 1616+ PLC and when I emailed Triangle back then about this resistor I got the following response:

The large resistor next to COMM1 reader is a current limiting
resistor that connects the ground voltage of the PLC and that of the
PC (or other devices) being hooked up to COMM1. For some reason your
connection caused a ground fault on the system, meaning that the
PLC's ground could have been connected to a power source non-
isolated from the power supply of the PC. When the devices are
connected the ground potential difference between the PC and the PLC
cause a large current to flow through the resistor and cause it to
burn out. Usually you just need to replace the resistor and check
the power source to ensure some isolation.

In the most recent situation it appears the problem (as far as we can tell) was that someone put a lock washer under the mounting screws and one of them penetrated the solder mask and made contact with a trace.  I believe it is a ground trace -- it's the one nearest to the mounting hole next to U12, on the component side of the board.

So if I'm analyzing this correctly the PLC's ground was tied to the machine's earth through the screw (since our chassis is tied to earth). However, our machine uses power from a 208 outlet while the PC is plugged into a seperate 110 outlet.  So it seems there was a difference in ground potentials between the PC and the machine (a seperate matter we need to address).

Does this make sense?

A customer in Mexico is having trouble with our machine.  Our field technician is measuring 30-32V at the power input for the PLC thanks to the horrible AC provided by the factory (AC line voltage measuring nearly 300V on what's supposed to be 220)!.

Could this amount of excessive DC voltage damage the PLC?

I have a feeling I already know the answer to this but I figured I should ask anyway.  Is there any way to recover a program from a PLC in the event you lose the source code?