Ox1_3.JPG (90724 bytes)Cortez-project
Home Up


Motor control
Piezo control
Motor drivers

The Cortez project is an embedded controller dedicated to motion control and chemical spotting with piezo jets. It grew out of a previous motion control design, which was based on solenoid valves, filling little vial-carriers. My resume page shows some early stage pics of this project. The hardware back then was still in the early prototype stage.

This page however is dedicated to the final production type controller. It is a multi CPU design, distributed over 3 CPU boards, 2 motor driver carriers and a passive back-plane. The communication between the master (motor controller) and the 2 slaves (piezo controller) is done by high speed clock/data serial loops over the back-plane.

More hardware details of the highly modular design can be found in the following pages :

bulletMotor control : The design of this board involves digital circuits with interfaces to stepper motors and valve drivers, which also provide an input function on the same output node. The software to run the motors is based on a custom TPU micro-code function and all of the critical motor control is handled in ISRs.
bulletPiezo control : This board uses the same modular CPU core as the motor controller and 1 digital I/O module. The main control part is dedicated to excite up to 6 piezo jets for the chemical spotting onto the individual carriers. The software to control the precise piezo timing is based on a custom TPU micro-code function and all of the critical piezo control is handled in ISRs. The design involves PLDs for the piezo clock decoding, as well as DACs and analog amplifiers for the programmable high voltage piezo drivers (+/-50 V, 5 us slew rate)
bulletMotor drivers : The motor drivers should show the packaging with the back plane concept.
bulletBack-plane : This concept is not new, but it always helps to clean up all of the usual interconnect headaches.

horizontal rule

Modular firmware concept : The software design is implemented in a stand alone OS (operating system), which consists of the kernel itself and the I/O driver shell. The hardware modules are supported by expandable modular driver functions. The entire design can be configured and sized to customer specs in a moderately easy way, without rewriting a lot of firmware. The OS will be the same for any APP (application) configuration, and only the I/O drivers will need some small changes. Any follow up design will benefit from the cost savings for all of the OS and a big part of the firmware development. Other advantages are the already written OS and I/O drivers, which provide a faster development cycle.

Operating System shell : The base for it is a preemptive real time multitasking kernel written by Jean J Labrosse. The source code and user licensing requires the purchase of his book “UCOS, The real time kernel, rev 1.08”. I ported the kernel to the 683xx family of CPUs and revised the source code, written in “C”. I further added some enhancements and debug features, which where not included in his book.

Operating system shell : This consists of  some basic startup code and several HW and SW drivers. The startup code is written in assembly and jumps at the end to the “main” function. Two serial drivers support the comm and the debug channel. The comm channel can be used to communicate to the host CPU, which is in most cases a PC running the final application on Win 95/98 or Win NT. Both serial channels have interrupt supported  ring buffers on transmit and receive. The max recommended Baud-rate should not exceed 19.200 Bd. This can be increased, depending upon the interrupt supported  I/O load activity for the CPU (motors, piezos, dig I/O, etc…). There are several “printf “ functions available for both serial channels, with and without transmit resource locking semaphores. A simple command parser (max 4 chars per command) is being used to process various debug and monitor commands.

Operating system interface : The interface to the OS is through an vector table, which allows the OS to be stand alone in memory and does not need to be linked with the final, also firmware based, control application. The same command parser is available through a parser function vector and a parser help menu vector. This OS is mostly independent of the final control application, except of some timer ISR support function vectors.

Application level support (motors) : There are a max of 6 motors supported by the APP. The programmability is through simple ASCII commands, which echo the command and response in ASCII as well. The acceleration curve is fully user configurable with a step range from full-step up to 12800 micro-steps. Two end-stop limit switches per motor are currently supported with motor enable/disable. Closed loop feedback through a quadrate position sensor is supported by the hardware but is not implemented in the firmware at this time.

Application level support (digital I/O) : There are a max of  80 CPU-board based digital I/Os supported by the APP. The programmability is through simple ASCII commands, which echo the command and response in ASCII as well. The digital output resolution on the CPU-board is 3ms with a guarantee that all of the selected outputs turn on/off at the same time. Additional slave based digital outputs will have a resolution of 12 ms with a synchronized on/off feature for the particular slave I/O serial loop. The slave-board based digital inputs are supported by the hardware, but there is no firmware support at this time.

 Application level support (Piezos) : There are a max of 6 piezos per board, and 2 boards per system, supported by the APP. The piezo timing resolution is 1 us. The min pulse width is 20 us. The driving voltage supports 3 programmable pulse levels within +/- 50 V (8-bit resolution). The burst count is programmable and up to 255 max, followed by a programmable idle period of up to 32k TPU clocks. There is one sync signal coming from the motor controller, which is being activated upon the start of any motor. Since the acceleration and speed of the stepper motor is known, the piezo-period, burst count and idle time determine the chemical spotting sequence (spacing) on the carrier.


horizontal rule

We are sure that You still have some questions or comments, so please contact us at
We would be very happy to hear from You.

Home Up