Patrick Ferrick wrote: >Hi all, > >After reading (and (for the most part) understanding) the integrator's >manual, I have come up with the following plan for constructing and >controlling a custom toolchanger. The changer will use three steppers, >one to spin a carousel of sorts and two to operate a scara-type arm to >place tools from the changer somewhere that they can be taken up by the >spindle. > >1. obtain and set up a second pc running EMC2 > > No problem.
>2. connect the mill's pc and the toolchanger's pc via ethernet cable > > No problem. >3. determine the correct NML messages needed to carry out the steps for >a toolchange > > Not simple, but not a big problem. Tool change messages have a separate nml command/status channel (I think). I believe you can get the messages going to the other machine by changing the NML files. This will cause all tool messages to go there, but that's probably what you'd want anyway. >4. add a button/code to AXIS using pyVCP to generate these messages > > It's automatic - T6 causes a tool prep message to be sent to the toolchanger (prep tool 1). M6 causes a change tool mesasge to be sent, etc. >5. figure out how to send the messages by connecting the button to the >parport with HAL > > Again, automatic. > Pretty simple, right? My rationale for this somewhat convoluted >sequence of events is that I think I can get all that going with what I >already know how to do with HAL etc. > > Well, the part above is simple, but it doesn't actually get the tools to change. You still need a way of making a tool change message turn into motion commands for the 3 motors. Either you need to change NML (I wouldn't even consider doing that) so there's a way to send arbitrary commands to a remote machine (while still operating the "local" machine), or you still need to get some HAL-foo working to do the tool changes. Actually, I think you'd need the HAL-foo anyway. >Based on my reading of the manual, it's going to take a good while >before I can get pull it off with straight HAL/ClassicLadder objects. >I'm going to work on that at the same time, so I'll probably get it to >work the "right" way at some point. > > I'd strongly suggest going straight to the right way :) HAL has all the motor limits already - stepgen won't do anything beyond the limits you set, and you can use a limit3 block if you want to use servos. Kinematics for an R-theta robot are trivial, and they're really unnecessary anyway since you can just specify the positions you want in cylindrical coordinates. You only need the motion controller and its kinematics if you want to specify cartesian coordinates for non-cartesian actuators. It's very easy to write a HAL component that outputs a sequence of positions whenever it's "clocked" - this can be done in comp I think. There are only a few positions anyway - you could almost do it with mux4 blocks as was suggested before. >Comments? > > If you haven't already, I think you should define what the motions and I/Os for the toolchanger will be: what needs to happen at start-up? (homing ...) what needs to happen to take a tool out of the spindle? what needs to happen to put a tool in the spindle? what needs to happen to get the right tool in the robot pickup position? what does the robot need to do to grab the tool from the holder? what does the robot need to do to place a tool in the holder? Once you know all the actions needed, you can start to think about how they need to be sequenced: at tool-prep: rotate carousel to correct position (or not - can the robot hold two tools at once? do you need to put away the old tool first?) at tool-change: rotate carousel to slot for tool in the spindle (closest direction or always forward?) stop spindle position robot to grab tool in spindle transfer tool from spindle to robot move robot to carousel drop tool in carousel move robot clear of carousel ... You get the idea :) Once you know exactly what has to be done, it's a lot easier to decide how to implement it. >Thanks, >Pat > >ps - It often occurs to me when I'm generating these posts that a twenty >minute conversation with one of you EMC gurus would be worth about a >month of back-and-forth on the list. Unfortunately, the NAMES show >happens right in the middle of exam week for me, so that's a little >tough. If anybody would be willing to try a brief phone conference >please email me privately...! > > <http://www.cnc-workshop.com> could be a good opportunity - it should be after exams. Then you can talk to almost all of us, so you can pick whichever person tells you what you want to hear ;) - Steve ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
