Spindle Step/Dir servo ramp down before stop on M stop command.

More
18 May 2021 20:22 #209395 by NoJo

HOME ALL > C rotates to index, stops momentarily ,shoots past, oscillates, converges to index and stops. Axes all show home icon

That was better before, I think?

No - that has remained unchanged - I tamed it down in previous tests by reducing MAX_OUTPUT to below 5 in the ini - but the inherent issue remains.

M101 > Jog works on all axes, C does not rotate but DRO changes.
To be expected, really. Add "setp axis.c.jog-enable 0" to M101 and "setp axis.c.jog-enable 1" to M100 to fix that.

Just to be sure I explained correctly the issue - When executing M101, I understand we should disable the C Axis mode, and are in 'normal' spindle mode, ie, M03 S1000 will now run the spindle @ 1000rpm as normal, so the C axis SHOULD NOT jog in M101 -
What do those added lines do? Presume the '0' disables and the '1' enables - but what is enabled/disabled? The jogging of the physical axis, or the DRO? Or both?
I would have thought the intent in M101 is that the C axis is simply disabled - no jogging of the axis or the DRO,ie, sort of a basic 2 axis lathe..

I may also not have been clear on 'Not jogging anymore' issue - NONE of the Axes physically jog anymore when a M100 is executed, so will the the line setp axis.c.jog-enable 0/1 enable jogging of the x and z axes?

M100 > C does not home but rotates to DRO setting = 270deg, rotate is very fast and oscillates about 270deg, to standstill.
That's odd.
It is starting to look like my idea for a simple way to do this wasn't very good.
I think you had something usable about 2 iterations ago, and it has got worse since?


No, not really - since where the C axis began to 'work', the oscillation has been present when entering M100.
I did not fix that, merely tamed it by limiting the PID MAX_OUTPUT, but
I still don't understand the reason for the oscillation - it is fast, so not good mechanically, and has been there from the first iterations where the C axis started to work - must be to do with the PID being unhappy with entry conditions - If we know that we should be able to fix that?
But a major issue is homing with M100 - that should work..I think one cause of the oscillation will go away if homing works -
If the axis homes , and the DRO is cleared, when the axis is enabled there is no delta between position and DRO.

The oscillation mentioned at the start of this post - after HOME-ALL is a mystery, but I am sure it is related to the PID error, and the time delay in that M100 script you last posted - when the delays time out, the PID output jumps somehow?

Also related to the oscillation - is there a possibility of error due to the index pulse width ( to short to detect 'sometimes'), or the sense of the pulse ( rising edge/falling edge)? - sort of detecting the index, going past, etc? And the MESA counters doing odd things as a result?

Not sure we should give up yet ( unless you have had enough!) - or have ideas regarding a better way..!

Please Log in or Create an account to join the conversation.

More
18 May 2021 20:51 #209402 by andypugh

I understand we should disable the C Axis mode, and are in 'normal' spindle mode, ie, M03 S1000 will now run the spindle @ 1000rpm as normal, so the C axis SHOULD NOT jog in M101 -
What do those added lines do? Presume the '0' disables and the '1' enables - but what is enabled/disabled? The jogging of the physical axis, or the DRO? Or both?

The DRO will no longer move, and the commanded position will stay the same.

I may also not have been clear on 'Not jogging anymore' issue - NONE of the Axes physically jog anymore when a M100 is executed, so will the the line setp axis.c.jog-enable 0/1 enable jogging of the x and z axes?

M100 puts the system in joint mode to home the C axis. When the C-axis is homed the system _should_ go back in to "teleop" mode.
Maybe we do need to unhome the C axis to actually get that to happen?


I still don't understand the reason for the oscillation - it is fast, so not good mechanically, and has been there from the first iterations where the C axis started to work - must be to do with the PID being unhappy with entry conditions - If we know that we should be able to fix that?


The PID enables with a very large error, and so commands a very high velocity. Limiting PID.c.maxerror should be able to fix that without affecting normal moves, but you seem to have said that it didn't?

There is a way to make the c-axis command match the c-axis feedback. But I don't like it:
Try running in spindle mode for a little while, then turn the machine off (F2) and then on again, and then try M100.

Please Log in or Create an account to join the conversation.

More
19 May 2021 08:42 - 19 May 2021 15:36 #209459 by NoJo

I am mixing to many things in a verbose post every time and getting us both in a twist.

In summary, there are presently 3 issues:
  1. Jogging-
    Jogging works after HOME ALL, machine is in M100 mode after HOME ALL
    Then M101 - Jog XZ works, Jog C increments the DRO, C axis does not move. DRO should not increment (?)
    Then M100 - JOG XZC no longer works.
    Then M101 - Jog XZ works, Jog C increments the DRO, C axis does not move, as above.
    This all with lines added > setp axis.c.jog-enable 0" to M101 and "setp axis.c.jog-enable 1" to M100
  2. Homing-
    HOME ALL works - all axes go to home, C to index - BUT C goes past almost a 1/2 turn and rapidly back to index.
    Thereafter, jogging as as described above.
    Then, do M101 and jog C ( only DRO changes now, C disabled) to 180deg
    Then do M100 - after a +-2sec delay, C moves to 180deg - NOT Home index position, ie, does not 'Home'
  3. Oscillations-
    If I make MAX_OUTPUT = 2 or less >
    All Gx Cxxx Moves are clean, stable, no oscillations
    The scenario in Homing above ( last two lines) caused the C axis to move to 180deg, instead of homing it, BUT that move is stable, no oscillation. So all moves are stable and clean.
    HOWEVER...The HOME ALL always does as described above - C goes to index, past +-1/2 turn, and rapidly back to index

NONE of the Axes physically jog anymore when a M100 is executed, so will the the line setp axis.c.jog-enable 0/1 enable jogging of the x and z axes?

M100 puts the system in joint mode to home the C axis. When the C-axis is homed the system _should_ go back in to "teleop" mode. Maybe we do need to unhome the C axis to actually get that to happen?

Your Call...

The PID enables with a very large error, and so commands a very high velocity. Limiting PID.c.maxerror should be able to fix that without affecting normal moves, but you seem to have said that it didn't?

See 3 above...

Try running in spindle mode for a little while, then turn the machine off (F2) and then on again, and then try M100.

This was interesting:
I set MAX_OUTPUT = 2
HOME ALL ( behaviour as in 2 above)
M101, M03 S500 ( run for maybe 5sec), then M05, F2, wait a while....F2, then M100
about a 2sec delay after M100, then the C axis unwinds ALL the turns it did in the M03 S500 period - 5sec of turns @ 500rpm..
I did not look at the C DRO value after the M05, so not sure what that was or if it had changed to a big number..
Last edit: 19 May 2021 15:36 by NoJo. Reason: Added the activation of F2 in last lines..

Please Log in or Create an account to join the conversation.

More
19 May 2021 21:48 #209551 by andypugh

The PID enables with a very large error, and so commands a very high velocity. Limiting PID.c.maxerror should be able to fix that without affecting normal moves, but you seem to have said that it didn't?

See 3 above...


Ah, no, there is a difference between limiting the max-error (on the input to the PID) and the max-output.

You could limit max-error to (say) 5 (or 1, or less) degrees, and then a 10-turn (ie 3600 degree) error would look like a 5 degree error. So in theory you would retain all the jogging / moving responsiveness but it would not go crazy on huge offsets.

Please Log in or Create an account to join the conversation.

More
19 May 2021 22:12 #209556 by NoJo

The PID enables with a very large error, and so commands a very high velocity. Limiting PID.c.maxerror should be able to fix that without affecting normal moves, but you seem to have said that it didn't?

See 3 above...


Ah, no, there is a difference between limiting the max-error (on the input to the PID) and the max-output.

You could limit max-error to (say) 5 (or 1, or less) degrees, and then a 10-turn (ie 3600 degree) error would look like a 5 degree error. So in theory you would retain all the jogging / moving responsiveness but it would not go crazy on huge offsets.


Ok,.....
I was kind of just doing as you said..abt 8 or so posts ago....When the oscillations were first observed,

'C_axis oscillates trying to find the 360deg position.
The command is set at 360,since C was at 360 before the M101. It looks like when the mode is entered (M100) , since the command is at a big number already, its seen as a big step change.'...etc,etc


Your suggestion then was:

You can probably calm this down by using pid.c.maxoutput, set that to 400


I will try pid.c.maxerror in the morning.

Please Log in or Create an account to join the conversation.

More
20 May 2021 07:54 - 20 May 2021 07:55 #209620 by NoJo

I will try pid.c.maxerror in the morning.


Set pid.c.maxerror to 10, pid.c.maxoutput to 400

All C moves are stable, EXCEPT for the usual HOME_ALL.
I Halscoped these during a HOME_ALL:
pid.c.command
pid.c.feedback
pid.c.error

and pid.c.maxerror, pid.c.maxoutput - these two remain zero during the home_all
Attached a photo of the 'scope..
Attachments:
Last edit: 20 May 2021 07:55 by NoJo.

Please Log in or Create an account to join the conversation.

More
20 May 2021 10:21 #209633 by andypugh
You could try an even lower maxerror. 1, or 0.1 might be interesting.

But, there is something wrong in the setup...
net c-pos-cmd    <= joint.2.motor-pos-cmd  joint.2.motor-pos-fb

For homing to work the C-axis feedback needs to be from the encoder, but it needs to be short-circuited like this in spindle mode or there will be a following-error.

First, try
net c-pos-cmd    <= joint.2.motor-pos-cmd
net spindle-degrees  joint.2.motor-pos-fb

That should make homing a lot better-behaved. But I think it will stop the spindle mode working. (I expect an instant following-error on joint2.)

Please Log in or Create an account to join the conversation.

More
20 May 2021 13:47 #209648 by NoJo
I tried 0.1 in maxerror - HOME ALL did as usual, C goes to index, then still goes past -+ 1/2 turn, then goes back to index, as usual, but this time VERY slowly, like 1 rev / day...
A 1 in maxerror - same behaviour but return to index is faster - 1 rev /hour.

Then, doing what you asked to first try -

HOME ALL homes X, and then would normally do Z and C, but dies with a joint 2 following error - does not home.
Ignoring HOME ALL on start up, I then activated the spindle on the AXIS Manual screen - this gave Joint 2 following error right away.

Please check the HAL section where I added those lines - some lines appear already, etc..Maybe I messed up.

HAL:
#*******************
#  AXIS C JOINT 2
#*******************

setp   pid.c.Pgain     [JOINT_2]P
setp   pid.c.Igain     [JOINT_2]I
setp   pid.c.Dgain     [JOINT_2]D
setp   pid.c.bias      [JOINT_2]BIAS
setp   pid.c.FF0       [JOINT_2]FF0
setp   pid.c.FF1       [JOINT_2]FF1
setp   pid.c.FF2       [JOINT_2]FF2
setp   pid.c.deadband  [JOINT_2]DEADBAND
setp   pid.c.maxoutput [JOINT_2]MAX_OUTPUT
#add max_error
setp   pid.c.maxerror  [JOINT_2]MAX_ERROR
setp   pid.c.error-previous-target true

net c-pos-cmd       =>  pid.c.command
net spindle-revs         scale.degrees.in
setp scale.degrees.gain 360
net spindle-degrees scale.degrees.out => pid.c.feedback
#Add Per Andy
net spindle-degrees joint.2.motor-pos-fb

net c-output            pid.c.output => mux2.0.in1
net spindle-index-enable joint.2.index-enable 
net spindle-index-enable pid.c.index-enable

# Here we setup to start machine in C_Axis mode
setp pid.c.enable 1
setp mux2.0.sel 1

#Change per Andy net c-pos-cmd    <= joint.2.motor-pos-cmd  joint.2.motor-pos-fb
net c-pos-cmd    <= joint.2.motor-pos-cmd

net c-vel-cmd    <= joint.2.vel-cmd

Please Log in or Create an account to join the conversation.

More
20 May 2021 14:30 #209653 by andypugh
I think it is time to give up, this isn't going to work.

A fundamental problem that has just occurred to me is that you can't rehome an Axis while running a G-code program, and it seems pretty certain that you would want to be switching mode during a program.

By trying for a minimalist. simple system I seem to have created something complex that doesn't even work.

Please Log in or Create an account to join the conversation.

More
20 May 2021 16:07 #209662 by NoJo
Ok. You would know, I certainly don't!

I can only thank you for all the time you spent on this, and on dragging me along, and apologise for having wasted your time!

Thanks Andy

Please Log in or Create an account to join the conversation.

Time to create page: 0.192 seconds
Powered by Kunena Forum