|
Post by Rod on Apr 23, 2023 15:12:42 GMT -5
No, you must use delsegment as I stated. Every time you do flush bak , bak is incremented by one and the old segment is left behind. Use the sequence I stated. That way the bak segment is never changed you just redraw it to clear the screen back to the original background. The bak variable never changes, You must delsegment fore before you flush fore else the same problem will occur. Fore will be incremented by one and the old fore segment will be left outstanding.
It is all in the article on the LBPE.
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 23, 2023 16:14:53 GMT -5
"That way the bak segment is never changed you just redraw it to clear the screen back to the original background."
That's the problem. Can't clear the screen back to original background. It will clear the data that's already there. All data must accumulate on screen until user intervention. There's a graphic being drawn with each reading.
Thinking along the lines of: var=0 Draw stuff "flush 0" 10 Draw stuff var=not(var) (or some function that changes the value of this var between 1 and 0) "flush ";var "Delsegment ";not(var) Inner loop here Goto 10
|
|
|
Post by Rod on Apr 24, 2023 1:59:58 GMT -5
Nope, segments don’t work that way. The variable that identifies the segment starts at 1 and then increases by one every flush statement no matter what. Even if you delete segments the number still increments by 1.
So we need another plan. The clock program is your model. It would not take too long to redraw your data lines from six arrays. Then the record is not in the segment. So store your data to arrays on receipt and redraw the entire line set when you redraw.
This will only happen once a minute. You can draw small things in between so long as you have no expectation they will be preserved on minimisation or screen covering. But if they are refreshed every second does it matter. This is between stuff needs needs dumped with “discard”
Draw background Flush bak
Do Do Do Check time set flag Discard Draw trivia Loop Delsegment fore Redraw back Draw lines Flush fore Loop Loop
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 24, 2023 3:28:25 GMT -5
Ok, have re-read some of your earlier posts, and some things on that Alice's Restaurant website, about memory segments. I think I got it now:
- Every flush command will create it's own uniquely identified memory segment with a sequential number.
- That sequential number is not user accessible (under normal conditions).
- User can attribute any label he wants to that memory segment (like bak, fore, others).
- Segments can be created or destroyed at will by issuing either "flush label" or "delsegment label"
- There's a few other commands, like "discard", "cls" that can clear all segments.
Having this in mind, and not going to create arrays for all my data, because that will imply a major redo of all code, I think I can do this:
draw background n=0 "flush ";str$(n) call logical_n n do read and draw stuff . do read and draw stuff . "flush ";str$(n) call logical_n n "delsegment ";str$(n) do timing control loop loop loop
function logical_n n if n=0 then n=1 else n=0 end if
Thank you
|
|
|
Post by Rod on Apr 24, 2023 5:58:10 GMT -5
Bit convoluted, the point of naming the flush is that you can delsegment it later without fuss, you would do that immediately ahead of creating the next flush
Draw background Flush bak
Do Delsegment fore Redraw bak Draw foreground Flush fore Loop
It’s that easy, it does not matter that there is no fore segment first time through the loop. The name, fore carries the segment I’d and automatically does what you are trying to do with logic n
|
|
|
Post by Rod on Apr 24, 2023 7:10:38 GMT -5
The difficulty of keeping c6000 charted points "flushed" has been discussed in the past. One solution was to "getbmp" the drawn lines, draw the bmp one pixel left and draw the 6 new points. The other solution is to use the blitter and a buffer. Keeping your data in an array might be just as easy. But lets see if you have a problem at all. If you can keep it to two segments you probably have a solution.
Then we see if it was drawing that was causing the problem, or the timer, or stacked events. Given the clock program runs it should all be possible.
|
|
|
Post by Rod on Apr 24, 2023 8:19:47 GMT -5
Ok, hang on. You cant redraw just the background. So that strategy is bust. This is what I would do. Draw the background once and the initial data once, preserving it all with "flush scr". Now "getbmp" the entire screen to "scrbmp", thats your new background with all current data preserved. When you are ready to draw the next cycle "delsegment scr", that frees the memory. Now "drawbmp scrbmp" restoring background and data, draw your new data and "flush scr". Now "getbmp" to "bmpscr" again.
With that cycle you are minimising the drawing to one big bmp draw and a few drawn updates. The single segment scr preserves everything and is recreated each cycle.
I am not sure how else you will preserve thousands of drawn points over time.
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 24, 2023 8:30:29 GMT -5
Ok, hang on. You cant redraw just the background. So that strategy is bust. This is what I would do. Draw the background once and the initial data once, preserving it all with "flush scr". Now "getbmp" the entire screen to "scrbmp", thats your new background with all current data preserved. When you are ready to draw the next cycle "delsegment scr", that frees the memory. Now "drawbmp scrbmp" restoring background and data, draw your new data and "flush scr". Now "getbmp" to "bmpscr" again. With that cycle you are minimising the drawing to one big bmp draw and a few drawn updates. The single segment scr preserves everything and is recreated each cycle. I am not sure how else you will preserve thousands of drawn points over time. THAT bmp technique might convince me! Will consider it if my "convolution" doesn't work. Thanks
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 24, 2023 12:32:45 GMT -5
Right... My n=not(n) technique for the flush segments works very well, Never saw Liberty Basic Task manager process so low, and stable for so long, with this program. But... Every time you delete a segment, whatever graphics that segment contained, are deleted as well. Only way I can see to do it with "flush" commands alone, would be to continuously flush more and more segments. Obviously not a good idea. So, the bmp technique comes into play. Have implemented it. Task manager shows a fat process. But does not increase over time. And it's actually smaller than initially, with the many flush commands over a medium/large period of time. However, it's not working as expected. Sometimes the background disappears. Investigating... **************************************** EDIT ***************************************
Seems that the getbmp technique works worst that the flushes. At least with the flushes, everything stayed on screen. only downside was the communications stopping.
With getbmp, I can't get the same background back. Only the latest drawned stuff shows up
|
|
|
Post by Rod on Apr 24, 2023 14:03:20 GMT -5
Yeah, lost site of the original problem, background working. There is a possibility that getbmp does not work when the program is minimised, or in the background. Something I have never checked. I suppose that leads me on to question why you are drawing a screen that no one is looking at.
You’re drawing it because this is your record, your memory of readings. Time to change tack. If getbmp has limitations you need to start writing to a log file. Then use that log file to draw whatever the user wants to see.
A log file and on demand drawing might be a much better solution to the problem. You can still have a regularly updated screen, using the current time and looking back over the file. So whenever the program starts, comes into view or updates it takes current time and draws back say 24hrs
That one complete set of drawing will still need a delsegment scr flush scr to make it persist over the minute between updates but thatis easy compared to our past efforts. You would probably still have one bmp based background to speed drawing and only really redraw the data lines and system conditions.
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 24, 2023 14:12:39 GMT -5
getbmp definitely has issues when in background. Just tested it by sending L.B. to the background 5 sec. before an update. Switched to an Internet page for about 10 sec. Back to L.B.. L.B. windows had all the latest data, but the background was the Internet page. Not going to use this technique for sure.
That log idea as crossed my mind before, for several reasons. Happened that wasn't necessary to actually have a logging system before. But now will have to consider it.
Thank you very much for all your help. Will keep you posted on any developments with this issue
|
|
|
Post by Brandon Parker on Apr 24, 2023 18:40:49 GMT -5
For what it is worth, I have typically held any data that changes on a continuous basis in an array. After every update cycle, the graph segment for the data would be deleted, the data would be redrawn, and the graph segment for the data would be re-Flushed.
Would it be possible to get a screenshot of the window you are working with including data (real or fake) so that everyone can see what we are working with?
{:0)
Brandon Parker
|
|
|
Post by Rod on Apr 25, 2023 1:18:05 GMT -5
I could post a screen shot if Nuno wishes. It’s a 1980x1080 screen with six charts showing data so at least 6x1980 points to redraw. Might be a bit slow but it is only getting redrawn once a minute.
I don’t often push API solutions but I have an old solution that uses the blitter and direct drawing to the buffer. If I recall I shift left and draw the six points then blit to screen. I will dig it out today.
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 25, 2023 2:13:00 GMT -5
I can post a screenshot of the actual thing later today. There's nothing secret about it. Rod, you're ok to post such if you wish.
As for the logging idea, that only makes sense in a 24h, 7 day a week, basis. We don't have a mainframe that's turned on continuously. Current machine would have to be relocated for that purpose. This is becoming a bad idea altogether... I'm setting up a meeting with management to discuss the issue further
|
|
|
Post by tsh73 on Apr 25, 2023 2:49:09 GMT -5
So how much data (lines per hour, numbers per line) actually is? Is it really needed to be updated on the fly as it happens? Or redrawing once in a second might be enough? I wonder if program could be split in two - one just reads com port and appends lines to file, Doing nothing more - so nothing interferes with it other just reads file ( last N lines?) and draws it.
|
|