Author Topic: Bug report: very inaccurate time estimates for vector cutting  (Read 212 times)

ianchia

  • Full Member
  • ***
  • Posts: 166
  • I like making things with my heart, hands & brain.
    • View Profile
Hi Zax,

Do you have on your radar fixing the very inaccurate vector cutting time estimate reporting? My raster engraving time estimates are usually pretty accurate. The vector cutting can be often wildly inaccurate.

For example, my current project uses speeds of 200 for vector and 1500 for rapid vector. The time estimate at 0% is 40m. The cut completed 11494 lines in 1 hour, 48min and 47sec. I made the pass twice manually and it took the same amount of time (1h48m47s) for each pass.

At 99%, the progress bar reports 36sec for completion and out of curiousity I videoed it - that final 1% physically took 3m56sec to complete. The last 1% was a 280mm wide circle for the outer border of my piece, so it shouldn't have been complicated to calculate the time remaining. The file is a DXF created using a conversion program call Able2Extract on Windows - converting a Adobe Illustrator CS6 PDF to DXF with full fidelity. It accurately displays in a CAD program called DraftSight and also correctly renders in the preview window of T2Laser (and also cut correctly.)

(I generally use the command line menu option in T2Laser but for some reason, this complex vector file gave the Convert2DXF some problems, and parts of my design disappeared when converted to DXF doing it my usual way.)

If you like, I'm happy to privately email you the PDF and DXF for further debugging, but I have noted that for me T2L reports inaccurate times on previous vector cuts. I often double the time to get a ballpark since my complex vector cuts can take 1 to 2 hours, but in this case, 2.7 times over the estimate was annoying enough for me to log a bug report. (-;

I've been thinking about the possible algorithmic approaches to improve the time estimate if you want to bounce some ideas back and forth.

All the best,

- Ian

« Last Edit: July 11, 2018, 11:14:30 PM by ianchia »

Zax

  • T2Laser
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 6000
    • View Profile
    • T2Laser
Re: Bug report: very inaccurate time estimates for vector cutting
« Reply #1 on: July 12, 2018, 05:06:02 AM »
Ian,

There are a couple of reasons the estimate would be inaccurate.

The calculations are based on the distance remaining to be traveled. It's relatively simple math based on your feed rate and acceleration / deceleration, however, I use my default values for the latter so if you've changed them in Grbl parameters it can make a huge difference on a large file. There's some black magic that can distort the estimate, as not all direction changes require slowing down, acute angles do but larger obtuse ones do not. I set an arbitrary value to determine that where in reality it's much more complex. It is an estimate after all but on larger jobs it may be inaccurate.

Grbl doesn't report when commands are complete, only when it has sent them from the input buffer to the motion planner so that's not accurate when you are down to the last few moves. It may have more or less moves still in the internal motion planner buffer but has acknowledged they were processed.

If you have a particular file, send it to me with the times you get and I will test it to see if I get closed to my estimate. When I created it I did many tests and it was close.

ianchia

  • Full Member
  • ***
  • Posts: 166
  • I like making things with my heart, hands & brain.
    • View Profile
Re: Bug report: very inaccurate time estimates for vector cutting
« Reply #2 on: July 12, 2018, 06:37:58 PM »
Thank you for your prompt response as always, Zax. I'll take this off-forum with you and if it's some funky GRBL setting I've changed, I'll add to this thread to save others from the same problem.

Best,

- Ian

nottingham82

  • Hero Member
  • *****
  • Posts: 1680
    • View Profile
Re: Bug report: very inaccurate time estimates for vector cutting
« Reply #3 on: July 12, 2018, 10:51:39 PM »
sooo what I have found is that the actual time is never higher but can be significantly lower than the estimated time.  If I run the entire job with one speed (rapid move, engrave and cut) , the estimate is accurate. 

If I use an increased rapid move speed for moves when the laser is off, it can over estimate the time in which it will take to finish.  Sometimes overshooting by hours on big projects.  I have always just assumed it was due to the algorithm computing all the moves at the engraving speed and not cutting out the time for the high speed moves, but i guess the black magic on the acceleration and decel could be just compounding because its a long job. 
Laser: 2500mw A5 eleks maker
OS: Windows 10 all in one pc
Software: T2
http://www.gearbest.com/3d-printers-3d-printer-kits/pp_290386.html Paid $160 in 2016

ianchia

  • Full Member
  • ***
  • Posts: 166
  • I like making things with my heart, hands & brain.
    • View Profile
Re: Bug report: very inaccurate time estimates for vector cutting
« Reply #4 on: July 12, 2018, 11:32:46 PM »
Is that for engraving raster jobs or vector jobs @nottingham82? I've found that that my raster is generally ok, and sometimes lower than the estimated time as you've observed. Vector jobs on the other hand are per the bug report.

Just reading your post now triggered a test idea, so I went into T2 and import my DXF file, set my vector speed to 200, rapid speed to 1500, and went into the Control Laser window. Job reports an estimated time of 27min and 48 sec. I hopped back to the main window and changed the vector speed to 300. Control Laser window reports identical estimated time. Hmmm. In the main window, change vector speed to 400. Control Laser window reports identical time. In main window, changed vector speed to **1000**. Control Laser window reports identical time...

Running T2 Laser 1.5j
Control Laser window says:

Total Lines: 11701
GCode Lines: 11691
Estimated Time: 27 minutes and 48 seconds
Total Distance: 27.8m (c27.5/r0.3)

***ZAX: Found an interesting thing. If I save a Gcode file from the main window, and then *Load* the Gcode file from the Control Laser window, I get different results for "Estimated Time".

Repro steps:
1. Import DXF
2. Set Vector Feed rate to 1000, Rapid Feed to 1500.
3. Save Gcode file (called it Gcode_VF1000.nc)
4. Set Vector Feed rate to 200, Rapid Feed to 1500.
5. Save Gcode file (called it Gcode_VF200.nc)
6. Go into Control Laser window. No Gcode file is autogenerated by T2 Laser.
7. Imported DXF file reports "Estimated Time: 27 minutes and 48 seconds"
8. Menu "Machine" > "Load G-Code" ... load the Gcode_1000.nc file
9. Control Laser window reports "Estimated Time: 27 minutes and 48 seconds"
10. Menu "Machine" > "Load G-Code" ... load the Gcode_200.nc file
11. Control Laser window reports "Estimated Time: 138 minutes and 59 seconds" <<<<<<<


Zax

  • T2Laser
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 6000
    • View Profile
    • T2Laser
Re: Bug report: very inaccurate time estimates for vector cutting
« Reply #5 on: July 13, 2018, 06:58:34 AM »
Wow that is interesting, I will check the calculations - something is obviously not right. Thanks for the detective work!

*edit: I don't see the same problem, when I change vector speeds it calculates correctly... more investigation required.
« Last Edit: July 13, 2018, 07:12:01 AM by Zax »

ianchia

  • Full Member
  • ***
  • Posts: 166
  • I like making things with my heart, hands & brain.
    • View Profile
Re: Bug report: very inaccurate time estimates for vector cutting
« Reply #6 on: July 13, 2018, 03:28:36 PM »
*edit: I don't see the same problem, when I change vector speeds it calculates correctly... more investigation required.

My least favourite category of bug - the nonrepro. Let me know if you need other system info. Iím running Win10Pro and an original A3 Eleksmaker with an L7 board and their supplied Arduino clone board. Default 1.1e firmware and the Trinamic 2130 stepper drivers. (The time estimate bug was exhibited with the stock driver boards as well as the Trinamics). The original laserís been swapped out w the 2W TTL module that you recommended in an old thread, but I doubt that matters.

Take your time Zax. No hurry on this bug (no pun intended).

- Ian
« Last Edit: July 13, 2018, 03:30:10 PM by ianchia »