-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/22/2013 7:19 PM, Bart Dring wrote: > Hi, > > I am working with a group of CNC builders at the Chicago > HackerSpace Pumping Station One. We are building a "simple" 2D > drawing machine. The machine uses 2 belt driven carriages on a > single linear bearing. You can see the details of the machine at > this link. > > http://pumpingstationone.org/2013/06/cnc-gonzo-build-2-recap/
A very cool setup! I'm not really qualified to help, but thought I'd chime in since I think most of the primary developers are still at the Dev-Fest in Wichita. > We are having trouble getting it to work in EMC. When we turn on > the machine in EMC, both carriages immediately race at full speed > towards the home switches. They trigger the switches, but keep > trying to go. We looked at the switches in HalScope and they appear > to be functioning properly. If we use F2 to quickly turn the > machine on then off before the carriages crash, we can turn it back > on and the carriages do not move spontaneously anymore. > > Using the MDI tab with G code commands we are able to get X motion > at the pen. That is pretty simple because for X, both carriages > always run at the same speed and direction as the pen. We can > command the pen to move in Y, but only at very low speeds. If we > try to go fast EMC gives us all sorts of joint speed and position > errors. > > There is a link to our kinemantics file at the link above. (We > just modified trivkins.c). At this point I think it has been hacked > beyond our initial successes, to completely broken. Other than review the kins file Andy pointed to, I would add when the system starts up you are probably in a state where X=0, Y=0, joint[0]=0, and joint[1]=0, which is basically impossible given the structure of your machine (it doesn't look to me like the two carriages can be in the same location, and if they are, Y=<max> instead of zero). I would recommend moving the Y=0 spot to the middle of your Y travel and perhaps try to clip potential illegal values in your kinematics routines or look for other initial value assumptions that could cause problems (how does your kins deal with negative Y, for example?). Otherwise, for debugging, you can try to work out some stuff with just HAL, but since this is a motion/kins issue, you might not get far that way. Instead, you could: * Yank the motor drive completely. It looks like you've got steppers w/o encoder feedback, so you should be able to just pull the motor connections and manually press the limit switches to test your homing. * Dial your maximum velocity *WAY* down in the *.ini file so instead of slamming into the limits when the machine turns on, it _creeps_ towards them and gives you a chance to hal-scope what's going on. * If you want time to setup hal-scope before LinuxCNC goes active, you should be able to wait on a user HAL function to complete (ie: loadusr - -w delay.sh), or just launch halscope in the background using a hal loadusr function if you've previously setup a halscope file. That way you should be able to see the initial conditions that lead to the runaway motors. Good luck! - -- Charles Steinkuehler [email protected] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHGd9kACgkQLywbqEHdNFxi0QCfWUmiHQvhLU+RdV57H81UnHTS JBgAoOxFb2Vn3+uwNjmbFVxrIf6EC5wJ =qM5o -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
