Mazak Micro Slant 15 Retrofit

The 7i49 can output analogue voltage, but I don't know how often it is used.

The point is that very often the motor resolver connects direct to the servo drive, with the resolver not connected to LinuxCNC.

On my machines the resolver is connected to the 7i49 but the servo drives are the Mesa 8i20 and those receive their current command and rotor angle information digitally through smart-serial.

If the servo drive generates the excitation signal then the 7i49 can't be used.

One possible setup would be an analogue-controlled servo drive that takes hall sensor (or the 16-step Fanuc signals). In that case LinuxCNC HAL would use the measured resolver position both for axis position feedback and to generate commutation signals for the drive, with the analogue output being used to control the drive current.

It might be nice if there was an alternative "passive" mode for the 7i49 where it sampled the excitation voltage on a spare channel and measured the output voltages to give motor position information in cases where the servo drive supplies the excitation (and uses the output for commutation)

oh, it sounds more and more complicated to me now:)..I think (I'll check) that that kuka robot has an absolute encoder+resolver on the motor..and on the driver an analog input from the controller..I thought I'd recommend 7i49 to him so that he could possibly bypass mach3..I think that friend wants to convert absolute encoder signals into incremental signals via arduino.. and then use one of the digital/analog cenvert cards to send analog output to the motor drivers, and to bypass the resolver.. I'll see in a few days what the situation is.

The robot is quite possibly using absolute encoders for joint position and resolvers (straight to the drives) for motor commutation. In that case you don't need to consider the resolvers any more than you would the hall sensors on a BLDC configuration.

LinuxCNC would probably be a better bet than Mach for a different reason, though. It supports custom kinematics, including serial (robot) kinematics.

Take a look at this demo config: sim/axis/vismach/puma/puma560

forum.linuxcnc.org/38-general-linuxcnc-q...xcnc?start=10#110845
 

Masiwood123 wrote:

ok but the driver is controlled by 7i49 via analog output? linuxcnc receives feedback from the resolver in order to give the appropriate output via the card, that circuit is not very clear to me in the sense that if we compare it with an encoder, some scale must be entered, so I wonder if it is a similar tuning as with the encoder, I think, as it has to enter the encoder scale, there should also be a resolver scale, or not?

  The 7i49 converts the resolver AC waves into a square wave encoder signal basically. It's handled with discreet logic at the board level. AFAICT linux CNC doesn't know the difference between encoder types at the signal processing level. 

smc.collins wrote:

  The 7i49 converts the resolver AC waves into a square wave encoder signal basically. It's handled with discreet logic at the board level. AFAICT linux CNC doesn't know the difference between encoder types at the signal processing level. 

The 7i49 actually passes the resolver angle digitally in to the driver as a number. The HAL driver converts that to a numerical angle and simulated encoder counts (but not, at any point, into a quadrature signal) 

 

I'd have to ask PCW, my gut tells ne that the resolver input gets slapped with clipping diodes to a square wave it then looks at the zero crossings, and converts that into a count cycle and calculates angles against a tpu in the asic.

but that's how automotive stuff handles those kinds of signals. the asic may very well report angles to Linux CNC, but there's no practical reason a standard e coder couldn't do the same thing with a bit of firmware updating. Bosch does it on almost every controller they sell with hall effect engine position sensors. with hall effect iirc it's a bit more complicated as you have to know the width of the tooth and some physical geometry, with a VR you can just look at zero crossing distance, iirc.

I'm really rusty in my 8 bit mcu assembly stuff, haven't touched it in 20 yrs.