LCD module on T1M00MD-2424+

[Lucas Sturnfield]

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

[bongofury]

Lucas,
I tried to replicate the scenario you described (as I understood it) on F2424 using the Tri 4x20 LCD. I used two special bit clk's,
a 0.5sec and a 1.0sec. I had them fire 2 relays(1 and 2).  Then I used two {dCusF}(1a and 2a).  I then created the 1's and 0's lines as described in the {dCusF}'s.  When clocks of the same value were used, I noticed some instability on the LCD read out.  I then changed clock values.  Still some instability.  Then I introduced the relays, using them to trigger the {dCusF}.  Same result. Then I had relay 1 trigger {dCusF}2a and relay 2 trigger {dCusF}1a.  This stablilized the LCD read out dramatically.  A few things come to mind from this experiment:
1. Clocks of the same value may "fight" each other under certain ladder configurations.
2. The simulator and the PLC behave slightly different.
3. I used the SETLCD 0,0, CHR$(1) to clear the LCD as the first command in my {dCusF}'s.
5. Using too short of clock values affects the LCD readability.
4. The opposing relay trigger puzzles me as to why it works, in this instance.

Support will probably have a much better explanation/solution and there is a good chance  that I didn't fully understand your question, so I hope that I didn't lead you down a dirt road and waste your time.

Dave  

[Lucas Sturnfield]

Support will probably have a much better explanation/solution and there is a good chance  that I didn't fully understand your question, so I hope that I didn't lead you down a dirt road and waste your time.

Dave  

Dave,

Thank you much for the insights. Conflicting clocks definitely can be an issue, especially with the addition of operational interrupts internal to the PLC. My implementation uses mutually exclusive rungs to indicate the type of message to be displayed (user warning, error, user feedback), and then BASIC logic statement to determine the precise message to be sent. As a consequence of this design approach, conflicting clocks are not the nature of this particular issue.

Some further details on what I did implement (and the current solution which seems to work):

The triggered ladder would execute the following code:
setlcd 0,1,chr$(12)
setlcd 1,1,"11111111111111111111"
setlcd 2,1,"00000000000000000000"
setlcd 3,1,"11111111111111111111"
setlcd 4,1,"00000000000000000000"

I then added an BASIC IO check conditional to switch to the alternative message described in the original post.

My current solution. I added "delay 10" statements between each setlcd command. This increases the LCD screen transfer time from ~22ms to ~62ms, and of course ties up the PLC in that custom function. However, the LCD errors seem to have gone away, although tests continue to be run.

Lucas

[Lucas Sturnfield]

My current solution. I added "delay 10" statements between each setlcd command. This increases the LCD screen transfer time from ~22ms to ~62ms, and of course ties up the PLC in that custom function. However, the LCD errors seem to have gone away, although tests continue to be run.

Lucas

For anyone stumbling onto this posting with similar problems, I've sourced my particular trouble to a faulty DMC20481 module. The trouble seems resolved with a replacement module, complete with better performance seen with the new module (line writes occur visibly slower on "faulty" module, with character phasing when new characters are written to screen).

Lucas

[support]

Thank you for informing the readers that it was the DMC20481 issue.  The LCD interface runs much slower than the PLC's processing speed so the PLC has to put a number of delay cycles when writing to the LCD interface. The delay time was tuned to the extent that it should work with most DMC20481, without adding more delay than necessary for the LCD display to work in order to reduce the execution time of SETLCD command.

However, if the particular DMC20481 that you are using is below the threshold it may require more delays in order to work 100% of the time.  That explains why after adding a 10ms delay it seems to work well.