On Sunday 17 February 2008, Ian W. Wright wrote: >Ok, thanks Alex, > >I seem to be getting there if a little slowly. I changed the BASE_PERIOD >down to 15,000 and got an error "RTAPI: ERROR: Unexpected realtime delay >on task 1" so I changed it to 20,000 and it is running fine. > >There is one thing I can't get a handle on - the jog speed of the A-axis >now wants to go in excess of 10,000 which is way beyond the range of the >stepper (its OK up to about 2200). I changed the MAXIMUM_OVERRIDE from >the 5.0 I had it at to 1.0 and I can get all the motions under control, >however, I don't seem to be able to find a way to set the "Jog Speed" >settings in AXIS to a realistic value. Each time I shut down and restart >EMC2, they go to silly values like 10,000 degrees/sec for the angular >axis and I have to move the slider back by hand to around 2,000. Where >are these values set - I assume that they too must be a complicated >multiplication of several other values?? If so how do you work out a >suitable figure? > >Since I changed the BASE_PERIOD, the linear axes atr also moving faster >and I'm struggling to understand how the speed figures are actually >arrived at... for instance, the BASE_PERIOD is now 20,000 and for the >X-axis, the INPUT_SCALE is -400, the MAX_VELOCITY is set to 4.0 and the >speed the axis shows in AXIS when moving under a G0 or Jog is 240 - I >can't get the figures to make sense..... > >Thanks,
INPUT_SCALE is the TPI of the drive screw (or TPcm/mm?) times the number of full steps it takes to turn the motor exactly one full revolution, times whatever microstep value the drivers are set for. But that is for linear motions, I don't know what the base unit is for the A axis, one full 360 degree rotation of the table, or how far it moved per full rev of the drive screw times how many turns is a full 360. In my case, that would be 10 degrees, and 36 turns times the steppers full turn times the micro-stepping used. Perhaps this can be clarified by one of the developers here? OUTPUT_SCALE s/b the same as the input scale, changing the sign of INPUT_SCALE if the motors run backwards, or the OUTPUT_SCALE if the display runs backwards. The tables should move opposite the gui's cutter motion so the cutter motion is correct relative to the workpiece. For newbies, it would intuitively make more sense if the image of the bit was stationary except for z axis, and the wireframe of the work moved in the same direction as the table was moving, but one does get used to this moving cutter in the gui idea after a while. Again, that is for the linear axis's, the angular ones need some clarification, at least in my mind. Idea: Since the A axis is normally rotary, and the wireframe gui now does perspective corrections, maybe its image could be rotated in the plane of the table as the table is rotated? :) Try BASE_PERIOD at 1000 less each time until you see errors while running gcode. I often get a single REAL_TIME error at startup of emc, but its never happened while running an nc program. Or if the gui gets sluggish raise it a wee bit. Everything you can do to give the BASE_PERIOD a higher cycle rate makes the speed changes at the higher step rates smaller & easier for the motors to follow, so you want the lowest value there that the box can tolerate and still function smoothly. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Q: What is the sound of one cat napping? A: Mu. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
