Hi, can anybody help me on this project. I need to control 20 stepper motors and 6 diodes. I have experience in project using pic16f887 etc. But i have never used port expander and/or assemblies using more than one microcontroller. So, i thought of two solutions:
1. Using 2 microcontroller as an input in the system (of encoders and photo sensors, and the code from pc [this will be via usart]), and then somehow the signals should be multiplexed and sent to appropriate microcontroller, which will control several stepping motors.
2. Or using similar solution but also using a port expander.
So is there anyone who can help with a solution for controlling so many actuators and choosing the right microcontroller.

{Sorry for my English, it is not my native language}

 

Do any or all of the motors require stepping at one time?
What do the diodes do?
Max.

 

Yes, all of the motors and diodes must be controled at the same time. And i need to control the current in the diodes.

 

You are fitting perfectly into the Allaboutcircuits tradition, asking for help with a complex problem and saying nothing useful about the details.

To start with:
How is the data on motor movement communicated to the processor? Not "by serial port" but how's the data organized? If it's in packets, how much data for each motor is included, and how far ahead of the current time does the data convey instructions for?

Do all the motors move at once or are they grouped, with some of them stationary?

How fast are the motors going to move, and what coordination is needed between them? Will a given motor just make a start-run-stop move at a preset velocity, or will it have to change speed on the fly?

If you want numerous motors each to travel at different speeds with variations as they move, then you're asking for a lot of processing power. What the processor can do is generate a fixed clock rate, not 20 independent clocks.

The diodes remain mysterious. Are they light-emitting diodes by any chance?

 

I am sorry for the lack of information. There will be transfer of a g-code from a pc to the system, and then according to the g-code the motors should be controlled within a 0.1 mm precision. They will be moving in 4-5 selectable speeds on the motors, but once the speed is selected it can't be changed until the next loading of the g code. There will be possibility where all of the motors will run, or two or maybe 5 etc. I want to control the current (up to 1A) in the diodes with PWM. Here are the motors and the drivers for them :
http://ms-motor.com/product_detail-8-en.html

http://ms-motor.com/product_detail-174-en.html

 

G code is normally part of a trajectory planner and not output as G code but translated, in the case of steppers, as a step/dir rate depending on the rpm required.
Is this a custom G code controller or off the shelf version?
I am not sure what the significance of the 1a in the diodes is, if this is stepper current, this would seem very restrictive for the average stepper motor?
Max.

 

What Max said.

I'm going to have to back out of this thread, or I'm just going to start being rude. Pancev, you just don't seem to get the idea that in order to answer your questions, we need information on what you're trying to do and what you're doing it with.

"The motors should be controlled within a 0.1 mm precision" is meaningless unless we know what the linkage between the motor and the controlled system is like. One step per millimeter or a million? Gonna tell us? Gonna think about why it's important?

I looked at the Chinese vendor's site and they also seem to be masters at leaving out the vital data.

Under their heading "Communication" they say:
Parallel Communication 40VDC (24002 is 35VDC)

Helpful, that. I'll get working on an interface design right away.

They also say:
Micro Step Resolution -40℃ ~ +125℃

Evidently having copied the "Environment Requirements" section and then left the information to mystify the reader.

My suggestion for a multi-axis system like this is to use one small microcontroller per axis, with some mechanism to keep them all synchronized, i.e. a master clock that updates each individual clock. Then the supervising computer does all the decoding of the Gcode data, and sends each processor a list of the times and directions for steps to be made in the future, with new instructions coming rapidly enough that the processor never runs out of data. Keep the information-processing part of the system in the computer, and let the processors do what they do best, control simple outputs at accurate time intervals. At least that's the way it looks to me, based on what's been described so far.

Current control for the diodes, maybe some day.

 

Current control for the diodes, maybe some day.

use the same driver.