Re: Backplot issues

[Ray <rehenry-at-up.net>]

Chris

We briefly discussed back plotting before I wrote tkbackplot.tcl and I
was left with the idea that one advantage of plotting from the real axis
values shown by tkemc would be that it would come close to showing the path,
including accel/decel and such.  

At that time there was no freqmod and steppermod did not overload most
computers unless you entered extremely large values for input scale.  I
admit to being no programmer at all.  And I admit that my way of colorizing
the lines is marginal at best and does not work at all with MDI and has some
problems with the latest itterations of tkemc.  

And as you have found, tkbackplot can only work successfully when the
PC running the EMC is able to keep up with realtime motion processes, task
and I/O processes, and the added burden of the Tcl/Tk code involved with
backplot.  The Tcl/Tk approach that was taken then could be made less
labor intensive by writing much of it in C.

The backplotter as upgraded by Paul and Ian has some advantages.  It
creates single entities from sets of points that lie along a vector and it
can zoom and rotate a plot while maintaining much of the original features.
And it can run alongside tkemc on many monitors.  But here again, it
suffers from those systems that lack sufficient computing power.

Perhaps it is time that we write a third backplotter that runs a part
program through the interpreter but uses the cannonical interpreter output
to directly plot to a screen widget.  It would be primarily a code
visualizer but perhaps that is all that most of us need. 

I believe that it would be nicest, if we were able to gain access to this
visualizer from within a running EMC but we would need to develop a way to
suspend the operation of the motion modules while it was working.  I can
imagine Fred and Will getting instant headaches here but this would allow
Linux to redirect processor power to the visualization routines.

It would also be possible to write a Tcl/Tk script that fires up the
interpreter in an almost stand alone mode, feeds it the file name to
interpret, and generates a canvas widget display or a dxf like file
of the commands issued by the interpreter.

We could also write a little realtime process that creates a file of the
tool path.  We could then simply submit this file to the visualizer widget.
This approach would further burden a PC running the EMC.

Comments please

Ray


On Sun, 10 Jun 2001, you wrote:
> I was using tkbackplot to preview a 2 axis milling toolpath yesterday,
> and getting some frustrating results.
> 
> The main problem seems to be that my stepper setup slows down the
> computer a lot, and so the tkemc display updates infrequently.  It
> seems that backplot perhaps connects the points at which the
> coordinate display updated or something, because I get horribly
> rounded and distorted corners in the backplot window, while the actual
> machine makes quite nice corners.  I tried increasing the acceleration
> to insane values (20) since the stepper system moves slowly enough
> that it isn't needed, but it really seems the problem is with the
> display, not with the trajectory planner.
> 
> The problem gets worse if I am trying to preview with the stepper
> drive turned off and the feedrate override cranked up.
> 
> So my questions:
> 
> 1) is there any easy fix to the distorted corners on the display?
> 
> 2) is there any way to use tkbackplot to rapidly but accurately
> preview the toolpath?  I'm thinking of some way of running it offline,
> as opposed to simply disabling the drives and cranking the feedrate,
> which wouldn't work on a closed loop machine anyway.
> 
> Chris
> 
> -- 
> Christopher C. Stratton, stratton-at-mdc.net
> Instrument Maker, Horn Player & Engineer
> 22 Adrian Street, Somerville, MA 02143
> http://www.mdc.net/~stratton
> NEW PHONE NUMBER: (617) 628-1062 home, 253-2606 MIT