Back
[00:13:14] <mshaver> Is halscope triggering 100% reliable? I ask because I was trying to capture a single trace of axis.0.f-error. I had the scope set up for single channel, 16000 samples at 10kHz. Triggering was on channel 1, rising edge at +500m so that I could start capturing data when f-error got over 1/2". The problem I had was that the scope would trigger itself before I could mdi the move I wanted to watch. I saved the data to halscope.log, but
[00:20:49] <jmkasunich> mshaver: you are getting false triggers? or failing to trigger when it should?
[00:23:57] <jmkasunich> it is on "normal" and not "auto", right?
[00:30:11] <JymmmEMC> FUCK I hate IT and being privy to 'terminations'.
[00:30:34] <shrdlu-> you got booted?
[00:30:42] <JymmmEMC> Not me
[00:31:28] <eric_unterhausen> when I left my last job, they wanted me to get a signature from the Vax administrator
[00:31:45] <eric_unterhausen> I asked why the hell they had a vax
[00:31:46] <JymmmEMC> 1972 ?
[00:31:56] <JymmmEMC> 1942?
[00:32:04] <JymmmEMC> 1891?
[00:32:08] <eric_unterhausen> november 2008, i kid you not
[00:32:32] <shrdlu-> net dout-00 motion.digital-out-00 => parport.0.pin-01-out
[00:32:50] <shrdlu-> should that mean I can just type M62 P00 and it'll turn my laser on?
[00:33:05] <eric_unterhausen> I told them I suspect that all the exploits were so well known by now that I could log in if I wanted anyway
[00:33:16] <JymmmEMC> or blow it up, one of the two
[00:33:45] <shrdlu-> nothing is happening in the hal meter
[00:34:18] <Paragon27> Hello All, Could someone please advise what would be the best tool post for a Boxford AUD, between the piston (Ref: 9511300) type and the other type Ref: 9511300found on the following page
http://www.chronos.ltd.uk/cgi-local/sh000001.pl?REFPAGE=http%3a%2f%2fwww.chronos.ltd.uk%2f&WD=toolpost&PN=Chronos_Catalogue_Quick_Change_Toolposts_69.html%23a9511300#a9511300
[00:34:33] <JymmmEMC> I had to 'backup' the person's laptop while they were in a meeting probably getting terminated - I feel/felt like shit aand on Friday the 13th of all days.
[00:34:43] <JymmmEMC> talk about your bad luck
[00:35:31] <JymmmEMC> the laptop was still locked to the docking station, so I was just handed the whole thing and asked to back it up.
[00:36:00] <eric_unterhausen> don't you work for a bank?
[00:36:10] <JymmmEMC> no
[00:36:50] <eric_unterhausen> Peanut company?
[00:37:05] <mshaver> jmkasunich: OK, I was on auto... My problem is that I have max ferror set to 0.6 for this axis, and on a 400"/min, 10" long move it gets a following error, but I haven't been able to scope it or figure out why. My scope traces (with max ferror set to a huge value) don't show any excursions above 0.5".
[00:38:22] <JymmmEMC> I feel like writtting an email and saying if/when you decide to restrutcure,reoganize, downsize,terminate, layoff me, just kill my accounts and lock me out of the bldg. no fuss no bullshit
[00:40:03] <jepler> shrdlu-: I get the same thing as you-- m61/m62 don't change digital-out-00 as seen in halmeter.
[00:40:43] <shrdlu-> :(
[00:40:43] <jepler> this is with CVS TRUNK updated just now
[00:41:06] <jepler> I think we'll have to wait for alex to come back and find out what's what
[00:41:24] <shrdlu-> nightmare. I think he went to bed
[00:41:41] <shrdlu-> My customer is going to lynch me
[00:42:15] <jepler> didn't you have version 2.2 running OK? Just go back to that.
[00:43:17] <shrdlu-> no, it doesn't work synchronously in 2.2. If I use the spindle or z axis it causes the other axes to jump
[00:43:51] <jepler> hmmm, hold on a second
[00:43:59] <shrdlu-> can't I just use a regular digital out to do this?
[00:44:06] <jepler> try with m63/m64 in TRUNK
[00:44:17] <jepler> I just did and in halscope I don't see the velocity changes I know are there in 2.2.
[00:45:02] <jepler> well, no, wtf
[00:45:26] <shrdlu-> ooh. m64 works
[00:45:44] <jepler> I get a dip in velocity at turn-on but not at turn-off !?
[00:47:38] <jepler> ok, this doesn't make sense to me, but if I use m61 I get nothing. If I use m62/m63 I get outputs changing but no dip in velocity. If I use m63/m64 I get dips in velocity
[00:48:29] <jepler> see if there's a combination that works for you without a dip in velocity; if there is, use it for now -- and we'll talk to alex_joni when he's awake again to figure out what it should be
[00:48:44] <jepler> (I thought m61/m62 were pairs, and m63/m64 were pairs .. am I mistaken?)
[00:49:09] <shrdlu-> 62 and 63, 64 and 65
[00:49:10] <shrdlu-> I think
[00:49:24] <shrdlu-> 64 turns my laser on, 65 off
[00:49:34] <jepler> does the velocity dip or is it OK?
[00:50:02] <shrdlu-> just changing the code
[00:51:59] <jepler> hm, I think my testing problem with g62/g63 is that it doesn't do anything until you issue the next move, and I wasn't issuing any moves
[00:52:36] <jepler> er, I keep saying g but mean m
[00:52:48] <jmkasunich> mshaver: trigger the scope on f-errored
[00:52:55] <jmkasunich> I think its a parameter, not a pin
[00:53:05] <jmkasunich> it's a bit, goes true when the fault happens
[00:53:51] <jmkasunich> that way you _know_ you captured the event, then you just have to examine traces (or move probes and try again) till you figure out what it is
[00:54:00] <shrdlu-> 64 still jumps
[00:54:26] <jmkasunich> triggering on the ferror signal is a crapshoot, since the problem may be ferror going < -0.6, rather than > 0.6
[00:56:45] <mshaver> Thanks John! I'll try that!
[00:59:25] <shrdlu-> YES
[00:59:36] <shrdlu-> it works. I have proper raster
[01:00:57] <jepler> shrdlu-: which combination is working for you?
http://emergent.unpy.net/files/sandbox/emc-dio-without-stopping.png
[01:01:26] <jepler> this is the one that worked for me, but only going by the velocity trace in halscope ^^
[01:02:14] <shrdlu-> I don't know. I just know it isn't jumping
[01:02:42] <jepler> oh, well, ok
[01:03:26] <shrdlu-> cut looks a bit funny though
[01:03:37] <shrdlu-> but I can work on the gcode for that
[01:03:43] <jepler> good luck
[01:03:44] <jepler> bbl
[01:10:43] <mshaver> jmkasunich:
http://www.mattshaver.com/emc2/configs/smithy/400ferror.png
[01:11:59] <mshaver> It's interesting. My min-ferror is set to .1 and as the velocity drops at the end of the move, I guess it gets in under the min threshold for an error.
[01:12:29] <jmkasunich> 50 thou of ferror seems like a lot
[01:13:03] <jmkasunich> I mean 150 thou
[01:13:04] <mshaver> And it's a 5i20 driven stepper system, so it's really imaginary, I think...
[01:13:20] <jmkasunich> not imaginary
[01:13:53] <jmkasunich> if ferror = 0.150, then you DO have 0.150" between command to the stepgen and feedback from it
[01:14:37] <mshaver> True. But why I wonder. Am I reading the last cycle's position feedback data?
[01:14:47] <jmkasunich> reduce the zoom (a lot), and move the position slider so the trigger happens near the right edge of the screen - you want to see what is going on leading up to the trip
[01:15:10] <mshaver> Sure! Moment please...
[01:15:25] <jmkasunich> if you are moving 0.150 inches in one cycle (1mS?), that is a damned fast machine
[01:15:36] <SWPadnos> it is odd that the f-error appears to be decreasing slowly when the error occurs
[01:15:37] <jmkasunich> 9000 ipm ;-)
[01:16:27] <jmkasunich> I bet there isn't any/enough stepper headroom, it fell behind (maybe by even more than we see) during the move, during decel it is catching up, but not as fast as the ferror limit is dropping
[01:16:44] <SWPadnos> oh interesting, that sounds like a good explanation
[01:16:49] <jmkasunich> btw, you can scope the limit, I think it is a parameter called max-ferror (or similar)
[01:17:00] <SWPadnos> ferror-limit maybe?
[01:17:14] <jmkasunich> could be, I'm going by rusty memory
[01:17:30] <SWPadnos> mine's just a little oxidized, but still doesn't conduct well
[01:18:42] <SWPadnos> blb
[01:18:45] <SWPadnos> uh
[01:18:46] <SWPadnos> bbl
[01:19:54] <mshaver> http://www.mattshaver.com/emc2/configs/smithy/thebigpicture.png
[01:20:34] <jmkasunich> are you running your servo thread at 10KHz?
[01:20:55] <mshaver> Let me check
[01:21:11] <jmkasunich> if you have to check, you probably aren't
[01:21:29] <jmkasunich> that would be a concious decision that you would have made
[01:21:38] <jmkasunich> (presumably only if you had a good reason to do so)
[01:22:19] <jmkasunich> for this kind of thing, it makes sense to sample in the servo thread - probably 1mS unless you changed it
[01:22:32] <jmkasunich> and you need more channels
[01:22:47] <mshaver> SERVO_PERIOD = 100000
[01:22:52] <jmkasunich> why?
[01:23:35] <mshaver> As I recall, the motors sounded a lot rougher at slower servo periods.
[01:23:54] <jmkasunich> this is a stepper machine?
[01:24:00] <mshaver> Yes
[01:24:18] <jmkasunich> I don't see the connection between servo period and motor sound
[01:25:06] <jmkasunich> there is some weirdness about 5i20 stepper behavior, unfortunately I haven't tried it myself (and don't have time to anytime soon)
[01:25:07] <mshaver> I don't either, it was sort of arrived at empirically. I should go back and try 1ms.
[01:25:42] <jmkasunich> what version are you running? 2.2.8 or TRUNK?
[01:25:48] <mshaver> The last time I tried this was before the newest hm2 firmware, so maybe...
[01:25:59] <mshaver> TRUNK, a couple of days old now
[01:26:24] <jmkasunich> then you should have the latest greatest firmware _and_ driver code
[01:26:31] <jmkasunich> I bet you will be fine with 1mS
[01:26:44] <jmkasunich> and if not, investigate using scope (after resolving this ferror thing)
[01:27:00] <fenn> mshaver: since you're here, is this any good and does it still exist?
http://www.erols.com/mshaver/bmp2cnc-0.22.tgz
[01:27:18] <mshaver> yep, I'll play around with this some more tomorrow. Thanks for the help! It's alway good to bounce things off other folks!
[01:27:25] <jmkasunich> I don't know all the pins and params in the driver - you want to look at something that lets you know where you are in your move - velocity
[01:27:49] <jmkasunich> I dunno if there is a commanded or feedback velocity pin handy (you can always make one with a ddt block)
[01:28:01] <jmkasunich> I think the 5i20 stepgen driver has a frequency or velocity pin
[01:28:29] <jmkasunich> it sure smells like you don't have enough headroom for the stepgen
[01:28:32] <mshaver> I've got both vel and fb in the driver.
[01:28:51] <jmkasunich> halscope has lots of channels - use 'em
[01:28:57] <mshaver> yep, I must be running out of time somewhere.
[01:29:11] <jmkasunich> not time
[01:29:28] <jmkasunich> the stepgen driver has max velocity and/or max accel parameters
[01:29:51] <mshaver> fenn: my erols account is long gone, but I have bmp2cnc somewhere
[01:29:52] <jmkasunich> they MUST be somewhat greater than the max-vel and max-accel parameters of EMC itself, so that the stepgen can keep up with what emc asks
[01:31:19] <PCW> I wonder if a stepgen reference frequency error could make the steppers noisier with a slower sample rate
[01:31:21] <PCW> on the 5I20 the reference frequency is PCI clock which is not guaranteed to be very accurate
[01:31:22] <PCW> (it really should be calibrated against the 50 MHz)
[01:31:45] <LawrenceG> fenn... I just checked my hd... I have bmp2cnc-0.21.tgz and bmp2cnc-0.22.tgz
[01:32:03] <LawrenceG> hi Matt!
[01:32:07] <mshaver> I'll go back and look at that. As I recall I talked to Seb about this.
[01:32:19] <jmkasunich> PCW: define "not very accurate" I'd be astonished if errors of less than several percent caused problems
[01:32:31] <PCW> (or against EMCs clock)
[01:32:36] <jmkasunich> and equally astonished if the PCI clock was several percent off
[01:32:37] <mshaver> Hey LG, use .22, it's the latest, probably the latest there'll ever be...
[01:32:53] <PCW> Maybe 3% (Ive seen 32 MHz)
[01:58:23] <JymmmEMC> SWPadnos: ping
[05:19:03] <jmk-robot> it has wheels now
[05:27:56] <topls64> I'd like to build a plundge edm and use emc to control it. I know I will have to make custom hardware,
[05:28:37] <topls64> but first, can emc handle variable data for display like volts, amps and vary the g-code dynamically to adjust for depth and tool wear?
[05:28:53] <topls64> Itf that makes sense
[08:03:17] <beachsurfin> would
http://lib2geom.sourceforge.net/ be useful for a 3d CAD program?
[08:03:51] <beachsurfin> the "3d mapping (perspective, flag, sphere)" is throwing me off, i thought it was mostly for 2d work
[08:07:34] <tomp> yes it could be useful. no it likely isnt ( has lOAS of stuff thats not useful for the major lang of cnc 'gcode'
[08:07:40] <tomp> that means...
[08:08:04] <tomp> it has lots of stuff thats not lines andd not circles, anything else is not in the gcode vocabulary
[08:08:12] <tomp> eg nurbs
[08:08:15] <tomp> splines
[08:08:31] <tomp> so, it is useful but not very
[08:08:41] <tomp> if you want lo level code
[08:08:49] <tomp> look at the src of emc
[08:09:03] <tomp> look at the src of some 2d or 3d cad
[08:09:15] <tomp> look at the 'computer gems books'
[08:10:27] <tomp> look at the srcs for APT and APT360, open src cad
[08:11:56] <tomp> if you dont already know y = mx +b, then you gotta get started ;)
[08:48:42] <beachsurfin> thanks tomp :)
[08:49:00] <beachsurfin> what are CGS routines?
[08:49:15] <beachsurfin> and implicit surfaces
[08:53:47] <tomp> cgs is ading subtracting shapes to get new shaes like a sqr with a circle sbtracted from corner is a sqr witha bite out of it :0 very handy for sketching
[08:54:54] <tomp> implicit surfaces... id onoy be guessing, like the srfx between a cube mashed onto a sphere ( like plane of intersection maybe, maybe def is up to implementator, its 'his' language at that point
[08:55:06] <tomp> sorry crap typist & crap kbd
[08:56:56] <tomp> its csg i think you mean
[08:56:59] <tomp> http://en.wikipedia.org/wiki/Constructive_solid_geometry
[08:58:07] <tomp> ah dyslexia makes the world go aronud
[08:59:42] <tomp> oops 5pm here gotta go home best o luck
[11:07:30] <archivist> beachsurfin, there is also some cad cam discussion in #cam
[14:18:16] <jepler> skunkworks: you know, I used to be awfully impressed by that big cap on your servo amplifier, but I'm not so impressed anymore. I think you should add about 6 more ...
http://blog.makezine.com/upload/2009/02/super_class_a_30w_amplifier/SuperclassA-Amp_1a.jpg
[14:22:54] <alex_joni> jepler: hi
[14:23:14] <alex_joni> seems you figured it out eventually.. I mean to fix the docs, didn't have a dapper around though
[14:23:39] <alex_joni> M62/63 are the ones synced with motion, more than one of them are ok, they all will be remembered and will happen on the beginning of the next move
[14:23:51] <alex_joni> if there is no next move, they have no meaning/result
[14:24:19] <alex_joni> M64/65 happen immediately when they are read by motion, but they do break blending
[14:25:13] <JanVanGilsen> jepler: I've been looking into xml-schema's to use it with pyvcp, it looks verry promissing
[14:25:36] <jepler> alex_joni: so you are quite confident that it's a feature for m62 to have no effect in mdi until a motion is also entered?
[14:25:43] <alex_joni> yes
[14:25:55] <alex_joni> for MDI m64 does the same thing
[14:26:36] <JanVanGilsen> It alows defining xml-structure for validation, default values, data validation, data restrictions, ...
[14:26:38] <alex_joni> jepler: I think it's possible to program the M62's and then run from line
[14:26:54] <alex_joni> it's just like starting spindle, but for synched laser it might be better this way
[14:27:15] <alex_joni> (I didn't test yet that switching modes doesn't do something to the TP, but it shouldn't ;)
[14:37:26] <jepler> alex_joni: the other weird thing i'm seeing is that the output gets set high at the start of a program even when it was set low at the end of the last run
[14:37:47] <alex_joni> that's odd
[14:38:12] <alex_joni> did you only issue a M63 at the end of the run, or did it actually set the output low?
[14:39:54] <jepler> jas
[14:40:17] <jepler> part program:
http://emergent.unpy.net/index.cgi-files/sandbox/oo.ngc halscope:
http://emergent.unpy.net/index.cgi-files/sandbox/digital-output-goes-high-at-start-of-run.png
[14:40:27] <jepler> the trace shows a full run of the program immediately after the previous run
[14:41:09] <jepler> I *expected* the output to be low until X=.1 but it comes on as soon as the program starts
[14:41:31] <alex_joni> that's probably a bug
[14:42:48] <jepler> I can even comment out the m62, and still get the same benavior
[14:42:53] <jepler> behavior
[14:50:54] <alex_joni> it looks ok here.. with the same program
[14:50:55] <alex_joni> wtf?
[14:51:42] <alex_joni> is yours compiled for RT?
[14:52:12] <alex_joni> http://imagebin.org/38392
[14:54:03] <alex_joni> mine's compiled for simulator
[14:54:04] <jepler> --enable-simulator here
[14:54:08] <alex_joni> same here
[14:54:08] <jepler> 64bit system though
[14:54:12] <alex_joni> 32 bit here
[14:54:23] <jepler> you ran it multiple times?
[14:54:23] <alex_joni> tried dapper and hardy
[14:54:26] <alex_joni> yes
[14:54:28] <jepler> hardy
[14:55:34] <alex_joni> is out-01 high?
[14:55:36] <jepler> no
[14:56:36] <jepler> well isn't that interesting
[14:56:38] <alex_joni> now this is a real wtf moment.. it's high here
[14:56:41] <alex_joni> out-01
[14:57:09] <jepler> I think you have uninitialized memory somewhere
[14:57:26] <alex_joni> * alex_joni looks
[14:57:51] <jepler> valgrind rtapi_app says this but doesn't give a good stack trace:
[14:57:52] <jepler> ==26171==
[14:57:52] <jepler> ==26171== Conditional jump or move depends on uninitialised value(s)
[14:57:52] <jepler> ==26171== at 0x6547E50: tpToggleDIOs (tp.c:605)
[14:58:50] <alex_joni> aha
[14:58:58] <alex_joni> it might be something
[14:59:58] <alex_joni> can you try a patch?
[15:00:58] <BigJohnT> crumb, my 50 pin cables only have 40 pins :/
[15:01:11] <alex_joni> heh
[15:01:17] <alex_joni> IDE vs SCSI?
[15:01:46] <BigJohnT> must be IDE cables... I was just searching through my junk boxes
[15:02:01] <BigJohnT> thought I hit paydirt but not
[15:03:18] <alex_joni> http://pastebin.ca/1337151
[15:03:24] <alex_joni> jepler: ^
[15:06:13] <jepler> I haven't made myself familiar with that code, so I don't know what that means
[15:06:17] <jepler> I can test it though, hold on
[15:06:40] <alex_joni> each tc has a struct attached
[15:06:58] <alex_joni> syncdio.anychanged = 0 means no dio has changed, and don't look at the struct
[15:07:24] <jepler> and somewhere, not in the context of that patch, is where it's set to 1?
[15:08:02] <alex_joni> yes, it's set to 1 on any call to tpSetDout()
[15:08:22] <alex_joni> well, there is a local struct which gets changed by calls to tpSetDout()
[15:08:55] <alex_joni> when a new movement is received, if the local struct was changed (syncdio.anychanged ==1), then it gets copied to that tc
[15:09:49] <alex_joni> bah.. sorry.. I only fixed rigidtap, hang on for a proper patch
[15:11:34] <alex_joni> http://pastebin.ca/1337160
[15:12:16] <jepler> looks better here, I guessed at where else to ptach while you were working on it too
[15:12:39] <alex_joni> line, circle and rigidtap are the only motions I found :)
[15:12:49] <jepler> I have the same change
[15:13:44] <jepler> I'll let you check it in though
[15:13:52] <jepler> I don't want to end up responsible for this code :-P
[15:13:53] <alex_joni> does it fix things?
[15:14:02] <jepler> yes, that's what "looks better here" means
[15:15:15] <jepler> no valgrind messages anymore, no inputs getting set to TRUE that I don't expect
[15:15:23] <alex_joni> same here
[15:15:40] <alex_joni> ok, gotta run for a bit
[15:16:34] <jepler> it seems to retain the output value at the end of the program even into the next program (which I think is probably just fine)
[15:16:50] <jepler> thanks for fixing it
[17:23:15] <motioncontrol> good evening .today i write at ROMANIA , for installation cnc maschine with 13 axis interpolated whith profibus line.
[17:25:23] <motioncontrol> i have one question for jogwheel. Can i use the parallel port for control the maschine with incremental emcoder of 100pulse/rev?
[17:26:15] <alex_joni> how fast do you want to turn it?
[17:26:35] <alex_joni> if it's only <10 revs/second, then it should be ok
[17:26:44] <motioncontrol> normaly use
[17:26:54] <alex_joni> even 20-25 would be ok
[17:27:09] <alex_joni> for normal use you can go even up to 1000 counts/rev
[17:27:52] <motioncontrol> the encoder for jogwheel is ok 1000 cout/rev ? normaly is 100cout/rev
[17:30:05] <motioncontrol> ok thaks alex.the emc when axis is possible interpolation?
[17:32:59] <alex_joni> what kind of interpolation?
[17:33:17] <alex_joni> currently you can move 9 axes from g-code in emc2
[17:33:23] <alex_joni> XYZABC UVW
[17:33:32] <alex_joni> XYZ are linear, and you can do circles and everything
[17:33:49] <motioncontrol> the command g1 x 10 y20 z30 a15 b20 f100
[17:33:58] <alex_joni> ABC are rotary axes, and they move together with XYZ (a combined move will make all start and stop at the same time)
[17:34:02] <alex_joni> yes, that works
[17:34:16] <alex_joni> the same for UVW
[17:34:40] <cradek> you can run sim/axis_9axis and see how it works
[17:34:48] <motioncontrol> very powerfull
[17:35:04] <alex_joni> cradek: for UVW you can't do circles.. right?
[17:35:16] <cradek> currently that is right
[17:35:35] <alex_joni> ok
[17:35:44] <cradek> it would not be too hard to add UV, VW, WU circles but nobody has done it yet
[17:36:21] <cradek> those would be G17.1, G19.1, G18.1 planes
[17:36:32] <cradek> we already have those planes but they are only used for canned cycles
[17:36:45] <alex_joni> so you would still use IJK ?
[17:37:36] <cradek> yes if I did it that's how I would do it
[17:40:56] <motioncontrol> alex on my maschine the general fuction is ok(motion,spindle,tool change I/O).i want change the raffiguration the axis:no icon,no menù ecc.is difficult modification the interface you are some idea?
[17:44:29] <alex_joni> motioncontrol: not sure what you mean.. do you want to modify AXIS?
[17:45:58] <motioncontrol> for my study i have change the someline in axis.py and axis .tcl but have the error.exist the documentation for studing the axis interface?
[17:46:20] <alex_joni> motioncontrol: only the code itself
[17:47:41] <motioncontrol> ok thanks. i have study python and tcl .now close the connection because the restaurant in Romania close fast.AT tomorroww and good night at all.thanks for all.
[17:48:23] <alex_joni> motioncontrol: where are you now?
[17:48:33] <alex_joni> what city I mean
[17:48:49] <motioncontrol> Drobeta turn severin
[17:48:59] <alex_joni> I see.. a bit far from here ;)
[17:49:08] <alex_joni> about 300 km
[17:49:42] <motioncontrol> yes the distance is 210km at tymiscoara
[17:49:46] <alex_joni> did you drive or fly?
[17:49:53] <motioncontrol> fly
[17:50:11] <alex_joni> cool.. enjoy
[17:50:27] <alex_joni> although Turnu Severin isn't one of the nicest cities around here :)
[17:50:30] <motioncontrol> i start at italy yesterday from Bari
[17:50:39] <alex_joni> there's a nice restaurant on the water there..
[17:50:58] <motioncontrol> Yes the Italian resturant is very nice and good
[17:51:29] <alex_joni> but you need a romanian restaurant, italian food you can eat at home :P
[17:51:37] <motioncontrol> <the resturant name is :gpapagi
[17:51:55] <motioncontrol> gipapagi
[17:52:46] <motioncontrol> tommorrow finisch istallation my maschine and 2 day after go to in italy
[17:53:04] <alex_joni> is this an emc2 machine?
[17:53:20] <motioncontrol> no is flexmotioncnc maschine
[17:53:27] <motioncontrol> my control
[17:53:34] <alex_joni> ah, I see.. ok
[17:54:14] <motioncontrol> alex if you want go in italy is possible start one project for emc implementation on big maschine
[17:54:56] <motioncontrol> ok alex i close my collega want dinner.
[19:17:51] <mshaver> jmkasunich: If you read back this far, I wanted to let you know I fixed my following error problem. You said it last night; headroom. I even have e-mails from Sebastian about this, but for some reason it didn't register with me. Anyway, once I added 10% to the stepgen's maxaccel and maxvel, all was well. With a scale of 50800 and 400kHz drives I can rapid at 470"/min. I need to do some reliability testing, but it sounds fine. Thank
[19:20:14] <alex_joni> cool
[19:20:28] <seb_kuzminsky> yay for headroom :-)
[19:22:14] <mshaver> seb_kuzminsky: I'm curious; Why is there a limit on accel and vel in the stepgens? I would think they should just do whatever they were told.
[19:22:45] <alex_joni> mshaver: imagine using them withough emc2
[19:23:03] <alex_joni> and having a limit will show emc2 TP problems
[19:23:16] <mshaver> I can't. I just can't imagine that. ;)
[19:23:29] <mshaver> I guess I see the point after all.
[19:23:30] <alex_joni> well.. there is a world where people use only HAL ;)
[19:23:50] <alex_joni> it's nice for embedded apps where a full emc2 is overkill or too complicated
[19:24:03] <seb_kuzminsky> mshaver: i put stepgen limits in because alex told me to ;-)
[19:24:15] <mshaver> hah!
[19:24:15] <alex_joni> * alex_joni hides quickly :)
[19:24:18] <seb_kuzminsky> heh
[19:25:28] <mshaver> I think what I really need to do is to do a "halshow" and make sure that I understand what everything is/does.
[19:25:53] <alex_joni> mshaver: anything specific in mind?
[19:27:36] <mshaver> No, just a general unease that results from tuning by fiddling with values until things seem to work. I need a more scientific approach. I need to know that I know what's going on, if that makes sense.
[19:29:10] <skunkworks> with the software stepgen - I know sometimes 10% Isn't enough. just an fyi. (that is about all I can contribute) ;)
[19:29:33] <mshaver> On the first systems I built I would put arbitrary values in for P, I, and D, and tweak the amp gain and tach gain and just twiddle everything until it worked. Sometimes it would work well, sometimes just barely.
[19:30:08] <mshaver> skunkworks: So, how much is enough? I did consider just putting in huge values...
[19:30:39] <alex_joni> I wouldn't put more than 20%
[19:32:06] <mshaver> OK! You see, that's the kind of knowledge that's really needed to work successfully with this stuff.
[19:32:26] <alex_joni> well.. PID is for servos only
[19:32:38] <alex_joni> headroom is for steppers only
[19:32:57] <mshaver> My early systems were servos. STG card based ones.
[19:33:37] <alex_joni> right.. I still have a STG from you ;)
[19:34:39] <mshaver> I just want to get away from "flying by the seat of my pants". I want to do this stuff procedurally.
[19:34:56] <alex_joni> sounds like a good idea
[19:35:15] <alex_joni> although "flying by the seat of pants" is also nice (if it works..)
[19:37:57] <mshaver> I still have a couple STG cards too, but I don't think I'd use them at this point. There's too much to be gained by using new fast PCs that don't have ISA slots. I often have wondered if you could translate the ISA bus to something usable by modern PCs, but it wouldn't be worth it unless the ISA card was really something really special.
[19:38:38] <alex_joni> you mean a PCI/ISA bridge?
[19:39:26] <mshaver> Yes, like that. But such a thing probably costs more than a mesa board set.
[19:39:35] <alex_joni> heh
[19:41:18] <mshaver> I only have one card I'd like to use (maybe, someday) and that's a universal format floppy controller card. It'll do 8", 5.-1/4" & 3-1/2" with any kind of sector layout.
[19:41:53] <alex_joni> heh
[19:42:02] <mshaver> It would be useful for data recovery stuff, but I don't really have that much use for it.
[19:43:50] <mshaver> Well, it's back to the shop for me. These machines won't build themselves! Although, that's a really good idea come to think of it...
[19:45:46] <alex_joni> ha
[20:18:30] <mshaver> OK, look at this:
http://www.mattshaver.com/emc2/configs/smithy/g1x10f465.png
[20:18:50] <mshaver> And this:
http://www.mattshaver.com/emc2/configs/smithy/asym-ferror.png
[20:19:16] <mshaver> Can anyone tell me why the graph of ferror is asymetrical?
[20:27:34] <alex_joni> did that move complete ok?
[20:28:06] <alex_joni> I mean you didn't stop it with abort or something?
[20:30:11] <mshaver> It completed normally
[20:30:24] <mshaver> went from x0 to x10"
[20:30:42] <alex_joni> what does it do when you return?
[20:31:11] <mshaver> Well, I can return, but I haven't scoped it. If you like, I will!
[20:31:54] <alex_joni> bbl.. gotta run for a bit
[20:32:12] <mshaver> OK! In the mean time, I'll plot the other direction!
[20:32:27] <mshaver> and, possibly eat something...
[20:48:58] <mshaver> alex_joni: Here it is:
http://www.mattshaver.com/emc2/configs/smithy/g1x0f465.png
[20:49:50] <mshaver> The ferror curve is still asymmetrical, just upside down. Thoughts?
[20:55:15] <skunkworks> is that .0004 error?
[20:55:55] <jepler> 2 200m divs = 0.4
[20:56:15] <skunkworks> I see that when I was playing with tuning.. I remeber making it better my adding ffsomething
[20:59:46] <mshaver> "Why is the error so large?" is another good question, but I was concentrating on the "Why is it asymmetrical?" question first. Ideas or answers to either would be welcome!
[21:02:07] <mshaver> back in about 1/2 hour, must obtain food...
[21:13:59] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/followingatpid.png
[21:14:04] <skunkworks> similar
[21:14:29] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/followingmore.png
[21:14:32] <jmkasunich> mshaver it looks like it is still falling behind
[21:14:56] <jmkasunich> it falls behind gradually, because it has "almost enough" accel and/or velocity (probably accel) to keep up
[21:15:13] <jmkasunich> it catches up quickly once the commanded velocity drops
[21:16:15] <jmkasunich> think about a guy in a 55mph car chasing one in a 60mph car - he doesn't fall behind very quickly, but when the 60 mph guy gets to a redlight, he catches up right away
[21:17:06] <jmkasunich> you can easily determine if the problem is vel or accel - just do a jog with the jog slider set to about half way up
[21:17:18] <jmkasunich> if it still lags behind, the problem must be accel
[21:19:46] <skunkworks> why would the fe stay up during cruise?
[21:20:08] <skunkworks> (if it was accel)
[21:20:45] <skunkworks> * skunkworks still hasn't done enough of this.
[21:35:50] <alex_joni> skunkworks: yours looks like a servo .. mshaver's is too "smooth" to be a servo
[21:36:22] <skunkworks> yes - but same issue?
[21:36:44] <alex_joni> * alex_joni has no clue ;)
[21:37:55] <alex_joni> yours overshoots
[21:38:31] <skunkworks> Playing off and on I noticed that a lot of the time there is a cruse FE - but I know I have adjusted it out..
http://www.electronicsam.com/images/KandT/servostart/ferrorff0.png
[21:42:52] <alex_joni> that looks nice
[21:45:12] <shrdlu-> qcad is evil
[21:45:36] <alex_joni> shrdlu-: there was a small problem with M62/63, you should update the code and recompile
[21:46:16] <shrdlu-> hi alex_joni, thank you very much for adding that stuff. I managed to get my first order out using emc today
[21:46:22] <shrdlu-> after staying up til 5am :/
[21:46:30] <shrdlu-> then getting up at 9
[21:46:35] <alex_joni> shrdlu-: you do realize, you need to provide some proof :)
[21:47:03] <shrdlu-> heh, I was thinking of that. I need to video something
[21:47:29] <shrdlu-> it wasn't perfect though, some mistakes were made
[21:47:36] <shrdlu-> probably due to the weird gcode
[21:48:14] <shrdlu-> what was the M62/63 problem?
[21:48:14] <alex_joni> please don't forget to update the code, it might trigger false laser outputs
[21:48:20] <shrdlu-> ah
[21:48:29] <shrdlu-> ok, I'll do that in a minute
[21:48:38] <alex_joni> I assume you know how ;)
[21:48:43] <shrdlu-> roger
[21:49:28] <eric_unterhausen> seems like a useful link:
[21:49:30] <eric_unterhausen> http://kalecoauto.com/index.php?main_page=product_info&cPath=2&products_id=6
[21:49:36] <eric_unterhausen> blinker fluid
[21:50:17] <alex_joni> eric_unterhausen: ROFL
[21:50:28] <eric_unterhausen> they have a batch of that stuff
[21:50:50] <alex_joni> 0 Units in Stock
[21:51:02] <eric_unterhausen> they also have a butt dyno
[21:51:37] <eric_unterhausen> seasonal tire air
[21:52:23] <alex_joni> engine oil bypass kit
[21:55:13] <BigJohnT> muffler bearing
[21:55:21] <alex_joni> now this is a musthave:
http://kalecoauto.com/index.php?main_page=product_info&cPath=5&products_id=21
[21:58:48] <BigJohnT> I have a metric adjustable wrench :)
[21:59:04] <BigJohnT> but it is not left hand :(
[22:01:39] <alex_joni> I could have used a lefthanded phillips screwdriver today
[22:01:57] <alex_joni> I only had a righthanded one, and the performance using it with my left hand was sooo low
[22:10:16] <BigJohnT> I can't do squat with my right hand since I pulled my middle finger out lifting an engine block for my tractor :/
[22:11:48] <jmkasunich> dang, I was afraid that might happen....
[22:12:10] <jmkasunich> I had my bench supply hooked up in parallel with the robot's battery (to keep the batt charged during testing)
[22:12:24] <jmkasunich> turned the supply off, and the battery back-fed it
[22:12:52] <jmkasunich> fortunately I had a fuse in series with the battery - it blew, but saved the supply
[22:13:05] <jmkasunich> * jmkasunich needs a diode
[22:13:27] <jmkasunich> and another fuyse
[22:13:30] <jmkasunich> fuse
[22:14:44] <BigJohnT> jmkasunich: I think I have one on my desk here somewhere... want me to e-mail it to you?
[22:15:16] <mshaver> finally back, full of lunch. I read back some and I'll try a few more things to see what's going on with ferror.
[22:16:09] <jmkasunich> BigJohnT: that's ok, I have a couple here
[22:16:16] <BigJohnT> ok
[22:16:51] <jmkasunich> taking this thing apart again is the annoying part
[22:17:24] <BigJohnT> do you have a picture of it so far?
[22:31:25] <mshaver> OK:
http://www.mattshaver.com/emc2/configs/smithy/g1x10f460.png
[22:32:13] <mshaver> I set maxaccel for the stepgen to 10000.0 and the maxvel to 100.0
[22:33:12] <mshaver> I'd like to remove all 5i20 stepgen limits on vel and accel so that I can just use what's built in to emc.
[22:34:40] <mshaver> I did try to set stepgen maxaccel to 1000000.0 and maxvel to 10000, but as soon as I tried to move much grinding, whining and carrying on type noises came from the motor.
[22:39:14] <jmkasunich> thats because the driver relies on the accel limits to send sane commands to the motor
[22:40:25] <tim__> mshaver: are you using a PID loop
[22:40:45] <mshaver> tim__: no
[22:41:01] <tim__> Bang goes that idea ;-(
[22:41:44] <mshaver> there's no actual real world feedback, just accumulated position from the 5i20 stepgens
[22:42:53] <tim__> What does it look like with a lower max speed
[22:43:07] <mshaver> jmkasunich: yea. I'm updating my copy of TRUNK right now and going to look at the source for the 5i20 stuff to see if I can figure out what to do.
[22:44:16] <mshaver> tim__: I can look. What are you thinking?
[22:47:23] <tim__> We
[22:48:58] <tim__> not shure, but even at the end of your run the error is still climbing, just.
[23:20:54] <tim__> mshaver: so suprised this is not a PID problem. Looks like a wide Proportional causing the slugish responce and following error.
