Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - DW_Microsys

Pages: 1 2 [3]
Technical support / Safety issue: output is ON when PLC power OFF
« on: January 18, 2012, 09:19:29 AM »
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.

Technical support / Re:Font size is too small, hard to read
« on: October 17, 2011, 11:35:02 AM »
I un-installed Java 1.4.2_19 and it come back normal. Looks like this version of JVM doesn't work with windows 7.

However, when I tried to upload program to PLC, I had one success out of 3 (350words of program).

My windows 7 has Jave 6 update 27 installed.

Please do some more investigation about running TriLogi on windows 7 and reply.

Technical support / Re:Font size is too small, hard to read
« on: October 17, 2011, 09:11:46 AM »
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.

Technical support / Font size is too small, hard to read
« on: October 14, 2011, 02:06:18 PM »
1. Main window:
Font size is small. The comment is difficult to read.
Tried to change the font file of comment in "en_language.txt" to "arial". It helps a little, but still not good.

2. Custom Function window
The font is too small, hard to read. Especially the comment, it is virtually unable to read.
Tried to change the font, no success.

Please refer to attached picture - it is 100% crop from screen.

Basic information:
OS: windows 7, x64
Trilogi: 6.4.3
Display: 24" LCD, 1920x1080

Technical support / Re:Baud Rate not accurate
« on: June 01, 2009, 07:10:20 AM »
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.

Technical support / Re:Baud Rate not accurate
« on: May 29, 2009, 01:51:00 PM »
Maybe you have a newer version of firmware? I checked question 2 with 3 PLCs and got the same result. All my PLCs have same version of firmware: T100MD+r50.


Technical support / Re:Baud Rate not accurate
« on: May 28, 2009, 07:46:22 AM »
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).

Technical support / Re:Baud Rate not accurate
« on: May 22, 2009, 02:53:56 PM »
One last thing.

If I use SetSystem 3,0, then the PLC will lost communication all the time, both on RS232 port and RS485 port.

If I use Setsystem 3,1, then I notice a lot of improvement on both ports, but still got a few times communication lost.

Eventually, I fixed the RS485 ports to "No Protocol", I got good communication virtually all the time.

Here are the commands in my PLC, lastest version:

Setbaud 3,6
setbaud 1,6

Setprotocol 3,10
setprotocol 1,1

setsystem 3,1


Technical support / Re:Baud Rate not accurate
« on: May 22, 2009, 02:46:09 PM »
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?

Technical support / Re:Baud Rate not accurate
« on: May 22, 2009, 02:12:12 PM »
Thank you for your quick reply. I managed to did some more test yesterday, here are the summary.

1. The bit width: you are right, I tested in the way you described in your post, the bit width is 26us. It was the data pack width confused me. Baud rate 38400, 1 start, 8 data, 1 stop, HMI gives the following data pack (260us width)

While PLC gives the data pack of 284us:

Looks like the PLC gives 2 stop bits instead of one.

Technical support / Re:Baud Rate not accurate
« on: May 16, 2009, 05:35:48 PM »
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.

Technical support / Baud Rate not accurate
« on: May 15, 2009, 01:47:23 PM »
I'm using T100MD16x16 with Maple 5056T HMI. I was using RS485 and encountered big problem with lost communication - it happened every 2-3 minutes. Then I switched to RS232 and it works much better, but I still get communication error from time to time, though it can pick up within 1 second.

I tried:
1. Fix the protocol to MODIBUS RTU
2. Set response time to ASAP.
3. Re-Set baud rate - this helps a lot for the response time. Suppose the port baud rate is 38400 by default. The PLC will response to HMI in about 30ms delay. After I re-set baud rate to 38400 in custom fuction, the response time reduces to 4ms!!!!!! Strange! I believe this is a software bug.

I also notice the baud rate on PLC side is not accurate. With an oscilloscope I found the bit width from HMI is about 26us, which is correct; however, the signal from PLC side is about 28us width, which is too far away from what it should be.

Thanks in advance for your help.

Pages: 1 2 [3]