Show Posts
1
Technical support / LCD module on T1M00MD-2424+
« on: February 14, 2010, 11:53:05 AM »
Hi all,
I'm wondering if there is a way to control the T100MD-2424+'s LCD module, other than using a series of SETLCD commands? Also, how big is the PLC's internal LCD message buffer? I realize that the design objective of the PLC's LCD module probably didn't include this low-level access, but I figure it is worth asking about.
I'm currently debugging an LCD error and would like to be able to control the exact messages sent from the PLC to an Optrex LCD module (DMC20481). The PLC's SETLCD commands are on a ladder with a 0.5 second trigger. My debugging code has 4 20-character lines being sent (all 1's, all 0's, all 1's, all 0's). An external switch is used in the triggered custom function to send an alternate message sequence similar to the previous, except the character "1" lines and character "0" lines are flipped. Measurements of the PLC LCD output lines demonstrate that the full 4-lines are transferred in ~22ms.
Every once and awhile, the LCD display seems to receive configuration messages that result in random effects (display reconfigures to 2-lines, display completely blanks, display shifts line text to the right several places, ect). This occurs most reliably during the transition between the two messages (when I throw that external switch), but errors are also noted during "steady-state" message, albeit far less frequently.
After initial configuration, no further explicit configuration messages are sent via the SETLCD commands, but monitoring the LCD control lines shows that the PLC does send configuration message as part of its SETLCD implementation (presumably to indicate which line each set of characters is to be written). The RS line is measured as triggering between each set of 20 characters, with two E edges seen within that window.
My current debugging narrative describes a buffer being flooded by the back-to-back SETLCD commands specifying 80 characters + line descriptor control bits. My next experiment involves inserting delays between the execution of each SETLCD command, which should alleviate any buffer flooding concerns. However, to find the root cause of exactly why this is occurring only sporadically, I would need to control the exact messages that are being sent. This would allow me to more precisely test which buffer is possibly being flooded (Optrex module, or PLC module).
Lucas
I'm wondering if there is a way to control the T100MD-2424+'s LCD module, other than using a series of SETLCD commands? Also, how big is the PLC's internal LCD message buffer? I realize that the design objective of the PLC's LCD module probably didn't include this low-level access, but I figure it is worth asking about.
I'm currently debugging an LCD error and would like to be able to control the exact messages sent from the PLC to an Optrex LCD module (DMC20481). The PLC's SETLCD commands are on a ladder with a 0.5 second trigger. My debugging code has 4 20-character lines being sent (all 1's, all 0's, all 1's, all 0's). An external switch is used in the triggered custom function to send an alternate message sequence similar to the previous, except the character "1" lines and character "0" lines are flipped. Measurements of the PLC LCD output lines demonstrate that the full 4-lines are transferred in ~22ms.
Every once and awhile, the LCD display seems to receive configuration messages that result in random effects (display reconfigures to 2-lines, display completely blanks, display shifts line text to the right several places, ect). This occurs most reliably during the transition between the two messages (when I throw that external switch), but errors are also noted during "steady-state" message, albeit far less frequently.
After initial configuration, no further explicit configuration messages are sent via the SETLCD commands, but monitoring the LCD control lines shows that the PLC does send configuration message as part of its SETLCD implementation (presumably to indicate which line each set of characters is to be written). The RS line is measured as triggering between each set of 20 characters, with two E edges seen within that window.
My current debugging narrative describes a buffer being flooded by the back-to-back SETLCD commands specifying 80 characters + line descriptor control bits. My next experiment involves inserting delays between the execution of each SETLCD command, which should alleviate any buffer flooding concerns. However, to find the root cause of exactly why this is occurring only sporadically, I would need to control the exact messages that are being sent. This would allow me to more precisely test which buffer is possibly being flooded (Optrex module, or PLC module).
Lucas