having trouble thinking
if a HAL pin is an input, then it's an output on the hardware
* jepler furrows his brow
yeah, so the input is named something like parport.pin-1-out
input on the driver in the hal pin sense
is that what you're talking about?
it doesn't help that there are 16 different input/output combinations per 825
I squinted at the parport docs for a while before I understood that
jepler, are you looking at the ax5214 driver for reference?
SWPadnos: no -- is it also 8255-based?
I didn't realize
and the driver can have any chip-supported combination of input or output
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)
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
heh - cool
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)
hmmm - it would probably be best to use the same method for all 8255-related drivers
I'd love to see a single driver that can use either card, actually
put in base address, offset between chips, and number of chips on the insmod line
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 ...
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
(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)
ok - that would be difficult to specify at insmod time ...
I agree with you in principle
but I'm not smart enough to make it work in practice
or maybe I'm too lazy
I'm not sure any of us is smart enough to make it work for the users in practice ...
I think I have all the digital outputs working now
I'll mess with inputs later .. and memory-mapped I/O last
* jepler calls it a night
see you later
Night jepler... nice work.
I'll probably be hanging around
but not furiously banging the keyboard
with outb() it is about 10us to write all 72 outputs (9 outb()s)
that's not too bad
clearly it doesn't have a huge speed advantage over a traditional parallel port
one thing - it would probably be more efficient to just use port C as a single 8-bit port, in one direction
that prevents two accesses to the same port
I hope that in memory-mapped mode, the processor's write cache will make the .write function appear to be very fast
SWPadnos: I permit port C to be split, but if it is not then I use a single I/O instruction for it.
that could be a good or a bad thing
sure - you always read or write in one go, but having both a read and a write is worse (for timing)
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
ie, making each char represent 8 bits is better for orrthogonality, even though it isn't for flexibility
flexibility >> making devices that aren't really the same look the same
I called that orthogonality
flexibility -> being able to specify anything the hardware can do
I could require one letter per bit, and bitch at the users if they don't use 8 or 4 at a time
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
something like that crossed my mind too
if you specified IIOOII, you'd get 6 bytes specified as in in out out in in
also, with numbers, so that you could specify everything as inputs with a very short string: 72i
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
shouldn't that be 12?
I must have 0x3ff on my brain
is that supposed to be for MAX=16 boards?
1152 i/o ? :)
it's not enough
not that there are any PC boards with that many slots ...
motherboards, that is
I have a 12-slot motherboard, but they're not all PCI
I have some pretty high count servo boards. Not 12 though
servo on the brain
yes - dual Pentium-Pro overdrive ;)
is that like 200mhz?
hey - the overdrive is 333 MHz!
ah - been a while
and plenty fast enough for a 2-person server (plus CVS access through DSL)
Good, if 16 is bigger than anyone will ever need, I chose well
it's possible to use more than 16 boardss with a few sidecars though
ok - time for bed. You guys have fun. :)
thanks. good night
how goes it?
Good so far. I'm fighting with steppers and gecko drives.
loosing steps on a regular basis.
double-checked all the setup and hold times, I assume?
Been playing with those.
This is head. You know if any issues?
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.
I saw a couple of parameters named steplen and stepspace that I don't know anything about.
Right I saw that they come out in integers
there is a picture of the waveform in the pdf documentation
you are using software stepgen, not ppmc or anything?
Right plain old parport.
Thanks for the hint about the image. I'd read the page before last night but didn't think to look on.
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
otherwise, direction can change at the same time step goes false again
(the times all default to 1 period)
hm I'm not sure if that description is correct
I mean, what I just said
see you later -- time to drive to work
rayh: do you know when steps are lost?
how is everything?
at work already?
Hi cradek. I'm back and forth to the machine right now.
Still trying to figure out when I'm loosing.
jepler: have you heard anything back from the fpga4fun guy?
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
I wonder if it's OK to apply 5V to an output pin
I'm seeing some "issues" running mdi
a line like g21 g1 f10 z2
interprets the f in the units used on the line before.
I'm also seeing f changes when an mdi command is issued even though not in mdi mode.
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"
I was in inches and issued g21 g1 f400 and got f101600
I'm surprised by that behavior but I do see it in the spec too...
wow. that makes a mess of the switch from inch to mm and back
you got 400 ipm and then switched the "display" to mm, so it shows 101600
No the inch feedrate was 8
look at the link jepler pasted
the g21 switches more than display
the F is run before the G21
sounds like g21/20 should be on its own line.
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
so the feedrate will be 101600 mm per minute
I don't particularly defend this behavior, but I do believe it's what the spec says
Yep and that is not what I would have expected from that block of code.
seems a little bogus to me
scared the crap outa me I can tell you.'
jepler: maybe you should put "use g20 or g21 on its own line" in the best-practices section
that's why I wrote under G-Code Best Practices: ... Don't put too many things on one line ...
ok I see it's all ready pretty much covered then :-)
our big lathe has a keyed switch to swop it from in/mm
1016mm per minute sounds pretty fast
not at all
er, 101600mm per minute that is
make that per second, and it's fast ;)
seen laser cutter doing 20m/sec for positioning
that would scare me
jepler: it's enclosed
looks to me like you guys are reading order of execution correctly.
and people usually stay away
I wonder if it's time to slap TomK around again?
I wonder if there's a better way to say "Don't put too many things on one line"
rayh: he probably had some thoughts before deciding that
for example it would be a mess to say evaluate F before any Gxx except G20 and G21
what about G63.7 (which probably doesn't exist) but may be influenced by F in a different way
The Interstellar Environment of Filled-Center Supernova Remnants ...
A multi-wavelength investigation of the candidate supernova remnant G63.7+1.1 and its surrounding interstellar medium is presented. ...
* jepler wonders what G63.7 is
should have picked a different name
rayh: if you ask me, he does deserve a bit of slapping about the units handling...
cradek: wonder if it's not a leftover from the initial rs274 spec
if you look at the list, everything about distances is under the "set length units" *except* F
so I think the order is bogus, but we can't change it without possibly breaking "correct" ngc programs
so we shrug and move on :-)
I know :/
odd behavior now I was trying to move z up and down by 0.0005 using increments
regardless of which way I tried on the tkemc screen it went the same direction.
hal show didn't show any change in direction for the moves.
rayh: is your scale more than 2000?
2035 or so
are you using incremental jog or mdi?
mdi seems to work properly.
hmm, that's interesting
2032 is the input_scale
I only have .001 and .0001 incremental jogs, did you add some others?
does it on all axes.
press the .0001 five times to get the step.
but always in the same direction regardless of which button is pressed.
that's one word for it :-(
can you try mini and AXIS?
I'll try changing pulse timing and see if I can get changes.
let me try.
for some reason mini doesn't show the .01. I'll have to look at that in a minute.
when I do the incremental jog in tkemc with stepper_inch, the numbers onscreen are right
is the readout right for you too, ray?
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
depending on the starting position, you may not get a step in one direction, but you would in the other
same problem with axis display
Yes the display seems to move the correct direction.
If I use a 0.001 increment it seems to work fine.
is there a DEADBAND?
It is the smaller increment that errors out.
Does the direction pin remain in fixed position until commanded to change?
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
(but don't take my word for it - I'm still on my first cup of coffee)
I was using tenth steps and clicking 5 times.
no, DIR can cahnge at any time
so four did nothing and the fifth made the change.
but direction does not change.
so I might not see a direction pin change with halshow.
rayh: direction might be too small for halshow to update
you should see it - the DIR pin should change as soon as the direction of travel changes (even if the speed is near 0)
so it always shows brown?
it can't change for less than 1 BASE_PERIOD
you may need halscope instead of halshow
trigger on the step output
No I don't see any direction change. Let me increase the increment and see if I see it then.
I'm seeing that the direction pin has a defined idle position and only changes during a commanded move.
But if that commanded move is very short, like one pulse it does not change direction at all.
maybe the gecko is missing the dir
cause it's too small
DIR is set by the sign of the "adder", which is proportional to the distance to move
if distance to move is 0, then DIR will be 0
regardless of the previous direction
so if move is tiny, DIR time is tiny?
it should stay valid for the full step pulse, plus dirsetup and/or dirhold
I hould be looking at the code during this conversation ;)
but a manual jog should still honor hold and setup?
regardless of how small the move is?
or am I not thinking clear
stepgen will always honor those settings, according to jmk
so a changed in direction, no matter how small the move associated with it should change the dir pin, wait, then issue the step.
But that appears not to happen.
Let me work with halscope for a bit and see if I can get a trace.
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)
ok - this could be a roundoff error in stepgen - you're asking for moves that are below its resolution
The way that the direction works now it certainly favors one direction over another.
yeah - I think it defaults to 0 for the DIR pin, since there's usually no distance to go
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:59:03] <jepler> http://www.microsoft.com/technet/security/advisory/929433.mspx
I don't find that suprising. thats scary.
this microsoft-hater isn't surprised
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>
if it happens to openoffice I'll still sneer and feel superior
I wonder how cautious you need to be to open a *word processor* document
skunkworks: I do see vulnerabilities fixed on my ubuntu system every so often
sometimes really embarassing ones
but I feel like the open model is better for security than the secrecy model and always will be
:) the thing is - you don't have many linux haters trying to exploit it compared to micro$oft
all those MS employees should be able to come up with something ;)
you would definatly think the issues would definatly be found faster with open souce
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
Lerneaen_Hydra_ is now known as Lerneaen_Hydra
I don't know what to do when someone comes along and wants to use g-code for something complex or complicated
do you understand what he wants?
jepler: tell them to get a CAM program
no, but I bet that no facility in rs274ngc is well-suited to what he wants
alex_joni: "buy some expensive software and maybe you'll be able to mill something useful .. maybe"?
that's no answer
well.. didn't really see an alternative to g-code
the newer standards like step-nc are not at all user-friendly
no more hand writing/reading
jepler: and people that sell expensive software better sell it with support
but I agree it's not the best thing :/
"oh, and you won't be able to run it at the same time as you run emc2; you'll have to reboot"
wine about it
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"
cradek: if there would be a standard with users writing in it in mind it would be better
but machining usually is about automated things (drawing <-process-> output)
anyways.. gotta get up in 5 hours :/ night all
"g-code" is very easy to target with a program written in a real programming language, so in that sense g-code is just fine
see you alex
see you guys
jepler: that's true
don't reinvent g-code without me :D
or j-code ;)
jepler: but other things are just like machining: g92 is "stop and set your handwheels to some number"
g81 is "now drill a hole"
it's more machining than programming
you can't machine a circle of holes without doing the trig
(so I still don't understand the question)
I don't know what he wants either
sounds like he's working with someone else's generated gcode, so it's going to suck no matter what
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"
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
a transform stack would be nice.
it's true you have that but you can only get one deep with g92.
hm -- you might be able to make it "stack-like" yourself since offsets are stored in variables...
ve7it is now known as LawrenceG