Internet PLC Forum

For the past 6 years I have been using Tri PLC from T100MD to FMD1616 and F1616. Recently I encountered a safety issue on output channels which should be notified via user manual and/or application notes. I'm quite disappointed, especially when I found this topic on the forum:

"Re:Output State on Power Off"

Here are some details.
PLC: FMD1616, DO#1-8 are connected to one mechanical relay and 7 SSR, which are used to control motors and high pressure valves.
Issue: at one moment, the 24V to PLC is lost, but 24V to relays and SSRs are still connected. Instantly, output #1-8 go to ON status: all the motors start running and high pressure valves start opening, which lead to an quite dangerous situation.

After some debuging, I found it is caused by the ULN2803 flyback diode. By bending Pin 10 out I solve the problem.

This can be a very serious safety issue when someone try to control a motor and high pressure gas. From this forum, I can see that Triangle knew this issue from years ago. I don't understand why this issue is not fixed, and/or at least the user should be notified to pay attention when using these channels.

I tried change the font size, from 14 to 100, no help.

I don't think the screen resolution is too high. Check the picture in my first post, compare the string "Press F1 for context-sensitive Helps" with the comments on both screen, you should see the difference. Especially in Custom Function Editor window, the comment is in "Italy" which makes it worse. If the font/color can be the same "Press F1 ...", it would be ok.

In the custom funtion editor, is there any way to change the font bigger? It uses very strange font and I cannot change it.

BTW, I use the same monitor in windows XP, everything is ok. It is something related to Windows 7.

Did you tested with a Maple HMI, like 5056T or 520T? I have both, and both give the similar problem.

I double checked with a thrid party device to monitor the command HMI sent out. I don't see any problem. However, the PLC somehow will skip some command - no response. I don't think it is caused by the configuration of Maple HMI, I already tried every sigle combination and the problem is still the same. From the oscilloscope, I can tell the command from HMI is right; the PLC just skip.

Could you test with "set relay" command, together with pull registery? To me, the problem always happens when the HMI try to turn ON/OFF relays on PLC. I have a watchdog circuit to monitor the communication between HMI and PLC: the HMI will toggle one relay every 200ms; The PLC use the N.O. and N.C. contact of this relay to drive two timers (with 1500ms set value). I notice that the timer will time out from time to time, may happen about every 10 miniutes.

If you have a Maple HMI, I can send you the test problem I used to debug.

That what I thought.

How about the other questions, 2?

Do you have any information about how to estimate the executing time of a customer function? Yesterday I had some new problem with communication again. In one  scenario I have two more customer functions activated, and the PLC stop response to the HMI again. In these two new customer functions, no EEPROM access, no communication command, just data processing (find max, get average, set relays, etc).

2. I hook up the HMI to PLC via COMM3 RS485 port and get the following results:

(1)Default Setting:   IN PLC, use power-up default setup, i.e. the RS485 will be 38400, 1, 8, 1, auto. DID NOT use any of the following commands: setprotocol, setbaud, setsystem.
The PLC response to HMI command typically 30-60ms. See the following picture.


(2) Use ONLY setbaud command: SetBaud 3,6, which means no change to RS485 port setting. The PLC will response to HMI typically 3-10ms, see the following pictures:




You can see, the PLC response much faster then before, even though I didn't use Setsystem command.

(3)Use Two commands: Setbaud 3,6 and SetSystem 3,1
Suppose the PLC will wait at least 10 ms before response to HMI. However, the PLC response time varies a lot: between 4-20ms. Here is an sample:


Any idea?

Thanks for your reply.

I have no problem with online monitoring, even though sometimes it seems "lost" communication for about 0.5s and then recover by it self.

I tried the OIT sample projects, both on 485 and 232. If I repeat pushing the button, some times the PLC will response slowly - about 1 second no response.

Again, with monitor the communication with ocilloscope, I found these two things. In both case, I'm using RS232 port and HMI is master, PLC is slave; also, I'm using a very simple PLC ladder circuit, basically it turn the outputs (Stack lights) based one the relay status; HMI will toggle the relay on/off and display the output status. No communicaiton command, no EEPROM access.

1. PLC response delay.
     If I use default setting, i.e. do not use setbaud 1,6,   but do use setprotocol 1,1 and setsystem 3,0, the PLC will response the HMI command after 30ms.
     However, if I re-set the baudrate by setbaud 1,6, which suppose no change to the baud rate setting, the PLC will response the HMI in about 3-4 ms.
     I'm thinking this is a bug in PLC OS.

2. Baudrate accuracy.
    I checked the signal again with ocilloscope. The problem is still there: transmitter signal from HMI is 26us bit width, while PLC transmitter signal is 28us bitwidth.
    By monitoring the command/response signal, I can tell that every one or two minutes, the PLC will stop response for one command cycle, i.e. you can see the HMI send command to PLC, but PLC no response. With RS232, most of the time the HMI will pick up the communicaiton in about 1 or 2 command cycle, so you don't notice the lost communication; but in some cases, it will lost communictiaon for more than 2 seconds, which is not allowed for my project.
 
I'm assuming the PLC uses HC12 CPU. I notice the PLC is using 16MHz crystal, which means the MCLK is 8MHz. I highly suspect that in the PLC OS, when setting the baudrate control register, it uses 14 instead of 13, which caused the bit width become 28us. I highly recommand that you ask your engineer to test this.

Next Monday I will double check the signal on RS485 port, to find out the bit width on 485 port.

Thanks for your support.