Back
[00:11:44] <mrled_> Anyone know what axisui hal pin toggles with the 'Override Limits' checkbox on the user interface?
[01:32:23] <Loetmichel> mornin'
[02:02:50] <DJ9DJ> moin
[08:27:07] <JT-Shop> SWEET! the plasma is coming alive again... it homes!
[08:30:09] <awallin> home sweet home..
[08:31:07] <awallin> 12.04beta out. anyone using that? any good?
[08:42:08] <skunkworks> JT-Shop: 5i25?
[08:50:43] <JT-Shop> skunkworks: yes
[08:50:57] <JT-Shop> just getting to the THC A-D card now
[09:06:26] <mazafaka> End mill, d=40 mm, 4 inserts, 15 mm cutting depth, 400 rpm, 30-45 mm/min is OK?
[09:09:56] <JT-Shop> butter, brass, 4140, 7075 ?
[09:12:02] <jdhnc> yes, yes, maybe, maybe.
[09:12:13] <JT-Shop> lol
[09:15:16] <mazafaka> worked today, stainless steel
[09:15:27] <archivist> water,wood,titanium,concrete
[09:15:44] <mazafaka> cooolant
[09:15:48] <JT-Shop> yes, yes, maybe, no
[09:16:02] <mazafaka> if no then rather surely 'yes'
[09:16:38] <mazafaka> our Win 98 -based coordinate-drilling CNC kicks the ass!
[09:16:51] <mazafaka> ...in milling.
[09:17:10] <JT-Shop> anyone seen the little green plug for the THC A-D card?
[09:17:29] <archivist> swept under the carpet
[09:17:47] <JT-Shop> can't be there, no carpet
[09:20:36] <JT-Shop> I suspect I will have to clean and organize until it is found...
[09:21:24] <jdhnc> the best way to find lost parts is to buy a replacement.
[09:21:55] <Loetmichel> hihi, nothing more true than tat , jdhnc
[09:21:56] <Loetmichel> that
[09:22:54] <archivist> but then you end up with a pile a mile high of "it might be useful"
[09:23:13] <jdhnc> or two.
[09:23:14] <archivist> build another shed
[09:26:18] <jdhnc> that, I can agree with.
[09:27:33] <JT-Shop> ha, it was still attached to the cable from the plasma
[09:41:43] <mazafaka> pretty nice explanation starting from 2nd minute at
http://www.youtube.com/watch?v=0Q2DA4_KdS8
[09:50:36] <mazafaka> I chew snickers to create a poo for the dog - young dogs sometimes eat various poo...
[11:08:16] <JT-5i25> from the 7i77 TB3 to the THC A-D (+5VP to +5V) and (ENCA+ to FO+)?
[11:17:46] <Loetmichel> re @ home
[11:17:51] <pcw_home> something like that (you can wire the THCAD differentially if you like and you have the wires)
[11:19:07] <pcw_home> in any case you need to jumper the encoder inputs to match the source (TTL or differential)
[11:19:08] <pcw_home> (and set the encoder mode to up/down in hal)
[11:19:56] <pcw_home> you may need to tie the B encoder line high or low to get the A-D reading in the right direction
[11:21:55] <Loetmichel> hmm, anyone here from Lietuva?... i have to go there in 18hrs. by car... from germany... 1000km to vilnius (700km ferry) and 1700km back...
[11:22:31] <Loetmichel> correction: i have to start driving 18 hrs from now, not go there IN 18hrs ;-)
[11:25:15] <JT-5i25> thanks Peter, I'll wire it up differentially
[11:27:52] <Jymmm> Is I2C fast enough for RTAI?
[11:28:13] <hatch789> hi peter, I'm working with Dave and having a hard time getting my resolvers to cooperate.
[11:28:46] <hatch789> The only number doing anything is velocity? And I have finished installing the resistor "bridges" on all of the X&Y sin/cos channels
[11:28:59] <hatch789> the voltage values are now between 0vAC and .824vAC
[11:29:05] <pcw_home> what is the velocity doing?
[11:29:07] <hatch789> so they seem very good and nice and smooth
[11:29:56] <hatch789> it's moving by itself (not much (just the decimas and the 1's column)) and then it does respond when I turn the hand wheel
[11:30:19] <hatch789> but the angle, rawcounts, counts are all at 1 or -1
[11:30:27] <hatch789> and the position is still an exponential number
[11:31:42] <pcw_home> strange maybe a 7I43 issue (this is the first use of the resolver interface in a 7i43)
[11:32:15] <pcw_home> sure you are using the latest bitfile?
[11:32:49] <hatch789> yup the one you just sent me
[11:33:24] <pcw_home> can you paste the md5 csum here?
[11:33:31] <hatch789> yes hold on
[11:34:49] <hatch789> 243a14cb485061ee342fcd077c74ce4d SVRM6.BIT
[11:35:13] <pcw_home> and this is from /lib/firmware/hm2/7i43?
[11:35:27] <hatch789> root@emc2-dell:/lib/firmware/hm2/7i43-4# pwd
[11:35:27] <hatch789> /lib/firmware/hm2/7i43-4
[11:36:08] <pcw_home> OK so maybe its a 7I43 issue or driver or something
[11:43:35] <Jymmm> SWPadnos: There we have it... Imation Blu-Ray Blanks 25 for $19.99
[11:44:49] <hatch789> pcw_home, do you need/want me to send any other csum's or anything? I took today off of work to try to get this baby up and running and my hopes are fading fast now :(
[11:45:58] <pcw_home> well if its a driver issue it may take a while as Andy P is in the middle of the ocean
[11:46:58] <hatch789> are there any tests that we can do to determine if it is or is not a driver issue?
[11:46:59] <Jymmm> with SpongeBob?
[11:50:57] <JT-Shop> Andy is sitting on the starting line
[11:51:31] <pcw_home> I will take a look at the 7I43 version today or Monday and see if I see anything strange at the register level
[11:51:32] <Jymmm> I thought he was on the third leg or something.
[11:51:33] <pcw_home> if not then its a driver issue
[11:51:47] <JT-Shop> 6th leg
[11:52:28] <pcw_home> JT-Shop does Axis have spindle RPM readout?
[11:53:57] <JT-Shop> there is motion.spindle-speed-out that any GUI can use
[11:54:36] <pcw_home> OK thats what SRT is missing (in the forum)
[11:54:49] <JT-Shop> ouch tornado warnings all over the place
[11:55:15] <Jymmm> Branson is no more btw
[11:56:31] <JT-Shop> pcw_home: ok I see the post
[11:57:11] <pcw_home> Ok thats the motion command thats not what I wanted
[11:57:13] <pcw_home> maybe he does have to setup a PYVCP display
[11:59:21] <JT-Shop> yes, he would have to tie the meter to motion.spindle-speed-out
[12:04:53] <pcw_home> He's using the resolver velocity out to make a real spindle
[12:04:55] <pcw_home> speed readout, but what I dont know is whether Axis has a built in spindle speed readout
[12:04:57] <pcw_home> (and what axis.xxxxx pin it would be)
[12:08:17] <skunkworks> No - there is no readout.
[12:08:29] <skunkworks> You would need to make one in pyvcp or such
[12:09:22] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot-HEADCIR.25mill.ngc%20-%20AXIS%202.5.0~pre%20on%20HM2-Servo-1.png
[12:12:16] <cradek> skunkworks: we have multiturn arcs now!
[12:13:17] <skunkworks> cradek: is it in 2.5?
[12:13:30] <skunkworks> I remember you adding them...
[12:14:24] <cradek> http://www.linuxcnc.org/docs/2.5/html/gcode/gcode.html#sec:G2-G3-Arc
[12:14:34] <cradek> To program an arc that gives more than one full turn, ...
[12:14:53] <syyl> really?
[12:15:01] <syyl> thats a great function
[12:15:33] <skunkworks> cradek: Did you see I used coordinate rotation on the K&T? worked great@
[12:15:47] <cradek> slick! I've used it for ... one project!
[12:15:48] <MrSunshine> hmm, can linuxcnc send non realtime commands over like i2c and such ?
[12:15:49] <cradek> bbl
[12:15:55] <MrSunshine> im thinking setting spindle speed for example
[12:15:57] <MrSunshine> spindle on/off
[12:16:47] <pcw_home> MrSunshine sure
[12:17:25] <pcw_home> you could call a userland script
[12:17:26] <IchGuckLive> MrSunshine: yes
[12:18:29] <MrSunshine> ok it does not support sending i2c command directly ? :)
[12:18:46] <IchGuckLive> i do it via python
[12:19:31] <IchGuckLive> http://pyi2c.sourceforge.net/
[12:20:38] <MrSunshine> nice =)
[12:21:05] <IchGuckLive> there are sketches and examples there
[12:24:02] <IchGuckLive> to get it into hal you can use a µC as arduino for example there is a hal component for it
[12:24:58] <IchGuckLive> then you got real scl/SDA on the µC
[12:25:30] <IchGuckLive> this also gives you 12 more IO
[12:25:59] <jdhnc> there was a project years ago to do i2c via a spare vga port
[12:27:05] <IchGuckLive> or if go go beond max 32768 port IO via PCF 8574
[12:27:38] <IchGuckLive> as i relised only 5000 in a scale train projekt
[12:29:26] <IchGuckLive> is there a special eng for modeltrains worg
[12:29:38] <IchGuckLive> word
[12:32:38] <IchGuckLive> cradek: the code for helic circel down penetration will it be in one circle
[12:34:13] <IchGuckLive> for example circeling down from zeo to -5mm at 0.05 radius
[12:46:39] <JT-5i25> pcw_home: 7i76 pdf page 2 slight extra word "When W4,W5,and W6 are in the right hand position, the encoder input _is_ mode is differential."
[13:05:27] <pcw_home> JT-5i25 thanks I'll fix that
[13:13:10] <Jymmm> pcw_home: just don't fix it like this...
http://thereifixedit.files.wordpress.com/2012/03/white-trash-repairs-take-your-baby-back-ribs-to-new-heights.jpg
[13:14:57] <ries> KimK: happen to be here?
[13:22:04] <JT-Shop> freeky 60kts winds with no clouds overhead
[13:27:12] <Jymmm> So if you cannot see the wind, is it not there?
[13:28:53] <jdhnc> s/wind/beam/
[13:30:00] <Jymmm> Jim Beam?
[13:33:14] <pcw_home> Jymmm: nice balcony no wasted space
[13:33:27] <Jymmm> pcw_home: =)
[13:51:28] <JT-5i25> pcw_home: is the encoder velocity supposed to be going backwards with 0v on the THC?
[13:52:43] <cncbasher> JT-5i245 : i'd guess you need a bandgap around zero
[13:53:03] <cncbasher> to stop it going negative at zero
[13:53:47] <JT-5i25> it outputs a frequency at 0v but I forget if it is positive counts at the encoder or not
[13:55:15] <JT-5i25> I have FO- connected to ENCA- and FO+ connected to ENCA+
[13:56:42] <cncbasher> could be just slightly out , so a filter may do the trick
[13:56:55] <cncbasher> i.e zero is not exactly zero
[13:57:44] <cncbasher> so giving a band gap around zero might cure it
[13:57:46] <JT-5i25> I have a scale and offset in the THC comp to take care of that
[13:57:53] <cncbasher> ok
[13:58:24] <JT-5i25> I just thought the base frequency would make the encoder count up iirc
[13:59:30] <JT-5i25> but last time I had it connected ttl... hmmm
[13:59:37] <cncbasher> is the thc a balanced input
[13:59:55] <JT-5i25> I don't know what that means
[14:01:01] <Jymmm> THC
[14:02:18] <cncbasher> i bet it's just an imbalance around zero ,
[14:03:16] <cncbasher> is it varing a great deal , or just a few counts
[14:04:50] <JT-5i25> kinda steady at -119000 velocity
[14:05:33] <JT-5i25> I guess I'll have to find a battery and see if it is backwards
[14:05:41] <cncbasher> yea good idea
[14:06:07] <cncbasher> any floating grounds or ground loops maybe
[14:07:14] <cncbasher> would be enough to upset the frequency and cause it to shift from 0
[14:07:16] <Jymmm> grounded on only ONE end, but not both.
[14:07:19] <JT-5i25> the voltage input is not even connected to the THC A-D card
[14:07:45] <JT-5i25> the THC A-D card never outputs 0 frequency
[14:08:10] <cncbasher> i'd go more for the encoder input
[14:08:33] <JT-5i25> what do you mean?
[14:08:56] <cncbasher> not being a balanced input
[14:09:07] <cncbasher> i.e same voltage both sides
[14:09:22] <cncbasher> but one obvously the inverse
[14:10:47] <pcw_home> if its backwards you need to jumper the B input for TTL and ground it
[14:11:17] <JT-5i25> ok, thanks
[14:11:51] <pcw_home> its the dir pin when the encoder counter is in up/down mode
[14:11:56] <JT-5i25> B+ to ground?
[14:12:16] <pcw_home> Yeah I think bu jumper that one pin for TTL
[14:12:47] <cncbasher> more information overload to remember
[14:13:00] <pcw_home> just jumpering for TTL may be enough
[14:14:59] <JT-5i25> it doesn't say in the manual can I assume that W4 is A W5 is B and W6 is IDX
[14:15:08] <pcw_home> not sure what an unconnected differential input on a 7I76 encoder does
[14:15:25] <pcw_home> it the jumper closest to the pin pair
[14:21:32] <JT-5i25> I changed W5 to TTL backwards still... going to ground ENCB+ now
[14:25:07] <JT-5i25> ok, that worked and the velocity is much steadier now
[14:25:12] <JT-5i25> thanks again Peter
[14:27:32] <JT-5i25> cncbasher: I think you were trying to help me fix something that was not broken... yet, thanks for trying
[14:28:45] <JT-5i25> hmmm, too late for a nap and too early for a beer :/
[14:28:53] <pcw_home> I think if only the A pin is used (and the other pins used for GPIO) the B line gets grounded in the FPGA
[14:28:55] <pcw_home> and you will count down again, so the THC comp should be able to deal with this
[14:29:15] <pcw_home> (that is with a custom config that has no B pin)
[14:31:54] <JT-5i25> the THC comp only uses the velocity number with the offset and scale applied to velocity
[14:32:40] <pcw_home> well if offset an scale can be signed it shoul dbe possible
[15:07:53] <CareBear\> archivist : so the 9 axis are one dimensional, right?
[15:09:02] <archivist> what do you mean by one dimensional, on the same machine working together
[15:10:11] <archivist> and many use servos not steppers
[15:11:41] <CareBear\> one dimensional as in each axis will always have a single set value?
[15:12:45] <CareBear\> servos are nice since they compensate on their own, but I don't know about their feedback..
[15:13:54] <archivist> feed back comes back into linuxcnc
[15:14:32] <Loetmichel> not neccessarily
[15:14:57] <Loetmichel> uhu-servocontroolers for brushed servos are working like steppers
[15:15:15] <archivist> Loetmichel, only the rubbish stepper types
[15:15:24] <Loetmichel> step/dir inputs, servo motor outputs, encoder inputs
[15:15:47] <Loetmichel> i meant from linuxcncs point of view
[15:16:04] <archivist> but the encoder goes back to the linuxcnc and is therefore in the loop
[15:16:08] <Loetmichel> the controller has only step/dir input from the pc, and does the PID in itself
[15:16:17] <archivist> not all
[15:16:25] <Loetmichel> so the encoder goes to the uhu b oard
[15:16:37] <Loetmichel> iirc gecos are the same way
[15:16:38] <archivist> grr
[15:17:21] <Loetmichel> ?
[15:17:21] <CareBear\> so, since sync is important, I would build a controller with some ARM chip (I like and do workshops with LPC1343) and an FPGA
[15:17:57] <alex4nder> CareBear\: we meet again
[15:18:38] <CareBear\> the key being that over USB to the ARM, a slightly higher level protocol is used, which actually fits the application. ie. not sending a move command which starts movement, and then sending a stop command to stop movement, but sending a "move to $setvalue" command
[15:18:59] <Loetmichel> hmm, the uhu servocontroller works with a atmel tiny2313... and goes up to 50khz steps
[15:19:11] <CareBear\> alex4nder : yo
[15:19:13] <Loetmichel> ... maybe a fpga is a bit oversized?
[15:19:30] <CareBear\> Loetmichel : the requirement was for 9 synchronized axis
[15:19:38] <Loetmichel> oh, i see
[15:19:45] <CareBear\> and even if there are just 2 axis
[15:19:54] <CareBear\> it still needs to be programmable logic..
[15:19:55] <Loetmichel> tahts a bit much for ONE 8bit cpu
[15:19:57] <archivist> CareBear\, I know there is a high speed bidirectional mode in usb, that part needs moving to the kernel in realtime
[15:20:05] <CareBear\> archivist : please forget about realtime
[15:20:17] <archivist> eg 1ms
[15:20:40] <archivist> we use rtai kernel
[15:21:09] <CareBear\> implementing 9x a simple closed loop control is pretty straightforward in an FPGA
[15:21:34] <archivist> the trajectory planning is not
[15:21:40] <CareBear\> of course
[15:21:48] <CareBear\> and it should certainly stay in the PC
[15:21:52] <archivist> so we keep it in the pc
[15:21:53] <CareBear\> key word is *planning*
[15:21:59] <CareBear\> not *execution*
[15:22:04] <CareBear\> they need to be separate
[15:22:17] <archivist> planning is realtime WITH feedback from the position
[15:22:31] <archivist> cannot be separate
[15:22:49] <CareBear\> so what does the planning do when something is not executing according to plan?
[15:23:07] <archivist> adjust , slows another axis to match
[15:24:16] <CareBear\> and you say it's impossible to precompute the compensation coefficients such that compensating is merely a lookup away?
[15:24:50] <archivist> you dont know without feedback
[15:25:05] <CareBear\> of course
[15:25:10] <CareBear\> given feedback
[15:25:28] <archivist> which is why communications have to be deterministic
[15:25:37] <CareBear\> they never are
[15:25:57] <CareBear\> not even on PCI or HT
[15:26:18] <CareBear\> but okey, you said something about 1 ms?
[15:26:30] <archivist> within a small latency
[15:31:48] <archivist> servo systems can work reasonably well with a 1ms period, stepper systems need a faster period
[15:38:57] <CareBear\> not going to happen
[15:40:21] <CareBear\> so, a USB primer:
[15:40:30] <CareBear\> most communication is unidirectional
[15:40:40] <CareBear\> there are a couple of layers of protocol
[15:40:41] <Jymmm> JT-Shop: "I'm ready for my close up"
http://i43.tinypic.com/o8s8px.jpg
[15:41:05] <CareBear\> bandwidth can be reserved on a bus, but only at the cost of error correction
[15:41:10] <CareBear\> this seems appropriate however
[15:41:33] <CareBear\> the full speed timeslot is 1ms
[15:41:40] <CareBear\> the high speed timeslot is 125µs
[15:41:55] <CareBear\> inside one timeslot there can be multiple data transfers going on
[15:42:44] <CareBear\> I don't believe that round trips can be accomplished within one timeslot
[15:42:47] <joe9> mikegg, wondering if you could help me make the spindle straight.
[15:43:07] <joe9> It was 0.002 inch runout. I made it 0.004 inch runout by trying to correct it.
[15:45:09] <archivist> cant find my copy of the spec here at the moment
[15:48:32] <CareBear\> archivist : in any case, you can not really control the scheduling
[15:48:43] <CareBear\> archivist : it is done by the host controller
[15:49:44] <archivist> but can the host be controlled to be more deterministic than normal
[15:49:57] <CareBear\> not to the degree that you need
[15:50:24] <CareBear\> Isochronous endpoints are given opportunities to the bus every N (micro)frames.
[15:50:28] <CareBear\> is one quote
[15:51:56] <CareBear\> so the best that could be done would be to schedule half a microframe full of isoc IN transfers, and half a microframe of isoc OUT transfers
[15:52:03] <CareBear\> interleaved
[15:55:08] <archivist> can half a microframe full of isoc IN transfers, and half a microframe of isoc OUT transfers can be done reliably though
[15:55:36] <CareBear\> that mostly depends on the USB stack
[15:55:56] <CareBear\> the host controller (the PCI device) is built to do it
[15:56:14] <archivist> and.... can we steal that part of the stack and move it out of userspace
[15:56:20] <CareBear\> huh+
[15:56:21] <CareBear\> ?
[15:56:27] <CareBear\> it's not in userspace
[15:57:19] <CareBear\> this is how every linux works
[15:57:43] <archivist> when using rtai
[15:57:52] <CareBear\> I never have :)
[15:58:00] <archivist> this is not every linux
[15:58:32] <archivist> I know there have been one or two attempts
[15:58:58] <Jymmm> JT-Shop: Did you see the links?
[16:00:44] <CareBear\> archivist : so what is USB like on rtai?
[16:00:57] <CareBear\> archivist : I mean, drivers/usb/*
[16:01:27] <archivist> it lives outside the realtime part
[16:01:43] <CareBear\> that's fine
[16:01:44] <archivist> so we dont/cannot use it
[16:01:49] <CareBear\> aha
[16:01:53] <CareBear\> so you have to write a USB stack then
[16:01:54] <CareBear\> good luck
[16:01:55] <CareBear\> :)
[16:02:11] <CareBear\> seriously - it's an xy problem
[16:02:26] <CareBear\> it will either fail or be a hellish effort
[16:02:34] <CareBear\> design another way instead
[16:02:38] <gene__> is anyone using ndiswrapper with a netgear WNA3100 USB DONGLE?
[16:02:39] <archivist> most use a pci or parallel port
[16:03:01] <CareBear\> sure, local bus can work fine
[16:03:12] <CareBear\> parport not so much
[16:03:24] <Jymmm> gene__: You using DOS ?
[16:03:36] <gene__> 10.04 on my lappy
[16:03:49] <CareBear\> archivist : building a pci device is more effort though
[16:03:55] <Jymmm> gene__: Why NDIS then?
[16:03:56] <CareBear\> archivist : buildling a clever usb device is not so much effort
[16:04:01] <cradek> 50,000,000 Elvis Fans Can't Be Wrong
[16:04:15] <gene__> it won't load bcmwlhigh5 now, last time powered up, it worked fine
[16:04:32] <Jymmm> gene__: Oh, did an update occure?
[16:04:48] <cradek> (probably the vast majority of linuxcnc users use the parallel port)
[16:04:49] <gene__> Only driver for a netgear usb dongle.
[16:04:53] <Jymmm> ah
[16:04:56] <CareBear\> archivist : the key is in the protocol. the planning must be split from execution, so that execution of one synchronized "move" can run standalone
[16:05:19] <CareBear\> archivist : this may mean requirement to precompute compensation coefficients
[16:05:30] <JT-Shop> I saw the squirrel Jymmm
[16:05:38] <CareBear\> archivist : and have them be delivered with the "move plan" which will be the atom of the USB protocol
[16:05:39] <Jymmm> gene__: I only use NDIS drivers in MS-DOS myself.
[16:05:45] <Jymmm> JT-Shop: Cool =)
[16:06:02] <Jymmm> JT-Shop: There are a couple of other links I gave you too.
[16:06:23] <gene__> I wouldn't let a dos install disk get within 100 feet of my stuff :)
[16:06:52] <Jymmm> why?
[16:07:08] <djdelorie> CareBear\: is this the kind of thing that would be better served by, say, a CAN protocol?
[16:07:54] <archivist> CareBear\, the intelligent other has to be up to a PC's abilities, current ly the display can be on a separate pc and communicate via a network
[16:12:42] <archivist> the djdelorie of djgpp fame? /me used it many years ago
[16:12:50] <djdelorie> yes, that's me
[16:13:38] <archivist> worked perfectly on a job I did where M$ stuff didnt :)
[16:13:43] <djdelorie> currently buiding one of these:
http://www.delorie.com/photos/cnc/ with three of these:
http://www.delorie.com/electronics/bldc/
[16:13:55] <djdelorie> archivist: glad I could help :-)
[16:21:16] <archivist> bldc driver looks interesting
[16:21:35] <DJ9DJ> gn8
[16:22:45] <djdelorie> thanks. My friend says they're the most expensive "free" motors I've ever gotten...
[16:23:12] <djdelorie> but I put a CAN interface on the boards, and in theory they're powerful enough to run the motor paths themselves, if I can figure out how...
[16:27:29] <CareBear\> hi dj
[16:27:32] <archivist> andypugh found some interesting hall phases from various bldc motors
[16:28:20] <djdelorie> I only use the hall phases until I see the enc-Z pulse, then I use the encoder value instead, they're more accurate.
[16:28:47] <CareBear\> dj : the requirement we're looking at is 9 axis synchronized. this needs control to be local, or it will just fail
[16:29:16] <CareBear\> archivist : the point is to make a protocol where the "other" can be pretty stupid as long as it has fast response time
[16:29:44] <CareBear\> archivist : worst case this means precomputing lots of data that the stupid other has to use to look up how it will compensate
[16:30:16] <vin321> are thease drivers any good ?
http://www.ebay.co.uk/itm/5-AXIS-TB6560-CNC-DRIVER-BOARD-4-STEPPER-MOTOR-ROUTER-/110834096417?pt=LH_DefaultDomain_0&hash=item19ce3a1921
[16:31:59] <CareBear\> dj : at least that's myho. the synchronization is the real difficult part. it doesn't seem like there's room for any round trips there.. the 9 controllers need to be closely connected. my thought was to put them all in one FPGA. could be that they can talk to each other via CAN just as well.
[16:32:17] <CareBear\> s/any round trips/a star topology/
[16:32:46] <djdelorie> my thought was, the controllers could "calibrate" their own axes, and share that info amongst themselves, then provide shared feedback to each other.
[16:33:11] <CareBear\> exactly
[16:33:12] <archivist> vin321, define any good, TB6560 has some strangeness
[16:33:40] <archivist> CareBear\, the controller is IN linuxcnc
[16:33:42] <djdelorie> but I still haven't gotten step/direction to work cleanly, so who am I to say? ;-)
[16:34:06] <CareBear\> archivist : that needs a redesign I'm afraid :)
[16:34:13] <archivist> no it does not
[16:34:55] <CareBear\> I think it does, in order to deal with bursty communication
[16:35:28] <vin321> i guess i need a cheep driver coz i smoked the lame 1's i had
[16:35:30] <archivist> cannot have bursty comms. the comms have to be fixed
[16:35:41] <CareBear\> sure can
[16:36:06] <CareBear\> but needs control closer to each axis
[16:36:07] <archivist> vin321, some are using those chips
[16:36:35] <CareBear\> archivist : is the situation for cnc same as for extrusion, that constant movement is important for a nice end result?
[16:36:56] <CareBear\> intuitively I might expect that it's not so
[16:36:57] <archivist> problems of noise(stepper whistle) adjust capacitors
[16:39:17] <CareBear\> archivist : my thinking is this: when a plan goes wrong, the 8 local controllers adjust to the one that went wrong. at some point all 9 are back on the originally planned trajectory, but going forward from there perhaps there should instead be a new plan. if that is the case, could they all stop and wait for a new plan when they have compensated and all come back on track?
[16:39:20] <archivist> CareBear\, constant and related to loads
[16:39:51] <archivist> and its flying at speed
[16:40:16] <CareBear\> didn't mean constant speed, but constant motion
[16:40:50] <CareBear\> ie. is it OK to stop?
[16:40:59] <archivist> no
[16:41:06] <CareBear\> why?
[16:41:11] <archivist> damage
[16:41:15] <CareBear\> of?
[16:41:22] <CareBear\> /to
[16:41:30] <archivist> tooling, who know
[16:41:52] <CareBear\> is the spindle considered one axis?
[16:42:00] <CareBear\> or would there be multiple?
[16:42:04] <CareBear\> ie. what are those 9 actually?
[16:42:06] <CareBear\> :)
[16:42:26] <archivist> spindle can be eg with solid tapping
[16:42:54] <archivist> so Z must follow loading on the spindle
[16:43:28] <CareBear\> but then Z could also stop
[16:43:43] <CareBear\> (while spindle does *not* stop)
[16:45:29] <archivist> sudden stopping breaks things with solid tapping unless axes follow each other with feedback and Linuxcnc controls the maximum following error
[16:45:49] <CareBear\> well, I'm not thinking so much sudden stopping
[16:46:03] <PCW> hatch789 around?
[16:46:26] <CareBear\> archivist : more that, in the case of X and Y being fixed, then Z can stop instead of move without problem
[16:46:47] <CareBear\> archivist : if we're making a hole straight down
[16:47:09] <cncbasher> PCW : yea he is
[16:47:15] <cncbasher> me too
[16:47:19] <archivist> tapping is the norm for some
[16:48:13] <archivist> CareBear\,
http://www.youtube.com/watch?v=g6p1-h5Rlv4
[16:48:20] <CareBear\> archivist : where I'm going is that compensating for an error during execution of the planning could perhaps be simplified to getting back to the originally planned trajectory, as opposed to calculating a completely new trajectory for the rest of the job
[16:49:35] <PCW> freeby.mesanet.com/svrm6.bit should be betterer
[16:49:42] <archivist> see video it HAS to follow what the spindle does
[16:50:18] <JT-Shop> I think you should do it CareBear\
[16:51:07] <CareBear\> JT-Shop : I have waay too many things to do already :p
[16:51:32] <CareBear\> JT-Shop : but the discussion helps me understand how a protocol could look
[16:52:03] <JT-Shop> oh, I though you were trying to convince archivist to do it for you :P
[16:52:43] <CareBear\> JT-Shop : that's fine too! I will not get around to it anytime soon
[16:52:49] <CareBear\> JT-Shop : if ever
[16:53:11] <CareBear\> JT-Shop : the discussion started with questions about USB, which is one of my scenes
[16:55:09] <CareBear\> archivist : I think the hardware effort for a PCI(e) controller is significantly smaller than the software effort for precomputing compensation the way I'm thinking of. I don't know linuxcnc, but I can understand that it would mean a big change.
[16:55:25] <CareBear\> 1-lane PCIe is not a bad idea
[16:55:33] <CareBear\> then it can go into an ExpressCard
[16:55:44] <archivist> we already have pci pcie is just around the corner
[16:55:59] <CareBear\> open? documented?
[16:57:05] <archivist> http://www.mesanet.com/ documented
[16:58:29] <archivist> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?EMC2_Supported_Hardware
[17:01:30] <CareBear\> ouch, rt-usb from 2005 /o\
[17:02:05] <CareBear\> originally only full speed
[17:02:30] <archivist> needs love and bringing up to date
[17:03:01] <CareBear\> project no longer at berlios
[17:03:32] <PCW> Its a nice spring day, here hows it there?
[17:03:41] <CareBear\> about midnight
[17:03:44] <PCW> oops
[17:03:47] <CareBear\> :)
[17:04:39] <CareBear\> cloudy, in the low 40s F
[17:04:47] <CareBear\> maybe high 30s even
[17:04:58] <joe9> is it a hard job to straighten a drill press spindle? I tried the tapping with the hammer approach, but that is just making it worse.
[17:05:30] <CareBear\> archivist : it seems the PCI FPGA boards from mesa don't really have a bitstream?
[17:05:40] <CareBear\> archivist : this is both good and bad :)
[17:05:55] <PCW> Cold and foggy this morning but now sunny and about 65/70s here
[17:06:06] <CareBear\> PCW : sounds nice!
[17:06:51] <archivist> joe9, it is an acquired skill, some take a lifetime to get there
[17:07:15] <joe9> archivist: i guess that means it is a hard job.
[17:07:33] <archivist> joe9, er yes, else get a replacement
[17:07:35] <cradek> for a drill press, runouts of .002 and .004 are both just fine unless you intend to use very tiny drills
[17:07:59] <joe9> cradek: yes, i am planning on using a drill bit for 0.5 mm holes.
[17:08:10] <joe9> with a chuck, the runout is amplified to 0.020 inches.
[17:08:15] <cradek> eek
[17:08:21] <joe9> and that is worrisome as I can see the wobble with my bare eyes.
[17:08:26] <cradek> maybe you need a completely different machine then :-)
[17:09:02] <cradek> a mill with collets, so you can use 1/8" or 6mm shank drills
[17:09:10] <joe9> cradek: do you think it is bad for a drill press with a transfer punch, to show a wobble that can be detected by the human eye?
[17:09:28] <cradek> depends on your eye calibration
[17:10:08] <archivist> your expectations of that type of drill press need relaxing a bit
[17:11:15] <archivist> which has reminded me, I need to make a new spindle for my high speed drill press
[17:13:03] <CareBear\> archivist : I'm off for food! very interesting discussion, thanks for that! I think the common packet busses simply aren't fit. PCIe will do.
[17:13:27] <CareBear\> aren't/don't
[17:14:46] <PCW> Glad that was a silly typo/braino in the 7I43 resolver stuff and not anything that required thinking
[17:15:28] <CareBear\> archivist :
http://www.picocomputing.com/e_series.html
[17:20:15] <joe9> archivist: it seems to be expected that drill presses have a runout that makes the the drill bit appear to wobble. I am of the opinion that a replacement spindle might not help. Is the "replacement spindle" was what you were recommending?
[17:20:42] <joe9> if a replacement spindle has the same runout, it does not help at all.
[17:26:52] <PCW> its it bent or just loose bearings
[17:26:57] <PCW> ?
[17:27:07] <joe9> i changed all the bearings
[17:27:20] <joe9> I think at this point, the only thing wrong, could be the bent spindle.
[17:27:41] <alex4nder> are you using a chuck? what kind?
[17:27:46] <joe9> tried tapping it a little, but, that is not giving it much better results.
[17:28:00] <joe9> alex4nder: I am checking the runout at the spindle, no chuck.
[17:28:04] <alex4nder> cool
[17:31:30] <joe9> PCW, does that make sense?
[17:31:56] <JT-Shop> joe9: is this a drill press?
[17:32:03] <joe9> JT-Shop: yes.
[17:32:44] <PCW> taper bored crooked?
[17:32:47] <JT-Shop> it ain't going to be perfect
[17:33:18] <joe9> PCW, when I tap the spindle with a hammer, it is changing the runout. but, just cannot get it well enough.
[17:33:24] <joe9> PCW, yes, that is possible.
[17:33:25] <JT-Shop> did you blue the spindle taper and the chuck to see if they have a perfect fit?
[17:34:05] <joe9> JT-Shop: no, I tried with a different arbor and chuck with the same results.
[17:34:17] <JT-Shop> joe9: if you use a hammer you must put your hand between the hammer and the object you hit to get a feel for the pressures
[17:34:27] <joe9> haha..
[17:34:30] <JT-Shop> what is the runout of the spindle at the taper
[17:34:45] <joe9> 0.002 initially. now, around 0.004 inches.
[17:35:06] <JT-Shop> that's dam good for a cheap drill press
[17:35:21] <joe9> with the chuck, that is getting amplified to 0.020 inches.
[17:35:26] <JT-Shop> was it .004 after the hammer treatment
[17:35:30] <joe9> yes.
[17:36:45] <JT-Shop> you probably borked your bearings when you hammered on it, aside from that check the fit of the chuck on the taper with some Prussian blue
[17:36:55] <fragalot> now ifyou replace the inches by mm, you've got yourself a damn nice system
[17:37:05] <JT-Shop> lol
[17:37:37] <JT-Shop> are you indicating the od of the chuck nose or a bent drill bit
[17:38:06] <joe9> when i put in a transfer punch, I can see it wobble pretty badly.
[17:38:28] <joe9> with the transfer punch or just at the chuck, the runout is 0.020 inches.
[17:38:52] <JT-Shop> put your test indicator on the chuck not the transfer punch to find out if the chuck is wobbling or your jaws suck
[17:38:53] <joe9> let me see if mikegg can help me. if not, I will have to look for another machine oslt.
[17:39:08] <JT-Shop> your skipping too many steps...
[17:39:12] <joe9> no, the chuck is good. tried with 2 different chucks.
[17:39:21] <joe9> and, the runout is the same at the chuck
[17:39:44] <JT-Shop> do you even know if you have the correct taper chuck?
[17:40:03] <joe9> yes, I have the correct taper chuck.
[17:40:16] <joe9> I matched the spec with the one that I bought.
[17:40:27] <joe9> it was a Morse Taper #3 for the machine
[17:40:31] <JT-Shop> then the chuck nose should not have any more runout than the spindle
[17:40:58] <JT-Shop> check the fit of the chuck on the spindle with blue
[17:40:58] <joe9> it does, and that is the reason I think it could be the spindle.
[17:41:17] <JT-Shop> how could it be the spindle
[17:41:50] <joe9> if the spindle is bent, would it not make it like a pendulum when the chuck is on?
[17:42:37] <JT-Shop> did you put your test indicator on the tip of the spindle then back up a bit to see if it is bent
[17:43:20] <JT-Shop> and yes 0.004" at the base of the spindle taper will be a bit more down the chuck
[17:43:20] <joe9> i put the dial indicator on the tip of the spindle. what do you mean "back up a bit"?
[17:43:50] <JT-Shop> measure at the bottom of the taper then the top of the taper to see if the runout is the same
[17:44:33] <joe9> I did with an arbor (no chuck) and it was the same at the spindle and at the (bottom) end of the arbor.
[17:44:40] <joe9> does that make sense?
[17:45:01] <joe9> want to check if I am able to explain what I did properly.
[17:47:35] <JT-Shop> do you mean you indicated the taper of the spindle or something on the spindle?
[17:48:44] * archivist hopes on a cleanly ground bit
[17:54:34] * JT-Shop goes back to making cannon parts
[18:08:18] <JT-Shop> lol, my drill press has 0.006" TIR and I don't care
[18:08:56] <PCW> Aim your cannon at joe9s drill press :-)
[18:09:22] <JT-Shop> LOL, OK Peter I will but he has to be within about 1/2 mile or so
[18:13:42] <joe9> JT-Shop: just wanted to check with you about this behaviour, when I have the quill all the way down and I press and hold the housing of the quill to the side, the runout is 0.002 inches.
[18:14:08] <joe9> but, when I leave it and check the runout of the spindle, the runout is 0.007 inches
[18:14:25] <joe9> JT-Shop: is your 0.006 inches runout at the chuck or the spindle?
[18:15:16] <JT-Shop> I just measured on my chuck as you piqued my curiosity
[18:15:31] <joe9> 0.006 inches at the chuck is pretty cool.
[18:15:32] <JT-Shop> but it doesn't affect the drilling any
[18:15:45] <joe9> mine is 0.020 inches at the chuck.
[18:16:01] <JT-Shop> blue the taper to the chuck fit
[18:16:10] <JT-Shop> do you know how to do that?
[18:16:12] <joe9> or, sometimes close to 0.03 inches.
[18:16:29] <joe9> no, I have never done "bluing". will see if I can do it.
[18:18:04] <JT-Shop> you smear a thin coat of something grease like on one part and put the two parts together and remove with care then see what areas the grease transferred to the dry part
[18:18:31] <JT-Shop> that shows you what parts touched
[18:20:18] <JT-Shop> the process is systematic to find the actual problem part, so if you mark the chuck and the shaft and assemble and indicate then rotate 1/4 turn and repeat you can figure if the chuck is bad or the taper or spindle is bad
[18:20:34] <joe9> ok, thanks.
[18:31:14] <SadMan> isn't there by chance a package with rtai kernel newer than 2.6.32?
[18:36:13] <raynerd> Hi guys, sure this is very obvious but have been working on my cnc machine for 2 weeks now and just these last few mins giving it its first 3 axis run of the emc2 splash screen. It is 12:30 midnight and I`m shattered but...
[18:36:30] <raynerd> when I`m cutting, I`m getting like an inverted image?
[18:36:54] <raynerd> so the EMC2 splash/demo looks like it is from behind.
[18:37:33] <alex4nder> your X is swapped?
[18:37:58] <raynerd> ahhh, could be...sorry tired, just wanted to go to bed happy.
[18:38:02] <raynerd> I`ll give it a go.
[18:40:31] <raynerd> nice one, thank you!
[18:43:50] <joe9> raynerd: what is your bom?
[19:21:01] <JT-Shop> someone pass me a tourniquet to stop the flow of red...
[19:21:25] <Tom_itx> don't spill the wine!!
[19:22:42] <JT-Shop> I'd hate to spill that
[19:24:04] <JT-Shop> I feel like Julia Childs cutting up chicken on Saturday night live
[19:25:39] <PCW> LOL You know, a glass of red sounds pretty good right now, must mean its time to go home
[19:26:13] <JT-Shop> I'd say it is time to head to the ranch Peter
[19:26:34] <PCW> yessir
[19:28:11] <PCW> take care and watch out for those tornadoes...
[19:30:59] <JT-Shop> ok, thanks and the tornadoes have moved on
[19:33:23] <Jymmm> JT-Shop: Got Basement?
[19:33:49] <Tom_itx> probably a cave in swampeast Mo
[19:34:18] <Jymmm> Branson is no more either
[19:34:36] <Tom_itx> ?
[19:34:42] <Tom_itx> what happened to branson?
[19:34:49] <Jymmm> tornado
[19:34:56] <Tom_itx> mmm
[19:36:19] <Jymmm> http://www.newspressnow.com/localnews/30596237/detail.html
[19:37:33] <Jymmm> Wehn I saw it a couple of days ago, it was a EF-4, not a EF2 tornado.
[19:38:08] <Tom_itx> when did it hit?
[19:38:20] <Jymmm> wednesday
[19:38:52] <Jymmm> The details are in that link Tom_itx if you're interestesd.
[19:39:20] <Tom_itx> k
[21:52:48] <hatch789> anyone have any idea why my 7i49 board would not have any DC signal coming out for my servo drives? I just got the resolvers working today with PCW's help, but my servo drivers are not producing any voltage to drive my servos
[21:55:36] <jdhnc> I assume you checked the power supply
[21:56:31] <hatch789> yeah ...my resolvers are working properly and picking up my movements on the handwheels
[21:57:04] <jdhnc> aren't they powered separately?
[21:57:07] <hatch789> for them to be working the board (7i49) has to be operating with the proper voltage and other things
[21:57:11] <hatch789> no
[21:57:28] <hatch789> the board gets it power from the 50 pin connector to my 7i43 card
[21:57:54] <pcw_home> 7I49 needs 2 enables and pwmgen set to mode 2
[21:58:10] <hatch789> I saw the 2 enables thing. But I didn't know what that meant?
[21:58:30] <jdhnc> ya know, you just can't beat the cost of Linuxcnc and the responsiveness of mesa guys
[21:58:31] <hatch789> pg12 enable inputs
[21:59:11] <hatch789> I have my pwmgen set to mode 2. It's been mode 2 since a few days ago
[21:59:29] <hatch789> but what's the 2 enable inputs that come from the FPGA?
[21:59:52] <pcw_home> they are from pwmgen enable
[22:00:09] <pcw_home> (both from ena 0 I think)
[22:02:50] <pcw_home> hm2_7i43.0.pwmgen.00.enable must be set true
[22:03:30] <hatch789> in my hal file? under the PWM Generator signals/setup section?
[22:04:34] <pcw_home> its supposed to be controlled by a linuxCNC or axis signal (take a look at the sample hm2 servo config)
[22:05:51] <hatch789> ok I will do that. this is what I have by the way in my PWM Generator signals/setup section
[22:05:52] <hatch789> net x-enable axis.0.amp-enable-out => hm2_7i43.0.pwmgen.00.enable
[22:06:11] <hatch789> then of course:
[22:06:12] <hatch789> net y-enable axis.1.amp-enable-out => hm2_7i43.0.pwmgen.01.enable
[22:09:13] <pcw_home> only 0 should matter
[22:09:15] <pcw_home> you can check that both pin 1 and pin 47 on the 7I49
[22:09:17] <pcw_home> 50 pin connector go low when you are in a machine on state
[22:10:57] <pcw_home> and trace in hal that they are true and the pwmgen value is reasonable relative to pwmgen scale
[22:12:06] <hatch789> I can't seem to find your hm2 servo config sample hal file?
[22:13:18] <pcw_home> it should be in ~/EMC2 (or LinuxCNC)/configs/hm2-servo
[22:13:41] <hatch789> ahh there it is
[22:15:02] <hatch789> is it this section I'm looking at mostly?
[22:15:04] <hatch789> # axis enable chain
[22:15:04] <hatch789> newsig emcmot.00.enable bit
[22:15:04] <hatch789> sets emcmot.00.enable FALSE
[22:15:04] <hatch789> net emcmot.00.enable => pid.0.enable
[22:15:05] <hatch789> net emcmot.00.enable => hm2_[HOSTMOT2](BOARD).0.pwmgen.00.enable
[22:15:09] <hatch789> net emcmot.00.enable <= axis.0.amp-enable-out
[23:28:13] <hatch789> pcw_home, it looks like everything is OK from an "enable" standpoint.
[23:28:32] <hatch789> My hm2_7i43.0.pwmgen00.enable is yellow and pwmgen01.enable is yellow
[23:28:51] <hatch789> when I turn the machine power button off (on AXIS) those buttons go red
[23:29:18] <hatch789> also hm2_7i43.0.gpio.001.in is yellow
[23:29:39] <hatch789> also hm2_7i43.0.gpio.047.in is red
[23:30:14] <hatch789> the hm2_7i43.0.gpio.047.in_not is yellow
[23:30:24] <hatch789> so how do I make the 047.in yellow?
