Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Sun Nov 19, 2017 1:47 am

All times are UTC - 7 hours




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: G75 intermitent failure
PostPosted: Wed Oct 06, 2010 8:07 pm 
Offline
User avatar

Joined: Thu Jun 14, 2007 9:05 am
Posts: 98
Location: Montreal - PQ
I really love these G75 terminals, they are simple to work with and up to now I've had the best support when needed.

A client where I was last week is experiencing some intermitent failures on one of the dozen QSI terminals (not all G75).

The screen goes black and displays...

''Unhandled firmware exception - level EXLEV_SYSTEM - GetObjPixmap: Unable to allocate memory"

There are 4 of them HMI close 20 feet away with the same programs. Only one does this... about once a week since about 3 months.

They cycle power and it's OK for another few days.

What are we to do. The unit is about 2 years old.

_________________
If it looks like a Cat ...


Top
 Profile  
 
PostPosted: Thu Oct 07, 2010 8:09 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
I am not 100% sure what is going on here, but I can take some guesses.

I suspect that your application is using most of the available RAM on the terminal. On rare occasion, it follows a code path that causes to require slightly more RAM than is available on the terminal.

If you want you can instrument this to see. If you are using Qlarity 2.6 or later you can add a SystemStatusV2 object to your workspace which will let you see how much RAM is currently available. If you ever drop below 1-2 MB of RAM, you might have cause for concern.

If you are not using 2.6, you can still query the current RAM, but it would take a little more work. You would need a label and a timer object. To the timer object add:

Code:
init parent := default
init timeperiod := 1

func timeout()
    dim bytesFree as integer
    FromBytes(bytesFree, mid(GetHardwareInfo(HW_MEMORY), 8, 4), true)
    myLabel.valuue = _strtocharstr(Str(bytesFree))
endfunc


Now, there is probably an easy fix -- easier, in fact than instrumenting the problem (to the point, where you may just decide to try the fix). Go to Power On Setup on the G75, and modify the DCache setting under Display. Lower the DCache setting by 1 value. The available values are (from highest to lowest) All, Enabled, Eff Enabled, None.

I suspect your DCache is currently all, and moving it to Enabled will fix the problem. If you have other G75s, there is a good chance they may already have a lowered DCache.

DCache stands for Draw Cache. The G75 can use some of its RAM to store pre-drawn objects which will speed up display updates. However this can cause it to run out of RAM. If you lower the DCache setting it will use less RAM to store the pre-drawn objects. Setting it to ALL is pretty aggressive. Most people will not notice any speed difference if you lower it to enabled, and it will free quite a bit of RAM. (roughly 600 kBytes for each screen in your workspace) If you lower it below Enabled, then you might notice a delay when switching screens.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Thu Oct 07, 2010 9:47 am 
Offline
User avatar

Joined: Thu Jun 14, 2007 9:05 am
Posts: 98
Location: Montreal - PQ
Thanks,

Will try this next week and post results,

_________________
If it looks like a Cat ...


Top
 Profile  
 
PostPosted: Tue Oct 26, 2010 8:41 am 
Offline
User avatar

Joined: Thu Jun 14, 2007 9:05 am
Posts: 98
Location: Montreal - PQ
Here's how it goes.

All 4 HMI are identical with same programs (except for IP addresses)

I have inherited these from the first integrator and the one thing that concerns me the most is the quantity of comunication it does. There is a lot of registers being polled... about 100. When I attemp to download, I do get a warning about this but it works pretty fine anyway.

On this issue, all where at the "ALL" and I did change this particular unit to the "Enabled" setting.

Now, after 15 days running with this new settings, Operators have not seen that BSOD (here B standing for BLACK)... BUT they have had to reboot the unit. One the phone, they where not very clear about why but they mentionned that for one, the screen is very slow... sometime when changing settings with a + button/function... they would overshoot the target value... and they say the screen is acting in a bizarre way...

I will be there next week and back on the forum for advices...

I will also add the code to monitor the actual memory usage...

_________________
If it looks like a Cat ...


Top
 Profile  
 
PostPosted: Tue Oct 26, 2010 8:57 am 
Offline
User avatar

Joined: Thu Mar 02, 2006 2:12 pm
Posts: 487
Location: Salt Lake City, Utah
Without looking at the source code of your workspace, I can only speculate on what might be hurting the performance of your application. Some common pitfalls:

1) Verify that you only have one screen enabled at a time. One way to ensure this is to use the _ShowScreen function to change screens. If you have screens enabled that are not displayed, that can hurt performance. A screen is enabled if its "enabled" property is set to true and it's parent is enabled.

2) Verify that you are not using TTF fonts. TTF fonts are slow. If you are using TTF fonts, change them all to BDF fonts and that should give you a significant boost in performance.

3) Make sure you are not over-using the API's "GetObjProp" or "SetObjProp". These can be very slow in a large workspace and should be limited in use.

_________________
Ron L.

http://www.beijerelectronicsinc.com/


Top
 Profile  
 
PostPosted: Tue Oct 26, 2010 9:00 am 
Offline
User avatar

Joined: Thu Jun 14, 2007 9:05 am
Posts: 98
Location: Montreal - PQ
Will do

_________________
If it looks like a Cat ...


Top
 Profile  
 
PostPosted: Thu Nov 11, 2010 7:10 am 
Offline
User avatar

Joined: Thu Jun 14, 2007 9:05 am
Posts: 98
Location: Montreal - PQ
OK, you guys where wright again ...

Although I was septic about your hints of solutions (based on the fact that we had 4 identical systems but only one was showing this failure...), here is what happened.

Last week,, adding one symbol to an HMI that never failed... it failed on me. Showing the same darn errors.

So I ajusted it to ''Enabled'' and now all is A-OK.

Basically, havin it setup for "ALL" uses up all available RAMs and eventually fails, with "NONE" its WAY to slow, now with "ENABLE", its fast and furious.

Thanks again,

_________________
If it looks like a Cat ...


Top
 Profile  
 
PostPosted: Thu Nov 11, 2010 7:53 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Glad that things worked for you. In general I would never recommend a DCache of None except in extremely specific circumstances. However Enabled is a good selection for most people -- actually starting in our newest generation of products Enabled has become the default.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 7 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group