M19 and spindle-index-enable issues
- Alexandrion
- Offline
- New Member
-
- Posts: 11
- Thank you received: 3
In my case I think I had an issue with the high values of the encoder count on my mesa 7i77, the longer the spindle ran the longer the orient took because instead of 1 rotation orient, my spindle did 6-7 rotations ccw and then another 6-7 cw before the orient was completed, even if I ran in orient mode 1. I even tried to use M5 and a dwell before orienting but no success.
The only issue I had with the new component was G33.1 not synching properly and wanting to go at maximum speed into the workpiece, quite a sphincter tightening experience, but it seems that this issue was resolved by deleting the index_enable = 0 from case 0.
Regards,
Alex
Please Log in or Create an account to join the conversation.
- COFHAL
- Offline
- Platinum Member
-
- Posts: 350
- Thank you received: 42
Please Log in or Create an account to join the conversation.
- COFHAL
- Offline
- Platinum Member
-
- Posts: 350
- Thank you received: 42
Please Log in or Create an account to join the conversation.
- Aciera
-
- Offline
- Administrator
-
- Posts: 4251
- Thank you received: 1873
Please Log in or Create an account to join the conversation.
- scda
-
- Offline
- Junior Member
-
- Posts: 32
- Thank you received: 3
Not sure if this is still relevant. I am using this "new" orient comp from Andy (recompiled it as orient2). And I have to say, this actually works great!
The only thing I changed is: uncomment "is_oriented = 0" (otherwise I was not able to run multiple M19 commands in a row).
This changes the behavior of the -is-oriented pin --> So i use the oneshot function to make the signal stay true longer and activate the spindle brake and some other stuff. Might add another input to the comp, so the i"s-oriented" pin can be reset with M5 or an other signal...)
Before I saw this, I had to use tallas83 idea to orient a spindle (which requires much more signals/pins & connections).
This should be added to the main fork in my opinion (maybe this was already done)?
One improvement in my setup would probably be to run the indexing only once (and then change the mode to 0) and after that do a few orientation commands. That should make it a bit faster as a constant rehoming is not necessary after every orientation (espescially if the spindle is not running in velocity mode in between).
Please Log in or Create an account to join the conversation.
- Aciera
-
- Offline
- Administrator
-
- Posts: 4251
- Thank you received: 1873
pin in s32 mode "0: rotate - shortest move; 1: always rotate clockwise; 2: always rotate counterclockwise. Add 16 (0x10) to the mode to force homing to index before orienting";
Please Log in or Create an account to join the conversation.
- scda
-
- Offline
- Junior Member
-
- Posts: 32
- Thank you received: 3
I connect the orient.mode signal to a signal and then manually switch the mode.
An improvement might be to use a custom M command to change the mode (via mux2 or multiselect component)
One thing I might try is to change the orient.comp to have a input for running the index function, that can be controlled easily via hal or M command.
About the brake control:
I found the spindle.xx.locked pin in the documentation which goes high when orient ist done (and low with M5 or a new M19 command) --> it is perfect for controlling the spindle brake !
Please Log in or Create an account to join the conversation.
- Aciera
-
- Offline
- Administrator
-
- Posts: 4251
- Thank you received: 1873
The point of IO pins is to only write any state to them when you want to set the state, and let other parts of the net be in charge at other times.
Looking at your code for case 0, which is the initial state, you are setting 'index_enable = 0' so this version of the component permanently forces 'orient.index_enable' low until an orient command is issued (ie 'orient.enable' goes true):
case 0: // waiting
index_enable = 0;
if (enable) {
if (enable ^ last_enable) { // positive edge on enable
is_oriented = 0;
if (mode & 0x10){
index_enable = 1;
state = 3;
} else {
state = 1;
}
}
}
break;
Your code looks like it will always set index_enable true?
No, my version forces homing to index because the mechanism with adding 16 to the p word does not work and 'orient.index-enable' is not written to unless spindle orientation has been called (ie 'orient.enable' is true) because 'index_enable=0' is now inside the if (enable) { statement.
switch (state){
case 0: // waiting
if (enable) {
index_enable = 0;
if (enable ^ last_enable) { // positive edge on enable
is_oriented = 0;
if (1>0){
index_enable = 1;
state = 3;
} else {
state = 1;
}
}
}
break;
Please Log in or Create an account to join the conversation.
- Aciera
-
- Offline
- Administrator
-
- Posts: 4251
- Thank you received: 1873
The only thing I changed is: uncomment "is_oriented = 0" (otherwise I was not able to run multiple M19 commands in a row).
After digging out my config from back then I notice that I made the same change.
thanks for confirming that as I thought I was missing something and yes that could indeed be changed.Yes that's the issue with the M19 command. But could probably be changed in a new release ??
What makes me wonder is why constantly forcing index-enable low does not cause a problem for you.
Please Log in or Create an account to join the conversation.
- scda
-
- Offline
- Junior Member
-
- Posts: 32
- Thank you received: 3
This allows it to start the orientation with indexing, once done, it will disable the automatic indexing.
It can still be activate again by setting the index enable cmd pin high again (eg. via custom M code).
Only software signals can enable the automatic indexing before spindle orient.
In hal i then use:
net index-enable-cmd <=> orient2.0.index-enable-cmd
Cheers,
David
Attachments:
Please Log in or Create an account to join the conversation.