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 - support

Pages: 1 ... 203 204 [205] 206 207 208
3061
Technical support / Re: EEPROM Program Memory
« on: November 24, 2003, 01:43:56 PM »
The T100MD+ PLC uses EEPROM that can endure rewrite of 100,000 cycles. This is nearly impossible to exhaust for the program memory under normal circumtances.

If you make use of the PLC's EEPROM data memory in your program, then just make sure that you do not have a rung that write to the EEPROM continuously every scan of the ladder as that will wear out the eeprom.

The EEPROM is replaceable if it is "worn out".

3062
Technical support / Re: RTC
« on: November 24, 2003, 01:48:54 PM »
You can use the TRiLOGI "Set PLC Real Time Clock" function under the "Controller" pull down menu to set the real time clock.

Once the real time clock is set to the value you defined, then you can use Online monitoring and click the "View Variable" to look at the new value of the RTC. It must work.

When you said "nothing happen" I think you are probably refering to what you display on the LCD? If your program does not refresh the LCD display regularly then the display will not show the new value even after you have set the new RTC data.

3063
Technical support / Re: MD2424 ADC conversion unstable
« on: November 26, 2003, 05:08:32 PM »
The ADC input on the PLC can be affected by digital noise in the digital section of the PLC. This include the switching noise in the power supply and the digital noise in the microprocessor circuit.
 
You may want to use a low noise linear power supply to reduce the noise that could affect the reading.

The ADC input built-in to the microprocessor can vary about +/- 3 LSB. Which means for 0-5V range, the variation is about:

5000*3/1024 = +/-15mV.

So it is not uncommon that the reading will jump around a median value. Such variation are quite typical of ADC circuit that are built into microprocessor.

The external analog module such as the I-7017 has its own isolated DC-DC converter in order to give very stable reading (16-bit resolution). This also partly explain its higher cost ($230) compared to the  built-in ADC on the PLC.


3064
Technical support / Re: Choosing ideal input Signals
« on: November 29, 2003, 11:41:45 PM »
The easiest type of sensor to use it one that output 0-5V which can be connected directly to the PLC's analog input. Of course you need to ensure that if the sensor has its own power supply then the sensor's ground must be common with that of the PLC's 0V.

If your sensor output 4-20mA, you can convert the current into 1 to 5V voltage using a 250 Ohm resistor (read your installation guide for the wiring method). Both 2-wire and 4 wires types can be used.

3065
Technical support / Re: PLC comm problem/ PLC Inoperative
« on: December 01, 2003, 07:58:29 PM »
If the PLC seems to be working properly and you are able to perform online monitoring, yet unable to transfer new program to the PLC, then you type in the following command at the serial command prompt in the TLServer:
 
@01$cKILL00*
 
(notice small letter "c" and capital "KILL")
 
That would delete the corrupted program and password which must have been there because of the corruption.  You will need to re-transfer your program to the PLC because the original program in your PLC will be deleted.

3066
Technical support / Re: PLC comm problem/ PLC Inoperative
« on: November 30, 2003, 12:00:16 AM »
Will, I am a little confused. You mentioned that you tried the reset instruction described in this post to no avail. Yet you mentioned that when you went to the site later you found that the PLC is running properly. Does it mean that initially you tried the instruction remotely? How were you able to turn ON DIP Switch and perform the reset if you were not at the site?

If your PLC gets back to running properly after a overnight shutdown without your manual intervention or transfering the program to the PLC, then it is likely that it RAM copies of the PLC CPU has been corrupted by the electrical noise in the system but the EEPROM copy is still intact. So after a power down and reset, the PLC runs the program properly again.

Protecting the supply to the PLC is important. Power to the microprocessor electronics is like life blood to human being. The PLC I/O circuit already filtered most of the noise coming from the  I/O but the power supply noise goes directly to CPU.  

Diesel/gas power generator are pretty noisy fellow. However, most power surge filter on the market are for AC circuit. You may want to try to search for a DC power filter to improve the reliability of your system.

3067
Technical support / Re: PLC comm problem/ PLC Inoperative
« on: November 28, 2003, 01:02:50 AM »
Your program seems to have been corrupted and that may be the reason why it doesn't work. Please follow instruction in your installation guide on the use of DIP switch #4 to reset the PLC program. The following are the steps:

1) Turn ON DIP switch #4.
2) Reset PLC by turning OFF power and then ON again
3) Open "Serial Communcation Setup" in TLServer and change the baud rate to 9600. Then type in the command "IR*". You should get a "IR01*" in return.
4) Now, transfer a blank program into the PLC to clear out the corrupted EEPROM.
5) Turn OFF DIP Switch #4
6) Reset PLC as in 2)
7) Change the baud rate to 38400.
8) Now the PLC should be workable as per normal.



3068
Technical support / Re: Transfer protected by password
« on: December 02, 2003, 06:19:46 PM »
Can you try to transfer one of those simple sample program to the PLC and then power OFF and then ON the PLC again. Check if the PLC goes into PAUSE mode again. We want to be certain if it is due to your application program or there is some hardware problem in the EEPROM.

If the PLC pauses after reboot even with the simple demo program, then most likely the EEPROM chip may have suffered some damage during the power outage. You should email us at support@tri-plc.com providing us your full contact address and we can make arrangement for replacement of the PLC or the EEPROM chip.

3069
Technical support / Re: Transfer protected by password
« on: December 01, 2003, 10:01:01 AM »
Glad to learn that the issue has been resolved.

There is a watch dog timer to reset the PLC if the CPU goes hay-wire. In your case, the EEPROM corruption may not be due to a spurious write by the CPU, but an electrical transient via the power supply that may have directly erased the EEPROM.

You can use the "Change PLC ID" button in the TLServer to easily change the ID to any number from 00 to FF.


3070
Technical support / Re: Transfer protected by password
« on: December 01, 2003, 07:53:27 AM »
Indeed your EEPROM seems to have been corrupted. Can you type in the following command at the serial command prompt:

@01$cKILL00*

(notice small letter "c" and capital "KILL")

That would delete the corrupted program and password which must have been there because of the corruption.

3071
Technical support / Re: Transfer protected by password
« on: November 28, 2003, 12:53:52 AM »
Is this the first time you attempt to transfer program to the PLC using this computer? Have you previously successfully transferred a program to this PLC?

The "Transfer password" is a legacy feature in the DOS TRiLOGI software but is not enabled in TL5. So if you have never used the DOS TRiLOGI to enable the password then it is unlikely that you should receive a prompt for a transfer password unless your EEPROM has been corrupted or your COM port is not working properly.

Open the "Serial Communication Setup" in the TLServer and type in the following command:

IR*

What do you get in return? The correct response should be "IR01*"  (or other ID if you ever change that). If your response box returned "IR*" then you serial port is not a "real" serial port. What will happen is whatever you type will be echo back to you (try typing your own name). If this is the case, try to use another available COM port. Sometime Windows may report a COM port to TLServer that it cannot use for some reason. So change your com port selection to another working comm port number and re-try.


3072
Technical support / Re: crc+modbus
« on: December 04, 2003, 08:42:22 AM »
What PLC model are you using? Only the M-series PLC support the MODBUS protocol directly using the READMODBUS or WRITEMODBUS commands.  You can also implement other modbus functions using the TBASIC CRC16 function. Check the following threads for more details:

http://www.tri-plc.com/cgi-local/yabb/YaBB.pl?board=FAQ;action=display;num=1058204850


3073
Technical support / Re: NTC sensor
« on: December 05, 2003, 05:50:18 PM »
You mean Negative Temperature Coefficient? You need to built a circuit such that the resistance can be converted into voltage reading and connect that to the PLC's analog input. Then you can compute the actual temperature using either a formula or a lookup table.

3074
Technical support / Re: How to send an ASCII break from Com port?
« on: December 05, 2003, 06:04:00 PM »
Unfortunately the command set does not support the RS232 break signal that you mentioned. You will probably need to use a relay to switch out the RS232 transmit line and connect it to a +5V or higher when you want to send that 100ms "break" signal.

3075
Technical support / Re: How to send an ASCII break from Com port?
« on: December 04, 2003, 08:45:25 AM »
What is the ASCII code for the "ASCII Break" that you mentioned? You can use the OUTCOMM command to send any binary data from 0 to 255. However, it is assumed that the data are transmitted using the NRZ format of 1 start bit, 8 data bit, 1 stop bit and no parity.

Pages: 1 ... 203 204 [205] 206 207 208