Mesa Reccomendations for custom made servo drive

I've recently almost finished designing and making my own servo motor driver. I've used a dsPIC to control the motor (permanent magnet synchronous), with position feedback currently from this Avago 17-bit absolute encoder although I could easily configure it to use other, e.g. quadrature, encoders. Since I have designed and programmed the drive, I can (within reason) choose whatever protocol I want for sending the position or velocity reference to control it, so my main questions are as follows:

• What protocol would you reccomend to send position / velocity data to drive? e.g. +-10V, RS485 etc...
• Which PCI card(s) would be most suited to the above?

I've currently put opto-isolators on the PCB in case I decide to just use step-dir or quadrature signals, but I also have spare outputs than can be mapped to the periphials. The PIC I'm using is here, with a list of peripherals:
www.microchip.com/wwwproducts/Devices.aspx?dDocName=en532302
I've used one of the SPI peripherals for the encoder and one UART for a general serial interface with computer (mainly for debugging and tuning via MATLAB or terminal), but there's still one of each spare.

Am I on the right lines thinking I could configure LinuxCNC to send out data packets to the drive containing the velocity information and receive the position data?

Thanks in advance...

For interfacing with Mesa HostMot2, and if you can figure out the somewhat sketchy protocol description in the
manuals, probably the easiest is to use RS-422/ SSerial. This will make the drives process I/O variables (velocity in, say position and drive status back) automatically available as HAL pins without requiring any driver changes.

SSerial has one limitation for this type of application currently, it only transfers one packet of data each servo thread.
this means the read data is always one servo thread period late. We intend to address this limitation some time this year
by splitting the transfer requests into a RX and TX part.

One way to live with the limitation is to run the drive in PVT mode where you send position/velocity/time packets
so the drive gets good velocity information from the host plus position data for a weak PI loop to correct for minor
timebase differences etc.

Thank you for the information - most helpful. It looks like I would be fine with just a 6i25, as unless I've missed something the boards to go with them don't seem helpful for my application. However, I think I'd be best off getting one with the 7i76 so I can trivially connect the existing stepper drivers on my machines. The 7I80DB is tempting so long as it wouldn't complicate matters much?

If the problem you describe is going to be addressed this year, that sounds fine to me. Adding a weak proportional controller for position to the driver code is also not a problem. However, couldn't we instead just halve the servo thread period and alternately send packets to request and read the data from the drive? That would halve the timing error, which as a temporary measure may be sufficient?

PCW wrote:

For interfacing with Mesa HostMot2, and if you can figure out the somewhat sketchy protocol description in the
manuals, probably the easiest is to use RS-422/ SSerial. This will make the drives process I/O variables (velocity in, say position and drive status back) automatically available as HAL pins without requiring any driver changes.

Is there any sample code for the 'remote' side available? Preferrably dsPIC, which you seem to be using on a 7i76 too.

I am busy building a mill, and for that I need, besides a bunch of I/O lines, 6 analog outputs, 8 encoder inputs and two stepper channels. I recently bought a 5i25+7i76 so I might want to buy an extra 7i77 and then I am there.

The thing is: 4 encoder channels go to glass scales, and I am considering leaving them and a small dsPIC33-based controller powered 24/7 so they behave as 'absolute encoders'. I was thinking parallel port for the communication, but SSerial is a far nicer option.

We dont have any C examples, the current remotes are all done in a funny macro assembler
dialect that allows similar code to run on our FPGA soft processors. We expect to move to STM32F3s
for some new remotes and may have sample C code available then. I dont think we would mind publishing
the assy code for a remote but its likely to be pretty weird for a C programmer.

Pretty sure Issy is using our custom code for his remotes

What is the maximum Arduino baud rate? (we will add this to the autobaud probe list)

We are looking at the STM32F303 parts for new sserial remote designs

These have:
32 bit Arm cortex M4 core with floating point at 72 MHz
4x 12 bit 5 MS/sec A-Ds
2x 12 bit DACs
multiple serial ports with baud rates up to 9M Baud
a couple of encoder counters

at about the same price as the DSPICs (~$3.25 in reasonable qtys)

all this and a $10.66 dev board

PCW wrote:

We dont have any C examples, the current remotes are all done in a funny macro assembler
dialect that allows similar code to run on our FPGA soft processors.

You know there are C compilers for Microblaze and Picoblaze cores, right?

the assy code for a remote but its likely to be pretty weird for a C programmer.

I can read/write assembler too, but then I basically have to start all over developing the SSLBP protocol stack, including spending 80% of the time getting the last few bugs out.

I am not in a hurry; I'll wait a while. Or I just use the parallel port; bitbanging multiple SPI channels with the clock in DDR mode so a single outb/inb is a single bit should be fast enough for the few words I want to transfer each servo period.

PCW wrote:

We are looking at the STM32F303 parts for new sserial remote designs

I have these in the visor as well, although I do like the dsPIC's a lot. Cost is low, processing power is often more than sufficient and package options go down all the way to DIP which is easy for prototyping (or a single personal product) on breadboard.

We should have relatively portable sserial remote code for the STM32F3 sometime this year one way or the other...

The Picoblaze and Microblaze are nice but for our purposes the
Picoblaze is too slow and the Microblaze is way too big and they are
both load/store (RISC) architectures which are quite inefficient when you have
lots of direct I/O.

They are really designed around a slow memory, fast register
model that does not match small embedded FPGA processors that run out of
BlockRAM very well.

Also not sure if C makes much sense when you only have 2K of code space