Parallax 4x20 serial lcd & pause commands

sailgene

Member
Hello. I've had great success with the Parallax LCD when connected directly with a Picaxe 18m2. But when using RS-485 comms over a 150 foot line, the LCD will work fine as long as I don't place a Pause command any longer than 2 seconds (Pause 2000) between Serout commands. I've tried the Calibfreq command (various numbers from negative to positive) and changing Baud rates. I'm using T9600 _8 right now. Has anyone encountered this problem? Again, works fine with pauses of 2 seconds or less, but freezes up with 3 seconds or more.
 

inglewoodpete

Senior Member
You've guessed it: we need more information. A circuit diagram will help, as well as a cut-down piece of code that exhibits the problem.

Things that I would be checking:
  • Which PICAXE pin are you using? The SerialOut pin has other purposes (program download, SerOut) and its state could become changed.
  • Does that problem happen on short lines with the two RS485 converters connected back-to-back?
  • The default speed of the M2 chips is 4MHz - does your code issue a SetFreq command to set the speed to 8MHz, since your are using T9600_8 parameter?
  • Describe "freezes". Does the LCD and/or the PICAXE need rebooting to get things going again (either or both)?
I would not be playing with the CalibFreq command unless you are getting character errors when things are communicating.
 

hippy

Technical Support
Staff member
As Inglewoodpete suggests, if it is displaying data correctly with pauses of less than two seconds then there is no need to use CALIBFREQ; the problem occurs when there is a lack of transmission, not with the transmission.

It could be that there is some timeout in the display module ( or even a bug ) which causes the display to switch to a different state if data is not received frequently enough. Do you have a link to the datasheet of the display you are using ?

Or perhaps your RS-485 interface has some timeout issue. It will help if you provide details of exactly what your hardware is and a circuit diagram.
 

sailgene

Member
Continuing Problem

Thanks for your suggestions. Yes, I'm not using calibfreq (although I've given it a try), I'm going with T9600_8 (Setfreq M8) and yes, once the LCD freezes, it needs to reboot to give it another try. I'm attaching some sample code. Could not figure out how to add a diagram to this message.

INIT:
PAUSE 1000 'ALLOW SPLASH SCREEN TO CLEAR
DISCONNECT
SETFREQ M8

PAUSE 10
HIGH C.3 'HIGH TO START ACTION
PAUSE 10
SEROUT C.3, T9600_8, (22) 'CLEAR SCREEN, CURSOR AND TURN ON BACKLIGHT
PAUSE 75 'ALLOW MINIMUM 5MS AFTER CLEAR SCREEN COMMAND
SEROUT C.3, T9600_8, (12)
PAUSE 75
SEROUT C.3, T9600_8, (17) 'TURN ON BACKLIGHT
PAUSE 75
SEROUT C.3, T9600_8, ("SENSORS")
SEROUT C.3, T9600_8, (" ON")
SEROUT C.3, T9600_8, (" LINE")
PAUSE 1000

MAIN:
FOR B1 = 1 TO 25 'START COUNTER
SEROUT C.3, T9600_8, (12,22)
PAUSE 75
SEROUT C.3, T9600_8, ("BATTERY = ")
PAUSE 75
SEROUT C.3, T9600_8, ( #B1)
PAUSE 75
SEROUT C.3, T9600_8, (13) 'CARRIAGE RETURN
PAUSE 5
SEROUT C.3, T9600_8, ("HOW")
SEROUT C.3, T9600_8, (" DO")
SEROUT C.3, T9600_8, (" YOU")
SEROUT C.3, T9600_8, (" DO")
PAUSE 2000
NEXT B1
END
 

hippy

Technical Support
Staff member
With a Txxx polarity your HIGH C.3 should be the first line of your program after "INIT:". You might need to add a pull-up to prevent issues when the pin is floating.

If you need the PAUSE 75 after the initialising SEROUT C.3, T9600_8, (22) and SEROUT C.3, T9600_8, (12), you may need those after your SEROUT C.3, T9600_8, (12,22), and you might need to separate that into two commands.

A link to the datasheet will help people check that you are complying with what the commands need and what they do.

What does the screen show when it freezes ?
 

sailgene

Member
The datasheet says to allow 1/2 second before sending any data to the LCD. This is why I'm delaying the HIGH C.3 command. I've tried separating the commands for "clear screen" and "clear cursor" but to no avail. PS: If I just send text without asking the Picaxe to perform any other tasks, it seems to work. But if I have the Picaxe check a sensor before sending the text, this seems to cause the problem. It's like once the LCD begins waiting for data, it is not happy if there's any delay in the next incoming data. When the screen freezes, it typically leaves the last text message with a backslash ("/") at the end. Here is a link to the data sheet: https://www.parallax.com/sites/default/files/downloads/27979-Parallax-Serial-LCDs-Product-Guide-v3.1.pdf
 

sailgene

Member
PS: When I say the text input works fine, I should add that if I loop the data to repeat over and over again, it freezes up after one or two loops. Also, just tried going HIGH C.3 right after INIT but no improvement.
 

hippy

Technical Support
Staff member
The datasheet says to allow 1/2 second before sending any data to the LCD. This is why I'm delaying the HIGH C.3 command.
You should still put it first. That initialises the signal line to the correct polirity, it doesn't communicate with the LCD module.

If I just send text without asking the Picaxe to perform any other tasks, it seems to work. But if I have the Picaxe check a sensor before sending the text, this seems to cause the problem.
I think you will have to clarify exactly does and does not work as the goal posts seem to have just moved.
 

sailgene

Member
Okay, so I moved the HIGH C.3 to the top, no help. Sending text messages works fine - to a point. If I loop to repeat sending the same messages again (over and over), it hangs up after about 2 runs. Up to that point, it sends the messages clearly.

It just seems that any sort of idle time (picaxe doing anything else - counting, sensor reading or even looping) jams up the signal to the lcd. This was my latest attempt at a simple loop command:

INIT:
HIGH C.3 'HIGH TO START ACTION??
PAUSE B2
DISCONNECT
SETFREQ M8
B2 = 5

SEROUT C.3, T9600_8, (12,17,22) 'CLEAR SCREEN, CURSOR AND TURN ON BACKLIGHT
PAUSE B2

MAIN:
DO
SEROUT C.3, T9600_8, (12)
PAUSE B2
SEROUT C.3, T9600_8, ("SENSORS")
SEROUT C.3, T9600_8, (" ON")
SEROUT C.3, T9600_8, (" LINE")
PAUSE 1000
SEROUT C.3, T9600_8, (13)
PAUSE B2
SEROUT C.3, T9600_8, ("HOW")
SEROUT C.3, T9600_8, (" DO")
SEROUT C.3, T9600_8, (" YOU")
SEROUT C.3, T9600_8, (" DO")
PAUSE 1000
SEROUT C.3, T9600_8, (13)
PAUSE B2
SEROUT C.3, T9600_8, ("SENSORS")
SEROUT C.3, T9600_8, (" ON")
SEROUT C.3, T9600_8, (" LINE")
PAUSE 1000
LOOP

The LCD screen writes "SENSORS ON LINE", "HOW TO YOU DO" AND THEN "SENSORS ON LINE". It will repeat this up to 3 times before quitting. Can you think of anything that might be going on inside the Picaxe to kill the output signal?
 

westaust55

Moderator
No guarantees this will work but it won’t do any harm:

On the RS-485 bus, add two 100 kOhm resistors (resistors in the range 56 kOhm to 100 kOhm May be used)
One from Data-A to ground/common
Second from Data-B to the supply voltage (ie 12 Vdc)
 

hippy

Technical Support
Staff member
In your code in post #9 you do not have a 500ms pause after power-up, and your B2=5, PAUSE B2 will not be giving 5ms pauses at 8MHz.

What happens if you run the following code -

Code:
INIT:
  HIGH C.3
  SETFREQ M8
  PAUSE 2000

  SEROUT C.3, T9600_8, (12) : Pause 100
  SEROUT C.3, T9600_8, (17) : Pause 100
  SEROUT C.3, T9600_8, (22) : Pause 100

MAIN:
  DO
    SEROUT C.3, T9600_8, ( #w0, " " )
    PAUSE 2000
    w0 = w0 + 1
  LOOP
 

hippy

Technical Support
Staff member
Pin C.3 is of course Download Serial Out on an 18M2. It is not recommended to connect an LCD to the Download Serial Out as during download the LCD will receive random data at a different baud rate than it is expecting which can cause the LCD to do things which are not expected.

Try driving the LCD from a different pin.
 

hippy

Technical Support
Staff member
Also, from your posts in another forum -

However, it still works great when tied directly to the Picaxe chip.
I've run a "counter" program with the variable showing as it incremented from 1 to 25. It would typically stop around 3 or 4 but then jump to 12 or more as if it stopped reading the incoming data and then restarted reading it.
That suggests to me it's nothing to do with the PICAXE, little to do with your program or the LCD display; everything to do with the RS485 interfacing and 150 foot line.
 

sailgene

Member
Thanks Westnaut. I'll give it a try. On another front, I was advised to turn the LCD display off and then back on between serout commands and it seemed to improve the reliability. However, the LCD still seems to crash after about 15 seconds (vs. 2 seconds before!). So some improvement. I'll get back after adding the resistors to see what happens. Thanks again.
 

sailgene

Member
Well, I've tried adding 100k ohm resistors to the RS 485 bus to no avail. I do think that there's nothing wrong with the picaxe other than maybe trying another serout pin just to see what happens (I'd already built the PCB but oh well). So question: Is there any likelihood that using an AXE LCD will be more successful using this RS 485 protocol? If so, I'll open my wallet and purchase one. Thanks again. Gene
 

inglewoodpete

Senior Member
So question: Is there any likelihood that using an AXE LCD will be more successful using this RS 485 protocol? If so, I'll open my wallet and purchase one. Thanks again. Gene
I would cautiously say "yes". My reasoning being that, I'm assuming we don't know how the software in the Sparkfun LCD's serial-to-parallel backpack is configured. The Rev-Ed LCD's back-pack uses a PICAXE chip (18M2) and the code is published on the website and can be charged and downloaded by the user if required.

Before you rush out the buy a Rev-Ed serial LCD, what happens if you replace the Sparkfun serial LCD with a PC-Based terminal program like the PE6 terminal? Does the data come through clean?
 

PhilHornby

Senior Member
Well, I've tried adding 100k ohm resistors to the RS 485 bus to no avail.... So question: Is there any likelihood that using an AXE LCD will be more successful using this RS 485 protocol
What devices/circuitry is being used to interface the Picaxe & the Parallax display to the RS485 bus?

Whatever this is, what's the electrical state at the Parallax end, when no data is being transmitted? ... maybe it just 'floats', in which case something like a 4K7 resistor to GND might help. A 'scope would be mighty useful to see what is happening at the Display end, but even a simple LED and resistor (as in the olde-worlde 'Breakout Box') would help. If there's data being received when you're not sending any, it could explain the problem.

(Many years ago, I saw RS423 signals being used over shielded cable, with one of the differential signals just connected to GND. It worked ok until the device at end of the line was powered off. At that point, the wiring just started acting like an aerial, and everything locked up.)

(Some useful RS485 info here: https://www.lammertbies.nl/comm/info/RS-485.html)
 

hippy

Technical Support
Staff member
Is there any likelihood that using an AXE LCD will be more successful using this RS 485 protocol?
I would say probably not. The issue appears to me to be more related to the interfacing than anything else to me, length of cable and your RS485 interface.

Post the circuit diagram of your interface, both transmitting and receiving ends.
 

westaust55

Moderator
You may wish to have a look at this past project of mine posted in the finished projects area.
http://www.picaxeforum.co.uk/showthread.php?28444-PICAXE-based-DCC-ACCESSORY-CONTROLLER-for-model-railways-using-NCE-DCC-control-system

While not using an RS-485 LCD I have a PICAXE 20x2 communicating a an RS-485 bus with other devices also present and communicating between the master and slaves. Comms baud rate is 9600 bps.
The project has schematics showing the RS-485 circuit and also the program for the PICAXE chip.
 
Last edited:

sailgene

Member
SOLVED! Hey Gang. After weeks and weeks of fretting, followed by a little deduction, I found that the problem was a pin on the MAX 485 which did not get soldered. I could not make it out without a magnifying glass but there it was! Strange that I could get some data but not enough. So anyway, I apologize for wasting everyone's time but thank you all for chipping in your ideas.
 

Attachments

Buzby

Senior Member
Hi Westie,

I'm working on a comms task, probably going to be RS485, so I took a look at your DCC project for some pointers.
( It is the protocol that I'm putting most effort into, the hardware is easy (!?) .)

I was intrigued by your finding ...
"Using the hardware HSERIN and HSEROUT commands, while each was capable of operating in its own right, did not appear to achieve a sufficiently fast change over between two consecutive commands."
Did you mean two consecutive hserouts, or two hserins, or one 'out' followed by an 'in' ?. ( I've not read the full document yet, did you use background receive ? )

Some time back I learnt that hserout can be very misleading when it comes to how long it takes to execute, and I don't want to spend time finding another 'funny' if it's been found already.

Cheers,

Buzby
 

westaust55

Moderator
Hi Buzby,
That I believe was an input followed by a output.
Listening to the Bus and on “seeing” the CAB number then responding to confirm presence
 
Top