Re: [Emc-developers] Patch: Phase drive algorithm (emcmot.c)

[Fred P. <fre...@ni...>]

EMC developers,

Lawrence Glaister ("Machine Control Operator") wrote:

> I have attached a patch for emcmot.c that I would like the group to
> comment on. I have added a second
> method of stepper phase drive that could be modified to directly drive
> 3,4 or 5 phase steppers directly. Also,
> I changed the original phase drive code to get it working with my phase
> drive system. Both routines have
> been tested on hardware phase drive  (with steppers) and work in a
> similar fashion. One can change stepper
> drive algorithms by using the STEPPING_TYPE var in the emcmot section of
> the ini file. STEPPING_TYPE=2 will select the new algorithm. Although I
> have developer access to the cvs, I would really prefer someone else to
> review and update the cvs with this patch (Will?, Fred?) as I am still
> quite a nubie on the devel team.

Looks good to me. It's consistent with the previous method, using
STEPPING_TYPE to select between algorithms, and it's tested, so we'll go
ahead and patch the file. I don't know if any changes have been made to
emcmot.c since you generated the patch. If we have problems we'll get
back.

> Another question for the team: I found that servo tuning in EMC lacks
> tools to see the results of changes... I am considering writing a
> standalone app that graphically displays the results of tuning gains.
> The idea is to  oneshot capture a move and record the drive component
> values, position, velocity, following error  and composite drive for the
> move. This would info would get stored in shared memory on the realtime
> side and read by the display frontend. It used a similar system for
> tuning hydraulic linear positioners in my previous job. Has anyone else
> strayed along this path? The gstripchart code doesnt quite make it. It
> looks like the logging function is about the closest model to what I
> want to do, but I have not tracked down how to get the plot button to do
> anything. Additional data would be required for logging the realtime
> valve drive components.

I've used the logging function to log and plot the commanded v. actual
position, and also following error. The logging works fine, but the
plotting is broken. I used xgraph to plot the points, using the system()
command in xemc to pass a Unix command line with xgraph and a bunch of
pipes to plot the files. It doesn't work in tkemc, since I couldn't
figure out how to compose the string to pass to exec.

It shouldn't be too hard to fix this, using Tcl/Tk plotting directly
rather than going through a shell call to xgraph. This would eliminate
the need for the xgraph program, which isn't part of the Red Hat
distribution.

The procedure was to start logging, do an incremental jog, save the log
to a file, and plot the file. It's almost all there except the plot
button in tkemc, but run xemc and you should see the result.

Anyone want to update tkemc.tcl to incorporate plotting of point files?
That's all that needs to be done to  be back in business.

> One more addition I found very useful, was to modify Tkemc to add  a jog
> option of 1" increments...
> when tuning the servos, clicking on jog + and jog - gave an easy way to
> move and check the results of the tuning parameter changes. I can
> forward a patch for this as well, although the implementation is only a
> few lines.

Yes, nice to have.

> I ran the new interpeter, and it does have a few quirks... one obvious
> one is that after completing  a program like cds.ngc, one needs to use
> the File/rest menu option before the program can be rerun. 

When I run a program, I can hit the "run" button repeatedly. Even if I
change the file on disk, I don't need to reload: I can hit "run", and
the new file is run. Can anyone confirm this?

> Another
> annoyance, is that when a following error or other fault occurs, the
> program listing in the lower window jumps to the end of the program
> (most of the time). It is really handy to leave the "cursor" on the line
> of code that was executing at the time of the fault. Even if restarting
> is not possible, it may help point out a bad choice of g code sequences
> that caused the fault.

Yes, annoying. We'll look into fixing this.

--Fred