Author |
Topic: LBB runs 7 times slower than LB on my GBRL-Sender (Read 1575 times) |
|
xtal
New Member
member is offline
Gender: 
Posts: 27
|
 |
Re: LBB runs 7 times slower than LB on my GBRL-Sen
« Reply #53 on: Dec 28th, 2017, 12:32am » |
|
Part 2
Code:
button #main.path,"<Path$>",[PathClr],UL, 445,70,50,16
graphicbox #main.PathBox, 445,48,413,20
statictext #main.drive, "Drive",415,104,30,16
combobox #main.drvbox, drv$(), comboClick,445,105,50,25
ComboboxColor$ = "yellow"
combobox #main.selbox1, fdr$(),comboClick,500,104,358,2
ComboboxColor$ = "green"
combobox #main.selbox2, fil$(),comboClick,500,104,358,2
graphicbox #main.Fdrbox,445,87,72,17
button #main.yellow,"Folder", comboClick,UL,455,89,45,12
graphicbox #main.Filebox,525,87,72,17
button #main.green,"File",comboClick,UL,535,89,45,12
statictext #main.nbrfdrname, "#Fdr's",500,70,30,14
textbox #main.nbrfdr, 535,69,30,17
statictext #main.nbrfilename, "#File's",570,70,30,14
textbox #main.nbrfile, 605,69,50,17
statictext #main.FilLen, "#FileLen", 660,69,50,14
textbox #main.fbox, 710,69,68,17
button #main.MZX, "Zx", [MZX], UL, 165, 0, 30, 30
button #main.MZY, "Zy", [MZY], UL, 165, 35, 30, 30
button #main.MZZ, "Zz", [MZZ], UL, 165, 70, 30, 30
button #main.MZR, "ZR", [MZR], UL, 195, 0, 25, 100
stylebits #main.DROMPx, _ES_RIGHT,0,0,0
textbox #main.DROMPx, 55, 0, 110, 30
stylebits #main.DROMPy, _ES_RIGHT,0,0,0
textbox #main.DROMPy, 55, 35, 110, 30
stylebits #main.DROMPz, _ES_RIGHT,0,0,0
textbox #main.DROMPz, 55, 70, 110, 30
stylebits #main.DROWCx, _ES_RIGHT,0,0,0
textbox #main.DROWCx, 220, 0, 110, 30
stylebits #main.DROWCy, _ES_RIGHT,0,0,0
textbox #main.DROWCy, 220, 35, 110, 30
stylebits #main.DROWCz, _ES_RIGHT,0,0,0
textbox #main.DROWCz, 220, 70, 110, 30
stylebits #main.DROWPx, _ES_RIGHT,0,0,0
textbox #main.DROWPx, 330, 0, 110, 30
stylebits #main.DROWPy, _ES_RIGHT,0,0,0
textbox #main.DROWPy, 330, 35, 110, 30
stylebits #main.DROWPz, _ES_RIGHT,0,0,0
textbox #main.DROWPz, 330, 70, 110, 30
listbox #main.S1, SA$(),[Prm1],476,125,102,108
listbox #main.S2, SB$(),[Prm2],580,125,102,108
listbox #main.S3, SC$(),[Prm3],686,125,102,108
listbox #main.S4, SD$(),[Prm4],792,125,102,108
listbox #main.S5, SE$(),[Prm5],898,125,102,108
texteditor #main.PopUp, 500, 250, 475,350
graphicbox #main.Plot3, 476, 235, 525,405
'------- added for test ?Delay and TicMs
graphicbox #main.BMPB, 188, 575, 100, 65
button #main.CLO, "CLOSE", [quit], UL, 198, 584, 80, 25
button #main.STP, "E-STOP", [ESTOP], UL, 198, 606, 80, 25
statictext #main.Dly0,"?Delay", 600,87,35,17
textbox #main.Dly1, 640,87,25,17
statictext #main.Tic0,"TicMS", 670,87,35,17
textbox #main.Tic1, 710,87,45,17
Open "Liberty Basic GRBL GUI" for Window as #main
#main "trapclose [quit]"
#main.Filebox, "fill green"
#main.Fdrbox, "fill yellow"
#main.Filebox, "fill green"
#main.BMPB, "fill red"
#main.yellow,"!font roman 6 10"
#main.green,"!font roman 6 10"
td = time$("milliseconds") +5000
while time$("milliseconds") < td
wend
etime=0 : lastsent=0
bucketdelay=15
oldtime=time$("ms")
[LoadMacros]
[Glog]
[ErrLoop1]
[LoopExit]
timer bucketdelay, [ckbuf]
wait
[ckbuf]
Qcnt=Qcnt+1
nowtime=time$("ms")
x$=time$()
elmstime=nowtime-oldtime
elapsedtime=(elmstime)/1000
oldtime=nowtime
etime=etime+elapsedtime
ztime=int((etime/Qcnt)*10000)/10
#main.Dly1, int(ztime)
#main.Tic1, ztime
#main.ManualTx,int(ztime);" - ";ztime
if Qcnt >99 then
mstime=int((etime/100)*10000)/10
Xtime$="<";x$;"> <";Qcnt;"> <";etime;"sec> <";mstime;"msTIC";">"
#main.GCwindow, Xtime$
print Xtime$
Qcnt=0 : etime=0
abc=abc+1
end if
if abc=15 then [quit]
if CommOpen=0 then [LoopExit]
[getbuffer]
[getmessage]
[loopx]
[PreProcess]
[StepWait]
[PrintResponse]
goto [LoopExit]
[ESTOP]
[quit]
close #main
END
Changed BMPBUTTON
added ?Delay text box and TicMS textbox
added code to write to ?Delay, TicMS, ManualTx boxes
These all dislpay in LB only ManualTx displays in LBB
Also Folder [green] & File [yellow] not displaying very well ?font
Program run after 5 sec LBB will see only ManualTx data
Looking into trying subroutine , it would be pretty big though...
|
| « Last Edit: Dec 28th, 2017, 12:41am by xtal » |
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: LBB runs 7 times slower than LB on my GBRL-Sen
« Reply #54 on: Dec 28th, 2017, 09:36am » |
|
on Dec 28th, 2017, 12:32am, xtal wrote:| Looking into trying subroutine , it would be pretty big though... |
|
The code you listed still contains WAIT!? Obviously, replacing the WAIT with a SCAN/Sleep loop is a lot easier than switching to a SUB handler, and it retains compatibility with LB 4. So I am puzzled that you appear not to have tried it, or perhaps you did but haven't reported the results.
If you are hitting other minor incompatibilities between LB 4 and LBB, for example that fonts aren't always exactly the same size, you may need to tweak your code accordingly. Similar issues can arise when running LB programs under Wine, for example, or if the DPI value isn't what you expect.
Richard.
|
|
|
|
Rod
Full Member
member is offline
Gender:
Posts: 110
|
|
Re: LBB runs 7 times slower than LB on my GBRL-Sen
« Reply #55 on: Dec 28th, 2017, 11:55am » |
|
The code can be made to run much faster without the Timer statement. Loop or Sleep will both cycle the code much faster.
But that isn't the problem we started discussing at the start. Why does Xtal's computer run slowly for LBB and not for LB? Everyone who has tested has reported that they can't see the problem on their machines. So what is broken on Xtal's machine?
If the code is for distribution it would seem wiser to code for a working machine.
What happens if you code a sleep loop? Does the code still run slower?
What happens if you reboot and use Safe Start, does that fix the problem?
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: LBB runs 7 times slower than LB on my GBRL-Sen
« Reply #56 on: Dec 28th, 2017, 1:17pm » |
|
on Dec 28th, 2017, 11:55am, Rod wrote:| The code can be made to run much faster without the Timer statement. Loop or Sleep will both cycle the code much faster. |
|
I'm not suggesting that the OP should remove the Timer statement, but simply to replace the WAIT with a functionally-equivalent SCAN/Sleep loop - exactly as is often necessary when LB is used with WMLiberty.dll. In normal circumstances that won't make any difference to the overall execution speed - internally the WAIT is pretty much equivalent to a SCAN/Sleep loop anyway (at least, in LBB it is).
However since the issue he is encountering seems to be specifically affecting the WAIT statement, anything which replaces it with an alternative formulation holds out the possibility of it fixing - or at least avoiding - the problem.
Quote:| Why does Xtal's computer run slowly for LBB and not for LB? |
|
The reason it affects LBB and not LB is, presumably, because under the hood they are completely different! If, as I hypothesize, it is an unwanted and unexpected side-effect of having some third-party utility installed on the PC, it would be pretty surprising if LB and LBB did respond in the same way!
Quote:| If the code is for distribution it would seem wiser to code for a working machine. |
|
I agree, but the workarounds I have proposed (switching the WAIT for a SCAN/Sleep loop, or using a SUB rather than a branch-label timer handler) don't in any way compromise the performance of the code on a "working machine" so there seems no harm in at least trying them.
Richard.
|
|
Logged
|
|
|
|
xtal
New Member
member is offline
Gender:
Posts: 27
|
|
Re: LBB runs 7 times slower than LB on my GBRL-Sen
« Reply #57 on: Dec 28th, 2017, 2:25pm » |
|
Trying sleep just screws up many things , and you never goto [ckbuf]
It would probably need many pgm changes to implement.....
Could the Wait be implemented a while wend timing loop , or would that block event's from happening ......
If I try
Code:
timer, bucketdelay ckbuf
next instruction
I assume the end sub will bring me back to the next instruction. I might be able to make that work.......
Also have you ignored that ?Delay & TicMS don't get data while ManualTx does - all textboxes -
changed the last test code....
Code:
[LoopExit]
'timer bucketdelay, [ckbuf]
'wait
timer bucketdelay, ckbufx
goto [ckbuf]
sub ckbufx
' do nothing
end sub
[ckbuf]
Now getting 4.6ms ??????
The ?Delay and TicMS -- still don't update..
will try on main pgm to see what happens....
Yea I know ,, that won't work I have to put the wait in there,but this did show that LB shows 0.2ms to do that simple bit of code while LBB shows 4.6ms ????
|
| « Last Edit: Dec 28th, 2017, 3:02pm by xtal » |
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: LBB runs 7 times slower than LB on my GBRL-Sen
« Reply #58 on: Dec 28th, 2017, 3:12pm » |
|
on Dec 28th, 2017, 2:25pm, xtal wrote:| Trying sleep just screws up many things , and you never goto [ckbuf] |
|
That doesn't make sense. Are you sure that you understood what I am suggesting? I want you to replace this single statement:
Code:
with this short block of code:
Code:[waitnow]
SCAN
calldll #kernel32, "Sleep", 1 as long, r as void
goto [waitnow]
This code is functionally the same as a WAIT statement. It isn't plausible that it can "screw up many things" or "never goto [ckbuf]". I can only assume that you have not made the code substitution correctly.
Quote:| I assume the end sub will bring me back to the next instruction. |
|
No. Have you never used a SUB event handler before - not even for a GUI event such as a button click? This is absolutely standard practice (indeed it is preferred over the branch label kind of handler in almost all circumstances). When using SUB handlers control returns to the WAIT statement - that is precisely why I think it might be helpful, because the WAIT gets executed once but never again.
Richard.
|
|
|
|
xtal
New Member
member is offline
Gender:
Posts: 27
|
|
Re: LBB runs 7 times slower than LB on my GBRL-Sen
« Reply #59 on: Dec 28th, 2017, 5:13pm » |
|
[quote author=Richard Russell
No. Have you never used a SUB event handler before - not even for a GUI event such as a button click? This is absolutely standard practice (indeed it is preferred over the branch label kind of handler in almost all circumstances). When using SUB handlers control returns to the WAIT statement - that is precisely why I think it might be helpful, because the WAIT gets executed once but never again.
Richard. [/quote]
I thought the wait was the next instruction..
Anyway Is there any way to pop the return off the stack?
Code:
After correctly adding the sleep the speed increased
greatly on LBB run , but has +/- 2ms bounce
while LB run has +/- 0.3ms bounce
The LBB.exe has close to the same as LBB run, with
occasional spikes to 28ms
ManualTx WRITTEN ok ?Delay -NOT WRITTEN TicMS -NOT WRITTEN
LBB Run program with sleep
ManualTx WRITTEN ok ?Delay -NOT WRITTEN TicMS -NOT WRITTEN
Speed INCREASED a lot, but is bumpy +/-2MS
<12:46:05> <100> <1.657sec> <16.5msTIC>
<12:46:06> <100> <1.801sec> <18msTIC>
<12:46:08> <100> <1.773sec> <17.7msTIC>
<12:46:10> <100> <1.736sec> <17.3msTIC>
<12:46:11> <100> <1.685sec> <16.8msTIC>
<12:46:13> <100> <1.816sec> <18.1msTIC>
<12:46:15> <100> <1.762sec> <17.6msTIC>
<12:46:17> <100> <1.709sec> <17msTIC>
<12:46:18> <100> <1.688sec> <16.8msTIC>
<12:46:20> <100> <1.716sec> <17.1msTIC>
<12:46:22> <100> <1.764sec> <17.6msTIC>
<12:46:24> <100> <1.8sec> <17.9msTIC>
<12:46:26> <100> <1.763sec> <17.6msTIC>
<12:46:27> <100> <1.809sec> <18msTIC>
<12:46:29> <100> <1.867sec> <18.6msTIC>
<12:46:31> <100> <1.842sec> <18.4msTIC>
<12:46:33> <100> <1.749sec> <17.4msTIC>
<12:46:35> <100> <1.73sec> <17.2msTIC>
<12:46:36> <100> <1.771sec> <17.7msTIC>
<12:46:38> <100> <1.667sec> <16.6msTIC>
---DONE-1---
***************************************************************
LB Run program with sleep
ManualTx WRITTEN ok ?Delay -WRITTEN ok TicMS -WRITTEN ok
***************************************************************
Speed stable with +/-0.3ms
<12:51:46> <100> <1.562sec> <15.6msTIC>
<12:51:47> <100> <1.562sec> <15.6msTIC>
<12:51:49> <100> <1.568sec> <15.6msTIC>
<12:51:51> <100> <1.58sec> <15.7msTIC>
<12:51:52> <100> <1.558sec> <15.5msTIC>
<12:51:54> <100> <1.559sec> <15.5msTIC>
<12:51:55> <100> <1.567sec> <15.6msTIC>
<12:51:57> <100> <1.567sec> <15.6msTIC>
<12:51:58> <100> <1.555sec> <15.5msTIC>
<12:52:00> <100> <1.562sec> <15.6msTIC>
<12:52:02> <100> <1.569sec> <15.6msTIC>
<12:52:03> <100> <1.565sec> <15.6msTIC>
<12:52:05> <100> <1.571sec> <15.7msTIC>
<12:52:06> <100> <1.562sec> <15.6msTIC>
<12:52:08> <100> <1.56sec> <15.5msTIC>
<12:52:09> <100> <1.564sec> <15.6msTIC>
<12:52:11> <100> <1.563sec> <15.6msTIC>
<12:52:13> <100> <1.564sec> <15.6msTIC>
<12:52:14> <100> <1.579sec> <15.7msTIC>
<12:52:16> <100> <1.566sec> <15.6msTIC>
---DONE-1---
|
| « Last Edit: Dec 28th, 2017, 5:16pm by xtal » |
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: LBB runs 7 times slower than LB on my GBRL-Sen
« Reply #60 on: Dec 28th, 2017, 5:52pm » |
|
on Dec 28th, 2017, 5:13pm, xtal wrote:| Is there any way to pop the return off the stack? |
|
Not too sure what you mean. What are you trying to achieve?
Quote:After correctly adding the sleep the speed increased
greatly on LBB run , but has +/- 2ms bounce
while LB run has +/- 0.3ms bounce |
|
By "bounce" do you mean 'jitter'? Jitter of that order is entirely to be expected.
If you are wanting LBB to behave identically to LB you are going to be disappointed. Indeed your other problems (font issues and 'non-displaying' textboxes) are caused by you making insufficient allowance for predictable variations between platforms, and you would likely see similar 'failures' if you ran your program in LB but under Wine rather than Windows. Even a different version of Windows or a different 'theme' setting might be sufficient. Modifying your code so that it works in LBB as well as LB will make it generally more reliable! 
Can we draw this thread to a close now?
Richard.
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: LBB runs 7 times slower than LB on my GBRL-Sen
« Reply #61 on: Dec 28th, 2017, 6:01pm » |
|
I have locked this thread because the original reported issue ("LBB runs 7 times slower than LB") has been resolved. Other issues are best raised in a new thread.
Richard.
|
|
|
|
|
