Running servos in position mode instead of analog

Would be nice if any of you could test in S/D mode with encoder feedback to LinuxCNC, i wonder how much would that be affected, if at all, as it might be something in the firmware that might cause it in velocity mode but be fine in S/D.
Wishful thinking?

I did do that when I was swapping from velocity to position. I still have the encoders hooked up to a 7i77 as I would like to use the index signal at some point. The delay was still there. Not sure if I have a screenshot saved to the machine. Other projects have pulled me away from finishing that one.

tommylight wrote:

Would be nice if any of you could test in S/D mode with encoder feedback to LinuxCNC, i wonder how much would that be affected, if at all, as it might be something in the firmware that might cause it in velocity mode but be fine in S/D.
Wishful thinking?
 

This likely makes no difference as like I said to you in the other thread, it's not an actual encoder output. It's something the drive's MCU is calculating then sending out.

DYN4 uses a 17bit encoder which is basically 131072 PPR. If you set it to 1000 PPR output then it has to actually figure out what and when to send to the encoder output. As I showed you in the other thread, the DMM guy sent me a scope pic of a 1ms delay, that sounds reasonable for an emulated output considering the motor actually has to start moving first.

For one, using halscope is not the greatest way to check this, it's easily done via an actual scope. For two you might ask how it compares to other servo drives of this class because if it's somewhere about the same then you have to ask "why can't my LinuxCNC setup handle this properly"

It's great he sent you a picture of a 1ms delay. But he told me the same thing. And when I asked why it's 5ms he could only point fingers at Linuxcnc but couldn't articulate any particular thing to look at that caused the delay.

Plenty of other setups use Linuxcnc and a 7i77 board but don't have this issue. I couldn't find a single example of someone using DMM with accurate encoder feedback. The only ones I found were using galil controllers and they used filters to remove the delays they were getting back from the encoder section.

And regardless of using a scope or not the servos would over current fault attempting to catch up to their commanded speed .I could never get them to run full speed in velocity mode with a closed loop.

You have to ask yourself "why is no one else having the same issue running Linuxcnc and servos in closed loop". Maybe the issue is with DMM servos not being well built.

You have to ask yourself "why is no one else having the same issue running Linuxcnc and servos in closed loop". Maybe the issue is with DMM servos not being well built.
 

Actually, it's not uncommon to have delay issues when using drive generated feedback.
I had the same issue using  Mitsubishi MELSERVO J4 drives with step/dir.

There is a whole thread about that here:
forum.linuxcnc.org/10-advanced-configura...pain?start=30#193073

Michael wrote:

It's great he sent you a picture of a 1ms delay. But he told me the same thing. And when I asked why it's 5ms he could only point fingers at Linuxcnc but couldn't articulate any particular thing to look at that caused the delay.

 

You can't either because it's not "5ms". Using the HAL analog output command as your starting reference is not the right way to do that because nobody knows what voltage you have the drive set to respond to. At best the 3ms delay between encoders is valid.

Plenty of other setups use Linuxcnc and a 7i77 board but don't have this issue. I couldn't find a single example of someone using DMM with accurate encoder feedback. The only ones I found were using galil controllers and they used filters to remove the delays they were getting back from the encoder section. 

I use a DYN4 with encoder feedback and it's plenty accurate. I use a 5000k rpm motor on my spindle controlled with step/direction from a 7i76e, it rigid taps all day. Analog control shouldn't make a difference except what is calculated as the deadzone. The analog command doesn't have an effect until the voltage is above/below the deadzone which is why you can't use the first blip of your HAL analog output command as a reference. If there was no deadzone you wouldn't be able to stop the motor but nothing about that is unique to DMM.

And regardless of using a scope or not the servos would over current fault attempting to catch up to their commanded speed .I could never get them to run full speed in velocity mode with a closed loop.

Again sounds like you didn't tune the deadzone out of your PID. I'm assuming that because A, that's exactly what would happen as the drive just reached the Analog input threshold and B you never mentioned the deadzone then you posted the halscope image and the only way you come up with 5ms from looking at that is if you don't account for the deadzone at all. The size of the deadzone is dependant on other parameters set in the drive, it's on P78 of the manual

You have to ask yourself "why is no one else having the same issue running Linuxcnc and servos in closed loop". Maybe the issue is with DMM servos not being well built. 

Well built compared to what? Are you expecting a $250 servo drive to be as good as a $1k drive? If the "issue" is the "delay" then we gotta figure out what the actual delay is and if it's unreasonable. I have a DYN4 setup on a motor stand coupled with an encoder so I can test this. I didn't feel like setting up a Windows VM last night to re-configure the drive but I'll do that at some point today maybe. Like I said, I would expect a "delay" on the encoder output because of the nature of how it's generated. 3ms seems excessive, 1ms is probably fine but realistically it has to be compared with other drives doing the same thing.