Back
[01:10:19] <jepler> having trouble thinking
[01:10:28] <jepler> if a HAL pin is an input, then it's an output on the hardware
[01:10:35] <jepler> * jepler furrows his brow
[01:12:35] <cradek> yeah, so the input is named something like parport.pin-1-out
[01:12:56] <cradek> input on the driver in the hal pin sense
[01:13:00] <cradek> is that what you're talking about?
[01:13:09] <jepler> yes
[01:13:30] <jepler> it doesn't help that there are 16 different input/output combinations per 825
[01:13:31] <jepler> 8255
[01:13:32] <cradek> I squinted at the parport docs for a while before I understood that
[01:13:42] <cradek> guh
[01:22:12] <SWPadnos> jepler, are you looking at the ax5214 driver for reference?
[01:23:59] <jepler> SWPadnos: no -- is it also 8255-based?
[01:24:14] <SWPadnos> yep
[01:24:18] <jepler> I didn't realize
[01:24:41] <SWPadnos> and the driver can have any chip-supported combination of input or output
[01:25:28] <SWPadnos> you may want to see if the register address spacing is the same (it will be for the 8255's, but they may have gaps between chips)
[02:27:51] <jepler> SWPadnos: you told me too late about ax5214 but now I'm getting the first outputs from the pci8255 board using all my own code
[02:28:03] <SWPadnos> heh - cool
[02:28:18] <jepler> SWPadnos: I might as well steal their method of indicating inputs and outputs -- it beats mine (a number from 0 to 0x3ff, used 4 bits at a time)
[02:28:42] <SWPadnos> hmmm - it would probably be best to use the same method for all 8255-related drivers
[02:28:57] <SWPadnos> I'd love to see a single driver that can use either card, actually
[02:29:11] <SWPadnos> put in base address, offset between chips, and number of chips on the insmod line
[02:29:56] <SWPadnos> hmmm - or maybe just have each 8255 be a separate unit - have only base address and 4 chars for I/O direction for each chip ...
[02:30:22] <jepler> there's additional setup that's specific to this board, the 8255 registers are spaced 4 bytes apart rather than 1 byte, and I think that using the memory-mapped rather than outb() communication will allow higher speeds
[02:30:27] <SWPadnos> (the reason I'm thinking this way is that there are a lot of generic 8255 cards out there, with 1,2,3, or 4 chips usually)
[02:30:48] <SWPadnos> ok - that would be difficult to specify at insmod time ...
[02:31:01] <jepler> I agree with you in principle
[02:31:11] <jepler> but I'm not smart enough to make it work in practice
[02:31:21] <jepler> or maybe I'm too lazy
[02:31:34] <SWPadnos> I'm not sure any of us is smart enough to make it work for the users in practice ...
[02:34:22] <jepler> I think I have all the digital outputs working now
[02:34:44] <jepler> I'll mess with inputs later .. and memory-mapped I/O last
[02:34:53] <jepler> * jepler calls it a night
[02:34:59] <SWPadnos> see you later
[02:35:06] <skunkworks> Night jepler... nice work.
[02:35:06] <jepler> I'll probably be hanging around
[02:35:11] <jepler> but not furiously banging the keyboard
[02:35:14] <SWPadnos> heh
[02:35:46] <jepler> with outb() it is about 10us to write all 72 outputs (9 outb()s)
[02:36:10] <SWPadnos> that's not too bad
[02:36:10] <jepler> clearly it doesn't have a huge speed advantage over a traditional parallel port
[02:36:18] <SWPadnos> that's true
[02:36:41] <SWPadnos> one thing - it would probably be more efficient to just use port C as a single 8-bit port, in one direction
[02:36:46] <SWPadnos> that prevents two accesses to the same port
[02:37:11] <jepler> I hope that in memory-mapped mode, the processor's write cache will make the .write function appear to be very fast
[02:37:24] <jepler> SWPadnos: I permit port C to be split, but if it is not then I use a single I/O instruction for it.
[02:37:26] <SWPadnos> that could be a good or a bad thing
[02:37:49] <SWPadnos> sure - you always read or write in one go, but having both a read and a write is worse (for timing)
[02:38:43] <SWPadnos> the added flexibility is probably worth it, though the use of a config char for 4 bits instead of 8 may be confusing, especially when we may have other FPGA-based things that can also specify I/O that way
[02:39:05] <SWPadnos> ie, making each char represent 8 bits is better for orrthogonality, even though it isn't for flexibility
[02:39:41] <jepler> flexibility >> making devices that aren't really the same look the same
[02:40:06] <SWPadnos> I called that orthogonality
[02:40:20] <SWPadnos> flexibility -> being able to specify anything the hardware can do
[02:40:23] <jepler> I could require one letter per bit, and bitch at the users if they don't use 8 or 4 at a time
[02:40:25] <SWPadnos> heh
[02:42:02] <SWPadnos> one suggestion I had for jmk when he was writing the ax5214 driver (I think) was to use lower case for the nibbles, and upper case for bytes
[02:42:23] <jepler> something like that crossed my mind too
[02:42:23] <SWPadnos> if you specified IIOOII, you'd get 6 bytes specified as in in out out in in
[02:43:03] <jepler> also, with numbers, so that you could specify everything as inputs with a very short string: 72i
[02:43:13] <SWPadnos> yep
[02:43:41] <jepler> I'll leave it as a number from 0 to 0x3ff for now, clearly that will offend you enough that you'll do something better right away
[02:43:47] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/pci_8255.c
[02:45:05] <SWPadnos> 10 bits?
[02:45:13] <SWPadnos> shouldn't that be 12?
[02:48:28] <jepler> er probably
[02:48:41] <jepler> I must have 0x3ff on my brain
[02:49:02] <SWPadnos> is that supposed to be for MAX=16 boards?
[02:49:05] <SWPadnos> heh
[02:50:39] <skunkworks> 1152 i/o ? :)
[02:50:56] <SWPadnos> it's not enough
[02:51:13] <SWPadnos> not that there are any PC boards with that many slots ...
[02:51:23] <skunkworks> minor detail
[02:51:24] <SWPadnos> motherboards, that is
[02:51:36] <SWPadnos> I have a 12-slot motherboard, but they're not all PCI
[02:52:02] <skunkworks> I have some pretty high count servo boards. Not 12 though
[02:52:17] <skunkworks> servo?
[02:52:20] <skunkworks> server
[02:52:36] <skunkworks> servo on the brain
[02:52:38] <SWPadnos> yes - dual Pentium-Pro overdrive ;)
[02:53:08] <skunkworks> is that like 200mhz?
[02:53:32] <SWPadnos> hey - the overdrive is 333 MHz!
[02:53:41] <skunkworks> ah - been a while
[02:53:58] <SWPadnos> and plenty fast enough for a 2-person server (plus CVS access through DSL)
[02:53:59] <jepler> Good, if 16 is bigger than anyone will ever need, I chose well
[02:54:17] <SWPadnos> it's possible to use more than 16 boardss with a few sidecars though
[02:59:56] <skunkworks> ok - time for bed. You guys have fun. :)
[03:00:28] <SWPadnos> thanks. good night
[13:18:07] <alex_joni> hi rayh
[13:18:23] <rayh> hi alex.
[13:18:32] <alex_joni> how goes it?
[13:19:07] <rayh> Good so far. I'm fighting with steppers and gecko drives.
[13:19:36] <rayh> loosing steps on a regular basis.
[13:20:26] <jepler> double-checked all the setup and hold times, I assume?
[13:21:49] <rayh> Been playing with those.
[13:22:12] <rayh> This is head. You know if any issues?
[13:23:30] <jepler> there was the "single reversed step (but within accel & vel limits)" issue we discovered after Ed Nisley's post. I also noticed that the documentation doesn't make it clear that the stepgen setup & hold time are in BASE_PERIODs, not in nanoseconds or microseconds.
[13:23:37] <rayh> I saw a couple of parameters named steplen and stepspace that I don't know anything about.
[13:24:34] <rayh> Right I saw that they come out in integers
[13:25:16] <jepler> there is a picture of the waveform in the pdf documentation
[13:25:30] <rayh> ah okay.
[13:25:34] <jepler> you are using software stepgen, not ppmc or anything?
[13:25:37] <jepler> er, usc
[13:26:29] <rayh> Right plain old parport.
[13:28:16] <rayh> Thanks for the hint about the image. I'd read the page before last night but didn't think to look on.
[13:28:47] <jepler> you need to make sure that the DIRECTION signal is held at least 20uS after the falling edge of STEP -- I think that means you need to increase dirhold from 1 to 2
[13:28:56] <jepler> otherwise, direction can change at the same time step goes false again
[13:29:06] <jepler> (the times all default to 1 period)
[13:30:06] <jepler> hm I'm not sure if that description is correct
[13:30:11] <jepler> I mean, what I just said
[13:30:45] <jepler> see you later -- time to drive to work
[13:30:52] <rayh> Thanks jeff.
[14:00:05] <cradek> rayh: do you know when steps are lost?
[14:01:14] <alex_joni> morning chris
[14:01:18] <cradek> hi
[14:01:39] <alex_joni> how is everything?
[14:01:42] <alex_joni> at work already?
[14:03:15] <cradek> not yet...
[14:10:17] <rayh> Hi cradek. I'm back and forth to the machine right now.
[14:10:28] <rayh> Still trying to figure out when I'm loosing.
[15:05:10] <skunkworks> jepler: have you heard anything back from the fpga4fun guy?
[15:06:04] <jepler> skunkworks: nope
[15:36:58] <jepler> the other thing I've realized is that the reset method intended by the fpga4fun guy is an FPGA output pin tied to the reset pin -- and my firmware had that pin in output mode
[15:37:12] <jepler> I wonder if it's OK to apply 5V to an output pin
[15:37:21] <rayh> I'm seeing some "issues" running mdi
[15:37:40] <rayh> a line like g21 g1 f10 z2
[15:38:35] <rayh> interprets the f in the units used on the line before.
[15:39:47] <rayh> I'm also seeing f changes when an mdi command is issued even though not in mdi mode.
[15:40:34] <jepler> The F- number is interpreted before G20/G21, so if you were in inches before then the feed you would get is 10 inches per minute, not 10 mm per minute
[15:41:20] <jepler> http://linuxcnc.org/docs/html/gcode/main/ heading "Order of execution"
[15:42:42] <rayh> I was in inches and issued g21 g1 f400 and got f101600
[15:42:53] <cradek> I'm surprised by that behavior but I do see it in the spec too...
[15:43:22] <rayh> wow. that makes a mess of the switch from inch to mm and back
[15:43:28] <cradek> you got 400 ipm and then switched the "display" to mm, so it shows 101600
[15:43:51] <rayh> No the inch feedrate was 8
[15:44:12] <cradek> look at the link jepler pasted
[15:44:18] <rayh> the g21 switches more than display
[15:44:19] <cradek> the F is run before the G21
[15:44:22] <skunkworks> sounds like g21/20 should be on its own line.
[15:44:46] <jepler> if g20 was active, and you command: g21 g1 f400, then the feedrate is set to 400 inches per minute, then the units are changed to mm
[15:44:52] <jepler> so the feedrate will be 101600 mm per minute
[15:45:13] <jepler> I don't particularly defend this behavior, but I do believe it's what the spec says
[15:45:24] <rayh> Yep and that is not what I would have expected from that block of code.
[15:45:27] <cradek> seems a little bogus to me
[15:45:48] <rayh> scared the crap outa me I can tell you.'
[15:46:15] <cradek> jepler: maybe you should put "use g20 or g21 on its own line" in the best-practices section
[15:46:16] <jepler> that's why I wrote under G-Code Best Practices: ... Don't put too many things on one line ...
[15:46:41] <cradek> ok I see it's all ready pretty much covered then :-)
[15:46:57] <alex_joni> lol
[15:47:17] <skunkworks> our big lathe has a keyed switch to swop it from in/mm
[15:47:19] <jepler> 1016mm per minute sounds pretty fast
[15:47:23] <alex_joni> not at all
[15:47:25] <jepler> er, 101600mm per minute that is
[15:47:28] <cradek> 400ipm
[15:47:32] <cradek> yeah, ouch
[15:47:51] <alex_joni> make that per second, and it's fast ;)
[15:48:06] <alex_joni> seen laser cutter doing 20m/sec for positioning
[15:48:17] <jepler> that would scare me
[15:49:19] <alex_joni> jepler: it's enclosed
[15:49:20] <rayh> looks to me like you guys are reading order of execution correctly.
[15:49:24] <alex_joni> and people usually stay away
[15:49:58] <rayh> I wonder if it's time to slap TomK around again?
[15:50:55] <jepler> I wonder if there's a better way to say "Don't put too many things on one line"
[15:51:28] <alex_joni> rayh: he probably had some thoughts before deciding that
[15:51:47] <alex_joni> for example it would be a mess to say evaluate F before any Gxx except G20 and G21
[15:52:14] <alex_joni> what about G63.7 (which probably doesn't exist) but may be influenced by F in a different way
[16:00:37] <jepler> The Interstellar Environment of Filled-Center Supernova Remnants ...
[16:00:38] <jepler> A multi-wavelength investigation of the candidate supernova remnant G63.7+1.1 and its surrounding interstellar medium is presented. ...
[16:00:42] <jepler> adsabs.harvard.edu/abs/1997astro.ph..8151W
[16:00:44] <jepler> * jepler wonders what G63.7 is
[16:01:26] <alex_joni> should have picked a different name
[16:04:30] <cradek> rayh: if you ask me, he does deserve a bit of slapping about the units handling...
[16:05:56] <alex_joni> cradek: wonder if it's not a leftover from the initial rs274 spec
[16:11:28] <cradek> if you look at the list, everything about distances is under the "set length units" *except* F
[16:11:51] <cradek> so I think the order is bogus, but we can't change it without possibly breaking "correct" ngc programs
[16:11:56] <cradek> so we shrug and move on :-)
[16:12:10] <alex_joni> I know :/
[17:18:55] <rayh> odd behavior now I was trying to move z up and down by 0.0005 using increments
[17:19:15] <rayh> regardless of which way I tried on the tkemc screen it went the same direction.
[17:19:38] <rayh> hal show didn't show any change in direction for the moves.
[17:19:56] <cradek> rayh: is your scale more than 2000?
[17:21:49] <rayh> 2035 or so
[17:22:08] <cradek> are you using incremental jog or mdi?
[17:22:21] <rayh> incremental
[17:22:38] <rayh> mdi seems to work properly.
[17:22:55] <cradek> hmm, that's interesting
[17:23:03] <rayh> 2032 is the input_scale
[17:23:08] <cradek> I only have .001 and .0001 incremental jogs, did you add some others?
[17:23:14] <rayh> does it on all axes.
[17:23:28] <rayh> press the .0001 five times to get the step.
[17:23:33] <cradek> ok
[17:23:49] <rayh> but always in the same direction regardless of which button is pressed.
[17:24:11] <rayh> fascinating.
[17:24:20] <cradek> that's one word for it :-(
[17:24:33] <SWPadnos> can you try mini and AXIS?
[17:24:33] <rayh> I'll try changing pulse timing and see if I can get changes.
[17:24:48] <rayh> let me try.
[17:26:53] <rayh> for some reason mini doesn't show the .01. I'll have to look at that in a minute.
[17:29:24] <jepler> when I do the incremental jog in tkemc with stepper_inch, the numbers onscreen are right
[17:29:34] <jepler> is the readout right for you too, ray?
[17:33:12] <jepler> and it looks fine in halscope too:
http://emergent.unpy.net/files/sandbox/halscope-stepping-left.png http://emergent.unpy.net/files/sandbox/halscope-stepping-right.png
[17:37:12] <SWPadnos> depending on the starting position, you may not get a step in one direction, but you would in the other
[17:37:23] <rayh> same problem with axis display
[17:38:07] <rayh> Yes the display seems to move the correct direction.
[17:38:19] <rayh> If I use a 0.001 increment it seems to work fine.
[17:38:24] <SWPadnos> is there a DEADBAND?
[17:38:26] <rayh> It is the smaller increment that errors out.
[17:38:30] <rayh> no
[17:38:38] <rayh> no deadband.
[17:38:41] <SWPadnos> ok
[17:39:31] <rayh> Does the direction pin remain in fixed position until commanded to change?
[17:39:36] <SWPadnos> stepgen maintains "fractional steps" internally. 0.0005 is just over one step, so if the fraction is slightly positive, and you try to jog down one step, you may not quite get it to output a step
[17:39:57] <SWPadnos> (but don't take my word for it - I'm still on my first cup of coffee)
[17:40:10] <rayh> I was using tenth steps and clicking 5 times.
[17:40:13] <SWPadnos> no, DIR can cahnge at any time
[17:40:24] <rayh> so four did nothing and the fifth made the change.
[17:40:32] <rayh> but direction does not change.
[17:41:02] <rayh> so I might not see a direction pin change with halshow.
[17:41:28] <alex_joni> rayh: direction might be too small for halshow to update
[17:41:32] <SWPadnos> you should see it - the DIR pin should change as soon as the direction of travel changes (even if the speed is near 0)
[17:41:50] <rayh> so it always shows brown?
[17:41:56] <SWPadnos> it can't change for less than 1 BASE_PERIOD
[17:42:07] <SWPadnos> you may need halscope instead of halshow
[17:42:21] <SWPadnos> trigger on the step output
[17:42:23] <rayh> No I don't see any direction change. Let me increase the increment and see if I see it then.
[17:45:09] <rayh> I'm seeing that the direction pin has a defined idle position and only changes during a commanded move.
[17:45:34] <rayh> But if that commanded move is very short, like one pulse it does not change direction at all.
[17:45:58] <alex_joni> maybe the gecko is missing the dir
[17:46:03] <alex_joni> cause it's too small
[17:46:22] <SWPadnos> DIR is set by the sign of the "adder", which is proportional to the distance to move
[17:46:34] <SWPadnos> if distance to move is 0, then DIR will be 0
[17:46:45] <SWPadnos> regardless of the previous direction
[17:47:12] <alex_joni> so if move is tiny, DIR time is tiny?
[17:47:40] <SWPadnos> it should stay valid for the full step pulse, plus dirsetup and/or dirhold
[17:48:02] <SWPadnos> I hould be looking at the code during this conversation ;)
[17:48:03] <SWPadnos> should
[17:53:08] <rayh> but a manual jog should still honor hold and setup?
[17:53:33] <rayh> regardless of how small the move is?
[17:53:41] <rayh> or am I not thinking clear
[17:53:47] <SWPadnos> stepgen will always honor those settings, according to jmk
[17:54:34] <rayh> so a changed in direction, no matter how small the move associated with it should change the dir pin, wait, then issue the step.
[17:54:49] <SWPadnos> yes
[17:54:51] <rayh> But that appears not to happen.
[17:55:26] <rayh> Let me work with halscope for a bit and see if I can get a trace.
[17:55:38] <SWPadnos> that's why you may get spurious DIR changes - even if no step is issued for a move, DIR will change, so that when a step is needed, the DIRSETUP time will have passed (or at least part of it)
[17:56:04] <SWPadnos> ok - this could be a roundoff error in stepgen - you're asking for moves that are below its resolution
[18:01:55] <rayh> The way that the direction works now it certainly favors one direction over another.
[18:02:27] <SWPadnos> yeah - I think it defaults to 0 for the DIR pin, since there's usually no distance to go
[18:03:29] <SWPadnos> but there's only a problem if there's ever a step output with DIR in the wrong state, or if there's a setup time violation
[18:07:25] <alex_joni> later guys
[18:07:28] <SWPadnos> see you
[18:08:27] <Lerneaen_Hydra_> bye
[18:59:03] <jepler> http://www.microsoft.com/technet/security/advisory/929433.mspx
[18:59:04] <jepler> oops
[19:03:50] <skunkworks> I don't find that suprising. thats scary.
[19:10:32] <jepler> this microsoft-hater isn't surprised
[19:11:44] <skunkworks> now now... If linux was the most popular o/s I think the viruses would be worse. You guys are way too smart for your own good. </devils advocate>
[19:13:53] <jepler> if it happens to openoffice I'll still sneer and feel superior
[19:14:21] <skunkworks> :)\
[19:16:44] <SWPadnos> I wonder how cautious you need to be to open a *word processor* document
[19:16:47] <cradek> skunkworks: I do see vulnerabilities fixed on my ubuntu system every so often
[19:17:05] <jepler> sometimes really embarassing ones
[19:17:34] <cradek> but I feel like the open model is better for security than the secrecy model and always will be
[19:17:41] <skunkworks> :) the thing is - you don't have many linux haters trying to exploit it compared to micro$oft
[19:18:03] <SWPadnos> all those MS employees should be able to come up with something ;)
[19:18:48] <skunkworks> you would definatly think the issues would definatly be found faster with open souce
[19:18:51] <skunkworks> source
[19:18:56] <SWPadnos> definitely ;)
[19:19:06] <skunkworks> right ;)
[19:20:37] <cradek> I routinely have my 'updates available' light come on before I see an announcement on bugtraq ... seems ubuntu is extra good at getting fixes out
[20:38:11] <Lerneaen_Hydra_> Lerneaen_Hydra_ is now known as Lerneaen_Hydra
[22:02:14] <jepler> g-code sucks
[22:02:46] <jepler> I don't know what to do when someone comes along and wants to use g-code for something complex or complicated
[22:03:14] <cradek> do you understand what he wants?
[22:03:42] <alex_joni> jepler: tell them to get a CAM program
[22:03:44] <jepler> no, but I bet that no facility in rs274ngc is well-suited to what he wants
[22:03:57] <jepler> alex_joni: "buy some expensive software and maybe you'll be able to mill something useful .. maybe"?
[22:04:01] <jepler> that's no answer
[22:04:17] <alex_joni> well.. didn't really see an alternative to g-code
[22:04:32] <alex_joni> the newer standards like step-nc are not at all user-friendly
[22:04:38] <alex_joni> no more hand writing/reading
[22:05:02] <alex_joni> jepler: and people that sell expensive software better sell it with support
[22:05:22] <alex_joni> but I agree it's not the best thing :/
[22:05:26] <jepler> "oh, and you won't be able to run it at the same time as you run emc2; you'll have to reboot"
[22:05:40] <alex_joni> wine about it
[22:05:45] <alex_joni> ;-)
[22:05:54] <cradek> maybe because I'm used to gcode my thinking is constrained, but I'm not sure what one could do that would be "much better"
[22:06:46] <alex_joni> cradek: if there would be a standard with users writing in it in mind it would be better
[22:07:07] <alex_joni> but machining usually is about automated things (drawing <-process-> output)
[22:07:33] <alex_joni> anyways.. gotta get up in 5 hours :/ night all
[22:07:38] <cradek> goodnight
[22:07:38] <jepler> "g[0123]-code" is very easy to target with a program written in a real programming language, so in that sense g-code is just fine
[22:08:02] <jepler> see you alex
[22:08:17] <alex_joni> see you guys
[22:08:23] <cradek> jepler: that's true
[22:08:23] <alex_joni> don't reinvent g-code without me :D
[22:08:41] <alex_joni> or j-code ;)
[22:08:43] <cradek> jepler: but other things are just like machining: g92 is "stop and set your handwheels to some number"
[22:08:58] <cradek> g81 is "now drill a hole"
[22:09:05] <cradek> it's more machining than programming
[22:09:57] <cradek> you can't machine a circle of holes without doing the trig
[22:10:08] <cradek> (so I still don't understand the question)
[22:11:26] <jepler> I don't know what he wants either
[22:11:51] <cradek> sounds like he's working with someone else's generated gcode, so it's going to suck no matter what
[22:12:40] <jepler> here's the thing I have wanted that I hear him saying: a transformation stack (like postscript or opengl) so that I can say "move the coordinate system here", do the trig without having to add in the origin every time, and "put it back"
[22:13:13] <jepler> you can't do it with g5x or g92.x because it doesn't behave in a "stack-like" way -- you're screwed if the code you're calling tries to use offsets too
[22:13:15] <cradek> a transform stack would be nice.
[22:13:34] <cradek> it's true you have that but you can only get one deep with g92.
[22:16:48] <jepler> hm -- you might be able to make it "stack-like" yourself since offsets are stored in variables...
[22:30:17] <ve7it> ve7it is now known as LawrenceG
