Forum Replies Created
-
Sorry, missed your post.
To understand PWM spindle setup have a look at this:A quick answer, set $p1pof=0.0, then issue an M5 Gcode command.
You spindle should spin down to orpmArc issue, Z axis travel issue, or both?
Did you try these Gcodes:
Please post an fresh $$ dump
By the way, your Z axis motor is direct drive, correct (not belt drive)?
Bill
Thanks for your expanded description of your objective. What you describe is in fact what I assumed you were attempting to implement, so we are relatively in synch with this discussion.Here is how I would ask this question of the developers:
” During a G28.2 homing cycle, can a status report be generated that reports the axis position at the instant a homing switch is operated, before the position value is reset to = 0 as the axis completes homing clcle.
Use Case: Consider a homing cycle initiated when a previously homed machine is at arbitrary position X1, Y1, Z1. The value of X position when the $xsn operates should be (-$Xlb) if the machine has been perfectly tracking since the original homing cycle. If not, the machine has drifted and requires maintenance ”
If you understand and agree with this wording ( a bit clearer at least to me what you need), post (or modify and post) the question here:
That is where the developers hang out
Assuming you can get the position information you desire, keep in mind a couple of obvious error sources that you will have to deal with:
A. The difference between mechanical operate/non-operate position in your homing switch. The zero point is actually $xzb away from the non-operate point, but you would get the operate point from the status.
B. The accumulation of moves smaller than the finite resolution of the machine(the distance each axis moves when a step is sent to the motor controller)Comments
1. Plenty of accuracy
2. Changing the number of microsteps to 4 produced the correct results.
TinyG computes the travel per microstep, then uses that value to determine how many step pulses to send to the motor driver. The motor driver is programmed by tinyG as to how many microsteps per step. So in this case tinyG sent half as many steps to the Z driver, but each step moved twice as far on each step pulse.Two issues are still to be worked: arc misinterpretation and the incorrect relationship between $3tr and reality; the Zaxis will move 2mm per motor revolution, but you need to set $3tr to 8mm to get a desired 1″ move for a 1″ jog.
Let’s chase the Z axis first.
First, two more questions popped up in my head
1. Double check your motors – are they 1.8 degree Step Angle or 200 step per revolution? That is typical, but 400 step (0.9 deg step angle) do exist?
That still would not explain your necessary *4 setting of $3tr, but would introduce a /2 error.
2. Please try this mini test. Put your tinyG into mm mode (send a G21 command on the Serial Console), then jog 10 mm, 1mm at a time. We are testing to see if for some reason tinyG’s mm to inch conversion is broken. If jogging 10 times, each 1mm, only moves about 2.5mm (10/4), then the mm to inch conversion is broken.The Fix (I predict/hope)
A. Connect CP to tinyG
B. Make sure tinyG is in MM mode
C. In the tinyG Serial Port Console, send a $defa=1 command
This will clear and reset EEPROM and reset all your parameters to ‘factory default’. You might want to make a copy of $$ dump at this point so you can compare to the current parameters you just posted.
D. Now one parameter at a time, enter the desired parameters in the Serial Port Console.
E. when complete, hard reset tinyG (reset button)
F. Reconnect CP to tinyG and dump $$ again to verify your work.
G. Try your 1″ jog. If I am correct in running this ‘fix’, it will only jog 0.25″. You will then need to go back and change $3tr=2.0mm to get your 1″ move.
H. you could try one of your multi-arc jobs again. It is possible that borked EEPROM could be affecting those computations as well.Then report back.
