#emc | Logs for 2004-12-22

Back
[11:33:33] <alex_joni> morning paul
[11:36:53] <paul_c> Morning Alex
[11:37:15] <alex_joni> what's up?
[11:42:13] <paul_c> Contemplating a rehash of the parport driver to get rid of a race condition.
[12:29:38] <alex_joni> hal_parport.c ?
[12:29:43] <alex_joni> or the emc1 one?
[12:31:47] <paul_c> * paul_c doesn't touch hal
[12:33:18] <alex_joni> * alex_joni remembers
[12:33:19] <alex_joni> :D
[12:41:26] <paul_c> after lunch...
[12:48:12] <alex_joni> * alex_joni agrees
[13:36:14] <jepler> well we didn't get axis 1.0b2 released last night
[13:36:38] <paul_c> Too much to do ?
[13:37:05] <jepler> Working on another project took longer than expected
[13:37:28] <jepler> and just as that was winding down it exposed a fairly nasty bug that I want to fix before releasing
[13:38:12] <jepler> if you load a file, "set next line", then load another file, emc will start in the middle of that second file
[13:40:44] <paul_c> The task state isn't being fully reset when a new file is loaded..
[13:46:47] <paul_c> Morning Tony
[13:47:12] <trp> good morning Paul, I just stopped by to see if anything was happening
[13:47:31] <paul_c> Working on a new BDI build
[13:47:49] <trp> What version will this be
[13:48:08] <paul_c> You may find this one better suited to your needs as the install can be fully automated.
[13:48:51] <trp> I checked out what was happening with development and am wondering how close a lathe is. I did see some work was done.
[13:49:08] <trp> When willl this new BDI be done
[13:49:55] <paul_c> The interpreter accepts a G33 input, the hooks for the canonical commands are in place
[13:50:11] <paul_c> Just the low level RT code to fix up.
[13:51:08] <paul_c> BDI-4.05 is available for testing
[13:51:15] <trp> Seems to be going good. I wish I could help but I have trouble using a telephone much less programming
[13:51:40] <trp> What's new on 4.05
[13:52:19] <paul_c> 2.6.9 kernel, KDE-3.2, totally new build of EMC...
[13:53:07] <paul_c> Space reserved for Synergy - Just waiting for Bob to complete a new package...
[13:53:24] <paul_c> and a brand new installer.
[13:53:38] <trp> Hey by the way I was going to ask this of someone. You may have an answer
[13:54:31] <paul_c> shoot
[13:55:46] <trp> I saw that emc is available for windows. I don't know if you know anything about the rutex drives but they have a tuning software for windows. The rub is you have to be able to controll and run the motors to use the tuning software. Can this version be used in conjunction with the rutex software?
[13:56:14] <trp> Nobody here has knowledge of tuning servos and the software would help enornously
[13:56:52] <paul_c> M$ Windows is not capable of running EMC...
[13:57:31] <paul_c> however, the tkemc GUI can run on a M$ platform and control EMC running on an RT Linux box.
[13:59:40] <trp> huh
[14:00:00] <trp> like I said I have trouble using a telephone.
[14:01:01] <les_away> trp: I'm an old servo tuner....
[14:01:55] <trp> What is the best way to tune them and be consistant with what we are sending out to customers.
[14:02:33] <trp> we need to ship about 6 machines before the middle of january and this is a major holdup
[14:02:53] <les_away> well as far as a cookbook recipe ziegler-nichols is a start
[14:03:20] <les_away> this is for rutex?
[14:03:33] <paul_c> Get in contact with Rutex and see if they will either do a linux port and/or release the code for the tuning app.
[14:05:31] <les_away> Yes as I recall you ported some of my old dos c aps to Linux easily
[14:05:52] <trp> Les,this is for rutex. Paul, I think Ray has done this and said he could find someone to write the code but this won't help in the short distance. Lack of planning!
[14:06:09] <trp> Do you think this is a good way to go
[14:06:43] <les_away> let me get you a good zeigler nichols link here... brb
[14:08:22] <les_away> http://eweb.chemeng.ed.ac.uk/courses/control/course/map/ZN/closednotes.html
[14:08:34] <les_away> required no instrumentation
[14:08:43] <les_away> requires
[14:10:36] <paul_c> trp: RT990H.exe looks to be a native DOS app
[14:11:25] <paul_c> should be fairly easy to port, or maybe run under a DOS emulator..
[14:11:46] <trp> can I find a dos emulator for linux
[14:13:29] <jepler> cradek recently used qemu to run an old DOS version of autocad
[14:13:38] <jepler> r14 for DOS or something
[14:14:04] <paul_c> dosemu, dosemu-freedos
[14:15:38] <trp> I have my laptop here, I think I'll try something out. Will let you know what I come up with.
[14:16:31] <trp> By the way Paul, Everything worked great when you were trying to help me out late that night to get the machine running.
[14:16:48] <paul_c> Just downloaded the rutex zip
[14:17:21] <trp> What I found out is the machine wouldn't run just off the disc. I had the software on another computer and it ran fine off an installed version.
[14:18:03] <trp> The live disc wasn't really. I don't know why though. Just a fyo
[14:18:08] <paul_c> We have a PowerBasic source...
[14:18:50] <trp> PowerBasic is used for what?
[14:19:15] <trp> I need to spend more time learning rather than playing
[14:19:44] <paul_c> It's just another programming language..
[14:22:44] <paul_c> I see... To set the internal PID gains, you need to bit-bang a serial protocol over the parport.
[14:23:44] <trp> theres the rub
[14:24:40] <paul_c> The cable is different to the one needed for EMC
[14:32:12] <trp> We would love to stay with EMC and a tuning procedure for the motors using EMC for warranty or maintenance purposed. If we have to replace a rutex drive or motor for some reason the customer would be stuck with the tuning task and would like to keep it simple for both of us.
[14:35:42] <paul_c> A quick look at the rt990h.bas doesn't reveal anything nasty...
[14:41:37] <paul_c> With the aid of some documentation from Rutex, could probably hack something together that would run under Linux.
[14:44:40] <trp> Do you think the instructions from Rutex would be accurate for using something like that?
[14:46:10] <trp> would it use the same cable for running the machine with or would a special cable still be required?
[14:46:14] <paul_c> Not the R990H pdf I'm looking at..
[14:47:05] <paul_c> To be able to use the same cable with EMC and a tuning app would be preferable for both you and the customer.
[14:47:45] <trp> and for anyone else using EMC and Rutex drives
[15:57:10] <alex_joni> * alex_joni is going home
[15:57:12] <alex_joni> bye
[16:52:34] <jmkasunich> jmkasunich is now known as jmk_away
[18:02:19] <les_away> #@$% arcs are not blended and are always exact stop
[18:03:47] <les_away> I sure would like something that works here...You know I was looking at cannon.cc
[18:04:43] <les_away> I think I could make a smooth tp from those cannonical functions
[18:05:25] <les_away> just don't know where to send it
[18:05:33] <les_away> allthose globals
[18:10:21] <paul_c> cannon.cc has nothing to do with the tp (directly)
[18:10:30] <les_away> I know
[18:10:50] <les_away> but the functions have the info a tp needs
[18:11:30] <les_away> If I just knew how to stick waypoints on the queue
[18:12:39] <paul_c> was it emccanon.cc you were looking at ?
[18:12:51] <les_away> yeah oops
[18:13:01] <les_away> let me check
[18:13:23] <les_away> yeah
[18:14:33] <les_away> so between each waypoint there could be a cubic...ax^3+bx^2+cx +d
[18:14:52] <les_away> a,b,c,and d would change for each segment
[18:15:13] <paul_c> like what is done in cubic.c ?
[18:15:35] <les_away> yes...but that does not seem to function
[18:15:49] <les_away> or it functions only at servo update
[18:16:17] <les_away> it's too "tight" to do anything
[18:17:05] <les_away> it just interpolates the trapeziods into closely matching cubics
[18:17:36] <les_away> what is needed is a cubic replacement for the trapezoidal segments in the planner
[18:18:23] <les_away> I have the math in closed form
[18:18:53] <les_away> it only needs the next 4 points to do a current cubic
[18:19:07] <les_away> at the trajectory rate...not the servo rate
[18:19:54] <les_away> let me glance at something in emcmot....
[18:32:28] <les_away> hmm if the ratio of traj cycle time to axis cycle time is low things would seem to get smoother
[18:32:34] <les_away> I will test that
[18:39:22] <babu> do i have to use GCC-2.9x series to compile EMC2/cvs. I use kernel-2.4.7, rtai vesuvio, debian unstable and gcc-3.3.5
[18:40:04] <paul_c> Use the same compiler for EMC that was used for the kernel/RTAI
[18:40:50] <babu> emc2 compiles, but when i start tkemc axis speed is set to a real huge number (284000) and does not work as expected. when i close it emc2 stays running an can't be finished cleanly
[18:41:22] <babu> * babu compiled kernel, rtai and emc2 in this sort order and all with the same gcc
[18:41:44] <paul_c> Should work then.
[18:41:55] <paul_c> * paul_c disappears for tea.
[18:48:16] <babu> hmm
[18:56:11] <babu> after closing tkemc and interrupting emc.run script with a ctrl-c (bash) i get iniaxis: dumpAxis(0, ....)
[19:22:02] <jmk_away> jmk_away is now known as jmkasunich
[19:42:15] <babu> hmm choosing a high accel on my stepper system (EMC2) causes e-stop (following error?)
[19:44:12] <tbl> following error?
[19:45:30] <babu> ferror is set to 1.0 (for a short try to 10.0) an min_ferror is set to 0.1 (for a short try to 1.0) helps just a bit
[19:45:57] <babu> can drive some mm but afterwards.. EMC_AXIS_ABORT (debug output) and e-stop
[19:49:23] <les_away> hopr emc2 inherited that ferror fix
[19:50:25] <jmkasunich> babu: can you send me your .ini and .hal files?
[19:50:42] <les_away> but in case not...just set min_ferror to a big number. If you are using stepper it is virtual anyway
[19:52:17] <jepler> babu: EMC_AXIS_ABORT is the name of the message sent from the frontend to emc to end a continuous jog. It is not an error message.
[19:52:54] <jmkasunich> it is also sent whenever emc wants to stop the motion controller for any other reason
[19:57:26] <les_away> hmmm tried to call Fred...think he is taking time off
[19:58:18] <babu> i'll send you my config, have a look because i cleaned up emc.ini for emc2
[20:00:54] <babu> emc.ini is @ http://www.pastebin.com/132391
[20:01:35] <babu> core_stepper is @ http://www.pastebin.com/132392
[20:05:22] <jmkasunich> which axis causes the problem? all of them?
[20:05:53] <babu> i just tried 0 and 1 because 2 is not finished yet
[20:05:59] <jmkasunich> ok
[20:06:07] <jmkasunich> * jmkasunich reads files
[20:07:02] <jmkasunich> 100mm/sec max speed = 8000 steps/sec, that should be OK
[20:07:52] <jmkasunich> 400mm/sec^2 means it will take 0.25 seconds to go from stop to max speed
[20:08:52] <babu> yepp, thats fast i guess
[20:08:57] <jmkasunich> 0 to 8000 steps/sec, in 0.25 sec, is 32000 steps/sec^2 acceleration
[20:09:16] <jmkasunich> but in core_stepper.hal you set maxaccel to 4000
[20:09:23] <jmkasunich> I think you wanted 40000
[20:09:57] <babu> hmm you are right, i'll this, pls watch out for other mistakes. did i overclean the emc.ini?
[20:10:05] <jmkasunich> because maxaccel is too slow, emc can ask stepgen for accel that it cannot deliver, so it falls behind and you get a ferror
[20:10:30] <jmkasunich> no - I think removing things you don't use is smart
[20:10:53] <jmkasunich> but we don't do that from the files in CVS because we don't know what other people will use
[20:14:09] <babu> i removed all things that emc2 doesn't even read from the ini
[20:14:30] <babu> * babu is happy to see his machine running! thx to jmk
[20:15:38] <babu> i set the ferror and min_ferror back to 1.0 and 0.1. when is start up tkemc a axis speed of 3600 is (pre)selected
[20:17:24] <jmkasunich> 3600mm/min = 60 mm/sec
[20:17:59] <babu> the machine does "dangle" abit if feed on all axis is 0 perhaps one step for one step back. it must be emc which does some kind of controll, because when i close emc the dangeling stops
[20:18:00] <jmkasunich> I don't know how tkemc picks the speed - I mostly work on the motion controller
[20:18:31] <babu> ah mm/min didn't know that
[20:18:50] <jmkasunich> * jmkasunich must hurry up and fix that "one step forward one step back" bug
[20:20:02] <babu> you are kidding, is it a real bug or just a mistake in my config?
[20:20:14] <jmkasunich> a bug in stepgen
[20:20:30] <jmkasunich> it "hunts" up to +/- 1 count around the desired position
[20:21:54] <jmkasunich> http://sourceforge.net/tracker/index.php?func=detail&aid=1020880&group_id=6744&atid=106744
[20:27:35] <babu> ok so i can confirm the exsistence of that error
[20:30:08] <jmkasunich> I can replicate the error here too
[20:30:21] <jmkasunich> I will work on it as soon as I can find my workbench
[20:30:29] <jmkasunich> (very very messy)
[20:33:54] <tbl> hey JMK, how goes it?
[20:34:02] <jmkasunich> hectic
[20:34:09] <tbl> story of my life!
[20:34:22] <jmkasunich> my middle name should be scrooge - I hate the christmas season
[20:34:33] <tbl> haha
[20:34:44] <tbl> i like xmas
[20:35:16] <jmkasunich> end of the year - I take all my previously unused vacation time
[20:35:24] <jmkasunich> two hole weeks
[20:35:35] <jmkasunich> and how much of it do I actually get to enjoy?
[20:35:44] <tbl> by two weeks of vacation
[20:35:54] <tbl> i think what you really mean is two weeks of emc2 development!
[20:35:58] <jmkasunich> between shopping and other xmas prep before xmas, and travel to visit relatives after, maybe 1-2 days
[20:36:07] <jmkasunich> I wish
[20:36:55] <jmkasunich> so far mon-wed, I've spend several hours (broken up into smallish chunks) on IRC, and haven't had _any_ of the long uninterrupted spans that make for good coding
[20:37:36] <jmkasunich> and I still have a couple hours to spend on a metalworking project for a paying customer before the weekend
[20:38:09] <tbl> nice
[20:38:26] <jmkasunich> I'd rather spend those couple hours coding tho
[20:38:53] <jmkasunich> in this case "paying customer" means "can't put off until later"
[20:41:01] <jmkasunich> babu: are you serious about wanting those linear motors?
[20:41:16] <jmkasunich> like "$500 + shipping" serious?
[20:51:52] <babu> jmk: if i knew they are ok and if i knew a sum which makes you happy (doing all that paperwork) and is payable to me - i would need lets say 2 days to find out if we are in deal or not
[20:52:48] <babu> my english is horrible i know - it will be far better after 3 years school with english education
[20:53:59] <jmkasunich> 500+shipping would make me happy I think. Knowing that they are OK is harder
[20:54:09] <jmkasunich> I don't have the drives for them as you know
[20:54:21] <jmkasunich> your english is fine
[20:54:32] <jmkasunich> I can test the motor windings with an ohmeter
[20:54:53] <jmkasunich> I don't know how to test the hall effect sensors, I don't have pinout information for them
[20:55:23] <jmkasunich> I might be able to test the encoders, if I can find the pinout - I have a power supply and oscilliscope here
[20:55:24] <babu> it would be sufficient to me if you could do some visual inspection... perhaps the ohmeter...
[20:56:03] <jmkasunich> I would feel really bad about taking a "poor student's" money for something that he couldn't actually use
[20:56:15] <babu> what would you sell to me for 500 bucks? motor, encoder, hall, cable (like on the picture)
[20:56:22] <jmkasunich> these will be hard to pack and ship
[20:56:50] <jmkasunich> yes - if you are actually going to use it, I would _not_ keep the encoder for myself, I would let you have it all
[20:57:16] <jmkasunich> the big one is about 20Kg, the smaller one probably 15Kg
[20:57:24] <babu> i'm not poor yet. in the moment im working and earn 3000 $ / month, but i will study for the next 8 years
[20:58:04] <jmkasunich> I just posted two more pictures, one of the carriage and one end view
[20:58:31] <jmkasunich> http://home.att.net/~jmkasunich/Pics/endview.jpg
[20:58:46] <jmkasunich> the overall width is ~185mm
[20:58:48] <babu> i'm getting nervous thinking to _have_ those!
[20:59:14] <jmkasunich> height about 100mm
[20:59:36] <jmkasunich> length of the long one 915mm
[20:59:57] <jmkasunich> travel 600mm
[21:00:24] <jmkasunich> the short one is the same width and height, but 615mm long, with 300mm travel
[21:01:32] <jmkasunich> the shorter one doesn't have an encoder like in the picture, it has a renishaw "tape" encoder next to the magnets (on the inside of the "wall" at the right side of the aluminum extrusion
[21:02:13] <jmkasunich> I'm nervous about packing them to travel safely - they are very long and thin - I don't know what I would pack them in
[21:02:40] <dave-e> pvc pipe?
[21:02:44] <paul_c> wooden crate
[21:03:05] <jmkasunich> crate I think
[21:03:06] <babu> seems ideal to me! the only thing is how to bring them from your home to my home. today we have the 22st could you give me time until the 24th
[21:03:15] <jmkasunich> take your time
[21:03:38] <jmkasunich> I will be traveling from the 26th to the 1st... let me know after the 1st if you are interested, and we can work out details
[21:03:45] <babu> perhaps it is best to spend 20 $ to de delivery company to pack them
[21:04:14] <jmkasunich> I can make a wooden crate - I have wood, screws, glue and a table saw
[21:04:27] <jmkasunich> the crate will just make them heaver and more expensive to ship
[21:04:49] <jmkasunich> 20Kg + 15Kg + 5Kg crate = 40Kg = 88 lbs.
[21:04:58] <babu> ok i will ask some frinds about shipping and after that i'll make my decision. i will give you feedback until the 1st jan 05
[21:05:11] <jmkasunich> sounds good to me
[21:06:06] <jmkasunich> one last pic: http://home.att.net/~jmkasunich/Pics/carriage.jpg
[21:06:15] <babu> cheapest packing depends what is rated: weight or volume...
[21:06:27] <jmkasunich> these are heavy for their size
[21:06:52] <babu> i definitfly love them!
[21:07:03] <jmkasunich> I almost forgot: http://home.att.net/~jmkasunich/Pics/plugs.jpg
[21:07:19] <jmkasunich> I have the mating plugs for those strange "MTR" plugs
[21:07:46] <jmkasunich> with 1-2 meters of cable attached
[21:08:11] <babu> those big nipples does look like 3 phase connection but whats up with does 5 little nipples in the middle?
[21:08:24] <jmkasunich> the three big ones are the three phase winding
[21:08:29] <jmkasunich> I don't know about the little ones
[21:08:46] <babu> i know: temperature sensors! perhaps pt100
[21:09:06] <jmkasunich> * jmkasunich gets out the ohmeter
[21:11:18] <jmkasunich> only one of them has a wire connected to it
[21:12:21] <babu> one pin?
[21:12:35] <babu> whats with the 4th nipple
[21:12:58] <jmkasunich> the fourth large pin is ground, I think
[21:13:11] <jmkasunich> * jmkasunich is uploading another picture
[21:19:30] <jmkasunich> http://home.att.net/~jmkasunich/Pics/connectors.jpg
[21:19:42] <jmkasunich> that shows the connectors attached to the slide
[21:20:00] <jmkasunich> the motor and hall connectors go to the coil assembly
[21:20:05] <jmkasunich> the encoder cable doesn't have a connector
[21:20:30] <jmkasunich> the other end of each cable goes to the plugs shown in the earlier photo (on the end of the assembly)
[21:20:46] <jmkasunich> (this picture is from the side, with the cover removed)
[21:21:34] <jmkasunich> the only small pin on the motor connector that is actually used has a green wire connected to it
[21:25:49] <jmkasunich> I posted a url with the motor specs yesterday, did you get it?
[21:26:34] <jmkasunich> http://www.rockwellautomation.com/anorad/products/linearmotors/ironcore/lck.html
[21:28:43] <jmkasunich> looks like the hall effect pinout is listed at the bottom of that page
[21:30:38] <babu> its nice to have those infos given on that page
[21:30:50] <babu> to find out all that stuff would be hard
[21:31:15] <babu> most problem will be to find a suited driver which is inexpensive
[21:31:20] <babu> enough
[21:32:03] <babu> but i think the motors can be driven by a smaller voltage/current giving a lower force
[21:34:16] <jmkasunich> force is proportional to current, speed is proportional to voltage
[21:35:26] <jmkasunich> I hooked one winding to a 24V power supply just to see what would happen - it generates a pretty good force (24V/7.8ohm = 3.08A)
[21:36:38] <babu> thats what i think... it would dislike to install water cooling... 338 - 738 N Peakforce is alot!
[21:37:30] <babu> * babu has to go for a short sleep
[21:37:52] <jmkasunich> goodnight
[21:38:01] <babu> goodnight all
[21:39:04] <paul_c> * paul_c ponders the us oh halscope for another roject
[21:39:57] <les_away> well I have a first
[21:39:57] <jmkasunich> what project would that be?
[21:40:19] <les_away> cnc machine is down for the first time
[21:40:32] <les_away> grr
[21:40:44] <jmkasunich> what's wrong?
[21:40:58] <les_away> somethin with the estop
[21:41:24] <les_away> I designed it..gues I can figure it out
[21:41:39] <les_away> a latching relay isn't firing
[21:41:40] <jmkasunich> ;-)
[21:41:48] <les_away> coil res seems ok
[21:42:21] <les_away> limit switches etc fire a 5v relay
[21:43:02] <les_away> that fires a great big contactor that connects the servos and spindle power etc
[21:44:04] <les_away> seems like eve n snubbed latching relays don't last long
[21:44:19] <les_away> just replaced two in an audio power amp
[21:45:11] <les_away> oh well
[21:47:19] <paul_c> jmkasunich: Graphing some non-realtime stats
[21:48:03] <jmkasunich> I'd think gnu-stripchart would be better for that?
[21:52:17] <paul_c> could use cgi for some of it...
[21:55:42] <paul_c> stripchart lacks any widgets for triggers & scales.
[21:55:51] <jmkasunich> I see
[21:56:34] <les_away> found the problem!
[21:56:40] <jmkasunich> would you somehow make the stuff you want to monitor into HAL signals? or would you replace the sampling code with somthing that accesses your data directly?
[21:57:01] <les_away> I have big red button estop switches all around the machine
[21:57:13] <les_away> most never get pressed
[21:57:27] <les_away> normally closed for safety
[21:57:28] <jmkasunich> except today ;-)
[21:57:54] <les_away> well contacts never wipe clean if they are not pressed for years
[21:58:19] <les_away> so just clicked em a few times
[21:58:23] <les_away> fixed
[21:58:38] <paul_c> jmkasunich: data input is from a file descriptor
[21:59:02] <paul_c> either a /dev entry or a saved file.
[21:59:20] <jmkasunich> so you'd hack the data acquisition code
[22:02:23] <paul_c> would, but hal affects several files.
[22:05:02] <paul_c> Hmmm... ksysguard
[22:10:34] <paul_c> got it - Use Qt and slots for the data acquisition.
[22:59:38] <jmkasunich> jmkasunich is now known as jmk-away