Back
[00:05:32] <MarkusBec> MarkusBec is now known as MarkusBec_away
[00:06:03] <andypugh> OK, bye folks
[01:57:03] <Dave911> Has anyone run EMC2 Axis on a touch screen? Is it workable, barely, or not at all?
[01:57:17] <cradek> barely
[01:57:28] <cradek> fortunately it's perfectly and totally keyboardable
[01:57:35] <cradek> if you have a keyboard you'll be fine
[01:57:49] <Dave911> It is very keyboardable - you are right..
[01:58:52] <Dave911> I am wondering if I set it up for a customer on a 17" screen if they will hate me afterwards! ;-) The environment is not agreeable with keyboards - waterjet
[02:00:20] <Dave911> Is there a "standard" config for doing a 2 drive gantry (two motors on the Y Axis that run in parallel) Does it home one side of the gantry at a time?
[02:00:47] <cradek> not standard - as you have guessed the problem is homing
[02:01:02] <cradek> you can do all sorts of stuff in hal - we could use a sample config from someone who gets it working well.
[02:01:38] <cradek> if you don't have a keyboard you MUST have a jogwheel - jogging with a touch screen (or mouse) is just plain terrible
[02:02:08] <Dave911> Homing -- Wow, that would really be nice. I could bang my head on setting up homing for quite a while.
[02:02:48] <cradek> maybe you misunderstood me - I was suggesting you could contribute yours after you figure it out...
[02:02:56] <Dave911> Jogging - wow you are right about that. A jogwheel would definitely be required. Heck with that, I'll use a rubber type keyboard on a tray.
[02:03:21] <toastydeath> mpgs are the only way to fly
[02:03:58] <cradek> Dave911: there you go - I bet you'll be happier
[02:04:17] <Dave911> Misunderstood - yes that would be the case.. ;-) So this has not been done before - the dual drive gantry homing thing? If I can get it to work I'd be happy to contribute that. Seems like that wheel should have been invented by now.
[02:04:36] <cradek> I am positive it has been done
[02:04:41] <toastydeath> several people have asked to do that, iirc
[02:05:31] <cradek> it can be as simple as you want - with steppers, mask the step pulses to the side that hits its home switch first, you're almost done
[02:05:34] <Dave911> On this channel? Perhaps I should search the archives.. to get started?
[02:06:11] <Dave911> What do you mean by mask the step pulses?
[02:06:16] <cradek> ... then when both sides are on their switch, send it on to emc
[02:07:06] <cradek> use hal. initially when homing send the step pulses to both motors. when one hits its switch, send them only to the other one. when both are on their switches, turn on emc's home-switch-in signal
[02:07:27] <cradek> I bet there are a dozen ways to do it - this is only the first I think of
[02:07:41] <Dave911> Wow, could it be that easy?
[02:07:44] <cradek> (homing encoders to index is a lot harder)
[02:08:30] <cradek> I don't know - make it as complex as necessary, but no more :-)
[02:08:40] <Dave911> I don't think I need index pulse accuracy. It would be nice, but not needed. I am probably more concerned about the gantry getting out of square during homing than anythng else
[02:09:08] <cradek> yes you definitely need to move the motors together
[02:09:08] <Dave911> >> make it as complex as necessary, but no more :-)
[02:09:10] <Dave911> We are thinking along the same lines .. ;-)
[02:09:23] <cradek> you know when you start it's sort of square - your task is to keep it that square or better
[02:10:05] <Dave911> Yes, as long as I don't jack it out of square I will probably be fine.
[02:11:47] <Dave911> I could mock this up in my office with stepper drives and motors and get the hal stuff ironed out before I have to shut the waterjet down.
[02:11:49] <Dave911> This should work. Once I get this working I'll write it up.
[02:12:04] <cradek> cool
[02:12:26] <Dave911> When I write this up, where do I put it? In the Wiki?
[02:13:01] <cradek> yes that's nice because when people ask (like this) we can just give the URL
[02:13:27] <cradek> if BJT wants it in the docs maybe he'll work with you to do that - not sure if it would be appropriate or not since it's a bit unusual.
[02:13:48] <cradek> the wiki is GREAT for "a bit unusual" and case study type of stuff
[02:16:00] <Dave911> OK, I should be getting the job (fingers crossed), their alternative is to buy a new waterjet and that is really expensive. I have to replace the servo drives as they are antiques. But after I rip out the AB 9 series CNC, there will be plenty of panel space! Their intensifier is fine, but the servos are old and the drive boards flake out. AB wants $5K for a new screen.
[02:16:49] <cradek> think you can do the whole thing for $5k? I have no idea what new servo drives cost
[02:20:22] <Dave911> No the motors and drives will cost about 2K each and there are three of them. A PC, a fancy flatscreen with a stainless steel bezel, an air conditioner for the panel (this is a hot humid environment in the summer) etc, plus a PLC to control the conveyor that feeds the waterjet.... The materials alone will hit 10K pretty fast. And I am only a sub, the mechanical guy has to rebuild the...
[02:20:24] <Dave911> ...conveyor and lower the entire machine a foot.
[02:21:04] <cradek> whoah
[02:21:07] <cradek> big deal then
[02:22:21] <Dave911> It is a big machine. The columns that support the cutting head are 10" square steel tubing. The existing servos are AB 1396? and about 18" long.
[02:22:38] <cradek> yike
[02:23:24] <Dave911> I'm going to let the mechanical contractor buy all of the stuff but the PC and some smaller stuff. He can carry the cost of that stuff and wait to get paid etc.
[02:25:36] <tom3p> for homing the 2 axis.. one first, hold that then the other... i picture something like an old lever style torque wrench, with the needle tripping a 'no more' switch due to excessive racking/crabbing.
[02:26:38] <Dave911> Yep, I think the machine is overbuilt but it has been running everyday for 10 years and mechanically it is in pretty good shape.
[02:27:01] <Valen> we have a membrane keyboard for ours
[02:27:28] <Dave911> Has it held up pretty well?
[02:27:34] <Valen> its ok
[02:27:43] <Valen> i type on it some times but it sucks for chatting
[02:27:51] <Dave911> Has anyone tried those flexible rubber keyboards?
[02:27:58] <Valen> thats what i was using
[02:28:13] <fenn> you have to push down on the center of each key.. it's very annoying if you're used to a real keyboard
[02:28:30] <Valen> yeah, you dont want to "type" on it
[02:28:34] <Dave911> OK, I thought you meant the old style membranes that had a mylar overlay..
[02:28:49] <Valen> but if your just pressing buttons its probably ok
[02:29:06] <Valen> IE editing a line or 2 of code or running axis fine
[02:29:16] <tom3p> i used advantech toucscreen iPPC and an iKEY rubber keyboard with a glidepoint. a water based hole drill edm. the guys like the touchscreen. not emc, and it required a pointed stick or good fingerpokin to use the screen.
[02:29:18] <Valen> chatting in here or writing code is teh sucksors
[02:29:34] <Dave911> Oh, well they don't type much on it anyway so I guess it should be fine.
[02:29:53] <Dave911> Why don't they like EMC
[02:30:03] <Valen> for $20 its easy to try ;->
[02:30:39] <tom3p> http://www.ikey.com re: not emc, couldnt sell them on it
[02:30:43] <Dave911> $20 - that is cheap. I thought this was some $200 industrial unit
[02:31:22] <Valen> $20 is an expensive one lol
[02:31:23] <cradek> tried one of those "hulapoint" - terrible
[02:31:55] <tom3p> 'eraserhead'
[02:32:34] <Valen> one guy i know always called those ones in keyboards by the name of a female body part
[02:32:44] <tom3p> the rollup keyboards are 20$ iKeys are 200+
[02:33:14] <Dave911> Is the Ikeys worth it - it looks impressive . ;-) Better be for $200
[02:33:22] <Valen> I was thinking about a touch screen on our mill, but decided against it
[02:33:30] <cradek> you'd think for $200 they could put the keys in the right places
[02:33:40] <tom3p> i really dont like typing on it, but it really is waterproof, fer sure
[02:33:42] <Valen> I figured dragging on the screen with a finger covered in grease and swarf was a bad idea
[02:33:59] <tom3p> haha ueh the keys are screwy!
[02:34:02] <tom3p> yeh
[02:34:26] <tom3p> use a pointed stick ( cheapo plastic pen sans ink tube
[02:34:29] <Dave911> >you'd think for $200 they could put the keys in the right places
[02:34:30] <Dave911> Perhaps they are trying to sell you up to the $300 unit
[02:34:34] <Valen> which keyboard in that lot are you talking about specifically?
[02:34:53] <tom3p> i planned on giving all buyers 'the finger'
[02:35:07] <cradek> none of them seem to have insert/delete/home/end/pgup/pgdn in the standard places
[02:35:31] <Dave911> Did you guys see the wearable keyboard?? I'm trying to figure out how someone could use that..
[02:36:43] <tom3p> we used the PMU-5K-TP2, it has over a dozen stud bolting it onto the panel
[02:37:19] <tom3p> the wearable reminds me of the old MIT LIZZY project ( wearable computer )
[02:38:09] <tom3p> the umpteen function keys sold the customer ( they told me which kbd to get )
[02:46:58] <Dave911> Well thanks guys... I need to fire up an Excel spreadsheet and start making up a BOM for this job. We have to turn in a bid Monday...
[02:47:20] <tom3p> the touch screen panel computer was a IPPC-6172
http://www.advantech.com/products/IPPC-6172A/mod_GF-DAW7.aspx
[02:48:37] <tom3p> OOffice spreadsheets export & import Excel, best o lucck
[02:53:26] <Dave911> That is a pretty nice PC. I have used some screens from this place
[02:53:27] <Dave911> http://www.hopeindustrial.com/
[02:53:29] <Dave911> They have held up really well and they have decent prices. I just saw that they have keyboards now also. I might just recommend a package from them and be done with it.
[02:57:02] <tom3p> is that a pc or a touch panel? none of the specs or numbers say processor or memory or storage...
[02:57:24] <tom3p> the prices are great if a useful pc
[02:59:10] <tom3p> the iPPC 17" was near 1700USD with 2G , 500meg, 2pci, usb par/ser/fw/thernet & wifi, and w2k
[03:14:21] <tom3p> hey, i didnt know ^p was up arrow, last command in history
[04:32:03] <ds3> hmm
[06:09:48] <Valen1> Valen1 is now known as Valen
[06:13:00] <cnuki> Good afternoon!
[07:40:15] <pjm> good morning
[07:42:52] <AchiestDragon> re pause / emergnacy stop regardless both sould be resumable the main issue here that i have seen on say kcam is say its current path is from 100,100,100 to 100,100,20 and its just satarted that current path
[07:44:10] <AchiestDragon> you hit pause and as its just satared that path it will continue untill finished , on a slow machine that can be a miniute or so
[07:56:12] <archivist> stop mid cut asap
[07:56:26] <archivist> no waiting
[07:57:13] <archivist> * archivist off out getting mot
[08:11:07] <AchiestDragon> bk sorry had to drop kidlet off at school ,,, bk to what i was trying to explain
[08:14:45] <AchiestDragon> and however you look at the problem cant seem to spot an easy solution to it ,, the best way would be to have the tool pull back from the work asap and stop , the e-stop should just stop
[08:15:56] <AchiestDragon> although going to be imposible to do say if cutting a t slot where the only way for the tool to go is back up its cutting path
[08:17:27] <AchiestDragon> and if using steppers on microstep then there not going to hold there position if not at a full step
[08:36:32] <AchiestDragon> actualy worst case e-stop could make things worse ,, if e-stop drops stepper power then the stepper may drop to the nearest full step that could force the tool further into the work causeing posiblay a tool break in the process
[08:36:58] <archivist> exactly the point I was making
[08:37:29] <archivist> safer to bring a machine to safe than cut power
[08:38:03] <robh_> Estop should follow the standard layed out by law if uask me, so BS or EU or US aproved standard where ever u are which mainly states a machine should be stoped in a safe way and in a timly manner seen fit by the intergrater with under power or not when estoped is down to the situation at hand
[08:38:56] <archivist> thats a good way of putting it
[08:39:05] <AchiestDragon> the only way arround the whole problem i can see is to drop spindle power imediatly , and pull the axis back allong its cutting path 1 or 2 steps to give it a slight clearance from the current cutting face
[08:39:05] <robh_> isnt program stop, abort more what u are talking about here? where machine is stoped in a way that is deemed safe
[08:41:11] <AchiestDragon> if stepper power is maintained then it should not drop the fractions of step in the process that would allow for an accurate resume
[08:41:12] <robh_> i only read the logs quickly so excuse me
[08:42:25] <AchiestDragon> well as i see it the E stop should be resumable ,, to the point that a seperate pause would not be needed
[08:44:40] <AchiestDragon> although the exception to that is a pause , then a power down of the whole system on a restart then the resume would be not practicle to impliment
[08:45:05] <AchiestDragon> pause / stop
[08:46:08] <archivist> pause/ adjust tool/resume is another can of worms
[08:47:36] <AchiestDragon> the main issue i find with a seperate pause / e stop is the e stop is usualy a phisical button ,, the pause may be a case of navigating a mouse pointer to the appropriate "icon"
[08:47:39] <robh_> estop is always a fuzzy gray area and many things have to be taken into account, type of machine, what happens if power is cut or not cut etc etc so only u I.E the intergrater is the one who can see what is fit for an estop situation, al down to where u are etc as i said, as for england the BS law states estop is to be unsed in emergencys only for stoping the machine in atimly manner etc etc (there is 4 types of estop cirucit too deemed sutable machine depe
[08:47:39] <robh_> ndable)
[08:48:23] <robh_> i gtg off to doncaster :) bbl
[08:48:35] <AchiestDragon> k
[08:49:21] <wavez> Hi everyone. This is my first time to this channel. I used irc and linux for a long time, some years ago. I'm very excited to learning CNC and EMC.
[08:49:37] <wavez> excited to *be
[08:49:49] <wavez> just wanted to give a general greeting to the channel
[08:50:41] <AchiestDragon> also while on the subject of e-stop and safty ,,, is there provision on the interface to accomodate safty cage interlocks ,, that would prevent the machine from opperating when cage open
[08:50:49] <AchiestDragon> hi wavez
[08:51:23] <archivist> often they are in the estop circuit
[08:52:37] <wavez> hi AchiestDragon :)
[08:55:07] <AchiestDragon> yea but in thats incorrect and not the correct way ,,, safty gate should close , swich to sence that , then it gets locked closed ,, e-stop pressed the cage should only open after a delay to allow for spindown time
[08:55:43] <archivist> that an interlock, thats different
[08:59:11] <AchiestDragon> although software controled e-stop is also has problem nomatter how its implimented ,,, the computer may crash for some reason in such a way that the stepers are driven in a wrong direction and as the computer fails the software e-stop fails to function
[08:59:46] <AchiestDragon> should file that as a bug report ,,, repoducable under conditions of ramdom power glitch
[09:01:42] <AchiestDragon> although on the fpga contolers that can be implimented in hardware the fpga itself is still essentaly a software device and can suffer the same
[09:03:23] <AchiestDragon> will think about it a bit more and see if i can come up with a fix
[09:14:16] <wavez> is ACE for windoze or gnu?
[09:14:44] <wavez> I'm checking it out on dakeng.com but not finding much
[09:15:14] <wavez> ah, it's for windoze
[09:28:10] <wavez> see everyone next time
[12:51:09] <Valen> Got the mill dialed in fairly close
[12:51:22] <Valen> however it hunts around any given end point
[12:51:29] <SWPadnos> I
[12:51:31] <Valen> it ticks from .999 to .003
[12:51:43] <Valen> deadband didn't do what i thought it would
[12:51:56] <Valen> any way to tell it that .004 is close enough?
[12:51:59] <SWPadnos> what's the step/feedback resolution?
[12:52:04] <Valen> .001
[12:52:14] <Valen> its stiction thats doing it is my guess
[12:52:31] <Valen> by the time its wound up enough force to actually move the axis it jumps past the 0 point
[12:52:40] <SWPadnos> deadband (for the PID) should be a value below which the error is considered zero
[12:52:56] <SWPadnos> right
[12:52:58] <SWPadnos> maybe less I
[12:53:39] <Valen> hmm I like the high I to get it to get close to 0 rapidly
[12:53:53] <Valen> I'll retry deadband I guess
[12:53:55] <SWPadnos> I shouldn't be doing that
[12:54:07] <SWPadnos> P gets it close fast
[12:54:20] <SWPadnos> D reduces overshoot/ringing (more or less)
[12:54:24] <SWPadnos> I eventually drives it home
[12:54:34] <Valen> yeah that was the bit of I i liked
[12:54:56] <Valen> I compensated somewhat with D and it is only oscilating due to the stiction now i think
[12:54:56] <SWPadnos> you can also use FF0/FF1 to make it get into position quickly
[12:55:13] <Valen> The docs weren't too clear on what the different FFs were
[12:55:21] <Valen> I have a FF0 of .001 or so
[12:55:30] <SWPadnos> oh - interesting
[12:55:36] <SWPadnos> velocity drives?
[12:56:16] <Valen> servos
[12:56:23] <Valen> via mesa
[12:56:31] <SWPadnos> right - what mode are the drives operating in?
[12:56:39] <SWPadnos> (velocity, torque, voltage, current ...)
[12:56:45] <Valen> whatever they operate in when they come out of the box?
[12:56:55] <SWPadnos> that varies
[12:57:03] <SWPadnos> and might be settable
[12:57:03] <Valen> current probably
[12:57:14] <SWPadnos> that's important to know
[12:57:18] <Valen> the mesa card puts a PWM signal out that goes into some fets that goes into the motor
[12:57:34] <SWPadnos> ah, you're using the Mesa drives?
[12:57:35] <Valen> yes
[12:57:42] <Valen> (22:56:15) Valen: servos
[12:57:43] <Valen> (22:56:22) Valen: via mesa
[12:57:52] <SWPadnos> ok, those are direct PWM
[12:57:59] <SWPadnos> "via Mesa" can mean many things
[12:58:10] <SWPadnos> since you can also output a +/-10V signal to other drives
[12:58:18] <Valen> yeah but that would suck ;-.
[12:58:21] <Valen> ;->
[12:59:04] <SWPadnos> I don't know the best way to get rid of that on straight PWM drives
[12:59:28] <SWPadnos> well, I don't know for sure on any drives, but I *really* don't know for those
[12:59:37] <Valen> does deadband still try to hit the 0?
[13:00:01] <SWPadnos> deadband (on the PID) is a threshold below which the error is considered zero
[13:00:19] <Valen> I spose what I would like is an adaptive deadband
[13:00:40] <Valen> because having that deadband set reduces its accuracy while moving
[13:00:45] <SWPadnos> if you set deadband to 100, then any time the feedback is within 100 units of the command, the PID will round the error down to zero
[13:01:10] <SWPadnos> usually, you set deadband to something near 1/2 encoder tick
[13:01:31] <Valen> .001mm is pretty fine
[13:01:31] <SWPadnos> a little above 1/2, but generally not more than 1 count
[13:02:07] <SWPadnos> the idea is that you don't want the PID to hunt between encoder ticks, it should sit still if the commanded position is in the middle of two encoder count values
[13:02:17] <SWPadnos> (remember that feedback is quantized)
[13:02:19] <Valen> yeah
[13:02:46] <Valen> I don't really have a problem so much with that
[13:03:00] <Valen> it was just this axis ticking
[13:03:16] <Valen> I must need a higher D term on the other axis
[13:03:43] <Valen> it also oscilates over 0 with a period of a few seconds
[13:04:00] <Valen> but a deadband of .001 might stop that
[13:06:54] <SWPadnos> I believe there's an effect with direct PWM drives that looks a little like stiction
[13:07:13] <SWPadnos> there's a little deadband around zero or something
[13:08:26] <Valen> mmm no it doesnt look like thats the problem
[13:09:02] <Valen> I can see the drive sitting at 000 but the drive power indicator LED keeps winding up until it pushes it off
[13:09:24] <SWPadnos> that made no sense to me
[13:09:26] <Valen> this is over a period of 5 or so seconds
[13:09:38] <SWPadnos> I don't understand what "the drive sitting at 000" means
[13:09:40] <Valen> the encoder count on axis is at 46.000mm
[13:09:42] <Valen> say
[13:10:28] <Valen> but the drive will keep pushing through that till hit hits 46.001
[13:10:38] <Valen> then will slowly reverse that
[13:10:48] <Valen> If i cut power it stops on .000
[13:11:05] <Valen> The I term is too large but only when its very close to its target
[13:11:39] <Valen> so it overshoots and oscilates with a period of 5 seconds or more
[13:12:11] <SWPadnos> halscope could be useful
[13:14:53] <skunkworks_> wow - steves halscopes look messy
[13:15:21] <SWPadnos> lots o' noise
[13:15:38] <SWPadnos> I wonder what model of tek scope wouldn't show that
[13:16:06] <skunkworks_> depends on where he is measuring I bet..
[13:16:37] <skunkworks_> might look great right at the encoder..
[13:17:36] <SWPadnos> yeah, could be
[13:18:07] <SWPadnos> also the scope probe adds 15pf / 1MOhm pulldown
[13:18:15] <skunkworks_> good point
[13:18:31] <skunkworks_> debouncing seems like a bad idea
[13:18:44] <skunkworks_> for a encoder input.
[13:18:46] <SWPadnos> certainly not in software
[13:18:51] <skunkworks_> right
[13:19:18] <SWPadnos> well, it's OK but would cut the max speed in half or less
[13:19:26] <Valen> halscope looks ok
[13:19:29] <skunkworks_> right
[13:19:47] <Valen> well its too slow for scope
[13:20:03] <Valen> but monitor shows the ferror at 0 with the motor power increasing
[13:21:02] <SWPadnos> does PID have some debug outputs so you can see the various terms?
[13:21:10] <Valen> probably
[13:21:26] <Valen> but it is pretty much a text book PID oscilation
[13:21:38] <Valen> what i need is a velocity term in the PID loop
[13:21:55] <Valen> because the systems behaviour changes depending on the speed its traveling at
[13:22:24] <Valen> Re steves halscope that does look pretty nasty
[13:22:53] <Valen> it definatly does look like its "bouncing" though
[13:24:43] <Valen> it looks like the drive on his encoder is marginal, its sitting at 2.6 volts and the threshold on his encoder input is 2.5,
[13:37:39] <cradek> I've found that deadband just makes the servo hunt over a larger distance
[13:38:18] <cradek> I bet that's because an exact zero command doesn't usually mean "don't move"
[13:38:26] <cradek> (I'm talking about velocity mode here)
[13:38:53] <cradek> I've found that deadband just makes the servo hunt over a larger distance
[13:38:53] <cradek> I bet that's because an exact zero command doesn't usually mean "don't move"
[13:38:55] <cradek> (I'm talking about velocity mode here)
[13:41:10] <skunkworks_> heh
[13:42:43] <AchiestDragon> phase distortion ,, same on pll frequancy synths used on radio kit ,,, to solve it you need a more accurate pulse width bit size resolution also having the optical encoder to give more pulses per deg helps
[13:44:20] <AchiestDragon> if you cant do eather then you need to up the frequancy of the pwm cycle by at least 2X
[13:45:00] <AchiestDragon> 2X would give you the equiv of one extra reslution bit
[13:45:33] <AchiestDragon> and should reduce the error by about 1/2
[13:46:27] <Valen1> Valen1 is now known as Valen
[13:47:03] <Valen> dern modems
[13:48:28] <Valen> cradek, hopefully back now
[13:48:30] <Valen> changed modems
[13:48:45] <tlab> I'm trying to test an axis and I have something wrong. when I hit run it seems to disable the motor and if I just try and jog it without hitting run it trys to spin but does not work very well
[13:48:45] <Valen> my old one was dropping connections every 1 hour 1 minute and 6 seconds
[13:48:49] <Valen> reading the log now
[13:49:38] <Valen> AchiestDragon PWM frequency is 20khz, oscilation period is 5 seconds
[13:49:49] <cradek> tlab: tell us more
[13:49:50] <tlab> I've set the acc at 2in/s^2 and the velo at 0.7in/s
[13:50:13] <Valen> is this a servo system or stepper?
[13:50:18] <tlab> stepper
[13:50:29] <tlab> I'm using this chip on a homemade board ...
http://www.allegromicro.com/en/Products/Part_Numbers/3979/
[13:50:50] <AchiestDragon> bk in a few ,,school run
[13:50:50] <cradek> ok, stepper
[13:50:54] <tlab> set to full step, not gonna try microstep till I get full step working
[13:51:11] <alex_joni> tlab: microstep might work better
[13:51:16] <alex_joni> when fullstep fails
[13:51:19] <cradek> so the driver disables? or emc disables with an error?
[13:52:01] <Valen> sounds like it might be trying to accelerate too fast for the torque available when it is doing a g0 or g1
[13:52:15] <tlab> ok well seems to be working better now, but it's choppy when it rotates
[13:52:57] <Valen> what sort of choppy?
[13:54:04] <tlab> sometimes it goes back before it goes forward again
[13:54:16] <Valen> by a small ammount?
[13:55:02] <tlab> ya but it struggles going forward also
[13:55:13] <Valen> i mean it jumps back by small amounts?
[13:55:30] <tlab> ok so check this out, if I hold the motor it seems to spin more, than if I just sit it on the table
[13:55:47] <tlab> ya seems to jump back
[13:56:00] <Valen> is this on a machine or free?
[13:56:05] <tlab> free
[13:56:21] <Valen> that is odd
[13:56:37] <Valen> sure you aren't running it way way too fast or anything?
[13:56:53] <cradek> full steps suck because of this kind of resonance
[13:57:05] <cradek> try half or quarter step
[13:57:27] <cradek> also driving some mass with it on a machine will change the resonance
[13:57:35] <cradek> but I bet the real problem is your full stepping
[13:58:16] <tlab> II tried 16th step and it seemed to do even less
[13:58:28] <Valen> sure all the phases are working?
[13:58:58] <tlab> can I just put a scope on one of the motor leads?
[14:00:29] <tlab> ok so 1/2 step works better
[14:00:41] <tlab> still pretty rough tho, with some steps backwards
[14:01:44] <Valen> like cradec said try 1/16th or something
[14:02:06] <cradek> I think 1/2 is good enough that it should step reliably
[14:02:13] <cradek> maybe something is wrong with your circuitry?
[14:03:31] <tlab> probably
[14:03:59] <tlab> how long of wires can I use to go from the PS to the motor control, currently they are about 3ft
[14:05:46] <tlab> I'm wondering if I don't have something grounded right
[14:29:12] <pcw_home> "Valen>so it overshoots and oscilates with a period of 5 seconds or more"
[14:29:14] <pcw_home> 5 seconds sounds a integral driven oscillation, maybe you have a little backlash?
[14:29:15] <pcw_home> a little deadzone may help here, since its a straight PWM amp (voltage mode)
[14:29:24] <AchiestDragon> tlab: may also have insufficiant regulation on the supply
[14:31:56] <AchiestDragon> Valen: 5 seconds sounds like its not a fault with the pwm itself how fast would you say the oscilation actualy is aoubt 50/60hz ?
[14:32:06] <AchiestDragon> or slower
[14:37:55] <AchiestDragon> tlab: the wire lenth would should be fine signal level wise up to about 20 foot but i would recomend that you used screened cable with the outer screen to gnd
[14:39:54] <jymm> You could put a cap across the PS input terminals of the driver
[14:41:07] <AchiestDragon> was going to sugest that ,, you should also have sutable suppresion caps on the servo also to stop back emf
[14:47:34] <AchiestDragon> tlab: looking at the data sheet for that stepper driver ,, not shown on that schematic on the link you gave ,,, pins step , dir , /reset , ms1 , ms2 , home , /sleep , sr and enable should have 10k pullup or puldown resistors on them so they are not be left unconnected and floating
[14:51:39] <AchiestDragon> also the connecting tracks between pin rc2 and r12,c12 should be as short as you can praticaly manage ,, otherwise you may get stray noise affecting the timing
[14:53:47] <AchiestDragon> the logic supply would be better totaly seperate from load supply if not already , if you cant then would suggest filtering the logic supply
[14:55:33] <AchiestDragon> without seeing the pcb artwork cant spot the usual pcb design errors like track thicknesses and gnd plane requirements etc
[15:04:58] <AchiestDragon> also " 28-pin TSSOP with exposed thermal pad" the exposed thermal pad not only needs to be soldered to gnd the aira of copper that it is soldered to acts as a heatsink so should try to get that aria of track to fill as mutch of the pcb as you can ,,,
[15:11:46] <tlab> whats the best way to post a picture?
[15:12:07] <tom3p> imagebin.ca
[15:12:59] <tom3p> post the pic to imagebin.ca and put the url here
[15:15:21] <SWPadnos> hah:
http://www.imagebin.ca/view/yKMdXe.html
[15:15:53] <tlab> http://imagebin.ca/view/nONa_hx7.html
[15:16:34] <tlab> ok so I didn't have home hooked up
[15:16:55] <tlab> it works good now, but pulls 600ma just sitting there, does that sound right?
[15:17:42] <jymm> SWPadnos: "You look marviously daaarlin"
[15:18:12] <SWPadnos> BAM!
[15:18:12] <SWPadnos> (I'm UNIX)
[15:18:37] <tlab> wonder why I can only get it to spin one way with the "test this axis"
[15:18:54] <SWPadnos> perhaps your direction wiring is incorrect
[15:19:35] <jymm> SWPadnos: I don't know, I could pictre you as Vista ;)
[15:19:47] <tlab> should it pull more amps sitting there, than when running?
[15:19:48] <SWPadnos> you have quite the imagination
[15:19:56] <AchiestDragon> should have a 0.1uf cap (100nF) between the vdd and gnd close as posible to ic1, jp3 ,jp4 and any other connector pin or active component on the board also
[15:22:34] <AchiestDragon> and as i mentioned you need pullup resistors or pull down resistors on all inputs ,,, failing to have a single input connected and just left floating WILL cause problems in real world use ,, but often does not show when bench testing
[15:23:40] <AchiestDragon> an unconnected input floats ,, any emf can cause that input to be random and affect the opperation
[15:24:20] <tom3p> re: "pull more amps sitting there, than when running?" steppers are more like brakes than motors ;) they are built to stop ( lock at an angle )
[15:25:05] <AchiestDragon> 600ma on the logic side or the load side
[15:25:17] <tlab> load
[15:25:36] <tlab> my breakout board has all 1k pullup resistors
[15:26:36] <AchiestDragon> with a stepper one coil is always energized ,, if the /enable line is high then it should drop power to the stepper
[15:27:58] <Phil31> hi all
[15:28:03] <tlab> I have /enable tied to gnd because I don't see an enable output in the parallel port setup
[15:28:05] <archivist> tlab, they remain powered to hold position
[15:28:24] <archivist> getting warm is normal
[15:28:24] <tlab> ahh, so 0.6A is probably normal
[15:28:40] <Phil31> please any french user ? i have some trouble with EMC2, but i'm sure to right define my problem in english ..,
[15:28:40] <AchiestDragon> your refrance voltage (tp1) seems to be wrong should be a potential divider to get a voltage not a current sence as drawn
[15:28:44] <tlab> for a 1.5A motor
[15:29:16] <AchiestDragon> tlab: yea
[15:29:32] <tlab> ya TP1 is in wrong spot, it's tied to gnd, should be on other side of pot
[15:30:07] <AchiestDragon> if you try to turn the motor you should see the idle current change
[15:30:15] <cradek> Phil31: your English looks fine, please try to explain
[15:30:32] <archivist> tlab, running closer to 1.5 A will make the motor faster
[15:30:52] <Phil31> ty cradek ;)
[15:31:18] <tlab> the a3979 is set to 1.5A, I assume it will draw more current when I put it on the machine, instead of it being free
[15:31:37] <Phil31> is see a good design of my Gcode in EMC2 ==> cool, it's a PCB for engraving ..
[15:32:10] <Phil31> but EM2 will not exactly do the job .. how can i show you a screen shoot ?
[15:32:30] <cradek> Phil31: imagebin.ca, paste the RUL here
[15:32:33] <cradek> the URL
[15:32:47] <Phil31> ok some seconds please
[15:33:01] <AchiestDragon> tlab: is the ref voltage half the vdd ?
[15:34:02] <AchiestDragon> ie 2.5v
[15:34:32] <tlab> ref volt is 1.8V
[15:34:36] <Phil31> please Cradek :
http://imagebin.ca/view/kXTtcu.html
[15:35:07] <tlab> I_trip = Vref/8Rs
[15:35:20] <tlab> Rs = 0.15
[15:35:32] <Phil31> cradek : in the corner of my PCB .. EMC2 will "turn" around the corner ... you see ?
[15:35:37] <cradek> yes
[15:35:37] <tlab> I want it to trip at 1.5A, because thats the max of the stepper
[15:35:45] <AchiestDragon> then i would of used a 1.8v zenner rather than a pot , saves having to manualy set it on each board
[15:35:52] <cradek> you can get a very sharp corner by using G61
[15:36:12] <cradek> but this means it must stop exactly at every corner
[15:36:16] <tlab> but this way I can using a bigger or smaller motor with it
[15:36:51] <cradek> you can configure a tolerance with (for example) G64 P0.1 which means stay within 0.1 mm of the programmed path
[15:36:51] <Phil31> but why EMC2 dont do exactly the corner ..? the Gode seem to bee good ( see the wihte line )
[15:37:20] <tlab> http://imagebin.ca/view/AkhifO.html
[15:37:36] <cradek> Phil31: this explains why:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TrajectoryControl
[15:38:20] <Phil31> i see that problem on each Gcode .. so i think that is a bad configuration of my INI file of EMC2 ..? ( remember i come here last week after a new installation of EMC2 .. maybe i have do something wrong ..? )
[15:38:41] <cradek> Phil31: read what I said above
[15:38:47] <skunkworks_> Phil31: your machines accelleration is probably pretty low. You could try running g64Px.xxx where x.xxx is how close you want emc to follow the commanded path.
[15:38:58] <cradek> Phil31: if you had less rounding before, that might mean your acceleration setting was higher
[15:40:04] <Phil31> yes i read : " It can also do what is called blending, " .. ok this is my problem ! :=)
[15:40:29] <Phil31> you say may accelaration was HIGHER with my old configuration ?
[15:40:31] <cradek> for engraving you could use G61 because the exact stops will not hurt the part or tool. but your program may take longer with G61.
[15:40:50] <cradek> Phil31: that is a guess, but yes higher acceleration will give less corner rounding by default
[15:41:29] <Phil31> i need to higher the acceleration i my new configuration ? ( dont want to play with G61 in each Gcode file !... )
[15:41:29] <cradek> turning a corner requires acceleration - the more acceleration you have the sharper a corner you can make at a certain speed
[15:41:48] <cradek> you should set the acceleration as high as your machine can safely/comfortably accelerate
[15:42:03] <AchiestDragon> tlab: not bad but sorry to pick fault ,, would start with the power and gnd tracks on that board from what i can see ,, they should be a lot wider ,, doing so reduces noise, the gnd should realy be a fill of all unused space
[15:42:11] <Phil31> i understand // may i disable the "blending" .. start acceleration angraving the line to the end with deceleration ..
[15:42:20] <Phil31> ?
[15:42:21] <cradek> yes by programming G61
[15:43:02] <Phil31> add a G61 in all my Gcode files ?.. ( or maybe try to modify my postprocessor .. )
[15:43:09] <cradek> yes either way
[15:43:12] <Phil31> but it will be better in the config file ?..
[15:43:13] <tlab> ya I'm still learning... not quite sure how to do ground planes in eaglecad
[15:43:44] <cradek> tlab: draw a polygon and then run ratsnest
[15:43:57] <Phil31> tlab : i discover cooperCAM ( Gerber to Gcode ...) perfect !
[15:43:58] <tlab> I'll make the board bigger next time, can't quite breadboard this chip due to the current sense res/cap
[15:44:36] <tlab> lost all my labels too
[15:45:04] <Phil31> cradek : so 2 solutions :
[15:45:06] <Phil31> * add G61 in my postprocessor
[15:45:26] <Phil31> * higher th acceleration value in my config file of EMC2
[15:45:29] <Phil31> right ?
[15:45:39] <cradek> yes
[15:45:58] <Phil31> for you the best ?
[15:46:26] <cradek> no preference - you decide - maybe try both
[15:47:12] <SWPadnos> acceleration is dependent on your machine, so you should set that correctly first. then, if you still get too much rounding, add G61 or G64Pxx
[15:47:28] <AchiestDragon> tlab:
http://www.whipy.demon.co.uk/gw1cto-trx-pcb.pdf should give you some ideas on how the power/gnd nets should be handled the module bottom right of each page of that ,, that also has a gnd tab on the underside
[15:48:42] <Phil31> ty guys for your help, will try it ;=)
[15:48:47] <AchiestDragon> the largeish hole under it is just wide enough to get a soldering iron to it to let it be manualy fitted
[15:51:12] <Phil31> have a good day, see you soon :)
[15:51:43] <AchiestDragon> eagle seems to always be a problem when it comes to track thicknesses ,, although a thin track may take the current you dont want it to act like a resistor / fuse or it will eventualy burn out
[15:52:47] <tlab> ya
[15:53:08] <AchiestDragon> eagle seems to default to the thinest size of track ,, should be the other way arround ,, not so bad for digital stuff but a pain for high power stuff ( 1A or more)
[15:53:08] <tlab> I made the inital tracks from PS bigger
[15:54:18] <tlab> I used a width calculator to make sure the trace was big enough to hold the amps
[15:54:24] <AchiestDragon> yea not too bad ,,, seen a lot worse
[15:55:02] <tlab> just need to figure out why my direction does work. step works
[15:55:13] <tlab> direction doesn't work..
[15:56:15] <tlab> the voltage on the direction pin changes... but the motor doesn't turn the other way
[15:56:21] <AchiestDragon> you should design for more than double the rating of the max load would go as far as to say 4* or more if posible
[15:58:40] <tlab> this makes no sense
[16:00:04] <archivist> cradek, started writing up hobbing, some more to do yet
[16:00:04] <archivist> http://www.collection.archivist.info/hobbing.html
[16:00:56] <AchiestDragon> tlab: scope on pin 2 of connector pc ,, is it changing state for the dir
[16:01:05] <tlab> yea
[16:01:23] <tlab> I'm about rdy to check pin 3 on the ic to see if it's changing
[16:01:23] <archivist> check threshold voltage
[16:02:12] <skunkworks_> AchiestDragon:
http://electronicsam.com/images/KandT/servostart/schem/latestcurrentlimit/latestboard.png
[16:03:17] <AchiestDragon> tlab: the connector pc should also have a gnd connection between that and the device connecting to it
[16:03:21] <skunkworks_> * skunkworks_ is very happy with eagle
[16:04:13] <AchiestDragon> skunkworks_: looks like you got the hang of it
[16:05:21] <tlab> eagle got bought out
[16:05:27] <tlab> ahh smoke
[16:09:19] <archivist> you let the smoke out!
[16:09:28] <tlab> ya the magic smoke 8(
[16:09:37] <AchiestDragon> http://fc05.deviantart.com/fs29/f/2008/085/f/b/pcb_artwork_by_AchiestDragon.jpg only a camara taken screen shot but eagle sort of fails when you need to do things like that ( 2 months work )
[16:11:20] <skunkworks_> yikes ;)
[16:11:48] <AchiestDragon> 16 layers , routed to do 800mhz on the ram and 1.2Ghz on the sata / ethernet
[16:11:53] <archivist> I should take a pic of my master piece
[16:13:34] <archivist> 16 layers is cheating redo single layer
[16:14:13] <AchiestDragon> guys i did that design for decided to change the spec the day it was compleated ,, so told them where to stick it
[16:14:44] <archivist> mine never went into production either
[16:14:47] <tlab2> ya it needs to be 2x2 inch square
[16:15:00] <tlab2> tlab2 is now known as tlab
[16:16:43] <tlab> time to eat, I'm starving, bbl
[16:17:53] <AchiestDragon> tlab could probably reduce that of yours down by 1/3 , smaller if you can allow for components on both sides
[16:18:23] <AchiestDragon> if nothing else would allow for room for mounting holes
[16:25:10] <AchiestDragon> http://news.bbc.co.uk/1/hi/sci/tech/8285380.stm :) no comment needed
[16:25:32] <SWPadnos> AchiestDragon, that looks suspiciously like Altium
[16:25:51] <AchiestDragon> SWPadnos: yea it is
[16:25:57] <SWPadnos> figured :)
[16:26:05] <SWPadnos> too bad it doesn't run in a VM (yet)
[16:28:59] <AchiestDragon> it works well enough to tollerate haveing to have a windows machine to run it on ,, and thats saying something
[16:29:37] <SWPadnos> yep. that's why this machine has Win2k on it
[16:47:51] <AchiestDragon> realy need to get a 3 axis machine sorted ,,
http://www.whipy.demon.co.uk/main-assembly.jpg about 36" by 20" by 12" travel ,, sutable for aluminum is the idea but have a couple of doubts
[16:48:21] <jymm> SWPadnos: 1.5TB hdd = $80
[16:48:32] <AchiestDragon> spindle is a 27000rpm bosch router
[16:50:50] <AchiestDragon> not too clear on that image but thats using skate bearings running on 20mm dia stanless bar ,, think i will need to change that , and also think that the spindle would need to be slower for aluminum (only 1/4" dia tools max)
[16:52:32] <archivist> could do with being more rigid for ally
[16:52:53] <AchiestDragon> also planning a 5 axis machine but more of a conventoinal design needed for making turbine impellors /props for models
[16:55:23] <AchiestDragon> yea ,,
http://www.whipy.demon.co.uk/dscf2326.jpg cheap and chearfull atm just ironing the bugs out atm , but not bad concidering its all built using basic hand tools
[16:55:30] <Valen> AchiestDragon the oscilation is over a period of several seconds, like 0.01hz
[16:55:47] <SWPadnos> .01 Hz would be closer to 2 minutes
[16:56:16] <Valen> pcw_home: I'm loath to add deadzone to the setup as when its moving i'll take every bit of precision i can get
[16:57:26] <SWPadnos> deadzone has essentially no effect while in motion, unless you're moving at a velocity that is less than one DEADZONE per servo period
[16:57:32] <AchiestDragon> Valen: with a error like that i would be more worried about it snaking with that oscilation when moving
[16:57:42] <SWPadnos> the deadzone value is not sbutracted from the error, it's a threshold
[16:58:12] <SWPadnos> so if the commanded position is moved by DEADZONE or more, then PID will act as though there was no DEADZONE setting
[16:58:21] <Valen> SWPadnos I was giving AchiestDragon the idea it was a slow thing
[16:58:41] <SWPadnos> it's only when the feedback position is within DEADZONE of the command position that there is any effect
[16:58:41] <SWPadnos> sure
[16:58:48] <SWPadnos> more like 0.1 Hz though :)
[16:59:03] <Valen> i did put a deadzone in when i was trying it before but it seemed to behave oddly
[16:59:20] <SWPadnos> jymm, Fry's?
[16:59:56] <AchiestDragon> are you shure that theres no slack on the optical encoder ?
[17:00:13] <Valen> if there was then it wouldnt have a sinusoidal oscilation
[17:00:19] <Valen> there are 2 seperate issues
[17:00:53] <Valen> one is a sinusoidal oscilation on one axis, of 0.001 the other is a similar one but it is being aggrivated by stiction to bump it out to 0.003
[17:01:13] <jymm> SWPadnos: yeah
[17:01:27] <Valen> it will push through to 0.000 on the first axis, and then keep pushing to 0.001
[17:01:52] <pcw_home> A couple of encoder counts of deadzone will probably cure the hunting without
[17:01:54] <pcw_home> compromising position accuracy too much.
[17:01:56] <pcw_home> If you have _any_ backlash an intergral term with no deadzone will guarantee oscillation
[17:01:56] <Valen> then back through 0 for a few seconds and on to .999
[17:02:20] <AchiestDragon> whats the relation of the error in relation to the optical encoder steps
[17:02:55] <Valen> encoder is 0.001 resolution
[17:03:20] <AchiestDragon> so about the size of 1 pulse
[17:03:20] <Valen> I'm looking at the light on the driver its doing a sinusoidal oscilation
[17:03:37] <Valen> its still ramping power up as it meets its target
[17:04:06] <AchiestDragon> size / distance
[17:04:08] <Valen> it looks like too much I in the PID, but when its in motion the I helps it track better
[17:04:10] <jymm> SWPadnos: 2TB = $170
[17:04:12] <pcw_home> ramp means intergral term windup
[17:04:21] <SWPadnos> ok, that's what NewEgg had as well
[17:04:24] <Valen> 1.5 Tb is the sweet spot I hear atm
[17:04:33] <SWPadnos> I does not help tracking
[17:04:55] <SWPadnos> while in motion
[17:05:00] <SWPadnos> or it shouldn't. if it does, then something else is probably wrong
[17:05:00] <pcw_home> You probably have too much integral term and not enough P and FF1
[17:05:16] <Valen> if there is a steady force on the action I helps to counter it and null it out
[17:05:58] <Valen> pcw_home, think i voided my warranty?
http://www.vapourforge.com/mill/IMAG0071.jpg
[17:06:14] <Valen> the description of the ff's is a little light on
[17:06:17] <pcw_home> Yes but suddemly remove that force and you're in deep sht
[17:06:29] <Valen> thats what D is for
[17:06:47] <Valen> P is already over what the formula says it should be
[17:06:48] <pcw_home> no thats what P is for
[17:06:54] <Valen> if i go much higher it oscilates
[17:07:11] <pcw_home> Is FF1 tuned?
[17:07:13] <Valen> D acts to minimise overshoot no?
[17:07:22] <Valen> 0.001 or so
[17:07:30] <Valen> actually thats ff0 I was using
[17:07:36] <pcw_home> Very important for voltage mode amps
[17:07:45] <Valen> 1 is set to 0 as the documentation was somewhat fuzzy
[17:08:01] <Valen> ff1 has something to do with acceleration?
[17:08:14] <Valen> 0 is velocity and 2 is rate of change of acceleration?
[17:08:34] <pcw_home> D does not help slow errors like those cased by integral windup
[17:08:49] <pcw_home> (caused)
[17:08:56] <Valen> but I couldn't see any info on how to apply those, I deduced that 0 would help to reduce a fixed offset
[17:09:00] <Valen> what do 1 and 2 do?
[17:09:04] <Valen> in practise
[17:09:14] <Valen> IE what error do they fix?
[17:10:04] <AchiestDragon> by the nature of pwm and pll type position locking there will always be a small amount of oscilation about equal to +-50% of one encoder step
[17:10:15] <pcw_home> FF1 is velocity feed forward, for a straight PWM amp, if tuned right, it will supply
[17:10:17] <pcw_home> the backEMF so that the PID loop is "centered"
[17:10:20] <Valen> PWM has nothing to do with it
[17:10:41] <Valen> is FF1 velocity or acceleration?
[17:11:25] <Valen> oh hang on yeah so 1 is velocity
[17:11:26] <SWPadnos> all of the PID parameters depend on your drive type
[17:11:28] <Valen> whats 0 then?
[17:11:37] <SWPadnos> constant output
[17:11:59] <SWPadnos> if you had an RC-type servo that needed a value proportional to the actual position, for example
[17:12:01] <SWPadnos> (I think)
[17:12:12] <Valen> hmmm interesting
[17:12:22] <Valen> and ff2 is acceleration
[17:12:27] <AchiestDragon> the pll type feedback loop senceing the position tries to track it , but the best it gets is a 1 or 0 back so it knows its on the 1or 0 level of that bit of the encoder but it has no idea of the part of that bit only the changeover point
[17:13:00] <pcw_home> For voltage mode amps, I would tune in this order
[17:13:00] <pcw_home> P
[17:13:00] <pcw_home> D
[17:13:00] <pcw_home> P
[17:13:00] <pcw_home> D
[17:13:00] <pcw_home> FF1
[17:13:00] <pcw_home> I
[17:13:06] <Valen> yes but if its at 0 and its commanded to be at 0 then the ideal is for it to stop
[17:13:21] <pcw_home> (I is nothing but trouble unless the rest is right on)
[17:13:25] <SWPadnos> at 0, FF0 would contribute nothing to the output, if it works the way I think it might
[17:13:32] <Valen> I used that magic formula to get into the ballpark then tweaked it somewhat
[17:13:43] <Valen> SWPadnos: I'm thinking your right
[17:14:06] <AchiestDragon> but as far as the circut is concerned 1 or 0 is the wrong state its the change its trying to stablaize on
[17:14:08] <Valen> it looks from the description like it just multiplies position by the number
[17:14:39] <Valen> so ff0 is somewhat pointless for a mill, although its weird
[17:14:54] <Valen> it seemed to 0 out the constant trailing error
[17:14:59] <Valen> mill/servo driven mill
[17:15:23] <SWPadnos> that's probably true, unless you are controlling hydraulic actuators or something
[17:15:40] <SWPadnos> (where you might need pressure proportional to the commanded position)
[17:15:48] <pcw_home> Looks like FF0 could counterbalance a spring force
[17:15:53] <Valen> that'd be a weird one
[17:15:55] <SWPadnos> yep, that too
[17:15:57] <Valen> good call
[17:16:17] <Valen> it wouldn't work all the way though, spring force needs a squared term in it
[17:16:23] <Valen> as i recall?
[17:16:26] <pcw_home> And BIAS could be used for a weight counterbalance
[17:16:49] <pcw_home> No Hooks law says linear...
[17:16:50] <Valen> does max output do anything on a mesa system?
[17:17:00] <AchiestDragon> now if the error was more than one optical pulse then it would be a fault , as it is you could reduce the oscilation error by eather using a optical encoder with more steps per rev or using a 1 to 10 gear up drive on the encoder ( but you would have to accont for backlash on that )
[17:17:03] <Valen> uni physics was a while ago ;->
[17:17:36] <Valen> if the current position equals the commanded position, any command to move away from that position is wrong
[17:18:01] <Valen> the system should reach a steady state.
[17:18:43] <SWPadnos> if abs(command-feedback) < DEADBAND, then error is set to 0, and PID have no effect. FF0-2 may still contribute to the PID output
[17:19:38] <SWPadnos> there are two independent things that contribute to the output, PID, which is based on error (command - feedback), and feedforward, which is based on the command input
[17:19:41] <Valen> I'll remove the FF0 term and play with FF1 instead
[17:20:00] <Valen> on one axis there is no FF term
[17:20:00] <SWPadnos> yes
[17:20:00] <Valen> can't rember which
[17:20:05] <pcw_home> FF1 is really important for voltage mode, dont make the mistake of using
[17:20:05] <pcw_home> the I term to replace it
[17:20:22] <AchiestDragon> Valen: no ,, the command is not to move , the idea is its trying to force itself to keep the required position , because unlike steppers servos dont have any holding touqe there free when unpowered , and when powered the move
[17:20:25] <Valen> I was using I from the ballpark of that "ideal PID tuning" loop
[17:20:49] <Valen> yes, so it should when it has met the target postion turn power to the motors off
[17:21:04] <pcw_home> The trick with I is dont use it until everything else is really close
[17:21:10] <Valen> i think I was in the 50 or 60 region
[17:21:15] <Valen> which seemed way high to me
[17:21:25] <Valen> but who am I to second guess wikipedia
[17:21:59] <Valen> or the docs for emc (which were ripped wholesale from wikipedia ;->)
[17:22:05] <Valen> the oscilation period for P was very very fast
[17:22:13] <Valen> 20miliseconds or so
[17:24:36] <Valen> what sort of numbers have you seen?
[17:24:55] <Valen> P is 2.4 or so and D is 0.01 - 0.03
[17:26:13] <pcw_home> What happens to your oscillation if you add more D?
[17:26:13] <pcw_home> Also whats your servo thread rate?
[17:26:45] <Valen> is servo thread the fast or the slow one? I know i sped one of them up
[17:27:02] <pcw_home> Slow
[17:27:20] <Valen> I think that is at 5khz
[17:27:35] <Valen> yes i believe that was the one i sped up
[17:27:58] <Valen> I can hear it modulating the motors at that frequency (not the PWM, thats at 20khz)
[17:28:10] <Valen> its changing the current at ~5khz by my ear
[17:28:30] <Valen> more D doesn't seem to affect the slow oscilation, but it does affect the higher speed ones
[17:28:51] <Valen> I think you are right, its too much I, I'll wipe that out and replace it with FF1 then add some I back
[17:29:18] <Valen> I don't like D, our positioning is somewhat noisy due to the linear scales and D makes the motors whine
[17:29:28] <Valen> (as a result)
[17:29:43] <pcw_home> I is the 'I'cing on the cake, do it last
[17:29:45] <Valen> well its noisy when the mill is running and everything is bouncing around
[17:29:59] <Valen> I didn't think you used D without I,
[17:30:10] <Valen> I was under the impression it was there to counter it
[17:30:31] <pcw_home> I think EMC will eventually be able to use HostMot2s velocity output which should fix some of the encoder whine
[17:30:35] <Valen> if all you were using was P you shouldn't actually overshoot should you?
[17:31:05] <pcw_home> No D is used to make P stable
[17:31:07] <pcw_home> (and P is needed to make I stable)
[17:31:17] <Valen> how do you mean? if I set D to 0 the whine goes away
[17:31:27] <AchiestDragon> Valen:
http://www.designers-guide.org/Analysis/PLLnoise.pdf read the section there relating to the phase detector ,, thats for rf frequancy tracking but the same principle relates to the feedback loop error your seeing
[17:31:38] <pcw_home> Yes P without D will overshoot
[17:31:50] <Valen> only if P is too large no?
[17:32:27] <Valen> AchiestDragon they are intentionally trying to capture oscilaitons
[17:32:58] <Valen> look at the wavy lines
http://en.wikipedia.org/wiki/PID_controller
[17:33:17] <Valen> you will note that in the well tuned loops they reduce to 0 error
[17:33:22] <pcw_home> (the whine is due to the velocity being determined by delta counts/sample)
[17:33:23] <pcw_home> this is coarsly quantized at low speeds, so the D term is "crunchy"
[17:33:52] <pcw_home> No P can be MUCH larger with appropriate D
[17:34:05] <AchiestDragon> yea ,,, but the same method is used to hold position just there changing frequancy of a vco rather than trying to track the position of a servo
[17:35:17] <Valen> ok you can have you mill oscillating all over the place instead of sitting at 0, i'll just have mine sit at 0 rather than intentionally push itself into an error just for kicks
[17:35:20] <AchiestDragon> the maths for the resaultant errors in the desiered position /frequancy are the same
[17:36:51] <pcw_home> When EMCs PID loop uses HostMots2 velocity signal the whine should mostly go away
[17:37:14] <Valen> ok look at it this way, the mill is sitting on 0, P I and D gains are all 100
[17:37:22] <Valen> what is the commanded output
[17:37:29] <Valen> P = 0 * 100
[17:37:33] <Valen> I = 0 * 100
[17:37:38] <Valen> D = 0 * 100
[17:37:48] <Valen> ergo what is the commanded output to correct this error?
[17:38:50] <Valen> (given that the error is 0)
[17:38:52] <pcw_home> 0 but the problem with I is its output depends on history...
[17:39:31] <Valen> pcw_home, yes i fully agree, i was talking to AchiestDragon who is saying that PID loops are sposed to oscillate
[17:39:44] <Valen> i simplified the integral of I to 0
[17:39:51] <Valen> yaknow for simplicity
[17:41:29] <Valen> anyway pcw_home, and swpadnos, thanks for the help, net result should be a much smoother running mill, I'll see if I can wind the servo loop timing up some more too, the computer is sitting there doing not much anyway and it has its own 3ghz cpu in which to do it
[17:41:44] <Valen> cya later
[17:42:03] <AchiestDragon> there is a method that can be used that will not oscilate but it involves using a binary output 2 phased optical encoder ,, that will be off if its in the right position , but the error is slightly more than 1 step incriment
[17:44:20] <AchiestDragon> ie encoder counts 0 ,1 , 2 then back to 0 if held at 1 it wont power the servo untill it hits eather 0 or 2 in oder to correct the position ,,, any oscilation there would be dew to machine vibaration or force on the axis
[17:47:03] <AchiestDragon> well eather that or use 2 encoders on the same shaft 1 offset to give you a half step position pulse ,, down side is extra cost plus having to design the controler to handle it
[17:49:15] <AchiestDragon> hmm pattent on that has expired afaik circa 1986 technology
[17:59:56] <jymm> SWPadnos: I JUST got mine, wth 2x AA, this thing is awesome!!!
http://www.dealextreme.com/details.dx/sku.4452
[18:01:01] <jymm> SWPadnos: you can get it as a single AA, but the extra tube is cheaper as a kit
[18:01:15] <tom3p> looks like a rifle sight
[18:01:42] <jymm> bright as shit with 2x AA
[18:01:48] <jymm> not bad with just 1x AA
[18:02:09] <AchiestDragon> anyway ,, since i broke a finger earlyer this week thats making finishing my cnc rather slow going , and could do to be doing something more restfull with it ,, got a couple of development questions realting to a fpga based controler board
[18:02:42] <AchiestDragon> 1 is there any one here who can develop /maintain vhdl code
[18:03:37] <AchiestDragon> 2 is there any preferance to number of supported axis's thinking support for up to 6 atm
[18:04:44] <tom3p> if your embedding emc, I'd like the full 9 ( and i do use & sell 7 axis systems xyzwabc plus handrad )
[18:04:50] <AchiestDragon> should give support for steppers or dc servos
[18:05:47] <AchiestDragon> ok ,, do you want to actualy integrate the drivers or have all the drivers on seperate boards
[18:06:57] <tom3p> separate 3 yaskawas & 4 panasonics... seperate 'boards'?, hell one is 4 kW
[18:07:22] <tom3p> any brand i like (or rather the customer wants )
[18:07:39] <AchiestDragon> as a stepper is basicaly 2 h bridges with a diferent drive logic ,, and a servo only a single ,,, could manage 15A at 46V ones onboard
[18:07:54] <tom3p> never mind i really cant use emc's position control, i need edm and just like emc ( sorry )
[18:08:12] <AchiestDragon> well up to 15A at 1 to 70v
[18:09:21] <AchiestDragon> using a fpga then you could do microstepping in vhdl
[18:11:07] <AchiestDragon> and planning on using the xilinx spartan3 eather 200k or 400k gate chips ( the board would accept eather ) if thats going to be enough gates to play with
[18:12:39] <tom3p> mesa's developed stepper and servo controls using similar ( if not same chips) maybe look at whats been done before investing
[18:39:03] <pjm> evening all, btw does anyone here have experience with Sony magnescale linear encoders?
[18:49:44] <andypugh> I think I might just get drunk tonight. I have just blown up my stepper driver.
[18:50:08] <skunkworks_> why do you need a reason? ;)
[18:51:34] <andypugh> I was meant to be trying out cradek's threading patch
[18:51:47] <jymm> skunkworks_: You ALWAYS need a reason, but any day ending in 'y' is good enough
[18:52:35] <skunkworks_> you don't need the drive for that... :)
[18:53:44] <andypugh> Annoying, though. I had checked that all the pins on the motor lead were right with no shorts, then when I plugged it into the control box it looks like two of them shorted together or to earth. Cue a fizz and a pop.
[18:54:45] <andypugh> It does mean I have an excuse to buy a bigger drive to get More Power. (Though I do like how everything is interchangeable at the moment)
[18:55:25] <andypugh> And I do still have 3 good amps, so can reconfigure and do most things.
[18:55:57] <andypugh> But I still very nearly swore.
[18:57:16] <skunkworks_> wow - I swear when my shoe comes untied
[18:59:12] <andypugh> But you are probably a horny-handed son of toil, where I am an effete intellectual.
[19:01:29] <andypugh> (err, was a smiley needed there?)
[19:01:29] <skunkworks_> heh - you may be right
[19:07:26] <Bridgeport_II> andypugh: Sorry about that, I hope it's repairable. Or not too expensive to replace.
[19:08:16] <Bridgeport_II> I have a question though.
[19:08:18] <andypugh> I think that repair is probably not feasible (the drive costs £36 + VAT + Delivery)
[19:08:29] <Bridgeport_II> By executing user-defined M-code scripts I can change scale factors in HAL. How can I get ClassicLadder to change scale factors in HAL?
[19:10:48] <Bridgeport_II> (I have some PyVCP buttons and some user-defined M-codes that should both be able to change scale factor)
[19:12:04] <andypugh> I don't know who else logged in is really there and listening. I know I have no idea if what you ask is possible.
[19:13:27] <Bridgeport_II> OK, thanks. Maybe others will scroll back later and have some advice. I'm looking at the wiki, but nothing so far.
[19:35:56] <AchiestDragon> re <tom3p> mesa's developed stepper and servo controls using similar ( if not same chips) ,,,,, a commertial product or a gpl design ??
[19:36:01] <AchiestDragon> anyone know
[19:36:23] <AchiestDragon> ho wb
[19:36:56] <AchiestDragon> re mesa's developed stepper and servo controls ,,,,,is that a commertial product or a gpl design ??
[19:38:00] <tomp> commercial, i think the src is available, not sure its gpl
[19:38:23] <tomp> check their site
[19:38:47] <AchiestDragon> was going to do this as gpl both hardware and software
[19:39:51] <tomp> take a look at
http://www.mesanet.com/pdf/motion/softdmc.pdf and others on thier site
[19:42:11] <tomp> look at the 7i43, very much what i saw dreamed of here on irc
[19:43:20] <tomp> hoho cfgs avail for waveform generator too, i gotta look at the docs again myself
[19:48:01] <AchiestDragon> yea on a bit simlar lines but was going to include individual connectors for drive connections , opto isolatated i/o where needed , some status leds , estop control , etc more talored to cnc use than that
[19:52:22] <L84Supper> how much space does all the softdmc take in the fpga?
[19:52:30] <tomp> not trying to rain on your parade, they do all/most of those features using add on pcbs or firmware. why not work with their framework to add unresolved stuff.
[19:52:50] <tomp> hominygates? DUNNO
[19:53:15] <L84Supper> was just looking through the vhdl
[19:53:35] <L84Supper> was going to order some to try today
[19:53:39] <tomp> my crappy internet hookup hasnt finished dloading the zip file yet
[19:55:39] <L84Supper> I just need two axis analog servo control, two quadrature channels and some digital IO
[19:55:42] <tomp> tomp runs away screaming 'the source is in PASCAL'!!
[19:55:51] <L84Supper> heh
[19:56:22] <tomp> tomp is now known as tom3p
[19:56:39] <wavez> Hello again everyone :D. I know I really sound like a total noob here, but I'm very excited and can hardly help myself. I was able to generate gcode for the first time using inkscape (worked like a charm)
[19:56:51] <AchiestDragon> not a big lover of pascal ,, or c++ for that matter ,, asm is much more fun
[19:57:28] <L84Supper> they show ASM and Pascal, there appears to be more files in the Pascal folder
[19:57:33] <wavez> I'm using the sim configurations in EMC to test it out. After I run the gcode, EMC complains that I can't home the cutter with the switch open...
[19:57:44] <AchiestDragon> if you cant do it in asm then try rewrite the microcode so you can
[19:57:52] <wavez> "Cannot home while shared home switch is closed"
[19:58:28] <wavez> how do I open the shared home switch?
[19:59:31] <Bridgeport_II> wavez: you have to move one (or more) of the axes that are sitting on the home switch
[19:59:35] <AchiestDragon> anyway tonights task is going to be finding the spare hdd for the laptop then i can install emc2 on it and give it a try ,, because kcam is a pita
[19:59:36] <wavez> Also, is there a way to make changes to the gcode within EMC?
[20:00:02] <tom3p> wavez this is sim? no machine tool? one thng at a time plz
[20:00:14] <wavez> Sim, yes
[20:00:35] <wavez> I jogged each axis. EMC still complains
[20:01:16] <tom3p> ok, what did you mean by 'after i run the gcode' it ran ok? it ran at all?
[20:01:34] <wavez> ya, the tool traces my path fine
[20:02:11] <tom3p> ok, did you run the code before you homed the machine?
[20:02:16] <wavez> I stopped it half way because it was really slow and I want to up the feed rate, but I don't think that matters. I think the error is given after every time I run some program.
[20:02:25] <wavez> no, I homed it first
[20:03:13] <tom3p> possibly, a program is a set of motions measured from someplace, usually the machine has to know where it is before it starts off
[20:06:14] <tom3p> ok, you begin ok, run 1/2 a pgm, stop, then get an error that suggests emc thinks you are rehoming the machine, and emc doesnt wish to do that due to the state of an input.
[20:06:35] <wavez> well I clicked to home all axes
[20:06:45] <wavez> I wanted to take the tool back to home
[20:06:50] <wavez> after I ran the program
[20:06:56] <tom3p> i dunno off hand, but would try some stock .ngc code supplied with your instal TWICE, then see if its your special svg2gcode code that makes a difference
[20:07:45] <tom3p> oh, i dunno that emc can 're-home', you can go to the same place, bu thte homing sequence , i dont know its available after you do it once
[20:07:45] <wavez> it does this when I run the default program which traces, "EMC2 AXIS"
[20:07:54] <wavez> I see
[20:07:59] <wavez> how do I go to home then?
[20:08:27] <tom3p> ok, that should be valid code ( tho it says its not meant to be run,... i never read the full caveat )
[20:09:44] <Bridgeport_II> You can go someplace using MDI and and entering G0 X? Y? Z? or, what, G28 or something, I forgot
[20:09:53] <tom3p> g28
[20:09:53] <tom3p> 'RETURN TO HOME'
[20:10:30] <wavez> ok, so then the next question is, how do I edit the gcode from within EMC2? Or do I give this command some other way?
[20:10:35] <Bridgeport_II> tom3p: thanks
[20:10:58] <wavez> ahh, mdi command
[20:10:59] <wavez> I see it
[20:11:17] <wavez> ya! It works :D. Thanks guys :D
[20:11:25] <Bridgeport_II> there's and "edit" on the pull-down if you filled in your preferred editor (or gedit default? not sure)
[20:13:25] <wavez> ah. That works. ty
[20:16:45] <tom3p> haha try (only in SIM) G28X0Y0Z1
[20:17:38] <tom3p> i couldnt figger why G28 insisted on a numric value for a homing operation, and the Z action acts like its some 'Clearance height' motion, scary!
[20:19:18] <tom3p> "The path is made by a traverse move from the current position to the programmed position, followed by a traverse move of the named axes to the predefined position." so you can have an intermediate waypoint
[20:19:56] <wavez> I'm wondering how easy it would be to make some simple changes to the EMC2 interface. Like the buttons for jogging the machine. Seems to me like I'd rather have a plus and minus button for each axis.
[20:22:08] <cradek> wavez: jogging with the keyboard arrows is much better: arrows for X,Y and pageup/pagedown for Z
[20:22:22] <Bridgeport_II> wavez: take a look at the PyVCP portion of the Integrator's Manual. And if you want "real" buttons and switches, the Halui section
[20:22:41] <tom3p> i just had a 7 axis machine that needed same, and 14 btns wasnt wanted, a rot swx and a +/- pair was used
[20:22:54] <cradek> in fact in AXIS you can do everything from the keyboard. It is much better than a mouse once you learn the shortcuts. See the help menu for the list.
[20:23:12] <wavez> ah! Thanks cradek, Bridgeport_II
[20:23:29] <tom3p> multiple axis jogging? (simultaneous xyz?)
[20:24:08] <AchiestDragon> would tend to have proper phisical buttons than eather
[20:24:26] <Bridgeport_II> Hi cradek, got time for a quick Q? I need a checklist for troubleshooting why I can't execute custom M-code scripts. I think I've got permissions OK, what else do I need?
[20:24:29] <tom3p> (and a live man switch.. let go and it wont work )
[20:26:09] <tom3p> wavez did you resolve the homing after 2nd program issue
[20:28:56] <wavez> tom3p: yes, I just g28 now
[20:28:58] <andypugh> I am definitely going for the "Getting drunk" plan. A second stepper driver went "Phut" and I have absolutely no idea why this time.
[20:29:34] <wavez> *just use
[20:29:53] <andypugh> In a fit of bravado I plugged the same motor in one of my dwindling collection of drivers and it was fine.
[20:31:01] <skunkworks_> have you checked continuity between the case and each coil?
[20:31:47] <andypugh> I am pretty annoyed actually, I started the week with a perfectly functional machine, except it didn't cut stupidly coarse threads. Now I have a broken machine and a bill for £150 of parts, a part-completed replacement encoder and a strange smell of burnt electronics about my person.
[20:32:25] <andypugh> Yes, absolutely no leaks, shorts or miswired phases.
[20:32:36] <AchiestDragon> bad insulation on stepper ,,, stepper power supply over voltage ,, short on connecting wireing loom ,,,
[20:32:59] <wavez> bfn. thx again
[20:34:03] <andypugh> I checked all those. I checked all those before I plugged the motor into the driver, it still went "pop". It did it after 10 mins of idling, too, while I messed with the .hal file to swap amps around.
[20:35:07] <AchiestDragon> they under warranty ?
[20:35:53] <AchiestDragon> open one up what part is burned out will give a clue to the cause of the fault
[20:39:34] <andypugh> Yeah, I am trying for warranty on the second one. The first one I know I shorted due to forgetting to insulate the terminals inside the plug.
[20:40:43] <andypugh> On that one it is a many-legged square chip (looks like a power driver in a stupid package) which has cracked and melted a leg
[20:40:43] <AchiestDragon> shourted what to what on that one
[20:41:08] <andypugh> I don't know, I think it is likely to have shorted phase to phase or phase to earth inside the conecting plug
[20:41:20] <AchiestDragon> you may have damaged something else that is then taking the driver down
[20:42:44] <andypugh> I hope not, I would hate the remaining two to fail on me.
[20:43:22] <AchiestDragon> ie short out the stepper , it overloads the psu , blows the regulation on the psu that in turn causes the stepper driver to burn out ,, replace the driver , psu still faulty blows that driver
[20:43:44] <andypugh> PSU shows exactly the volatge it did last time I checked it
[20:45:01] <AchiestDragon> k , other thing that may happen is you have not blown the stepper but the short caused the wires connecting to it to melt at one point causing a short on the cable between the stepper and driver
[20:45:06] <AchiestDragon> do check those
[20:45:13] <andypugh> (Though I only checked the 27V one, not the 5V logic supply
[20:45:54] <andypugh> The short (if it was a short) was at the control cabinet end
[20:47:20] <andypugh> The wires inside are fine. (all the motor wiring is 32/0.20 so I doubt it could get hot)
[20:50:16] <AchiestDragon> kool ,, the 5v ok ?
[20:50:29] <andypugh> I wonder if I am brave enough to reconfigure as a lathe with the remaining two drivers and the known-dodgy motor? I suspect not.
[20:51:23] <AchiestDragon> well drop the known dodgy motor ,, going to be cheaper to replace that than a few more stepper drivers testing it
[20:51:30] <andypugh> I haven't checked it, but I don't really see how it could not be and still have the other logic-level stuff happy.
[20:52:02] <AchiestDragon> ok
[20:52:39] <andypugh> It is only the +5 for the optos in the drivers. But I will check.
[20:53:23] <AchiestDragon> you got a link to the driver modules
[20:55:19] <AchiestDragon> http://www.arceurotrade.co.uk/Catalogue/Stepper-Motors/Stepper-Drivers i got 3 of the 4.2A ones last week £38.95 each
[20:56:44] <AchiestDragon> they have steppers on specal offer also atm
[20:57:41] <andypugh> Hmm, I wish I had remebered looking at that yesterday, I just bought :
http://www.slidesandballscrews.com/pm542-microstepping-driver-p-111.html?cPath=44&osCsid=0ec365f780aa89b80ed8492c8facb9d3
[20:59:00] <andypugh> Which I am pretty sure is the exact same drive
[20:59:13] <AchiestDragon> seen the same ones on ebay from chiana at about £38 but with postage extra
[20:59:39] <andypugh> Ones I saw were £46 + £15 postage. A non-bargain
[21:00:39] <andypugh> As for the dodgy motor, it has a replacement on order. But where do I order a replacement weekend?
[21:01:10] <AchiestDragon> timelordsareus
[21:01:55] <celeron55_> your boss? 8)
[21:05:30] <tom3p> webewholigans
[21:07:37] <tom3p> i dont see it in the emc docs, should pins 18 thru 25 of par port cables be grounded at the parport side?
[21:08:22] <celeron55_> i suppose yes, on both sides
[21:09:07] <Bridgeport_II> I'm still having trouble getting M1xx scripts to run, they seem to be ignored. Any suggestions? Or things to check?
[21:09:33] <tom3p> Bridgeport_II: any messages?
[21:09:36] <AchiestDragon> in practice you should only need to connect a couple of them for it to work one min
[21:09:52] <andypugh> If you can keep you p-port signal ground seperate from power ground it might be better
[21:10:24] <AchiestDragon> http://pinouts.ru/ParallelPorts/ParallelPC_pinout.shtml
[21:10:43] <andypugh> I think Ideally you would only have opto-isolators connected to the parallel port.
[21:11:06] <Bridgeport_II> No messages from Axis, but I'm not running out of a command line, so no messages available there, would that help?
[21:11:25] <tom3p> re: pport gnds: yes , only 1 would 'work' but mine go to diff subsections ( limits, amps, spindle..) so I use more, esp on the long runs ( yes i used the .ru also )
[21:12:19] <tom3p> what do you see happen? just the next line executed as if the Mcode wasnt in the gcode file?
[21:13:00] <andypugh> I have all the p-port grounds soldered together, and they go to logic ground. Unfortunately the drivers connect logic ground to power ground so I can't keep the seperation I would like.
[21:13:02] <Bridgeport_II> It seems to accept the M1xx code by MDI, but nothing happens.
[21:13:44] <andypugh> Are they meant to run in MDI?
[21:13:49] <AchiestDragon> idealy each of those signal gnd lines is paired up with one of the data lines in a twisted pair insed the connecting cable ,, lets it work with a longer cable
[21:13:49] <tom3p> maybe try mdi, maybe try execing the body of the Mcode 9copy to a file and exec as a stand alone gcode file)
[21:14:08] <Bridgeport_II> It shouldn't make any difference in my case
[21:14:18] <tom3p> (copy...
[21:15:27] <Bridgeport_II> tom3p: OK, that's a good idea, I never thought of testing by executing as a program, I'll do that and brb.
[21:16:24] <Bridgeport_II> (I was going to test first and then execute, but hey, whatever works, right?)
[21:17:16] <tom3p> Bridgeport_II: be safe!
[21:17:16] <sed_> is there a fix for the verify function in emc2, emc1 used to show the line the error was on.
[21:18:43] <tom3p> 'whose line is it anyway' ;)
[21:20:31] <tom3p> re: mcodes in mdi. t hought (hehe) that any mcode not native to the 'canon' was searchde fro in a designated directory & exec'd. i dont think ( hehe) that it matters mdi/auto
[21:22:17] <tom3p> i dont have any to test with, but mdi only said M100 didnt exist ( didnt blow up )
[21:27:02] <tris-> tris- is now known as tris
[21:28:37] <AchiestDragon> second big net split today
[21:38:59] <andypugh> Are we still here?
[21:39:24] <archivist> no
[21:40:21] <archivist> I did have a comment for you earlier but I forgot what it was
[21:41:40] <tom3p> where do you set the editor preference in emc?
[21:47:39] <jymm> 80core cpu!!!
[21:48:21] <AchiestDragon> only 80
[21:48:56] <AchiestDragon> think bluegene has upto 8096 cores
[21:52:07] <andypugh> Tom3P: In the .ini file for the machine config
[21:52:12] <AchiestDragon> but guess given that 79% of that would be taken up running the drm if you put vista on it
[21:53:08] <tom3p> andypugh: yes found it, the real Q is, why is my edit greyed out? ( the ini for sim stepper mm has gedit in the .ini )
[21:55:49] <tom3p> perms are ok from root thru to file loaded, but edit is grey
[21:56:38] <tom3p> does anyone have edit non-grey? (this is a runinplace, git'ed from about a month ago
[21:57:01] <andypugh> It works for me. (2.3.0 normal install)
[21:59:17] <tom3p> yep, normal has edit, rip does not...
[22:03:57] <archivist> * archivist has a git checkout running from yesterday and the edit works , its a run in place
[22:04:01] <tom3p> state {$interp_state == $INTERP_IDLE && $taskfile != "" && $::has_editor} \
[22:04:01] <tom3p> {.menu.file "_Edit..."}
[22:04:17] <tom3p> should be ok, it has a src file and is idle
[22:04:46] <tom3p> archivist thx, must be munged
[22:06:06] <tom3p> got gedit, maybe cuz its open already?
[22:07:30] <archivist> nope /me opened another file then one from axis
[22:10:19] <tom3p> argh; irreproducable results! it works ( edit not grey, opens loaded src in gedit ) on umpteenth try
[22:11:43] <tom3p> archivist thx, chalk it up to gremlins, works fine now'
[22:12:29] <archivist> I had gremlins in the compile phase, had to reboot the box, then was fine
[22:13:41] <tom3p> http://upload.wikimedia.org/wikipedia/commons/e/e0/Falling_hare2.jpg
[22:14:11] <tom3p> bugsbunny meets a gremlin in wwII
[22:29:03] <roh_> roh_ is now known as roh
[22:51:22] <sed_> is it normal for halscope to crash from time to time, the only way to reset is to restart emc?
[22:56:43] <andypugh> Not that I have noticed. Perhaps your base thread is too short?
[22:58:13] <sed_> base thread?
[23:07:02] <andypugh> Aye, it's part of the configuration, how often the system is interupted to run your real-time stuff.
[23:08:18] <sed_> cool thanks, will play with it
[23:09:39] <andypugh> Don't fiddle blindly
[23:09:40] <sed_> what about verify no longer scrolling through program and stopping on error?
[23:10:19] <andypugh> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TweakingSoftwareStepGeneration
[23:14:29] <sed_> so its BASE_PERIOD your taling about?
[23:22:39] <andypugh> Aye, that controls the speed of the base thread
[23:22:53] <andypugh> What's your number?
[23:23:39] <sed_> hang on will check..
[23:23:54] <andypugh> (err, ignore any lapses into pirate-speak, I am playing an MMORPG in a different window)
[23:24:29] <oPless> yarrrr
[23:27:04] <sed_> stg.ini:BASE_PERIOD = 50000
[23:27:28] <andypugh> Sounds fairly conservative, actually.
[23:27:55] <sed_> I think we fixed halscope
[23:28:16] <andypugh> What did ye do?
[23:28:18] <sed_> it was coming up with some werd value... we changed it, saved and exited.. now it does not seem to crash
[23:32:53] <sed_> so now on to more mondane shit..
[23:33:33] <sed_> if you click on offset and add/change a tool. it works, but it does not save it to the tools file like emc1 did, in fact I dont know where it goes
[23:35:56] <andypugh> If ye touch-off the offset should go into the tool table.
[23:36:30] <andypugh> Assuming you have a tool selected with M6. But you need to G43 to apply the tool offset
[23:39:41] <sed_> it doesent write to the tools file
[23:40:43] <sed_> so the offset in ram or wherever, does not match the one in the tools table
[23:40:58] <sed_> If I change the tools table and save it, it of corse works.
[23:41:10] <andypugh> How odd.
[23:41:24] <sed_> but not if I change/add a tool by clicking on the offset box in the tkemc window
[23:41:28] <sed_> yea I thought so
[23:41:39] <sed_> that and verify is busted
[23:42:09] <andypugh> I know nothing about tkemc
[23:42:39] <sed_> which one do you use?
[23:42:44] <andypugh> Axis
[23:43:02] <sed_> so I guess no one likes tkemc much
[23:43:13] <sed_> is Axis the more popular one?
[23:43:26] <andypugh> It's the default one
[23:43:44] <sed_> oh, realy?... I installed the BDI
[23:43:49] <sed_> maybe thats it..
[23:46:17] <sed_> what is Axis written in, is it faster/less cpu than tcl?
[23:47:02] <sed_> cuz I have a 450mhz Pentium2, I need all the CPU I can get, I ganked ubuntu/gnome desktop and now run blackbox for that reason
[23:48:30] <andypugh> I think it is python, but don't quote me. I wouldn't choose it for a low-overhead system
[23:50:14] <andypugh> Keystick might suit
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Interfaces
