Hello Guest it is April 15, 2024, 11:50:24 PM

Author Topic: VB execution Speed  (Read 8035 times)

0 Members and 1 Guest are viewing this topic.

VB execution Speed
« on: July 20, 2013, 02:30:18 AM »
Hi, i have a 3d router and i have written a script for 3d digitizing, it works, but is very slow. My machines runs pretty fast when it cuts.

Maybe a better computer? but i am unable to understand why the speed of cutting is greater (10 times greater) on the same computer.
I have windows 7, 32 bit, 4 GB of ram, Intel core duo 2,56 Ghz. I use parallel port.

I Have tried to change kernel speed in mach3.
The script contains ~300 lines of code (including some comments).
The script compute the next move based on the state of touch probe (1 or 0) at the end of the anterior move.
All the coordinates are stored in some variables, and from time to time, are written to a file.

What do you think the problem is ? how can i increase the speed of a VB script execution?

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: VB execution Speed
« Reply #1 on: July 20, 2013, 04:32:25 AM »
By it's very nature a probing routine is a series of very short moves and direction changes and therefore will always be "slow" - that's the nature of mechanical digitizing. Trust me - the script engine is running waaaaaaaaaaaay faster than your machine ever can - it (the script) will be spending most of it's time doing nothing whilst it waits for the machine to catch up.

OK - you (might) say - but if I CUT a shape made up of lots of small lines it cuts faster - why? - that's because Mach is a "planner" i.e. it has the ability to "lookahead" but it can't "plan" (dynamic) digitizing moves because each move has to be calculated on the fly based on the result of the previous probe result. That said, even a "non-dynamic" regular bed of nails probe can not be planned either for obvious reasons.

Ian
« Last Edit: July 20, 2013, 05:10:49 AM by stirling »

Offline ger21

*
  • *
  •  6,295 6,295
    • View Profile
    • The CNC Woodworker
Re: VB execution Speed
« Reply #2 on: July 20, 2013, 06:18:15 AM »
Also, you can specify the feedrate of your probing moves. Have you tried increasing the feedrate?
Unless your machine is literally not moving while the script is doing calculations, the feedrate could be the issue?
Gerry

2010 Screenset
http://www.thecncwoodworker.com/2010.html

JointCAM Dovetail and Box Joint software
http://www.g-forcecnc.com/jointcam.html

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: VB execution Speed
« Reply #3 on: July 20, 2013, 10:18:30 AM »
IF you write the probing sequence in GCODE (no CB ) it will run much faster and be more stable..

(;-) TP
Re: VB execution Speed
« Reply #4 on: July 20, 2013, 02:17:39 PM »
BR549, how to write the probing sequence in GCODE? (in Mach3) can you give me an example? i have tested the plug-in that creates GCODE for scanning, but is slower than my script, because it makes a lot of useless moves  ... (bed of nails?!)

ger21, i have increased the feedrate, but no luck. If i decrease the speed below a certain value, it slows down.


stirling, thank you for the explanation. I was thinking that Mach3 is "has the ability to "lookahead"" and that is why is much faster when cutting (but i wasn't sure).

I will experiment more and write down the conclusions here...

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: VB execution Speed
« Reply #5 on: July 20, 2013, 04:41:49 PM »
All you have to run in mach3 is the bed of nails and a couple of hybrid senarios written outside of mach3.

In mach3 you do NOT have a "fast"  option like you do with other controllers.

Doing the code in G CODE allows Mach3 to USE the look ahead buffer to an advantage.

I have written a Gcode only crawler type for surface scanning using subs and variables BUT it is not fully tested and I have no intention to finish it it was just a test to see IF it could be done. I ran into the "almost but not quite able to finish" because of glitchs in mach3. AND workarounds were out of the question. I was THIS close,(;-) but without a SAFE mode for the probe you run the risk of crashing the Probe. It never crashed with me BUT I can see the possibilty of it doing so.  AND the Gcode side of probing can runs  as fast as you can run your machine. Super Fast Z acelleration is required for fast 3d probing not fast speed as most of the time you are never going to hit rapid speeds you are stopping and starting most of the time.

Just a thought, (;-) TP
« Last Edit: July 20, 2013, 04:47:01 PM by BR549 »
Re: VB execution Speed
« Reply #6 on: July 20, 2013, 11:22:56 PM »
if i make less cals to getOEMDRO(*********) it goes 2-2,5 faster

I think that the problem is somewhere around these specific commands and VB. The communication is not so fast. The best way is to store as much values as possible in variables, and only use special commands when needed.

I have achieved somewhere around 15 points per second at a precision of 0,03 mm, if i can double the speed is perfect
Re: VB execution Speed
« Reply #7 on: July 21, 2013, 12:37:31 AM »
how can i stop the machine in the middle of the movement?
let's say that i gave this command from script Code "G0 X500 " and now i want to stop the machine because the probe hit the object

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: VB execution Speed
« Reply #8 on: July 21, 2013, 04:29:16 AM »
how can i stop the machine in the middle of the movement?
let's say that i gave this command from script Code "G0 X500 " and now i want to stop the machine because the probe hit the object

You can't. That's why the gcode fairy gave us G31.

Doing the code in G CODE allows Mach3 to USE the look ahead buffer to an advantage.
Interesting comment Terry. I fail to see how the planner can lookahead over a G31 when by definition it has no idea in advance where it's going to stop?

Ian

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: VB execution Speed
« Reply #9 on: July 21, 2013, 10:26:11 AM »
AH but it does . When you call a G31 X10 the planner plans  to go to X10 . When the trip is done it is an "interupt" signaling mach to go to the next line.

That is also one of MAch3 problems when it gets to the end of the call "X10 "it should NOT write to file as that would be a phantom value, It at least could write an error code to signal a positional error with a g31 call.

If you want a faster "write" use the M40 "Create write file" then mach will write the trip values internally to the file WHICH should be  much faster than a script writing to a file.

Just a thought, (;-) TP