HMI com error

[ssutton]

I have a EA1-S6ML panel connected to the serial port on a H2-DM1E PLC. I am using DV-1000CBL to connect the 2 devices. I keep getting a PLC timeout on the HMI. It does not do this all the time, it may run fine for 10-15 minutes or so and work perfectly. Then all the sudden the HMI will seem to freeze and then a timeout error follows. I have tried 2 different cables and HMI's. The HMI's have been configured using C-More micro software version 3.61 and I have updated the firmware on both screens. The PLC has been configured and using Do-More 1.4.3 and the firmware was updated.

The Do-More port:
Do-More Programming
Baud 19200
Parity None
Stop bits 1
Data Bits 8
Transmit control Unconditional
RTS control off

The HMI port:
Automation Direct Do-More Serial
Baud 19200
Parity None
Stop bits 1
Data bits 8
Timeout 40
Poll time 0
memory version 1

I have tried various baud rates. The faster the baud rate the more frequently the error occurs. But even down to 9600 I still and getting errors every few minutes. Any thoughts, AD support suggested updating the firmware which I did a couple of days a ago.

Thanks,
Scott Sutton

[BobO]

I don't know anything about the comm protocol implementation, but 40ms timeout seems way too short for 19200. That's only about 80 character times. It should be plenty for the PLC to turn around, but if the protocol handler is waiting until all expected data is in the buffer before doing anything, 40ms won't be long enough for anything non-trivial.

[ssutton]

The timeout is at its maximum at 40, the software will not allow me to configure it for any longer?

Thanks for the response.

[BobO]

40ms is the longest for serial?!? If that's milliseconds, that seems too short. Need to ask around a bit...

[b_carlton]

The '40' is a multiplier times the base timeout of 100 ms.

[ssutton]

Yes, Carlton is correct I just confirmed it. So it should have plenty of time. Still original issue persist.

Scott

[BobO]

Like I said, I know nothing about the implementation.

Yes, that is plenty of time, in fact, I bet your display "freezes" for 4 seconds. It won't cure the issue, but reducing that to 10 or less, maybe even 6, will greatly reduce the freeze while still providing a reasonable timeout.

Grounding, noise, and cable placement/quality are responsible for 99% of serial comms issues.

[Dean]

Grounding, noise, and cable placement/quality are responsible for 99% of serial comms issues.

Just got a Harvard education on this topic myself. Have essentially the same setup as described. I started getting steady Read errors on the HMI. Guess what, the ground lug on the PLC and the ground wire on a RJ12 RS232 pigtail were connected but not super secure, (certainly not as tight as the day I installed them). Tightened them up, and viola! not a single comm error since. Took about 3 months for them to loosen up enough to start causing problems.

[franji1]

I have had Serial Comm issues that were actually grounding issues in my cushy-office here at Host Engineering.

Hey, I'm a bit-weenie (although I did take Physics III (Electricity and Magnetism) in college as an elective; and I do stay at a Holiday Inn Express whenever I visit Automation Direct ).

[BobO]

Just got a Harvard education on this topic myself. Have essentially the same setup as described. I started getting steady Read errors on the HMI. Guess what, the ground lug on the PLC and the ground wire on a RJ12 RS232 pigtail were connected but not super secure, (certainly not as tight as the day I installed them). Tightened them up, and viola! not a single comm error since. Took about 3 months for them to loosen up enough to start causing problems.

I have an LED light bulb in a lamp in my family room that will honest to goodness completely unscrew itself. Takes weeks, but eventually while walking across the floor or flopping on the couch the lamp will blink, and upon checking the bulb, it has removed itself. Spring terminals are not well loved in automation, but don't suffer from those issues.

[ssutton]

All good thoughts and much appreciated! Now suspecting that this is a noise issue I unplugged the 24VDC power cable on the back of the HMI and let it operate directly in low power mode from the 5 volts on the port. Panel is dim as expected but no more comm errors. Will be scoping the 24 volts to see what is going on. Normally I bond the 24 volt common to earth ground on the machine chassis. Is this advisable? In the past this has solved some noise issues but I guess it all depends on the quality of the earth ground coming to the machine.

Scott

[plcnut]

I would bond the 0V leg of the 24 VDC supply. I would only let it float when there was a specific reason for doing so.

[Controls Guy]

Yes, you should always ground the 24VDC return unless specified otherwise (and even in that case I'd dedicate a separate supply for the equipment that wanted floating and keep the rest properly grounded, plus asking if you could ground through a resistor or something).  Electronics can be damaged by a high common mode voltage on the DC power.