I'm having a periodic problem with the GLK-12232. We're talking to it through a serial interface using Perl under Linux, and most of the time this all works happily. However, very occasionally - usually when developing additions to our display software, or when attempting to debug it - we see a curious effect that seems to be the result of sending the panel something it tries to interpret as a command but cannot understand.
Basically, the whole thing freezes, won't respond to any valid commands anymore, and requires a hard power cycle to sort it out. I've not found anything in the manual which hints at this kind of behaviour, and it's not a panel fault because I've used five or six different panels for development over the last eight months or so, and they all do this.
I'm extremely curious to know if this is a known issue with these panels, and if there's any way to snap the panel out of it without requiring a power cycle. This is of particular importance right now as it has been known to occasionally occur on machines shipped to customers, which I believe is a problem in our software originally causing it, but it would be nice to get the panels running again without requiring the customer to power cycle their machine, which for our products can be a big issue. Thankfully the panels aren't critical to the operation of the system.
I've tried numerous things to see if I can make the panel work again, but nothing has any response - the keypad returns nothing, it doesn't respond to read module type commands, won't display graphics, no backlight control, no text display - it's more or less like it's not connected to the serial port anymore.
Oh, and if this is something that's supposed to be in the panel behaviour, a mention of it in the manual would be extremely helpful to people who find themselves in the same situation I did when I first encountered this problem.
GLK-12232 freezing up
soft reset, even if the buffer did overflow?
Hi,
I am experiencing the same problem from time to time. For the most part I have put in safe guards to ensure the buffer will never overflow. However, it is hard to know if I have tried and tested every possible case. For our products it would be unacceptable for the LCD to ever become unresponsive.
From the previous posts and from my own experience it appears that if the LCD internal buffer ever does overflow, it becomes unresponsive and requires a hard reboot (power cycle), in order for it to respond to any new commands. I can reproduce this issue by using the LcdTester application to send text to the Lcd multiple times quickly. After doing this, the LCD becomes unresponsive until a hard reboot. Is this expected behaviour? Is there any other way to make the LCD respond to commands again without a hard reboot?
I am experiencing the same problem from time to time. For the most part I have put in safe guards to ensure the buffer will never overflow. However, it is hard to know if I have tried and tested every possible case. For our products it would be unacceptable for the LCD to ever become unresponsive.
From the previous posts and from my own experience it appears that if the LCD internal buffer ever does overflow, it becomes unresponsive and requires a hard reboot (power cycle), in order for it to respond to any new commands. I can reproduce this issue by using the LcdTester application to send text to the Lcd multiple times quickly. After doing this, the LCD becomes unresponsive until a hard reboot. Is this expected behaviour? Is there any other way to make the LCD respond to commands again without a hard reboot?
Hey Scott...
Check your email...let me know what you think...!!
The hard lock up is something we know about but cannot avoid due to the way we handle data in the internal buffer. Currently my advice would be to always use flow control and avoid overruning the internal buffer at all costs!!
Check your email...let me know what you think...!!
The hard lock up is something we know about but cannot avoid due to the way we handle data in the internal buffer. Currently my advice would be to always use flow control and avoid overruning the internal buffer at all costs!! Miles Y.
Head of Technical Support
Product Manager
Matrix Orbital
Head of Technical Support
Product Manager
Matrix Orbital