Prop as general purpose motion control chip for servo motors/valves?

Mickster

New user here and still getting to grips with the chip.

I'm considering the Prop for the above application and would appreciate any comments on its suitability. I have read quite a bit about interfacing to servo amplifiers and incremental encoders but all the examples that I found were of the hobby standard.

High-end servo drives typically require a bipolar command signal of +/-10v. This can be filtered PWM but what would be the benefit of this over a serial DAC?

Encoder Interface: I have seen the examples that read an encoder connected to the Prop's I/O pins but I have not found any examples that cater to the complementary signals that pretty much every industrial encoder features. I have seen an app-note for a dedicated serial encoder interface/counter and wonder if this, coupled with a differential line receiver, might be a better way to go as the dedicated chips perform filtering and are capable of much higher pulse frequencies (not to mention the X4 multiplication).

Based on my limited knowledge of the Prop, at the moment, it would appear that, using PASM, a single cog could manage several PIDs, read the same number of serial encoder counters and write the same number of serial DACs(???). Maybe use another cog to handle the velocity profiling, another cog for PLC and another for communication with the host controller(???).

Or am I missing something?

Great forum, thanks for reading my post!

Mickster

RS_Jim

Mickster,
Welcome to the forum. I would say the Prop could easily handle the software requirements of your application. I am not able to answer your questions about the hardware interface, but there are many hardware guru's lurking about the forum. You might consider using optoisolators to provide the interface between the Prop and your high voltage requirements as long as the speed you need is within the capabilities of the opto.
Jim

Mike Green

Servo drives: Filtered PWM only needs an RC filter. It's cheap, requires little board space, and only one I/O pin. As far as the Prop is concerned, both that and a serial DAC are easy to implement and there's sample code available

Encoder interface: Someone with specific experience will need to answer this

Usually, you'd have one cog handle several encoders. Another cog would handle several DACs. A third cog would handle serial communication with the host. These operations would be low level and in PASM. The encoder cog would leave its information in global variables. The DAC cog would pick up its new values from global variables. Serial communication would involve ring buffers, typically 64 or 128 bytes each for transmit and receive.

Velocity profiling could be done either in Spin or in PASM depending on the number of channels and the speed needed. The overall control would be done with a cog running Spin. A lot depends on the specifics of your application. The general notion is that various control tasks tend to simplify and linearize when split along appropriate boundaries. Each such task gets assigned to a cog. Often tasks would be assigned to independent hardware control blocks, like a UART. With the Propeller, these would be assigned to a cog. For example, I have a specialized Basic interpreter that interfaces with a TV, PS/2 keyboard, EEPROMs, SD card file system, IR distance sensors, and an ultrasonic distance sensor. The cogs are used for: 1) low level TV display driver, 2) keyboard driver, 3) combined I2C and SPI driver for low level EEPROM and SD card functions, 4) modulated IR driver, 5) ultrasonic pulse timing, 6) main program. #4 and #5 are started only as needed. #s 1, 2, and 3 are in PASM. #s 4, 5, and 6 are in Spin.

Mickster

Servo drives: Filtered PWM only needs an RC filter. It's cheap, requires little board space, and only one I/O pin.

Hmmm, except I need bipolar +/-10v so an opamp would be required and one I/O pin per axis.

With the serial DACs and Encoder chips, I was considering daisy-chaining them, no?

Thanks for the response!

Mickster

Mike Green

Assuming you're using I2C DACs and encoder chips and the data update rates you need are compatible with daisy-chained devices, you would have one cog that does the low-level I2C operations in PASM. Maybe you'd have one cog in Spin that'd do the motor control for all the motors.

I assumed you'd need an opamp regardless of whether you used a DAC or PWM. Most serial DACs are limited to logic level voltages.

Mickster

Assuming you're using I2C DACs and encoder chips and the data update rates you need are compatible with daisy-chained devices, you would have one cog that does the low-level I2C operations in PASM. Maybe you'd have one cog in Spin that'd do the motor control for all the motors.

Was thinking of daisy-chaining SPI devices.

I assumed you'd need an opamp regardless of whether you used a DAC or PWM. Most serial DACs are limited to logic level voltages

Looking at the MAX5312 (12 bit motor command is fine) which can provide +/- 10v.

Well, I am encouraged already!

Thanks again!

Mickster

hkiela

Hi Mickster,
The way I dealt with this was following:
- Encoders with the standard Obex quadrature encoder driver
- Motor drives: by using the double Pololu drives #1112. These can be daisychaned bidirectional via one serial port with a max update rate of 5 ms per drive (two motors) including sending new current setpoints for two motors and reading errors and motor currents. I used the standard serial port stuff from the Obex here as well.
- Velocity and position PID for 8 motors with 50Hz for 8 motors, programmed in spin. This PID as well incorporates ramping of setpoints, velocity limit checking and if operated in position, control following error checking.

For most (robotic) applications, a 50Hz PID control is sufficient unless your system has better mechanical specifications.

I have posted the Polulu drivers on the Obex.

If your are interesetd in the PID part, I don't mind sharing it.

Henk