Trajectory Planner Control

[sdavenport]

I'm running a plasma cutter and doing the pierce routine on the pc side with VB6 and Kmotion_dotnet. The cut vectors are in a gcode file. I upload the gcode using ctrl.Interpreter.Interpret_2 path & file which also starts the motion. Everything works fine unless the gcode file is large. If it is large then there is too long a delay before motion starts which causes the arc to fail. Is there some way to upload the gcode and prevent the trajectory planner from executing it so that it will be ready to run immediately after piercing is done? I put an M00 in the beginning of the gcode which stopped the motion but I don't know how to resume. I also tried StopImmediate0 which works but needs to executed just before the trajectory planner starts motion. I am sure there is a simple way to do this.
Thanks, Shannon

Similar Threads:

• New Trajectory Planner - Testers/programs wanted
• Trajectory Planner Break Angle question
• What values are the velocity and acceleration in Trajectory planner?
• Need Help!- Trajectory page
• Trajectory planning of EMC 2.0

[TomKerekes]

Hi sdavenport,

I'm not sure I understand. The Interpreter should not really "load the file". It should just start interpreting lines, trajectory planning them, and then after it has several seconds of motion planned and downloaded to KFLOP the motion should start. If the first few GCode Blocks are long lines or arcs then the motion should start very quickly. If there are thousands of tiny vectors at the beginning it may take longer. The overall total size of the file shouldn't matter. Is this what you are observing? What size of delay are you observing?

But besides this could you trigger your "pierce" somehow from the GCode?

Maybe an M Code in the Gcode could be written to wait until the pierce is complete?

What does the pierce operation involve and how long does it take?

(sorry for all the questions).

Regards

[sdavenport]

Hi Tom,
The file I'm testing with is the spiral that is in your Gcode Programs folder and it has just over 1000 tiny vectors.

The delay looks to be a little more than a second.

The pirece is as follows:
move down until contact with work - bit(78)
move until not bit(78)
move up to pierce height
start plasma
wait for arc ok - bit(79)
wait for pierce time
move down to cut height
start motion - and this is where the delay is occurring
I thought I might try (CMD setpersistdec 0 1) at the beginning of the gcode watch for it in vb, stop the motion, do the pierce, start the motion. Will the setpersist work with CMD?

Thanks Tom,
Shannon

[sdavenport]

Hi Tom,
The delay in motion starting with many tiny vectors in the beginning is proving more difficult to overcome than I thought. I was able to set a flag in the beginning of the Gcode and prevent motion from starting. But there is still the same start delay after I "StopImmediate1". I also tried setting the feedrateoverride to a very low value and then back to normal after pierce but again the same start delay. I understand that the trajectory planner recalculates whenever a change in velocity is made. Is there any way to have the TP calculate a path for a given speed and then just wait until told to go?
Thanks, Shannon

BTW - I timed the delay with the spiral and it is 1.31 seconds and only when starting in the center of the spiral.

[TomKerekes]

Hi Shannon,

Sorry for not getting back to you sooner, I've been looking at various options.

I don't really see the amount of delay that you do. On my system the delay is hardly noticeable. Maybe 0.1 seconds. So I don't understand why you are seeing so much delay. Setting the minimum amount of buffering (I'm using 3 seconds) will help. Also the other Trajectory Planner Settings will have an effect. I'm using Facet angle of 1 degree, corner tolerance 0.003, collinear tolerance 0.001. My XY max velocity is 10 ips and acceleration of 30ips2.

However regardless, I don't think this approach will ever work reliably. Whenever the PC and MS Windows is involved things will never be 100% real-time. Once in a while there will be a delay and a problem.

We added a new feature that should help. Previously we added buffered output commands (SetBitBuf and ClearBitBuf) to be passed through the Trajectory Planner, through USB, and through the Coordinated Motion Buffer in KFLOP so to be executed exactly in sync with any motion. Two new buffered commands have been added (WaitBitBuf and WaitNotBitBuf) that will hold the execution of Coordinated Motion until an IO bit (or Virtual IO bit) is at the specified level.

So for example the beginning of the Spiral Gcode would be changed as:

g20 g64
s3400 m3 F400
(BUF,WaitBitBuf46)
g1 x1.724638 y-1.012731
x1.613302 y-1.178668
x1.486083 y-1.332506
x1.344282 y-1.472733
x1.189344 y-1.597975
x1.022843 y-1.707013
x0.846464 y-1.798789
x0.661990 y-1.872422


To get guaranteed response your pierce program should be written in C and set bit 46 when the motion should be allowed to start.

To have access to the new feature you will need to use this new Version4.30a

HTH

[sdavenport]

Hi Tom, thank you for for getting back to me. The delay was no inconvenience at all. Your tech support is invaluable and and the best I've ever seen. I don't know how you have time to answer everybody's questions.

I did tried burning several other jobs with my plasma cutter one had >6000 small segments (converted from splines) and the delay was as you observed in <100ms and it did not cause any problems. The worst I've seen is that spiral and only on the center. I will implement your new, (BUF,WaitBitBufnn). I'll need to modify the Version4.30a source code and rebuild it to use COM in VB6
Shannon