Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: BobO on March 07, 2014, 11:45:42 AM
-
Simple question: If we were to develop a 3 axis coordinated motion technology for Do-more, what are the basic features and price required to win your business? Additionally, what are you currently using, and what types of apps are you using it for?
Our current thinking is a module-based controller, a management app, and a well-integrated instruction set.
Sound off!
-
If it could do a gantry I could use it now. Currently using a Ctrio2 to pulse Sure servo letting the sure servo close the loop. Price point if it well intergrated in to the do-more I would not think twice about $800 twice the cost of the do-more.
-
Most of my customer apps have not been coordinated motion. Those customers doing coordinated machines at the moment are experiencing ultra-safety paranoia and using the servo systems with integrated safety.
Most of any possible jobs I see in the future would be single axis rotary feed systems or lead screw applications. I would normally use a 250 system with a sure servo in indexer mode, setting up the moves over the serial link and triggering it with the I/O. I would love to be able to use motion commands directly in the Domore and Do-Away with the link and use analog control. Biggest problem with the Sure Servo Indexer is that you can't switch between Position Mode and Velocity Mode on the fly. You have to reset the drive between changing modes. If you can use the drive in stupid mode and do it all in the PLC module, that would reduce design time considerably for myself.
Most of the newer PLC based servo systems are moving toward the networked type drives, either Ethernet, other standards or proprietary networks. I have not priced a system in a while, but you might want to investigate that possibility as well if AD has any plans to sell a more advanced type drive.
-
So what I'm hearing is that our basic positioning functionality in CTRIO2 is adequate for most apps (Do-more/CTRIO2 Axis mode), but without a servo solution (analog + encoder) you can't use it for many apps?
I feel that 3 axis coordinated motion will open a lot of currently closed doors, but I'm hearing an orthogonal perspective that we also need to address servo vs stepper for both simple positioning and full coordinated motion.
-
If you are asking what we are using, well here I go. Single axis is popular and on occasion 2 to 4 axis. All the commands are in the software. Ethernet is being used also. Ethernet on a separate line for the I/O. I used the Sure Servo and Trio a few years back, I am sure it has improved, but it seemed well a little cumbersome. You may want to look at what AB has. I know, dirty word, but everything is in the software. Both the systems we use and AB use ethernet and setup is automatic, in that the software reads the drive and motor info and sets up for you. Gearing among other commands work well.
-
It would be easy to do basic coordinated moves from the instruction set, but the trick would be in how you used instructions to describe non-linear paths. The advantage of something like G Code is in the ability to use external tools to create scripts. Does AB have instructions to do curves, or do they revert to something like G Code for that?
I could definitely see us developing a hybrid of MOVETO X/Y/Z type instructions and G Code for complex operations.
-
To do coordinated motion in RS5000, you set up a master virtual axis. Then create a CAM chart for each slave axis. You specify points on a curve and it interpolates the rest. Once the cams are engaged, then any simple motion command (ie. Jog, step, velocity, position move) makes all the other slave axis follow the virtual axis according to the Axis cam chart. They have some pretty good tools to define the cam chart and you can create the charts at run time. They have commands to engage and disengage each individual axis. All the tools are pretty much there to do whatever I needed to do. I've worked mainly with ControlLogix, which is their high end line and it worked well. It is a good approach.
-
I've been waiting for this one Bob ::)
Koyo currently builds a D2-MLINK module that interfaces with any MECHATROLINK-II enabled drive. MECHATROLINK is an open protocol used for Industrial automation, originally developed by Yaskawa and presently maintained by Mechatrolink Members Association (MMA). This solution, while not being compatible with current ADC offerings in terms of Servo Systems, would provide 15 axis of coordinated motion and 2 axis of linear and circular interpolation per module. The hardware works, I have a system in house we have been testing, but requires a special version of DirectSoft and DL-260 CPU/firmware. Given the miracles you and your team have performed with the Do-more, incorporating some instructions to an existing hardware module would offer some fantastic and quick solutions for advanced motion control.
-
I didn't know the D2-MLINK existed. We use Yaskawa servos which are commanded, via MLINK, from their own controllers. We talk from the DL PLC and ECOM-100 via MODBUS/TCP to the controller. It works well. But a direct link would be great.
-
The Yaskawa controller still does all the motion control, correct? The MLINK module just provides a communications gateway?
-
The D2-MLINK handles all the communications and control functions, no other controller needed. The Do-more would read and wright values to "shared" memory and the module executes on command. I've been using the Yaskawa MP2300 and the Sigma V servo drives with Mechatrolink for years and they work great. Haven't found anything yet I couldn't do...
-
What about coordinated motion?
-
Second ATU's comments on ControlLogix motion being well implemented, especially for coordinated or cammed motion. Graphical cam editor and so on. For Cartesian applications, you could supplement that with a graphical path editor.
-
Bob0
You still looking at this? If so make sure to have analog command 4-20 and/or +/- 10 as well as step direction (line driver) along with I/O for enable, 2 limits, Home if not using a limit, a pause input (I really like the way the CTRIO 2 does pause ramp to a stop then ramp back to speed) some general I/O(some systems use brakes and other outputs ) , Encoder feed( line driver) back along with provision for other types of feedback analog (4-20 and voltage), serial(rs232,rs422,rs285 and SSI) This would have to be on a break out board zip link style. Basically a CTRIO on I/O steroids would be major improvement over what we have available from AD now
-
We are looking at two things right now: 1) what we do on the bricks, and 2) what we do in a full motion card.
Bricks are moving toward a variant of CTRIO2's Axis Mode, hopefully for three axis.
For the full motion card we are thinking about both analog + encoder and pulse train, but thinking that might be two different cards. I'm not sure that we want to attempt the 24 I/O that would be required for three axis of line driver encoder and stepper, plus the other I/O for limits and such, on a single card. We should be able to fit everything required for analog + encoder *or* pulse train, but probably not both on one card. We'll see.
-
Just the terminals would be a pain. Would you still be able to coordinate well via the backplane if you split to multiple modules? Might you need to make an inter-module connection outside the backplane? Across the module fronts, or a multi-slot module?
-
That's one option. We've lever done it, but I'm sure it could be done.
-
Could you comment on the following estimates of the situation:
1) If multiple axes are spread across multiple modules, I assume communication directly between the two modules will be necessary for coordinated motion. The update time per axis will presumably need to be much faster than maximum scan times in CPU's, so you can't use the CPU as an intermediary, and it would be an unreasonable hit to the CPU anyway,
and
2) I assume that if module to module communication is necessary then the 205 backplane is not an option. First, it was probably not designed with capability for module-initiated comms, especially ones directed not at the CPU but at another module (although the ECOM....). Then, even if module to module comms were theoretically possible, they would probably not be feasible on the scale needed for axis coordination.
Is that all about a reasonable assessment?
-
Could you comment on the following estimates of the situation:
1) If multiple axes are spread across multiple modules, I assume communication directly between the two modules will be necessary for coordinated motion. The update time per axis will presumably need to be much faster than maximum scan times in CPU's, so you can't use the CPU as an intermediary, and it would be an unreasonable hit to the CPU anyway,
and
2) I assume that if module to module communication is necessary then the 205 backplane is not an option. First, it was probably not designed with capability for module-initiated comms, especially ones directed not at the CPU but at another module (although the ECOM....). Then, even if module to module comms were theoretically possible, they would probably not be feasible on the scale needed for axis coordination.
Is that all about a reasonable assessment?
Yep.
-
That's what I thought. Thanks!
-
Which is why the most viable answer is to put it all on one card...even if the one card were a double wide.
-
A single module with a ZipLink Style Termination Strip? You could use the high density connectors and cable from the 32 channel units?
-
A single module with a ZipLink Style Termination Strip? You could use the high density connectors and cable from the 32 channel units?
We may end up doing exactly that.
-
Are you all still continuing on this project. We have been discussing here programming production equipment with G code that way it frees up us controls guys from having to make program changes in the plc and motion controllers to meet productions needs and wants. If we could get the package to allow the process guy to enter in a G code on the HMI and then run the equipment this coould be a really powerful tool.
Thanks
Chris
-
We will likely still do it, but have reevaluated priorities and are doing another project first. I like the idea.
-
We will likely still do it, but have reevaluated priorities and are doing another project first. I like the idea.
Are we working at the same place. That's our normal operation mode.
One side note we just started up a machine with a 200 hp motor that getting to 1 encoder count by just taking the step velocity and multiplying by a scaling parameter then sending that out a analog output to the drives.