We've built these boxes from scratch; Arduino drives a Gecko controller that drives a small stepper to move a cone valve and deliver plastic sand to our river experiments (www.emriver.com).
After hundreds of hours of prototyping; we built production boxes and then this happens; part of the display goes haywire. Program still running, machine works, everything OK otherwise. Any ideas where to start troubleshooting other than replacing parts? I know it's not the code, and it happens intermittently.
Middle one in attached photo shows how the display is supposed to look. Thanks!
I can't see any obvious problems in the code (yet).
In the photo, it looks like unit 2 has a different cable arrangement than the other two. Does it also have the problem with garbled LCD data? If not, I'd look at what is different about its cables that might contribute to its immunity. Unit 3 appears to have a power cable wrapped around the data cable (or vice versa) which might be introducing noise into the unit.
Thanks guys, both good possibilities. But now we've run them for hours and can't reproduce the fault! A colleague thinks it may be that I'm simply writing blanks to clear the left hand side of the screen when I update LCD (because SN=XX on the right never changes when it's running).
And perhaps I'm just "pushing" those characters somewhere and eventually they fill up a buffer or some such. Makes sense because only the part I'm writing over like this is garbled, and it's very consistent.
I've worked on this code for literally years, and probably the writing blank spaces v. lcd.clear() had a purpose at one time, but not now, so I'll use lcd.clear().
You should tie D0 to D3 of the display to GND - if they are kept floating they can pickup electrical noise and tell the display to enter 8-bit mode and then garble all actions after that point.
Zapro, could this cause the consistent pattern with the right third of the screen unaffected, though? Seems the whole screen would go bonkers.
Also please note there is a Gecko stepper driver lower right (has LED); very well engineered, but could be noisy, maybe? And also we discovered case was getting up to 150F inside; we fixed that too.
But we ran them all day today and no replication of the problem.
Physical computing for sale is very, very hard, I don't recommend it. Like being a professional musician, you suck all the fun out of it :-/
And I should mention we've used that basic PCB (designed by us) for over 200 units of the controller you see here, worldwide, with zero display problems -- people step on them and break the control knob; otherwise perfect record in the field.
gravelbar:
And I should mention we've used that basic PCB (designed by us) for over 200 units of the controller you see here, worldwide, with zero display problems -- people step on them and break the control knob; otherwise perfect record in the field.
Are the displays from a reputable source? There has been more than one instance of people having troubles like yours when using certain (possibly out-of-spec) displays in the 4-bit mode with the Arduino LiquidCrystal library.
If you experience problems again you might want to try the latest version of the library that JJRaines wrote for the 40x4 displays. That library seems to handle slow (out-of-spec) displays where others don't.
gravelbar:
Paul__B, thanks, but I can't find anything on "impulse interference" searching the forum.
As mentioned in another thread here, searching the forum is difficult. I may call it "impulse interference" but that does not mean other people ever said that in so many words.
What is common is intermittent problems with the LCD crashing when relays/ solenoids operate, and adding the capacitor often works if it is only the LCD which crashes.
gravelbar:
We have 100µF caps in the lab, would that work?
Paul__B:
As mentioned in another thread here, searching the forum is difficult. I may call it "impulse interference" but that does not mean other people ever said that in so many words.
What is common is intermittent problems with the LCD crashing when relays/ solenoids operate, and adding the capacitor often works if it is only the LCD which crashes. Certainly should.
In very general terms - in an industrial environment you have two kinds of interference - dropping / interrupting the power supply and RFI.
100 pf cap won't do anything for neither one of them - it won't hold the power - way too small and it won't short out the RFI either.
If it is a real problem, so far you did not prove that, you need to find the real source.
Since you said "it was 150 inside the box" - how "industrial strength " is your power supply or is it Walllwart type?
I''l bet that Arduino stuff is good for 68 degrees AC environment only anyway.
