search

gerritv / Grbl-Panel

A control panel for Grbl
MIT License
180 stars 102 forks source link

V1.0.9.0a send gcode have a time delay #47

Closed viewsat closed 8 years ago

viewsat commented 8 years ago

Thank you! Read 1M line less than 3 seconds, very fast. I sent Roy Rogers Metric.nc this gcode, Use V1.0.7.0 send 100 line 2 seconds, Use V1.0.9.0a send 100 line 8 seconds,

Sorry, my English is not good.

rwensley commented 8 years ago

Gerrit, Some additional information on this issue. The data grid shows the present line being processed and sent to grbl. When a line is sent, on the left the Run/Idle box changed to Run. grbl makes the move, the Box changes to Idle. The next line on the data grid is sent. Repeat. Very slow process. It appears that the buffer in grbl is not be utilized but I am unsure.

I have a gcode file I was running yesterday that is 475k ish lines long. After 6 hours it was at line 35000. Then the program, grbl panel, crashed. There were several hundred pop up windows that said something like Unexpected communications error. Unable to recover.

You are creating an excellent program here and I am sure it is time consuming. I for one appreciate your effort and time you dedicate to this.

Thank you, Ron Wensley

gerritv commented 8 years ago

The question is, was this the same behavior as with pre-1.0.9.0? My testing with Grbl 0.9j (default spindle pwm enabled) and 1.0.6.0 as well as 1.0.9.0a are the results are similar. I also tried Thoralts 'byte stuffing prototype' to see if it was a problem with no getting the buffer full enough. Not a big improvement there either. Grbl does recomputes and a resulting delay on spindle speed changes. The RoyRogers file is littered with S records.

I removed all screen updates from 1.0.9.0a, same slow result. My laptop is an HP4520S, with i7 cpu. I don't see the Idle symptom not comms errors although the Buffer indicator is seldom more than 1 light. Not sure what to make of this yet. I don't run UCS so can't compare it's behavior. I will try with 1.0.7.0 soon.

rwensley commented 8 years ago

If the problem existed prior to 1.0.9.0 it was not noticeable. I used 1.0.7.0 and it was fast and did not fail on comma issue.

rwensley commented 8 years ago

Gerrit,

I just loaded 1.0.7.0 and it sends the code fast. Perhaps this will help.

Ron

gerritv commented 8 years ago

Thx, that will help I think. can you email me your file? Email address is on my GitHub page. Thanks

gerritv commented 8 years ago

One observation, the RoyRogers file is very different machining from Ron's file. The RoyRogers example uses S blocks to (I assume) control a laser output. S blocks cause a delay int he current version of Grbl. I think the 1.0 version will have a different method available for laser use of S blocks. But the performance difference is probably still related to what Ron is seeing as well.

Ron's file is 'normal' in that it is not relying on S blocks. My test so far with 1070 and 1090a are that the Buffer (Q display) is full at all times, which is a good thing. No comms errors so far (at line 4000)

Ron, what kind of machine are you running on? Did you try 1080 as well? Between 1070 and 1080 I changed the serial read code, 1080->1090 I changed the gcode display code. It will help me if I know which one to chase down :-) Thank you for your patience while I figure this out.

gerritv commented 8 years ago

Ron, also can you list your settings, esp the steps/mm, accel, etc. I need to duplicate your environment as best as possible. Presently I am using Grbl defaults which as quite slow.

rwensley commented 8 years ago

Gerrit,

Your work is appreciated so do not feel pressured to fix this. I am benefitting from your generosity so I am sure I can be extremely patient.

400 steps/mm on XYZ 2000 mm/min max rate 100mm/sec/sec acceleration rate 270 mm max travel on X and Y 80 mm max travel on Z

I have not tried 1.0.8.0 however; I can tonight after work if it will help.

At some point if you post your Paypal account name I will donate some funds to this cause.

Thank you, Ron

rwensley commented 8 years ago

Gerrit,

I just tested v 1.0.8.0 here is what I observed Upon connection a > symbol appears to the right of the Z position value File loading is about the same speed as previous version (slow) Run results in a pulsating send speed. 20 or so lines will go real fats then a pause (500~ms) then slow for a 5 to 10 lines, then a pause, then fast for 20 or so...Repeat.

I hope this helps.

Ron Wensley

gerritv commented 8 years ago

Well, this is fascinating:(minutes/seconds/parts of seconds). I configured my Grbl to Ron's settings. 1.0.9.0a 1000 lines of Ron's file: 1:21:3172 1.0.7.0 1000 lines of Ron's file: 1:20:7329 Although visually 1.0.7.0 visually seems faster due to fewer stumbles/delays at certain points

Not sure where to look next, will try a few ideas but difficult when I can't reproduce the scenario :-(

rwensley commented 8 years ago

Gerrit,

I have two videos I took one of 1.0.7.0 and the other of 1.0.9.0a running the same file (the one I sent you). The machine speed is much slower with 09. The files are 75M and 47M respectively. GitHub limits attachments to 10M

If you would like to see these vids I will need a place to send them to.

Thanks for your work.

Ron

gerritv commented 8 years ago

I believe you, I just am not seeing it myself. Very frustrating. I used the Grbl settings that you gave so that the 'machine' is the same. What OS and Cpu are you on? I am on Win 10, i7 cpu. I can try to get my Atom powered Win 8 machine running if that is a closer match.

gerritv commented 8 years ago

Ron, can you time the first 1000 lines on your file for me? Thx

rwensley commented 8 years ago

My machine is an HP laptop WIn10 AMD Turion X2 dual core at 2GHz 8GB ram As to timing it will be done be guess with a second hand. Not very accurate.

rwensley commented 8 years ago

Okay. Not taking into account my reaction time I used the stop watch on my cell phone as a time. 1000 lines of gcode was timed the same file was used both times vs 1.0.7.0 took 1:19.9 vs 1.0.9.0a took 3:47.26

gerritv commented 8 years ago

That is very interesting indeed. At that difference .5 seconds or two lost on reaction time has no impact. On my machine/PC I am at the 1:20 range for both 1070 and 1090a. I will try another machine to see if I can reproduce. I might revert the serial IO code back to 1070 version so that I am not on anyone's critical path.

Mac2712 commented 8 years ago

gerritv and rwensley why not allow others to download the file then we could test the same file and give you some more feedback. I for one have no problems helping test this.

rwensley commented 8 years ago

Not a problem.
CDbrooks.cnc.txt

Mac2712 commented 8 years ago

Ok just run the file a couple of times and averaged the results quite interesting.

setup of GRBL as above

1.0.7.0 took 1:14.2 1.0.8.0 took 1:14.3 1.0.9.0a took 2:58.7 and just for comparison UGS took 1:14.6

I ran them with steppers but not attached to anything and 1.0.9.0 was not as smooth as the others

rwensley commented 8 years ago

My results are very simular and the jerkiness in 1090 is strange.

Thanks for verifying. I would hate to find out it was my machine and I had cause Gerrit to go on a wild chase.

gerritv commented 8 years ago

Thanks for the confirmations. That means the problem is with the move to using DataGridView, not serial IO. This is more challenging to fix as going back to ListView for the Gcode display means eons of waiting for a file to load. I couldn't get hold of 'the other machine' tonight, Saturday should be ok to see if I can get it reproduced on a less powerful cpu. I did learn about the profiling tools in Visual Studio though, which are very useful. And free.

gerritv commented 8 years ago

I think I have solved the performance issue. Can someone please test using http://psgv.ca/Files/Release1090aTest.zip This has some instrumentation as well, after 1000 lines it displays the elapsed time in the MDI box. CPU usage was cut to less than half on my machine.

Thanks.

Mac2712 commented 8 years ago

Good news is its taken the same time as previous versions bad news there are a lot of Unhanded exceptions as below

\ Exception Text ** System.ArgumentException: Column named status cannot be found. Parameter name: columnName at System.Windows.Forms.DataGridViewCellCollection.get_Item(String columnName) at GrblPanel.GrblGui.GrblGcodeView.Rewind() in C:\Users\gerrit\Documents\My Projects\GrblPanel-master\Grbl-Panel\GrblGcodeView.vb:line 239 at GrblPanel.GrblGui.processLineEvent(String data) in C:\Users\gerrit\Documents\My Projects\GrblPanel-master\Grbl-Panel\GrblGcode.vb:line 283 at GrblPanel.GrblIF.raiseAppSerialDataEvent(String data) in C:\Users\gerrit\Documents\My Projects\GrblPanel-master\Grbl-Panel\GrblIF.vb:line 312 at GrblPanel.GrblIF.VB$StateMachine_45__client_ComReadData.MoveNext() in C:\Users\gerrit\Documents\My Projects\GrblPanel-master\Grbl-Panel\GrblIF.vb:line 282 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.b__6_0(Object state)

This one is when you jog and it repeats the command continuously \ Exception Text ** System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource) at GrblPanel.GrblGui.GrblGcodeView.UpdateGcodeSent(Int32 index) in C:\Users\gerrit\Documents\My Projects\GrblPanel-master\Grbl-Panel\GrblGcodeView.vb:line 208 at GrblPanel.GrblGui.GrblGcode.sendGCodeLine(String data) in C:\Users\gerrit\Documents\My Projects\GrblPanel-master\Grbl-Panel\GrblGcode.vb:line 113 at GrblPanel.GrblGui.btnJogArray_Click(Object sender, EventArgs e) in C:\Users\gerrit\Documents\My Projects\GrblPanel-master\Grbl-Panel\GrblJogging.vb:line 62 at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

gerritv commented 8 years ago

I'll sort those out shortly, hadn't seen them when running inside VS. They are from the M30 handler, rewinding the gcode. Thank you for confirming the main goal, performance!

Interesting that the actual performance problems were not in the DataGridView updating code as I had thought. Proves once again that without profiling tools you really can't tell what is going on where in your code. Thankfully VS 2015 CE has free profiling tools built in.

gerritv commented 8 years ago

I think this is the final candidate of this fix. http://psgv.ca/Files/Release1091Test.zip @rwensley , @Mac2712 , @viewsat I will wait for your verdict before pushing the code onto GitHub.

The 1000 line timer indication in MDI is still there for your convenience.

Thanks for your help

Mac2712 commented 8 years ago

OK I have tested this version and found its running the test file in 1.15.8 very close.

viewsat commented 8 years ago

I'll tell you tomorrow Release1091Test.zip test results.

viewsat commented 8 years ago

I tested Release1091Test using win10 (64bit) and win7 (32bit), [Sts] showed some problems, send gcode good speed, but after the end of the send gcode, sometimes can not work. See yotube video. https://youtu.be/sfuvmwuEGkc

gerritv commented 8 years ago

Thank you, the video showed the Sent/Ok in Sts column very well. I will look into the strange behavior of Sent/Ok when you resize. I saw also that there is a > in the Z position display, are you using an older Grbl 0.9? What is your $10 set to? Are you happy with the speed compared to previous 1.0.9.0 version?

gerritv commented 8 years ago

Sent/ok mess in Sts column is fixed.

viewsat commented 8 years ago

I use grbl 0.9j. Sent / ok mess is not fixed, sometimes when I resize mess, sometimes do not mess.

gerritv commented 8 years ago

Sorry, I was not clear. I fixed it in my version, not released yet :-)

The > will go away if you set $10 to 15, this will show the Q and Rx indicators.

viewsat commented 8 years ago

I'll do as you say set grbl $ 10 to 15.

gerritv commented 8 years ago

Fixed, at last :-( Thank you for your assistance in narrowing this down. I have saved some performance traces for comparison in the future.

rwensley commented 8 years ago

Thank you Gerrit! I will check it out tonight after work and let you know what a great job you have done.

Ron

-------- Original message -------- From: Gerrit notifications@github.com Date: 02/18/2016 09:22 (GMT-06:00) To: gerritv/Grbl-Panel Grbl-Panel@noreply.github.com Cc: rwensley ronwensley@live.com Subject: Re: [Grbl-Panel] V1.0.9.0a send gcode have a time delay (#47)

Fixed, at last :-( Thank you for your assistance in narrowing this down. I have saved some performance traces for comparison in the future.

Reply to this email directly or view it on GitHubhttps://github.com/gerritv/Grbl-Panel/issues/47#issuecomment-185771855.

gerritv commented 8 years ago

I am not totally happy with the solution, the X position doesn't update nicely and the Q/Receive Buffer indicators lag. But the key thing, speed, seems to be back.

More tinkering ahead.....