Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Mon Nov 20, 2017 12:51 am

All times are UTC - 7 hours




Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Fri Sep 18, 2009 11:27 pm 
Offline

Joined: Fri Sep 18, 2009 10:59 pm
Posts: 19
Location: Mumbai, India.
Dear sir,

I have made a Qlarity application on QTERM-G75 which receives and transmits data on COM1 using RS-485. The data is received at every 200 ms. Using this data I am updating the labels (7 to 8 in nos.) of type LabelV2. All these labels are kept in a screen of type ScreenV2. When this screen is not visible in the entire application (i.e. when it is disabled), I am receving the data transmitted from the QTERM-G75 at proper time intervals (within 125 ms of transmitting data to it). However, whenever the screen with labels is visible (enabled) alongwith all the labels which are getting updated with new data at every 200 ms, the data transmission from QTERM-G75 is seriously affected. Instead of within 125 ms after transmitting data to QTERM-G75, I am receiving data at around 500 to 700 ms.

I am not able to understand where the problem lies. I have also tried using label of type LabelLite. However, the problem still persists.

Additional information:

1>
RS-485 communication using element (named rs485) of type SerialBasicV2:
Data reception using:
func datareceived(data[] as byte)
Data transmission using:
rs485.senddata(arrayName)

2>
Label update is done as follows:
labelName.value = str(numVal) ' In case of LabelV2 type label
labelName.caption = str(numVal) ' In case of LabelLite type label

Kindly help me so that I can move ahead in my project. Tell me if any additional information is required by you.

Thank you.

- Jay


Top
 Profile  
 
PostPosted: Mon Sep 21, 2009 7:23 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
The first thing I would check is that the Draw Cache is enabled (Power On Setup->DCache. Should be All, Enabled or Eff Enabled).

The next thing I would try is make sure you are using BDF fonts (LabelV2s can use BDF or TTF fonts. LabelLites only use BDF fonts).

Assuming both of those previous suggestions were set the way I had suggested, I would ask you to try an experiment.

If I understood you correctly, you are updating 7 to 8 labels on each serial "pulse." Try stacking the labels, like I show in the screen shot.
Attachment:
OverlapLabels.PNG
OverlapLabels.PNG [ 16.57 KiB | Viewed 2614 times ]


Let me know if this fixes your performance issue. If so, I think I know what is going on and may be able to offer suggestions. (Obviously stacking like this isn't a valid solution, but it can help diagnose the problem).

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Tue Sep 22, 2009 6:36 am 
Offline

Joined: Fri Sep 18, 2009 10:59 pm
Posts: 19
Location: Mumbai, India.
Dear Jeremy,

Thanks for the reply. I have DCache set to ALL and also I am using BDF fonts only. I tried your suggestions and kept all the labels stacked together. This improves the performance as predicted by you. However, I am not able to understand why is this happening and also what shall I do to get around the problem (without stacking up the labels).

Thank you.

-Jay


Top
 Profile  
 
PostPosted: Tue Sep 22, 2009 7:39 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
The problem you are having is a little bit tricky to explain if you don't know what is going on under the hood of Qlarity. Let me see if I can explain enough to clarify the behavior without explaining so much as to muddy the water.

When you modify a display property of an object (such as the value property of the LabelV2), the object does not directly redraw itself. Instead it tells the firmware that its state is dirty and requests a redraw (there are good reasons for doing it this way, however they are a bit beyond the scope of this particular question.) In response to this request, the firmware does two things. First it flags the object as "dirty", it then generates a MSG_DRAW targeted at the rectangle occupied by the object and places the MSG_DRAW in the draw message queue. Every time a MSG_DRAW is added to the queue, the firmware checks the queue to see if the new MSG_DRAW can be combined with an existing one in the queue. To be eligible for combining, the rectangles must at least partially overlap (non-empty intersection). If they are combined a single MSG_DRAW is placed in the queue with the union of their rectangles and the two MSG_DRAWs that were combined are discarded.

Now, the reason for that complicated discussion is that the draw message queue is very small in size, only about 4 items deep. If the draw message queue fills up and another MSG_DRAW is generated that cannot be combined, the system gives up and simply creates a single MSG_DRAW with a rectangle that fills the entire screen. Unfortunately a full screen redraw (even if virtually all of the draw is restored from the draw cache) on the G75 takes a fair bit of time, about 200 ms. Given the description of what you are doing and the fact that stacking the labels seems to have helped, I strongly suspect that by updating 7-8 labels you are causing the system to punt and perform a full screen draw. Given that you are trying to update the screen at 200 ms intervals, I can certainly see how the system might get fairly busy and seem sluggish on updates (display updates are always the lowest priority, to ensure that communication data is processed first).

There are several things you can try to help alleviate the problem. The first thing that comes to my mind is to place a transparent object underneath all the labels. A good choice would be a RectangleV2 object with a borderwidth of 0 and transparent set to true.

Next, before you update any of your labels you would request a redraw of the rectangle. For example

func DataReceived(data[] as byte)
'Parse the data
...

rerender(rectange_1)
label_1.value = "a"
label_2.value = "b"
...
endfunc

This will cause MSG_DRAW region combining to come in to play from the beginning and cause the system to never give up and draw full screen.

Now, a word of advice here: The effectiveness of this approach will be proportional to the size of the bounding rectangle that encloses all of the updated labels. The smaller you can make that rectangle (for instance by putting all the labels in a single row or column if possible) the more effective this approach will be.

A possible refinement of this technique would be to arrange the labels into two rows or columns and use two rectangles. If the sum of areas of the two rectangles is smaller than the area of a single rectangle, then two rectangles will be a net win. (Be careful about generalizing this too far, if there are other items in the draw message queue, you could trigger the original situation).

----------------------------------

Another, completely different, approach to this problem would be to try and combine as much of the information into a single object as possible into a single object. Several objects might be appropriate for this (as I don't know how your workspace is set up, I am only guessing here). The ListboxV2, the DataGridV2 and even multi line LabelV2s come to mind.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Wed Sep 23, 2009 4:18 am 
Offline

Joined: Fri Sep 18, 2009 10:59 pm
Posts: 19
Location: Mumbai, India.
Dear Jeremy,

Thanks for the detailed explanation regarding the working draw queue.

I tried putting a transparent rectangleV2 object below the labels. It actually improved the performance.

However, my screen included eight labels and two dials of type TachometerV2. Together they are occupying almost 50% of the screen. I had to remove both the dials (tachometers) in order to achieve desired performance. My doubts are:

1. Is draw message queue common for all the objects or is it different for different types of objects?
2. Performace depends on what? The number of non-overlapping objects being redrawn OR the area of the screen that the objects being redrawn cover? i.e. Will single label covering entire screen take same time to get updated as that of the full screen redraw?
3. Can we change the size of the draw message queue?
4. Regarding the priorities, can we set priorities for display updates and communication? I will like to have the highest priority for communication and the least priority for the display updates.
5. What other precautions shall I take in order to keep the performace over the serial communication channel satisfactory?

Thank you.

- Jay


Top
 Profile  
 
PostPosted: Wed Sep 23, 2009 7:06 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Quote:
1. Is draw message queue common for all the objects or is it different for different types of objects?


There is a single draw message queue shared by all objects

Quote:
2. Performace depends on what? The number of non-overlapping objects being redrawn OR the area of the screen that the objects being redrawn cover? i.e. Will single label covering entire screen take same time to get updated as that of the full screen redraw?


This is a very tricky question to answer. On the G75, drawing time increases linearly with the number of pixels to be redrawn (1 pixel draws essentially instantly, 300,000+ pixels take about 200 ms to draw -- mostly due to the amount of time required to push the memory around). Now, for the actual dirty objects (ones whose appreance is changing), they will take time as well. Stack 200 relatively small objects on top of each other and redraw each and the draw will take a fair bit of time as well.

Quote:
3. Can we change the size of the draw message queue?


This is not under user control. It is very rare that the draw queue size is in any way observable to a user. Yours is a worst case scenario.

Quote:
4. Regarding the priorities, can we set priorities for display updates and communication? I will like to have the highest priority for communication and the least priority for the display updates.


This is also not under user control. Drawing is the lowest priority. Communication is on par with everything else. However, a draw will not be interrupted once it has started, even if communication arrives.

Quote:
5. What other precautions shall I take in order to keep the performace over the serial communication channel satisfactory?


Unless you are using large numbers of timers, I cannot think of anything.


Is there any chance you can post a screenshot of the screen that is causing problems, I might have some more suggestions.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Wed Sep 23, 2009 9:51 pm 
Offline

Joined: Fri Sep 18, 2009 10:59 pm
Posts: 19
Location: Mumbai, India.
Dear Jeremy,

Thanks for the reply. Here, I am attaching the screenshot of the screen that is causing serial communication problems.

Image

I have used a tabContainer. Whenever, the tab with the shown screen is visible, communication performance gets deteriorated. As suggested by you, I have kept transparent RectangleV2 objects below each columns of the labels that needs updation (2nd and 4th column). Also, there are two dials of type TachometerV2.

When, these TachometerV2 object are enabled, the communication performance is degraded. However, I tried disabling both the tachometer objects (thinking that it will reduce the number of pixels being redrawn considerably), and the desired communication performance was observed.

Can you suggest something by which I can keep the tachometers enabled and also have the desired communication performance. Also, tell me if any additional information is required.

Thank you.

- Jay


Top
 Profile  
 
PostPosted: Thu Sep 24, 2009 7:05 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Hrm, this is a tricky one. The first thing I would try is an additional rectangle under the tachometers and see if that helps things.

I might try shrinking the area of the tachometers about 25%. I am thinking you should be close now in terms of performance.

Another thought would be to only update the labels or the tachometers every other 200 ms serial pulse.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Tue Oct 06, 2009 10:41 pm 
Offline

Joined: Fri Sep 18, 2009 10:59 pm
Posts: 19
Location: Mumbai, India.
Hi Jeremy,

I tried putting the additional rectangle under both the tachometers. It did not help. Also, reducing the size of tachometers did not help much. Right now, I have removed both the tachometers and moving ahead without them.

Thank you.

- Jay


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 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