JB2020 (Customer) asked a question.
Servo or Stepper?
I have been searching a lot of videos and other information on the AD Site to try and find what is the best system to use for motion.
Do robotic arms use servos or steppers? These have more continuous motion obviously.
What about something that has a small motion like a reject pusher or gate? Is it best to use stepper or servo for that?
My initial thought has been that robotics use servos and smaller stuff uses steppers, but now I'm not sure.
Also, I have looked into the AMC Motion Controller. The small amount of research I've done tells me this is stepper only. Is this unit solely for steppers?
I primarily use Productivity, so I need something that is easy to program and setup.
Hobby robots almost always use steppers due to cost and ease of use. They also don't require any tuning and work well with mismatched motor / load inertia. All other robots are going to use servos with usually a zero backlash gearhead, either harmonic or Cycloidal.
For a reject pusher or gate, pneumatics tends to be a better solution. If you want to use a motor I would keep it as simple as possible unless you need multiple diverter positions or similar.
If you're looking for a stepper based controller, they sell some at AD although I've never used them. If you want another suggestion, message me and I'll give you some options.
You can use servos with the AMC module, that is all I use it for. You just need to set your servo input to step/direction mode instead of quadrature. Your servo or stepper must also support a differential line-driver input signal as that is all the AMC has. SureServo 1 and 2 both support this, IDK about the "LS" models as I havent used those. Some Leadshine stepper drives support differential, some do not. Same for the SureStep drives, some do and some dont. Have to check the spec sheet for those. Look for differential listed on the "input circuit" or "input type" categories
This is good information. However, Do I need the AMC? Does it make using servos that much easier? Or is it easier just to use implicit messaging via Ethernet/IP?
It's just a difference of doing your motion in the PLC vs the servo itself.
For EIP motion control you would set the servo to PR mode and use EIP to Initiate the moves to each saved position you set up. It isn't hard, and is the way many servos are controlled. On SureServo1 you have 8 positions, so if you need more than that then you can re-use registers and load new revolution, counts, accel, and decel. So you have unlimited positions, but you have to keep track of what data you are loading. SureServo2 has 99 saved positions, so you probably won't ever have to re-use registers. You can also initiate mode changes from PR to speed and back if you want, and the servo keeps track of its position so you can still do correct PR moves after a speed move.
The disadvantage of PR moves and EIP control is that if you are trying to follow another piece of equipment or product and that other thing has a variable speed, matching the servo up with a PR mode move is extremely hard if not impossible. You would have to grab the other items velocity and calculate your accel and decel right before you want to do your servo move and load all the data into the servo. This unfortunately takes time, not a lot, but having a 25-50ms delay can throw things off sometimes. And if the thing you are trying to match changes its velocity at all during the servo move then you wont be in sync with it anymore.
That is where PT mode comes in, and an advantage of a motion controller. The servo moves based on the pulses it gets in PT mode, so the position it goes to, the velocity it moves, the accel and decel, all are based on whatever is sending the pulses to the servo. So with a motion controller, you can set up unlimited moves as well, and they are all instructions in the PLC. Which, personally, is easier for me to visualize the data you are working with is often from the PLC itself so your data is right there too. If you need to match another piece of equipment or a product piece that is far easier, as you can simply pull the velocity, accel, decel from the tags of the other item, or many times just turn on a "gearing" instruction which follows a master automatically. So it can make matching other parts of the machine far easier, at least IMO.
Now when it comes to steppers, those don't have a whole bunch of position registers in them or any of that. So either way you will be using the PLC for control. You can still use network communication to initiate move profiles on a stepper, but you can also use a motion controller and control it the same way as the servo with that. I feel like a motion controller with move instructions is far easier to control a stepper exactly like you want and with faster profile changes than with network communication.
I believe I only need step and direction for my application, but would like some input on that as well.
Below is a photo of a 'napkin drawing' of the proposed project. I am doing a reject system that consists of 2 parallel diverter gates that will 'reroute' the flow of cans or bottles.
For such a simple thing like move to position 2, move back to position 1 that is perfect for PR type moves. Easier and cheaper to control it with EIP or Modbus to initiate the move, and even easier still to control it with discrete IO on DI2 and DI3.
I don't know the speed of your line, but typically bottle lines are VERY fast. So assuming you are going at very high speeds a discrete IO from a PLC telling a servo to move to position 1 or 2 would be quicker than EIP. The difference would be something like 2-3ms response time vs 10-15ms response time. Either is probably fast enough for you, assuming your conveyor is doing something like 200 bottles a minute. But anything that you can eliminate from network communication the better, to keep the "airways" clear for devices that do need that sort of control which makes them more responsive.
Below is a better drawing of the system I am working on. And here is an explanation of my theory on how I would like this to work. Please feel free to critique this and let me know if I am way off in left field or if this is doable.
For this article I will be referring to the product as "bottles" because we are currently running bottles on this line. The Can Line has not been added yet. My explanation is based on Gate 1(Position 1 and Position 2), Photo Eye 1 and Photo Eye 2.
Gate 2(Position 1 and Position 2), Photo Eye 3 and Photo Eye 4 will be added when the Can Line is added.
Starting at the bottom of the photo, I have a filler that can fill either cans or bottles (just different tooling). Gate 1 is in Position 2 to move the bottles to the bottle line. The bottles feed into the filler and continue around the turret. The fill chute has a metal detector around it. If metal is detected, Photo Eye 1 will start counting bottles. When the 17th bottle is detected, Gate 1 will move to Position 1 until that bottle is detected by Photo Eye 2. Upon detection of a bottle on the reject conveyor (by Photo Eye 2), Gate 1 will return to Position 2 to continue production until the next reject event occurs.
A second photo eye may be added to detect empty bottles, but I think that'll be an easy thing to do.
Gate 2 will be a duplication of Gate 1 except for the can line.
I do plan to have a Mode Selection that will put the gates into their production positions. If Can Line is selected, then Gate 1 will stay in Position 1 and Gate 2 will do the rejecting. If Bottle Line is selected, then Gate 1 does the rejecting while Gate 2 stays in Position 2.
Thoughts?
I think this is very doable, but I may need to access this forum quite a bit for more information. I feel I am very cable of writing a program using discrete I/O for the photo eyes, counters/timers, coils to control outputs to the servo drives, etc. And I think I will do this without Ethernet comms just to simplify it.
That all seems plenty doable and should work well.
I see this as an Air Cylinder Gate Actuation Scenario, and Shift register Clocked on the 'One Bottle Flag' from the Feed Screw of the Filler, with the Data being the 'Defect Detection'
Cap
I understand that pneumatics would work great for this. However, I am wanting to use servos because I am wanting to expand my knowledge about them. This project is a small simple deal that is not as complex as robotics. I eventually would like to get into robotics, so I'm learning in "baby steps".
Now, you opened another "can of worms" when you mentioned a shift register. I also know nothing about those other than the fact that they can shift the output to the next point based on another event. Clocking them, etc., I'm lost, LOL!
Give me some more information on this, please. This filler that I am working on had a shift register in the program that originally took care of the rejecting.
Now, you may ask, why not just use the program that previously took care of rejecting? Because all of the rejecting equipment has been removed from this system by a previous owner. We do not have any of those items. Hence, the reason for re-engineering the system.