#emc | Logs for 2009-06-16

Back
[00:00:01] <SWPadnos> the price coulld be anywhere from $100 to $100,000
[00:00:17] <SWPadnos> even used
[00:00:17] <SWPadnos> (though I wouldn't pay $100k for a used machine)
[00:00:26] <SWPadnos> unless it used to be a $1m machine or something :)
[00:00:42] <toastydeath> used three axis mills, no whistles, go for 5k-60k usually
[00:00:43] <SWPadnos> err, $1M
[00:00:43] <i-pink> OMG...
[00:01:00] <toastydeath> 5k is usually a little beaten on, older control, brushed servos
[00:01:02] <i-pink> i feel blond..
[00:01:06] <SWPadnos> heh
[00:01:11] <SWPadnos> you do have a pink laptop ...
[00:01:19] <i-pink> yes
[00:01:40] <i-pink> servo is bether then stepper?
[00:01:49] <toastydeath> yes
[00:01:49] <SWPadnos> by most measures, yes
[00:03:55] <i-pink> mmm ok
[00:05:23] <i-pink> maybe switch to servo motor?
[00:19:08] <jepler> lerman: the first thing I've learned about those $15 servos is that it'll cost me $30 in parts for the mounts, and then the labor to make them..
[00:20:04] <lerman> What are you mounting them on? Titanium?
[00:20:24] <toastydeath> orphaned children
[00:21:57] <jepler> lerman: the pulleys are about $9 each, two per motor (big and small). $2 for belts. some tooling. some screws and whatnot. some aluminum for the mount itself.
[00:22:24] <jepler> direct drive would have been in the same ballpark, with a $20ish flex coupling (cradek thinks a rigid coupling would just break the motors)
[00:22:39] <lerman> Wouldn't you need those for any motor?
[00:23:22] <jepler> the steppers were direct drive and rigid coupling
[00:23:38] <lerman> Make a flex coupling. The type that looks like a cylinder with slots should be easy to make.
[00:23:42] <jepler> (you saw the machine)
[00:24:03] <lerman> Ah. Didn't realize you were reworking that.
[00:24:19] <jepler> yeah
[00:24:38] <jepler> I failed to follow rule 1a: if it's broken, fix it only proportionally to the brokenness
[00:26:13] <lerman> Now that you have plenty of aluminum stock, you can replace the UHMWPE structure with aluminum.
[01:03:37] <stustev> good evening
[01:04:43] <stustev> I still want to know how to run my sim (or any other I add) without the emc.nml file in the config directory
[01:11:18] <SWPadnos> stustev, use TRUNK, and remove the reference to the nml file from the ini
[01:11:45] <SWPadnos> you need to have a common directory though, probably at ~/emc2/configs/common
[01:12:07] <SWPadnos> assuming that you use ~/emc2/configs/<something> as the config dir
[01:12:14] <SWPadnos> bbl
[01:13:05] <stustev> i am using trunk - and it worked - thanks
[02:39:01] <jepler_> jepler_ is now known as jepler
[02:39:05] <jepler> * jepler spanks his internet connection
[02:40:24] <SWPadnos> ooooh. naughty
[02:47:23] <jimbo132> Ok back to onre of the earlier questions. is halui where the code for the display of the data for the XYZ position is located and kept?
[02:47:40] <SWPadnos> display in what program?
[02:47:48] <jimbo132> Axis
[02:47:53] <SWPadnos> no
[02:47:59] <SWPadnos> axis does its own calculations
[02:48:11] <jimbo132> What program keeps that data?
[02:48:16] <SWPadnos> axis
[02:48:37] <SWPadnos> there is a status buffer that's available to all the UIs (including halui and axis, tkemc, mini ...)
[02:48:54] <SWPadnos> each has to inspect the status, and make its own decisions about what to display
[02:49:39] <SWPadnos> you could have two UIs running, one showing commanded and the other showing actual position
[02:49:40] <jimbo132> Is this buffer part of shared mem
[02:49:58] <SWPadnos> it's an NML channel
[02:50:35] <SWPadnos> so it's in a buffer, though I'm not sure what happens when a client reads the buffer (it could get a copy or a pointer to a shared area, I'm not sure)
[02:50:55] <jimbo132> Not used that. so if I want to send the actual data out serial ports what would be the best place to add this code?
[02:52:02] <SWPadnos> hmmm
[02:52:43] <SWPadnos> there was discussion about adding either (a) pins to AXIS or (b) position outputs to halui, but I'm not sure which of those, if any, was actually done
[02:54:51] <jimbo132> In my vision if I do this I will not need the position locations in Axis as I will have VFD displays showing this data.
[02:54:52] <tomp> tomp is now known as tom3p
[02:55:34] <SWPadnos> understood. you would need switches to select between the various display modes
[02:56:13] <jimbo132> Yes, I have an afinity for old looking hardware with VFD/Nixi displays.
[02:56:14] <SWPadnos> I think the main issue with implementing this was that the display device/software needs to know what coordinate system you're using, what its offsets are, G92 offsets, etc.
[02:56:25] <SWPadnos> it's not simply print a single number per axis
[02:56:33] <SWPadnos> cool by me :)
[02:57:47] <jimbo132> So you can't take the data that AXis would display for each and simply output that data to 3 serial ports. one for each axis
[02:58:42] <SWPadnos> you can only do that if you either have the data AXIS is displaying (if it exports pins with that data), or you know what mode the AXIS display is in and perform the same calculations on the raw(ish) data in the status buffer
[03:00:27] <jimbo132> please explain pins to me. I would assume that the number that is generated in AXIS prior to output to the dispaly counl be output to an opend serial port?
[03:00:52] <SWPadnos> HAL pins
[03:01:09] <SWPadnos> the things that let you connect HAL components together
[03:01:18] <jimbo132> OK
[03:01:31] <SWPadnos> the displayed number could be output, if you want to modify AXIS to do that
[03:01:45] <jimbo132> what language?
[03:01:49] <SWPadnos> python
[03:02:04] <SWPadnos> plus tk, and some python extensions in c
[03:02:35] <jimbo132> you are trying to expand my horizons.... I know shell, C and thats about it....
[03:02:49] <SWPadnos> heh
[03:02:57] <SWPadnos> AXIS is not my fault :)
[03:03:07] <SWPadnos> (it would be nice to be able to claim it was)
[03:03:45] <jimbo132> Is Python interpited/
[03:04:09] <SWPadnos> sort of
[03:04:12] <SWPadnos> it's interpreted :)
[03:04:23] <jimbo132> Thank you....
[03:04:40] <SWPadnos> AXIS is a text file, though the extensions are compiled
[03:05:37] <jimbo132> How do you handle IO with python?
[03:06:27] <SWPadnos> I think there's a library called pyserial
[03:06:39] <SWPadnos> but I definitely have no idea how to use it. I'm a python neophyte
[03:07:14] <jimbo132> I'm even worse but I may become great frinds.....
[03:07:21] <jimbo132> freinds
[03:09:48] <jimbo132> I am assuming that Ubuntu has a copy of python?
[03:09:50] <SWPadnos> you'd be much better off making friends with jepler - he actually knows python
[03:09:57] <SWPadnos> yes, or you wouldn't be able to run AXIS
[03:10:15] <SWPadnos> there is no IDE or anything, but the python interpreter is there
[03:10:53] <jimbo132> so ther is no developer kit per say...
[03:11:12] <SWPadnos> not really
[03:11:33] <SWPadnos> you can get any number of editors that look like IDEs, and there are some good documentation packages you can download
[03:11:46] <SWPadnos> via synaptic/apt
[03:12:55] <jimbo132> Is the code for axis part of the developers download?
[03:13:08] <SWPadnos> it's interpreted, so it's part of the normal download even
[03:13:36] <jimbo132> Cool I will download and take a look...
[03:14:07] <SWPadnos> if you want to modify axis, you will want to keep a diff of the changes you make, since anything you do will be overwritten whenever you upgrade EMC
[03:14:48] <jimbo132> OK if it all works you might also want it :)
[03:14:56] <SWPadnos> incidentally, there may be an easier way - I do remember discussion about displays, but I don't remember the outcome
[03:15:05] <SWPadnos> it might have been the DRO tab in AXIS :)
[03:15:40] <SWPadnos> you might want to take a look at emclcd - it might be able to print positions, and it's a C program
[03:16:05] <jimbo132> That would be much better for me
[03:18:13] <tom3p> SWPadnos: i got servo max jitter down to 25237 and base down to 26039 by going to vesa :) , turning off smi left me at 2.1 million still ( btw: the .ko is on the live install, just not run by default )
[03:18:17] <tom3p> thx :)
[03:18:35] <SWPadnos> jimbo132, of course you would need the emc2-dev package and the source as well
[03:18:41] <SWPadnos> tom3p, cool
[03:18:47] <SWPadnos> were you using the mga driver before?
[03:19:27] <tom3p> hmm. hard tro say, X11 calls it "the previously configured device" , i was plugged into the MGA tho
[03:19:47] <jimbo132> SWpadnos: Is that not part of the source download?
[03:20:11] <SWPadnos> apt-get source will give you the exact source used to build the installed package
[03:20:32] <SWPadnos> a cvs checkout will give you whatever snapshot you want
[03:20:47] <SWPadnos> neither will install the software needed to actually compile emc
[03:21:12] <SWPadnos> apt-get build-dep emc2 will get pretty much everything (but not CVS - you'll have to install that yourself)
[03:21:40] <SWPadnos> apt-get emc2-dev will install some other things that are useful for emc2 development, though I don't recall exactly what at the moment
[03:22:08] <SWPadnos> (emc2-dev could be a subset of the build-deps, such that you can use comp and make new components but not generate the debian packages)
[03:25:29] <jimbo132> I am feeling dumb as a stump CVS is this the c development system for Ubuntu? More fluent in SUSE...:)
[03:25:37] <SWPadnos> no
[03:25:54] <SWPadnos> Concurrent Versioning System - the source code management system we use
[03:26:20] <jimbo132> How does one aquire this ?
[03:26:41] <SWPadnos> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CVS
[03:27:45] <jimbo132> Thanks
[03:27:59] <SWPadnos> sur
[03:28:01] <SWPadnos> e
[03:31:36] <tom3p> SWPadnos: re: the intel mobo latency. i couldnt make the G450 pci the primary in BIOS,
[03:31:36] <tom3p> BIOS has 2 options for this, PCI and AGP,
[03:31:36] <tom3p> I only have PCI G450 and whatevers on mobo.
[03:31:36] <tom3p> I guess the mobo is 'AGP' but, when i select PCI, i get >no< vid on either cnx. when i select AGP, i get vid on >both<
[03:32:01] <SWPadnos> weird
[03:32:15] <SWPadnos> I wonder if you have to put it in some specific slot
[03:32:29] <cradek> jimbo132: I didn't read the whole conversation and I'm not sure if I said it already last time, but my approach would be to start with halui (or xemc, same idea) and throw out everything you don't need, then add the serial port goo to the main loop.
[03:32:43] <tom3p> will try that, thx
[03:33:16] <SWPadnos> sometimes the AGP slot shares an IRQ with one (or more) PCI slots
[03:33:25] <SWPadnos> who knows what else is going on
[03:33:43] <tom3p> hello? mr. who? can you tell me....
[03:34:01] <SWPadnos> Horton is unavailable at the moment
[03:35:16] <jimbo132> are halui and xemc both written in "c"?
[03:35:53] <SWPadnos> dunno - check the extensions on the source
[03:36:01] <SWPadnos> some might be c++-ish
[03:36:02] <jimbo132> OK
[03:37:08] <jimbo132> Oh well more chances to learn.....:)
[03:37:36] <cradek> everything that talks nml is at least a little bit c++, but only barely
[03:38:19] <jimbo132> Then thats a good thing.
[03:39:15] <cradek> if you can read any C, you'll be fine
[03:39:49] <cradek> the other thing you might consider is linking with shcom.cc, which is the shared nml communication routines that all the interfaces should be using (they have a lot of duplicated code)
[03:47:15] <jimbo132> so shcomm.cc is like a shared memory routine that you can open and have access to?
[03:48:31] <jimbo132> I am an old UNIX sysadm so I think more in unix terms. not as versed on the new stuff...
[03:48:50] <SWPadnos> shared communications, I believe
[03:48:57] <cradek> there's boilerplate in there for making the nml connections and then sending messages that UIs like to send like sendMistOn() to send an EMC_COOLANT_MIST_ON message
[03:49:05] <SWPadnos> it happens to be a memory buffer on a single machine
[03:49:38] <SWPadnos> another interesting possibility - implement the necessary NML on a microcontroller. NML is supposed to have a serial transport oprtion
[03:49:45] <SWPadnos> option
[03:49:47] <cradek> I don't know the details of how nml works and I suggest you don't have to either - just do what the other guis do
[03:49:52] <SWPadnos> heh
[03:49:59] <SWPadnos> that's not as "interesting" :)
[03:50:12] <SWPadnos> (though it's likely to be successful much sooner)
[03:50:17] <cradek> well there's "interesting" and "I want my display to work", haha
[03:50:40] <cradek> I usually like to avoid "interesting"
[03:50:42] <jimbo132> I like the quick and dirty myself.
[03:50:46] <SWPadnos> I don't know that the serial server was ever implemented actually
[03:50:57] <SWPadnos> I know it was intended to run on microcontrollers for I/O
[03:51:16] <SWPadnos> that was an explicit use case
[03:51:31] <jimbo132> Time to take the Boss out for dessert...bbl
[03:51:41] <SWPadnos> see you . time for be here, I think
[03:51:43] <SWPadnos> bed
[06:12:27] <jimbo132> the communications through shcomm.cc does this syncing multiple GUI like axis and keystick
[08:01:39] <micges1> micges1 is now known as micges
[09:36:21] <piasdom> g'mornin all
[09:54:50] <seb_> seb_ is now known as sebjames
[11:22:10] <anonimasu> * anonimasu is ordering broaches
[11:25:02] <archivist> expensive
[11:28:26] <anonimasu> hm.. I dont know yet..
[11:28:32] <anonimasu> I doubt a 5mm broach will kill my budget
[11:29:21] <anonimasu> im making fixtures :)
[11:29:24] <archivist> or reamer?
[11:29:49] <anonimasu> dunno the difference
[11:29:56] <archivist> * archivist hates the common confusion of the names
[11:30:13] <archivist> broach is pushed through
[11:30:24] <archivist> reamer is rotated
[11:30:30] <anonimasu> your language is fucked up..
[11:30:45] <archivist> hehe no
[11:30:48] <anonimasu> they are both broaches in swedish :)
[11:30:59] <anonimasu> indeed, they are reamers
[11:31:16] <archivist> clock trade uses broach to mean taper reamer as well
[11:31:27] <anonimasu> http://smartchoice.dormer.sandvik.com/JPG_PIC/B168.jpg
[11:31:40] <anonimasu> and I have 5mm ground pins on order :)
[11:33:32] <anonimasu> though I'm not sure if H7 is tight enough.
[11:34:29] <archivist> clockmakers broach http://www.j-m-w.co.uk/gfx/pt23.gif
[11:34:44] <anonimasu> :)
[11:35:09] <archivist> 5 sided plane edge only cuts brass
[11:35:20] <anonimasu> :)
[11:35:23] <anonimasu> cute
[11:37:33] <archivist> to me broach really means http://www.max-t.co.uk/images/keywayBroach.jpg
[11:38:31] <archivist> or http://www.warrenbroach.com/splineBroach.html
[12:09:02] <anonimasu> done..
[12:09:06] <anonimasu> and some endmills too :)
[12:09:24] <anonimasu> the broach was like 17 eur
[12:10:11] <archivist> I need more endmills now the machine is solid enough to use them
[12:25:50] <anonimasu> im prett annoyed..
[12:25:55] <anonimasu> endmills are $$$$$$$$$$
[12:25:57] <anonimasu> :/
[12:27:24] <micges1> micges1 is now known as micges_plasma
[14:08:44] <EbiDK> EbiDK is now known as EbiDK|AWAY
[15:14:50] <skunkworks_> http://www.electronicsam.com/images/gear.jpg
[15:16:02] <archivist> slight wear
[15:16:28] <archivist> not worn out...still has teeth
[15:20:39] <anonimasu> iab
[15:20:52] <anonimasu> time to design a fixture plate
[15:22:01] <skunkworks_> that was about 16 years on a laser bed
[15:22:57] <anonimasu> uh?
[15:23:05] <anonimasu> skunkworks_: the gear?
[15:23:11] <skunkworks_> yes
[15:23:57] <anonimasu> nice :)
[16:05:46] <jepler> skunkworks_: servo motor mount WIP: http://emergent.unpy.net/files/sandbox/img_4755-medium.jpg http://emergent.unpy.net/files/sandbox/img_4756-medium.jpg http://emergent.unpy.net/files/sandbox/img_4757-medium.jpg
[16:15:30] <skunkworks_> jepler: very nice!
[16:15:39] <jepler> it's mostly cradek's work
[16:15:57] <jepler> waiting for some standoffs before I can actually mount it and try running an axis
[16:18:26] <skunkworks_> I like the way the belt will get tightened.
[16:18:35] <skunkworks_> pivoting the servo
[16:19:16] <jepler> it looks like the middle point of the pivot is about right
[16:29:36] <skunkworks_> jepler: did you take any pictures of the servos?
[16:30:46] <jepler> skunkworks_: no
[16:31:11] <jepler> they look about like the photo from that surplus website where I bought them
[16:32:05] <jimbo132> the shared communications through shcomm.cc does this include syncing multiple GUI's like axis and keystick
[16:33:15] <cradek> the guis do not have to know or worry about each other
[16:33:42] <skunkworks_> jepler: did you guys have luck boring out the timing pullys?
[16:33:58] <jepler> skunkworks_: yes, cradek did that last night and the results look good visually
[16:34:06] <skunkworks_> Great
[16:34:26] <cradek> I manually centered (approximately), then drilled and reamed it
[16:34:32] <skunkworks_> ah - cool
[16:34:39] <cradek> well, time will tell
[16:35:01] <cradek> it's part of the test (we're making everything for one axis first)
[16:35:07] <cradek> we have a couple spare pulleys
[16:35:43] <cradek> also, I need a 4-jaw chuck
[16:37:09] <archivist> or 3 jaw and shim :)
[16:37:23] <skunkworks_> heh - yes a 4 jaw is nice for fine work
[16:38:10] <archivist> and for 3 jaw try each drive screw/square as that can make a difference
[16:38:47] <archivist> or we use soft jaws and true up
[16:39:31] <cradek> if they hadn't made the flange part .480 inch a collet would have worked. (wtf? .480?)
[16:39:32] <toastatwork> soft jaws ++
[16:40:35] <jimbo132> thanks bbl (have to work0
[16:41:05] <archivist> cradek, 12mm collet
[16:42:45] <cradek> archivist: no such animal 'round here
[16:43:14] <archivist> hehe /me haz :)
[16:43:48] <archivist> slight stretch but mek it fit
[16:44:35] <cradek> my next plan would be to make a split cylinder 1.000 OD and ID= pulley teeth, then use the 1" collet
[16:44:55] <cradek> centering on the teeth is better than centering on the flange anyway.
[16:45:21] <archivist> sure is
[16:46:15] <archivist> I make those for gear bores too
[16:46:51] <cradek> I was too lazy to do it right, partly due to jepler's buying extra pulleys (at my insistence)
[16:47:25] <cradek> who wants to bore a .125 hole .650 deep? ugh.
[16:48:41] <archivist> I have some 1/8" hss ground up as boring bars...fun
[16:48:50] <cradek> yeah, me too
[16:49:08] <archivist> one of my most used tools
[16:49:09] <cradek> I think I have three of them currently - none are small enough
[16:50:31] <cradek> heh, I just recalled that I have a sherline 4-jaw. I should make an adapter.
[16:50:43] <cradek> that might actually be handy.
[16:51:29] <cradek> I wonder if there's some 5C thingy I could start from
[16:53:48] <archivist> when desperate 4 jaw in 3 jaw :)
[16:54:20] <cradek> funny - I bet that would actually work.
[16:54:37] <cradek> not sure if it would work without reversing the 3 jaw's jaws though.
[16:54:41] <archivist> you you have not done it?
[16:55:15] <archivist> does increase overhang a lot and yes use reverse jaws
[17:32:14] <skunkworks_> cradek: you did it on the hardinge?
[17:36:51] <SWPadnos> jepler, is there room in the motor shaft hole for pivoting?
[17:37:24] <SWPadnos> I guess it's probably a pretty narrow shaft, relative to the hole size
[17:37:24] <skunkworks_> the shaft is only 5/32 - so I would think so.
[17:49:59] <cradek> SWPadnos: that hole is a fixturing hole - the motor shaft was not meant to stick through it, although it is in the right place and could.
[17:50:10] <SWPadnos> ah
[17:50:15] <cradek> skunkworks_: yes
[17:50:37] <SWPadnos> oh, the motor is on the same side as the pulley, on standoffs?
[17:51:37] <jepler> SWPadnos: yes
[17:53:24] <SWPadnos> is the motor shaft too short to stick through the plate? (neglecting the problem of the motor needing to occupy the same space as other machine parts if it were on the other side)
[17:54:36] <archivist> 3 or more bearings in a row == binding unless alignment is carried out
[17:56:55] <jepler> SWPadnos: I think there would be enough shaft length, but I'm not sure
[17:57:22] <SWPadnos> when I was asking the question, I realized that you need the motor to stick out, so it's kind of a moot point
[17:57:51] <jepler> the shaft is about 1", the pulley is about .5", and the plate is 1/4".
[17:58:01] <jepler> of course, the counterbores for the screws would be on the wrong side then too
[17:58:25] <SWPadnos> heh
[17:58:38] <SWPadnos> unless you stick the pulley on the other side (though I did notice that)
[17:58:40] <cradek> archivist: http://www.use-enco.com/CGI/INSRIT?PARTPG=INLMKD&PMPXNO=4840059&PMAKA=240-3227
[17:58:45] <jepler> yeah
[17:58:59] <jepler> before you press the bearing in it can be reversed to do like you're suggesting
[17:59:11] <archivist> instant chuck mount
[17:59:27] <cradek> archivist: not quite instant, but it would be cool. I'm going to try it.
[17:59:29] <jepler> (the bearing is just thicker than the plate, and you need it to be flat on the right side)
[18:36:22] <geo01005> jepler, I missed what it is your are making. A really small mill?
[18:39:52] <jepler> geo01005: I'm switching from steppers to servos on my small circuit board mill http://media.unpythonic.net/emergent-files//01188441458/img_7045-medium.jpg
[18:40:44] <geo01005> These motors? http://www.skycraftsurplus.com/index.asp?PageAction=VIEWPROD&ProdID=1877
[18:40:48] <jepler> yeah
[18:41:04] <geo01005> wow, I didn't realize they were than small.
[18:41:15] <jepler> waiting for one more part, then I can actually run an axis around and see whether the whole thing will work out
[18:42:11] <geo01005> What kind of lead screws are you using?
[18:42:36] <jepler> 16TPI acme
[18:43:06] <geo01005> hmm, cool.
[18:43:26] <jepler> it originally had 20TPI triangular threads which had terrible backlash
[18:43:27] <geo01005> That picture shows an interesting way of recording data onto a cd ;)
[18:43:37] <jepler> I also threw out the dremel tool and bought a different spindle with lower runout
[18:44:03] <geo01005> What kind of nuts?
[18:44:43] <jepler> the nuts are made by http://dumpstercnc.com/
[18:48:46] <geo01005> how do you like those nuts?
[18:50:38] <jepler> they're nice. the backlash is plenty low for circuit board milling (<.001"). The original design just had a plain brass (?) nut riding on triangular thread, so it had terrible backlash that was hard to effectively overcome in software
[18:50:55] <jepler> that and the upgrade from the dremel were both necessary before it was a useful machine
[18:51:47] <geo01005> Yeah, dremel tools have lots of runout.
[18:52:49] <archivist> stop the bearing flop in the dremel case
[18:53:14] <geo01005> I take it the move to servo motors is more for fun rather than out of necessity?
[18:53:38] <jepler> yep
[18:54:26] <geo01005> Cool, what drivers/hardware do you plan to use?
[18:54:58] <jepler> mesa 5i20 + mesa 7i30
[18:55:56] <jepler> mesa 5i20 + mesa 7i30
[18:55:59] <jepler> oops
[18:56:08] <geo01005> I'm using a 7i43 and a 7i30.
[18:56:25] <cradek> 7i30 is very cool for little motors.
[18:56:26] <geo01005> I really like hm2 and the mesa cards.
[18:56:56] <jepler> I ran with 7i43 + stepper long enough to help seb work out some of the kinks. that's coming along real nicely too.
[18:57:06] <jepler> er, I guess that was 5i20 too, not 7i43
[18:57:14] <jepler> I have a 7i43 but it's not dedicated to anything yet
[18:58:49] <geo01005> My current computer only has lpt, no pci... So I had to use a 7i43 instead of a 5i20. I would like to have had the extra 24 i/o
[19:00:30] <geo01005> I think I finally figured out how to build new FPGA bit files for hm2. I havn'
[19:00:55] <geo01005> I haven't had a chance to see if what I made works.
[19:08:43] <jepler> I forget whether cradek is using a hm2 firmware I built or not
[19:08:56] <jepler> I recall that I had to build him an old-style 5i20 firmware to support index mask
[19:09:20] <cradek> pretty sure mine is not custom
[19:09:49] <cradek> if I needed a custom one, I'd whine until it was in the distribution :-)
[19:09:54] <cradek> oh wait, I did
[19:09:57] <cradek> ha
[19:58:43] <cncjerry> hello all, can I use any math functions like sin, cos, etc in Gcode on variables?
[20:02:37] <Vortex2> SWPadnos: hello, still havin same proplem whit homing
[20:03:00] <SWPadnos> cncjerry, http://www.linuxcnc.org/docview/html//gcode_overview.html#sub:Unary-Operation-Value
[20:03:25] <SWPadnos> Vortex2, have you gotten a halscope trace showing the problem?
[20:04:12] <Vortex2> SWPadnos: not yet, what you need whitch parameters and signals
[20:04:39] <Vortex2> now i need to go to local shop, ill be away for 20 min
[20:05:12] <SWPadnos> on the Z axis: home-state parameter, motor-pos-cmd pin, motor-pos-fb pin at least
[20:05:30] <SWPadnos> there may be something else I'm forgetting
[20:05:55] <SWPadnos> you can trigger on the ferror parameter
[20:06:27] <cncjerry> can you send that link again for the math functions? somehow hit my back button and lost the connection
[20:06:34] <SWPadnos> http://www.linuxcnc.org/docview/html//gcode_overview.html#sub:Unary-Operation-Value
[20:08:57] <Guest441> I have a vismach question
[20:09:15] <SWPadnos> ask, hopefully someone knows an answer
[20:10:51] <Guest441> I am running the scara configuration and the simulation dynamically rotates around a point way below the machine - is there a way to change the center of perspective so that zooming and 3d rotation allows for better side and front views
[20:11:31] <Guest441> or are there some shortcut keys for manipulatinjg the window view I don't know about -
[20:12:33] <SWPadnos> hmmm
[20:12:49] <SWPadnos> I don't think there are keys for that - it would be nice to add them
[20:13:21] <SWPadnos> you probably need to change the coordinates of the model to change the center of rotation
[20:14:01] <SWPadnos> it may be built "above the plane", you'd just change the Z values to be lower (I don't know exactly how to do that, or if there's an easier way)
[20:14:51] <Guest441> I looked in the /usr/bin/scaragui file - thats a good idea - nice if I knew where the look_at point - I guess I could just keep dropping the z values
[20:15:07] <cncjerry> thanks, another question: does the trajectory planner work on while loops?
[20:15:21] <SWPadnos> I think the look_at is actually part of the call to openGL to draw it
[20:15:32] <SWPadnos> cncjerry, what do you mean?
[20:15:48] <SWPadnos> the interpreter parses the loop and issues motion commands, which the TP then executes
[20:16:19] <SWPadnos> so at the TP level, it's just a bunch of well-defined motions - the decisions have already been made by the interpreter
[20:16:45] <Guest441> SWPadnos: is that openGL/miniGL call in the vismach.py file? and where is that btw
[20:18:28] <Guest441> SWPadnos: the only vismach file I can find on my machine is /usr/lib/python2.5/site-packages/vismach.pyc and it is binary (uneditable)
[20:18:30] <SWPadnos> it's in the vismach / scaragui .py file, but I don't know where :)
[20:18:37] <SWPadnos> hmm
[20:18:46] <SWPadnos> the vismach.py file should be in the same place, I'd think
[20:19:09] <cncjerry> I need a continuous thread with .233 pitch. so i am using a rotary table to run thru 180 degrees as I move the x out .233 and back at the 360 point. The thread came out a little square and now I am planning to use a while loop and step thru a sine wave. I was just wondering how much precision I needed to add to the sine wave to get a smooth finish.
[20:19:44] <cncjerry> so if the trajectory planner smooths it out a little then I can decrease my steps
[20:19:47] <SWPadnos> it could be backlash somewhere
[20:19:58] <SWPadnos> you can control the path following of the TP
[20:20:21] <SWPadnos> check G61, G64, and G64 Pxx
[20:21:49] <cncjerry> swpadnos, if you look at the thread, it is perfect, but I wanted the transition to be smoother, so I am going to try a sine wave to smooth out the transition points at the top of the thread.
[20:22:08] <SWPadnos> this is threadmilling?
[20:22:50] <cradek> I don't understand what you're doing - for thread milling you just need helical motion or linear+rotary motion
[20:22:53] <cncjerry> you would consider it a thread but it goes out to .233 inches and then goes back.
[20:23:21] <SWPadnos> ok, so it's a groove that goes out for 180 degrees, then in for the next 180 degrees
[20:23:31] <cncjerry> yes.
[20:23:42] <Guest441> what is the geometry of the thread profile - acme? round? V?
[20:23:50] <SWPadnos> it's not a thread, it's decorative :)
[20:23:59] <cncjerry> the thread profile is square and cut with a .25 endmill.
[20:24:12] <SWPadnos> can you exit from the part on either end?
[20:24:29] <cncjerry> it is the oscillator cam for a gatling gun, swings the gun from side to side as the indians approach.
[20:24:34] <SWPadnos> heh
[20:24:35] <cncjerry> no exit
[20:24:38] <SWPadnos> ok
[20:24:55] <Guest441> wont a .25 endmill cutting a .233 pitch just make a cylinder?
[20:24:55] <cncjerry> there is a cam follower, .25, that swings the gun.
[20:24:59] <SWPadnos> and you're looping for multiple depth passes?
[20:25:21] <SWPadnos> Guest441, depends on the diameter of the blank
[20:26:24] <cncjerry> no it is not a cylinder. and yes, I was doing multiple passes with a ramped z plunge.
[20:26:35] <SWPadnos> ok
[20:27:22] <cncjerry> I am going to program a loop to advance the A, sin(a) for the x and z ramp
[20:27:26] <SWPadnos> so you have O while [Z isn't done] / g1 x0.233 A180 / g1 x0 A360 / done
[20:27:35] <SWPadnos> just do one move
[20:27:43] <SWPadnos> they'll be synchronized
[20:27:53] <SWPadnos> 0.233 " X, 180 degrees A
[20:28:22] <cncjerry> yes, but that program gives a very abrupt transition, that is what I did. I want the transition to be smoother.
[20:28:34] <SWPadnos> you can turn on blending with G64Pxx
[20:28:39] <SWPadnos> or just G64
[20:32:02] <Guest441> cncjerry: are you using a mill?
[20:32:45] <cncjerry> yes, a mill, rotary table is horizontal
[20:33:17] <Guest441> cncjerry: are you making a cam?
[20:33:27] <cncjerry> technically, a linear motion on the x with angular on the A should give me a sine wave on the cylinder, no?
[20:33:32] <cncjerry> yes
[20:34:26] <SWPadnos> err
[20:34:42] <SWPadnos> no, I think you'd need an arc in the XA plane
[20:34:47] <SWPadnos> which of course doesn't exist
[20:34:58] <Guest441> cncjerry: that will give you a hellical ramp -
[20:35:08] <cradek> why not ignore the rotary table and just cut the shape you want in XY?
[20:35:22] <SWPadnos> cradek, it's a round cam
[20:35:30] <SWPadnos> a cylinder with a groove in it
[20:35:37] <cradek> heh, I still don't understand the part, sorry
[20:36:24] <SWPadnos> http://www.valhallagrafix.com/images/cylindrical_harmonic_cam_finished.jpg
[20:36:36] <SWPadnos> something more or less like that, I think
[20:36:40] <Guest441> cncjerry: break it into pieces like you said - sounds like a good idea -
[20:36:48] <cncjerry> the part is a cylinder .84 in od, the cut is made into the cylinder .1385 deep at .233 pitch. so I start at x0 and do a g01 a180 x.233 z.01 successively to get to the depth
[20:37:00] <cradek> I thought he said the rotary table is horizontal
[20:37:15] <SWPadnos> it is, Z is the groove depth
[20:37:24] <Guest441> I think the part is horizontal -
[20:37:29] <SWPadnos> X is along the part, and A is rotation around the part
[20:37:30] <cncjerry> sorry the axis of the part is parallel to the table the table is vertical
[20:37:41] <cradek> oh ok! I see it now.
[20:37:51] <cncjerry> z is cutting down into the cylinder.
[20:38:36] <cradek> with a sine profile is you'll spend most of your time away from the center - you'll shoot to both sides more than ahead
[20:38:39] <cncjerry> I want to get rid of the sharp transition at the 180 point caused by the interaction of the .233 pitch and cylinder diameter being only .233 with the cutter at .25
[20:38:53] <Guest441> cncjerry: if you do break it into say 360 lines of code, ie and x move for every 1 angle then the points where you passthrough -180 and 180 are tangent...
[20:39:14] <cradek> ok I understand
[20:39:28] <SWPadnos> just move the HAL connections and make the rotary Y for a little while, then you can use an arc move :)
[20:39:35] <Guest441> :-)
[20:39:36] <cncjerry> what i want to do is spend more angular time at the end (0 and 180) points
[20:39:42] <cradek> the sine would be the smoothest motion (bounded acceleration and jerk and every other derivative)
[20:40:10] <Guest441> haas has a gcode for mapping to cylinders - g102 or something
[20:40:53] <cradek> so yeah, just divide it up into 100? segments
[20:41:47] <Vortex2> SWPadnos: http://picasaweb.google.com/JSSKangas/DropBox?authkey=Gv1sRgCLOz8NjNx8fkFg#5348028248638045234
[20:41:48] <cncjerry> I am going to do 1 degree increments first into plastic. I'll let you know in 30 minutes how it comes out.
[20:42:10] <cradek> cool
[20:42:44] <jepler> or first do it in the air and watch the velocity display or listen to it. If you divide it up too finely, you'll see or hear your speed go down or become irregular.
[20:42:57] <Vortex2> SWPadnos: im now at machine if you need more data
[20:43:11] <Guest441> do it incrementally and use smaller and smaller +-x values and make sure you have a 0 when you pass through half of your total angular motion - that and all the incremental moves need to add up to 0.233
[20:43:15] <cncjerry> is sin in degrees or radians?
[20:43:16] <SWPadnos> is the red trace f-errored?
[20:43:20] <SWPadnos> degrees
[20:43:33] <cradek> cncjerry: gcode is all degrees
[20:44:48] <toastatwork> one degree seems awfully corse
[20:45:27] <anonimasu> indeed it is...
[20:45:56] <Vortex2> SWPadnos: red: home state, blue: motor pos cmd, green: motor pos fb, violet: f-error
[20:45:58] <cncjerry> so is this the correct form to set the x position #2=[sin[#1/2*.233]]
[20:46:01] <SWPadnos> Vortex2, at that scale it's hard to tell what's going on with the feedback and command. you have a 90 mm change in the position and feedback, so it's hard to see the <0.2 mm of deviation
[20:46:16] <cncjerry> sin(90) is 1 so I want to hit .233 at 180
[20:46:39] <SWPadnos> #2=[sin[#1/2]*.233]
[20:46:42] <cradek> .840" diameter gives .007" long moves at the surface if they are 1 degree
[20:46:46] <cncjerry> wait I just screwed that up.
[20:46:51] <cradek> I predict it'll smooth fine and look perfect
[20:46:54] <cncjerry> been working in radians too long
[20:47:18] <SWPadnos> probably just [sin[#1]*0.233]
[20:47:45] <SWPadnos> for the second half, use sin[360-#1]*0.233] or similar
[20:47:59] <cncjerry> so the sine of 180 is 0, it is on its way back, so it will be sin[#1*2]
[20:48:22] <SWPadnos> no, unless you want the second half at twice the "frequency"
[20:48:35] <SWPadnos> you don't want to multiply inside the sin parameter
[20:48:49] <SWPadnos> you only want to add or subtract to select direction of travel
[20:49:04] <SWPadnos> (if anything)
[20:49:06] <cncjerry> I want x to be .233 at 180 degrees
[20:49:19] <cradek> for every degree d, move to X=.233*cos[d], A=d
[20:49:21] <SWPadnos> you multiply the result of the sin function by 0.233
[20:49:30] <SWPadnos> right
[20:49:37] <cncjerry> sin(180) is 0, sin(90) is 1, so it has to be sin(1*2)*.233
[20:49:52] <cradek> duh, you're right
[20:50:02] <cradek> you want a half cycle over the 360
[20:50:04] <SWPadnos> if you did sin or cod [2*d]. you'd get two back-and-forth paths per revolution - it would do sin[720] at the end
[20:50:04] <cncjerry> yes,cosine function
[20:50:10] <cncjerry> not sine
[20:50:11] <SWPadnos> s/cod/cos/
[20:50:31] <cradek> for every degree d, move to X=.233*cos[d/2], A=d
[20:51:00] <cradek> no
[20:51:02] <cradek> forget it :-)
[20:51:23] <SWPadnos> I think you want one full sin/cos wave per revolution
[20:51:43] <cradek> X=(.233/2)cos[d], A=d
[20:51:45] <Vortex2> SWPadnos: http://picasaweb.google.com/JSSKangas/DropBox?authkey=Gv1sRgCLOz8NjNx8fkFg&pli=1#5348030922362831634
[20:51:50] <cncjerry> I need to put excel into degrees and run a simple chart
[20:51:55] <cradek> yeah now I agree with SWPadnos
[20:51:57] <SWPadnos> but you want it offset and half amplitude
[20:52:11] <SWPadnos> make L=0.233
[20:52:17] <cradek> right, the amplitude is +-1, so use half
[20:52:31] <SWPadnos> the position is L/2*(1+sin(theta in degrees))
[20:52:47] <SWPadnos> that's (L/2)*(1+sin(theta in degrees))
[20:52:56] <SWPadnos> (jsut so there's no ambiguity)
[20:53:05] <cradek> yes
[20:54:13] <cncjerry> If it was in radians than it would always be positive allowing to start at x and move to .233
[20:54:24] <SWPadnos> why are the positions still changing by >80 mm?
[20:54:36] <SWPadnos> ^^ Vortex2
[20:55:16] <Vortex2> SWPadnos: what do you mean?
[20:55:31] <SWPadnos> the green and blue traces change by a lot
[20:55:37] <Vortex2> yes
[20:55:43] <SWPadnos> the purple trace is the difference between them, and is very small
[20:55:58] <SWPadnos> it's hard to see anything but flat lines at the scale you need to show the large changes
[20:56:29] <SWPadnos> are you stopping EMC, moving the axis manually, then restarting and homing?
[20:56:41] <cncjerry> cradek, ok, if #1 is degrees and #1=[#1+1] for 1 degree increments, how do you put #2 (x) in the correct form using x=(.233/2)*cos[#1]
[20:56:44] <SWPadnos> a better question is, how are you creating these plots
[20:56:57] <Vortex2> boom is down and when i start homing position goes up to 90mm and that place will be zeroed to home position
[20:57:23] <SWPadnos> can you start with the boom closer to home, like maybe 5mm away?
[20:57:32] <Vortex2> Why
[20:57:35] <Vortex2> ???
[20:58:15] <SWPadnos> so you can make the vertical scale on the green and blue traces much smaller, like the violet error trace
[20:58:30] <Vortex2> ok
[20:58:59] <SWPadnos> also, widen the time scale - all I need to see is the falling edge of the motor-pos-cmd/fb up to the falling edge of the home-state
[20:59:18] <SWPadnos> also, is it throwing a following error every time?
[21:00:24] <Vortex2> SWPadnos: yes every time when home position differes from zero is
[21:01:38] <Vortex2> SWPadnos: this is why i thin it does not update real position and position to go at same time
[21:02:01] <SWPadnos> that's also hard to see at 100 ms/division
[21:02:42] <SWPadnos> I'm surprised it takes so long to complete the homing sequence actually - it's well over 100 ms after the position has been zeroed that it finishes
[21:03:11] <SWPadnos> I don't know what the states are offhand, and I unfortunately don't have the time to look at them right now
[21:04:07] <geo01005> Vortex2, what version of emc are you working with?
[21:04:41] <Vortex2> geo01005
[21:04:52] <Vortex2> I need to chk that
[21:05:04] <Vortex2> -----> to garage
[21:05:37] <geo01005> There was a recent bug fix that may solve your problem.
[21:07:07] <geo01005> http://article.gmane.org/gmane.linux.distributions.emc.devel/2268
[21:10:08] <Vortex2> geo01005: i think its 2.27
[21:10:14] <Vortex2> 2.2.7
[21:11:11] <SWPadnos> you should at least update to 2.2.8
[21:11:38] <SWPadnos> I don't know if the bugfix geo01005 mentions is in a released version yet, so upgrading to 2.3.x may not be necessary yet
[21:11:59] <SWPadnos> there are necessary config changes - lots of them for hostmot users - when you upgrade
[21:12:12] <geo01005> Yeah, I think SWPadnos is right, I was only expecting that problem if you had compiled from source.
[21:12:19] <geo01005> (recently)
[21:12:48] <Vortex2> hmm. hostmot is it driver for mesa card
[21:12:53] <SWPadnos> yes
[21:12:58] <Vortex2> ok
[21:13:30] <SWPadnos> there's m5i20 in 2.2, but the better hostmot2 driver is - um - better
[21:13:35] <Vortex2> does this newer version of emc run on 8.10 ubuntu
[21:13:37] <SWPadnos> no
[21:13:58] <SWPadnos> we generally only support LTS releases, which happen every two years
[21:14:09] <Vortex2> ok
[21:14:19] <SWPadnos> (LTS=Long Term Support)
[21:15:29] <Vortex2> thas one proplem, because i use elo touchscreen, there is no support in older ubuntu
[21:15:36] <SWPadnos> sure there is
[21:15:49] <SWPadnos> I've had a touchscreen working on 5-year old Linux
[21:15:59] <Vortex2> ok
[21:16:02] <SWPadnos> BDI 4.1x
[21:16:06] <SWPadnos> it's not an Elo though
[21:16:23] <Vortex2> i have elo accutouch
[21:16:34] <SWPadnos> it may not be automatically detected on earlier versions, but there should be driver support for it
[21:16:43] <cncjerry> when I try loading the program I wrote for my cam, EMC2 goes into a loop
[21:16:58] <SWPadnos> you didn't end the loop correctly :)
[21:17:10] <SWPadnos> Vortex2, serial or USB?
[21:17:14] <Vortex2> is nise, screen is werry strong, doesnot get scrats werry easyly
[21:17:19] <Vortex2> usb
[21:17:49] <cncjerry> I think it is this statemnet -> #2=[sin[#1*100/2]*.233]
[21:18:18] <cncjerry> my rotary table is 3.6 not 360 so I need to multiply by 100 to get degrees
[21:18:31] <cncjerry> the loop is correct, i think
[21:18:46] <Vortex2> SWPadnos: so i should use this Ubuntu 8.04&EMC2 Live CD
[21:19:02] <SWPadnos> for what?
[21:19:10] <SWPadnos> if you're upgrading, just upgrade, don't reinstall
[21:19:26] <cncjerry> I am trying to set #2 to (sin(angle*100)/2)*.233
[21:19:34] <Vortex2> no i have 8.10 ubuntu
[21:19:48] <SWPadnos> Vortex2, so you've compiled your own EMC and RT kernel?
[21:19:54] <Vortex2> no
[21:20:14] <Vortex2> this was some one elses
[21:20:24] <SWPadnos> ah, Eric Johnson's packages?
[21:20:28] <SWPadnos> (I think)
[21:21:15] <Vortex2> link was in emc2 page
[21:21:26] <Vortex2> some time a go
[21:22:28] <Vortex2> SWPadnos: I think i need to compile my own emc, cause i need this different kind of homing system
[21:22:51] <SWPadnos> I don't think that should be necessary, or everyone with a Mesa card would have the same problem
[21:22:54] <Vortex2> to syncronice those two servos
[21:23:07] <SWPadnos> this is not the dual-motor axis though, right?
[21:23:08] <geo01005> you can just use comp right?
[21:23:21] <Vortex2> yes
[21:23:37] <SWPadnos> geo01005, yes, to compile/install a single component, comp is the easiest way
[21:23:56] <Vortex2> SWPadnos: no this axis was sigle motor
[21:24:32] <SWPadnos> so the dual-motor thing is independent of this problem, and every other mesa user should be seeing the problem
[21:24:38] <Vortex2> SWPadnos: this same proplem whit homing is present in all axis
[21:24:48] <SWPadnos> so I think it's either a configuration issue, or something that will be fixed if you upgrade
[21:25:46] <Vortex2> ok i need to donwload this version that runs in ubuntu 8.04 nad try that does it have same proplen
[21:25:47] <Vortex2> m
[21:27:12] <Vortex2> SWPadnos: not configuration error, makes same thing whit mesa exsample
[21:27:46] <Vortex2> But now i need to go to sleep
[21:27:49] <SWPadnos> it could be the bitfile or the driver. 2.2.7 isn't the latest in the 2.2 series, so the first thing to do is update to 2.2.8
[21:27:51] <SWPadnos> ok
[21:28:09] <SWPadnos> then try 2.3.x
[21:34:04] <Vortex2> geo01005: using comp?!?
[21:34:18] <Vortex2> compile my own homing
[21:34:45] <Vortex2> or make new HAL component for homing
[21:34:52] <cncjerry> so i ran the code and got an "X" instead of a continuous thread.
[21:36:08] <Guest441> cncjerry: TREASURE
[21:36:26] <Guest441> cncjerry: you should dig there...
[21:36:41] <cncjerry> hey, there must be a part in there.
[21:37:04] <SWPadnos> cncjerry, can you post the exact formula you used?
[21:37:11] <Guest441> cncjerry: I was thinking - maybe you could use NURBS to do it - http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?NURBS
[21:37:34] <SWPadnos> I don't know if NURBS can run rotary axes
[21:38:11] <Guest441> SWPadnos/cncjerry: I was going to try it first - but I am still patching(dwnloading)
[21:38:40] <geo01005> Vortex2: didn't you say that you wrote your homing routine as a realtime hal component?
[21:38:48] <cncjerry> what I can do is draw it linearly in CATIA with nice rounded transitions and then just cut it treating A as linear.
[21:39:04] <cncjerry> but then I would lose the ramping of the Z
[21:39:40] <Guest441> cncjerry: I think you should just change your config so that the a axis is linear and use the circuference of the workpiece to scale the stepgen correctly and the just use go2/g03
[21:40:10] <Vortex2> geo01005: no i have not done that yet, need advice for that
[21:40:15] <cncjerry> '441 - that would be too easy
[21:40:42] <Vortex2> geo01005: How to disable current and use my own
[21:40:42] <geo01005> Vortex2, Where did you put the homing code?
[21:40:52] <Guest441> cncjerry: if you make a copy of your config files you wont be out anything - then you can go back anytime and change the scaling for different diameter workpieces
[21:41:38] <Vortex2> geo01005: I have not yet writen this homing code.
[21:41:50] <SWPadnos> Vortex2, you can't change the built-in homing - it's not a separate component
[21:42:23] <SWPadnos> you can mess with the signals that get sent to the motor drives and from the encoders though
[21:43:06] <geo01005> http://www.linuxcnc.org/docs/html/hal_comp.html
[21:43:30] <Vortex2> SWPadnos: can i disable build in homing from selected axis
[21:43:47] <SWPadnos> you can no home using the normal keys/commands
[21:43:50] <SWPadnos> but that's about it
[21:44:14] <SWPadnos> but since the motion controller is the only thing that can reasonably command motion, you can't really do it any other way either
[21:45:07] <Vortex2> geo01005: thank, I have allready writen couple of HAL components, but I dont know how homing works and how to make adjustment to it
[21:46:47] <geo01005> SWPadnos: You don't think a hal component could be used for homing?
[21:47:09] <geo01005> I mean actually control the motion of the machine during homing?
[21:47:21] <SWPadnos> not really
[21:47:53] <SWPadnos> you can make a HAL component cause motion only if you fool the motion controller into thinking there's no motion - else you get a following error
[21:48:22] <geo01005> Right.
[21:48:22] <SWPadnos> but you need the motion controller to think it's getting homed somehow
[21:48:32] <SWPadnos> which of course cuases the motion controller to command some motion ...
[21:48:55] <SWPadnos> you might be able to get by somehow, but it would be very convoluted
[21:49:34] <Vortex2> I think I have found way to do this other vice
[21:52:16] <cncjerry> well, I got it to work and it looks very smooth, nice even transitions at the peaks, definite improvement. Thanks for the help
[21:52:17] <Vortex2> I need to make normal homing but backup to second index pulse, when i find first motor index pulse, I start to count tistance for motor 2 next index pulse.
[21:52:50] <SWPadnos> Vortex2, you might be able to do it closer to the hardware
[21:53:05] <SWPadnos> hmmm
[21:53:07] <SWPadnos> maybe not
[21:53:58] <SWPadnos> the index pulse on the secondary motor is kind of irrelevant to homing actually, the difference between positions will be determined by the home switch accuracy
[21:53:59] <Vortex2> I mean count distance between motor1 index pulse and motor2 index pulse, and simply make offset for motor 2 to correct position
[21:54:41] <SWPadnos> yes, then add that to the command and subtract it from the feedback (or the opposite)
[21:55:11] <Vortex2> and when this correction is done in several loops (not at ones) movement will be smooth
[21:55:33] <Vortex2> This is correct solution
[21:56:58] <toastydeath> i'm confused as to why you need to home both motors
[21:57:37] <Vortex2> SWPadnos if i add it to command and subtract it from the feedback no movement
[21:58:13] <Vortex2> srry
[21:58:24] <Vortex2> sorry , i was not thinking
[21:58:53] <Vortex2> SWPadnos: its like you say
[21:58:56] <SWPadnos> heh
[22:00:36] <Vortex2> toastydeath: bridge of my machine is 1,6 meters wide, it has ballscrews one each side
[22:01:42] <toastydeath> right, but why does the other screw have to home
[22:01:58] <Vortex2> toastydeath: if you move bridge by hand you can get 1mm offset between two servos
[22:02:07] <toastydeath> oh
[22:02:08] <toastydeath> ty
[22:39:35] <anonimasu> too bad he left..
[22:41:01] <anonimasu> I were gonna say if your machine moves 1mm when you push it.. you need to figure some about your tuning..
[22:46:36] <Guest441> cncjerry: did you get your cam made?
[23:21:08] <cncjerry> guest441 - had to pickup the kids. yes, cam came out perfect, very nice transitions. I am now going to cut one from aluminum in the next few minutes to see if there is any cogging noticeable
[23:57:09] <i-pink> hi everybody
[23:57:26] <i-pink> someone here?