Back
[14:19:55] <cradek> jepler: fr_rs274_err.po looks really screwed up to me
[14:20:08] <cradek> msgid "exceeds +X limitexceeds +Y limitexceeds +Z limitexceeds -X limitexceeds -Y limitexceeds -Z limit"
[14:20:13] <cradek> "command (%s) cannot be executed until the machine is out of E-stop and "
[14:20:14] <cradek> "turned oncan't do that (%s) in manual mode"
[14:20:30] <cradek> he faithfully translates all this mess, but surely it can't work can it?
[14:22:49] <jepler> I did not look carefully at it ..
[14:25:56] <jepler> OK, I e-mailed him back
[14:26:01] <jepler> thanks for bothering to look
[14:27:13] <jepler> I am having trouble writing the documentation for the double step speed mode
[14:35:57] <SWPadnos> what's the trouble?
[14:36:11] <jepler> I don't think I can describe it in a way anyone will understand
[14:36:15] <jepler> at least, anybody who's not a wizard
[14:36:24] <SWPadnos> heh - ok, I can se that would be trouble :)
[14:36:26] <SWPadnos> see
[14:37:05] <cradek> then concentrate on making a sample configuration that will work for nonwizards
[14:37:17] <SWPadnos> somewhat OT: in your perusal of stepgen, did you notice if dirspace / dirhold are used in the quadrature mode?
[14:37:28] <SWPadnos> (even under a different name)
[14:37:54] <cradek> * cradek gently directs SWPadnos to the stepgen manpage
[14:38:05] <jepler> what would it mean if they were??
[14:38:08] <SWPadnos> * SWPadnos directed himself to the source ;)
[14:38:40] <SWPadnos> just curious. the idea of an external microcontroller/logic chip quad->step/dir board came up again yesterday
[14:38:59] <SWPadnos> it's a lot harder if the board has to do timing enforcement
[14:39:24] <jepler> there's no way the external parts can know the "next direction" before the first quadrature transition towards that direction actually takes place
[14:40:01] <jepler> so even having dead time between the last + transition and the first - transition doesn't help anything
[14:40:58] <SWPadnos> that's the problem. it would be possible to have a microcontroller delay a step in the opposite direction, but that causes a ripple effect on the timing of future steps
[14:41:22] <SWPadnos> which is why it's better for stepgen to just wait at direction changes, even in quadrature mode
[14:41:46] <cradek> I think you are talking past each other
[14:42:12] <cradek> the external device can't know a reversal will occur until it sees it
[14:42:12] <SWPadnos> could be. I haven't had coffee, so I may be making incoherent statements and links
[14:42:22] <SWPadnos> understood
[14:42:29] <cradek> stepgen waiting does no good unless it tells the external to reverse the dir bit before it waits
[14:42:47] <SWPadnos> ah - ok, now I get it :)
[14:43:42] <cradek> you could do something hideous like always issue an extra step in the reverse direction, then wait, then send the "real" step, and have the external flip dir at the first step but otherwise drop the step
[14:44:27] <SWPadnos> I think I'd rather just delay the output with the microcontroller, and have the second reverse step a little closer than expected to the first reversed step
[14:45:04] <cradek> I think I'd rather go to the dentist than try to optimize step/dir output
[14:45:07] <SWPadnos> the micro then has to count steps though, which does make the code a little more complex
[14:45:09] <SWPadnos> heh
[14:45:27] <SWPadnos> been watching "Little Shop of Horrors" again, have we? :)
[14:45:29] <cradek> sorry, that's not very helpful of me
[14:45:39] <SWPadnos> no big deal
[14:45:45] <jepler> the main advantage to quadrature is (was) that you could get one step per period
[14:45:56] <jepler> that's not true if you apply my gross patch
[14:45:55] <SWPadnos> right
[14:46:04] <jepler> so we can just quit worrying about it now
[14:46:07] <SWPadnos> quadrature is a little more noise immune
[14:46:22] <SWPadnos> but only very expensive drives have it, so it doesn't matter much
[14:46:46] <skunkworks> Is it in trunk?
[14:46:57] <jepler> skunkworks: no, not yet
[14:46:58] <SWPadnos> (it seems that quadrature is added after analog, PWM, step/dir, serial, firewire, and ethernet)
[14:47:04] <SWPadnos> oh, and optical
[14:47:15] <jepler> skunkworks: just patches on my website
[14:47:24] <jepler> skunkworks: though I intend to check it in after I get some documentation written
[14:47:29] <skunkworks> jepler: thanks
[14:47:42] <SWPadnos> jepler, so which part seems to be unintelligible to the average user?
[14:48:04] <jepler> SWPadnos: the same problems as always -- what does it do? how do I correctly configure it?
[14:48:28] <jepler> * jepler dreads trying to talk some guy through adding it to his configuration over irc
[14:48:50] <cradek> I think "everyone" uses one of two pinouts for step/dir. so, you should make those easy and document it in whatever wizardspeak is necessary.
[14:48:54] <SWPadnos> ah. I think I'd start with the differences between a standard stepgen config and one with double-step (unless you'd like to call it something else)
[14:49:30] <SWPadnos> like - you need to set parport-reset-time to your step duration
[14:49:54] <SWPadnos> parport.reset has to be added to the thread
[14:50:07] <SWPadnos> write needs to go at the beginning of the thread instead of the end
[14:51:05] <SWPadnos> I think if you take one of the standard stepgen configs and convert it over, and write down why you did each change, that would be most of the work
[14:51:11] <jepler> so you are talking about the part that goes in the unwritten "configuring emc for parport stepper machines" document
[14:51:19] <SWPadnos> err - could be
[14:51:38] <SWPadnos> if you do a step-by-step, then others can help as well ;)
[14:52:29] <SWPadnos> I think the "what does it do" part is well taken care of by your blog post
[15:00:00] <jepler> *boom*
[15:00:11] <SWPadnos> * SWPadnos ducks
[16:27:08] <tomp> jepler: maybe... the name 'doublestep' might be what makes it hard to explain... it's like an edge trigger in the driver, and a one shot on the parport ( driver ). then some explanation of how this is faster than on, then off , each eating a cycle. and then maybe something about how the one-shot ( parport driver ) isnt so bothered by system jitter.
[16:27:59] <fenn> you also have to tell the parport which pins to turn off each cycle
[16:28:11] <tomp> yeh mask
[16:28:25] <fenn> its not a mask now though, its converted from hal parameters internally
[16:28:59] <fenn> i mean you set a "reset" parameter for each pin
[16:29:12] <tomp> ok, bitmasks are difficult for most users, reset parm sounds cool
[18:06:56] <SWPadnos> cool - my Mesa order just arrived
[18:07:15] <SWPadnos> uncool - there are no terminal plugs to plug into the 7i37T terminal headers :(
[18:07:46] <cradek> eh?
[18:07:57] <cradek> no screws?
[18:08:12] <SWPadnos> no plugs, just pins in a nice shroud
[18:08:57] <cradek> you'll have to chisel another message into a stone tablet to send to them I guess
[18:09:25] <SWPadnos> just did it
[18:12:30] <SWPadnos> gah - I can't even see any manufacturer symbol on the things, and the numbers are nearly impossible to see
[18:16:10] <alex_france> salut tous
[18:17:00] <skunkworks> Hi alex. How is france?
[18:18:30] <alex_france> different
[18:18:41] <alex_france> they have crippled keyboards
[18:20:42] <cradek> kezboards?
[18:20:53] <cradek> it's funnz to talk to jepler when he's in germanz
[18:21:13] <SWPadnos> surelz zou jest?
[18:21:33] <cradek> nope
[18:21:41] <SWPadnos> "no, and don't call me shirlez"
[18:22:11] <cradek> those jokes don't work when spelled out
[18:22:16] <skunkworks> heh - that is my wifes name.. We had watch airplane so she would get the joke..
[18:22:18] <SWPadnos> heh
[18:23:00] <alex_france> heh
[18:23:07] <alex_france> azerty - sux
[18:23:32] <alex_france> anything interesting lately (question mqrk)
[18:23:38] <alex_france> aaaargh
[18:23:39] <cradek> ha
[18:23:55] <alex_france> ha
[18:23:57] <cradek> jepler hacked stepgen to double the step rate
[18:23:58] <alex_france> found it ????
[18:24:02] <alex_france> nice :D
[18:24:38] <cradek> "It is a kludge. One of my better ones, I think." </ken l>
[18:24:39] <jepler> hi alex_france
[18:25:49] <alex_france> hi jeff
[18:26:04] <alex_france> cradek: seen that :)
[18:26:29] <SWPadnos> holy sh!t!! the connectors for the 7i37T are $20 each
[18:26:37] <SWPadnos> and you need 2 per board!
[18:27:03] <cradek> so it's on purpose that they come without the screws?
[18:27:09] <SWPadnos> and that's in qty 10 - they're $22 in singles
[18:27:11] <SWPadnos> I guess so
[18:27:15] <cradek> offs
[18:27:21] <SWPadnos> holy freaking crap
[18:27:26] <jepler> buy qty 10, cradek will want to share with you
[18:27:46] <SWPadnos> I need 10 for the 5 boards I just bought (but I can ge textras)
[18:27:47] <cradek> The -T version uses 3.5 mm screw terminal compatible plugs for motor I/O.
[18:28:02] <SWPadnos> better check the number of connections on that
[18:28:04] <cradek> is that what it said when I ordered??
[18:28:42] <SWPadnos> I don't know. I could have sworn it was supposed to come with screw terminals
[18:28:46] <cradek> I expected to get screw terminals ON IT
[18:28:56] <cradek> I feel screwed and I don't even have my cards
[18:29:06] <SWPadnos> I just re-read it as well, and saw the headers comment
[18:30:29] <cradek> why doesn't their website show part numbers for the connectors you have to order?
[18:31:04] <cradek> they HAVE to know everyone is going to feel screwed when they get these cards and they don't have those connectors
[18:31:08] <skunkworks> jepler: there isn't a reset funtion here
http://www.linuxcnc.org/docs/devel/html/man/man9/stepgen.9.html
[18:31:27] <SWPadnos> cradek, I was thikning the same thing
[18:31:36] <jepler> haha feel screwed
[18:31:40] <cradek> * cradek kicks jepler
[18:31:55] <jepler> skunkworks: "reset" is a function of the hal_parport driver (and perhaps others if they want to adopt it), not stepgen
[18:31:57] <SWPadnos> they have the same problem with the motor connectors on their driver cards - no documentation on mathcing part numbers
[18:32:09] <skunkworks> jepler: duh - sorry
[18:32:12] <cradek> if they had any brains they'd sell the matching connectors
[18:32:24] <cradek> otherwise it's just a huge pain in the ass
[18:33:00] <SWPadnos> yeah. they get down to $13 each in 1000's
[18:33:51] <SWPadnos> you can't quite buy a cable and breakout board for the cost of these terminals, but it's close
[18:34:17] <cradek> does the cable have to be special or can you just use old scsi cables?
[18:34:42] <SWPadnos> you can use SCSI cables, but you probably want to use short ones
[18:34:45] <cradek> I guess for motor connections the wire would be way too small
[18:35:37] <SWPadnos> the wayback machine doesn't show anything after April of this year :(
[18:35:45] <SWPadnos> on the mesa site
[18:37:13] <jepler> This is G o o g l e's cache of
http://www.mesanet.com/parallelcardinfo.html as retrieved on Jul 24, 2007 17:54:15 GMT.
[18:37:30] <jepler> http://209.85.165.104/search?q=cache:QhtdDhOF1E4J:www.mesanet.com/parallelcardinfo.html
[18:37:42] <cradek> I canceled my order.
[18:38:01] <SWPadnos> well, it certainly does say "compatible with blah blah" there
[18:38:20] <SWPadnos> at least money is no object for this project
[18:39:36] <cradek> for me it's not really the money.
[18:39:55] <SWPadnos> it could be if you were ordering 5 boards and 10 terminal strips ;)
[18:40:08] <SWPadnos> but the principle is pretty shabby as well
[18:40:20] <alex_france> gotta run
[18:40:20] <jepler> see you alex_france
[18:40:20] <alex_france> see you guys
[18:40:20] <jepler> have fun
[18:40:21] <SWPadnos> have fun
[18:40:49] <cradek> I can't decide if this thing about the screws is deceptive, but at the very least it's incompetent
[18:41:28] <SWPadnos> they did respond with the part numbers for the motor connectors when I asked after the group buy
[18:41:42] <SWPadnos> and at least they're available at mouser/digikey
[18:42:13] <SWPadnos> but it would be nice if they (a) sold them and (b) let you know what they are ahead of time so you can decide if the overall cost is acceptable
[18:42:47] <SWPadnos> I'd be pissed if I thought I'd get screw terminals for the extra $10 and ended up having to spend an additional $50 (and wait for the connectors to arrive)
[18:43:08] <SWPadnos> so I guess I'm a little pissed ;)
[18:43:13] <cradek> well isn't that what happened?
[18:43:15] <cradek> yeah that.
[18:43:35] <SWPadnos> I guess it's time for a phone cal
[18:43:37] <SWPadnos> l
[18:43:38] <cradek> I thought I was paying the extra for screw terminals.
[18:43:55] <cradek> I didn't say why I canceled my order. I should have probably.
[18:43:57] <SWPadnos> yeah, or headers with plugs
[18:44:36] <LawrenceG> I got a 7130 board from mesa and they included the matching pins and molex plug for the motors
[18:44:47] <cradek> LawrenceG: I got one too, and they didn't
[18:44:49] <SWPadnos> taht was nice of them. how long ago was this?
[18:45:03] <SWPadnos> hmmm. I wonder if it's because we've gotten all our stuff in quantity?
[18:45:12] <SWPadnos> an OEM should have sources for those parts
[18:45:32] <LawrenceG> jan 26 2004... wow didnt think it was that longago
[18:45:53] <SWPadnos> though the 20% discount is far from sufficient to cover the cost of these connectors
[18:46:22] <cradek> SWPadnos: please let me know when you get some answers.
[18:46:41] <LawrenceG> it would have been nice to have pc drive connectors or something likethat in the board.... lots of those around free
[18:46:42] <SWPadnos> will do. I'm finishing an unrelated email, and will call once I'm done
[18:47:00] <SWPadnos> the 50-pin connectors are like SCSI
[18:47:32] <cradek> yeah the 50-pin things are no problem I think.
[18:47:34] <SWPadnos> it is too bad that they connected all 4 pins on the power headers though - you could use floppy connectors from the PC if the 12V pin had been left unconnected
[18:47:45] <LawrenceG> thats what I am using.... 50pin internal scsi cables approx 2' long.... they were not included
[18:47:45] <cradek> the other stuff is so relatively unusual that everyone is going to have to order it.
[18:47:56] <SWPadnos> (of course, you can snip the 12V wire as well)
[18:50:04] <LawrenceG> hey... on the new double rate pulsing stuff.... is there any reason not to make that the default config and have the old form as a backup for very slow cpu/slow pulserate boxes?
[18:50:46] <jepler> after some reports come in that it works, maybe
[18:51:15] <LawrenceG> Hi Jeff... nice work
[18:51:21] <jepler> thanks LawrenceG
[18:52:27] <LawrenceG> it makes a nice QC for incoming drives.... if they are spec'd for 4us pulse width, one now has a way to test them
[18:53:36] <jepler> on the machine where I was testing this, the scope showed that the smallest "1" times were more like 5000ns and still somewhat variable
[18:54:08] <jepler> (1GHz AMD "duron", 5 or 6 years old)
[18:54:24] <jepler> so you will be able to detect if they are really 10uS instead of 4uS
[18:54:36] <jepler> but maybe not detect if they're 5uS or 6uS instead of 4uS
[18:55:23] <skunkworks> jepler: explain the reset mask.. if the step pins are 2,4,6 - is the mask 84?
[18:56:14] <skunkworks> I mean 70
[18:56:20] <jepler> skunkworks: NO
[18:56:26] <jepler> er
[18:56:26] <jepler> sorry, capslock'd
[18:56:26] <skunkworks> ouch
[18:56:29] <skunkworks> ;)
[18:56:45] <jepler> in the first revision there was this business about reset mask
[18:56:46] <jepler> that's gone
[18:56:53] <skunkworks> ah - ok
[18:57:01] <jepler> now you 'setp parport.0.pin-NN-out-reset' to TRUE if it should be reset (i.e., is a step pin)
[18:57:36] <skunkworks> ok - is there a manpage on parport yet? I could not find it. (isn't in with the stepgen manpage)
[18:59:33] <jepler> http://linuxcnc.org/docs/devel/html/hal/drivers/
[18:59:53] <skunkworks> jepler: thank you
[19:00:02] <jepler> (or in the PDF documentation,
http://linuxcnc.org/docs/devel/EMC2_Integrator_Manual.pdf)
[19:00:13] <jepler> no, I don't know why the parport picture is broken in the HTML
[19:00:19] <jepler> I think fenn has volunteered to write a parport manpage, you should bug him about it
[19:00:56] <skunkworks> I don't want to scare him away again..
[19:01:32] <jepler> page 127 in the pdf
[19:06:28] <SWPadnos> gah. the weidmuller online catalog doesn't tell you what mates with the plug/header you're looking at
[19:17:48] <fenn> heh volunteering me are you
[19:18:45] <fenn> i was complaining, not volunteering! :) but i'll try
[19:19:50] <jepler> oh my mistake
[20:53:35] <skunkworks> um- I am having some odd behavior
[20:53:52] <SWPadnos> time to take your meds?
[20:53:59] <skunkworks> heh
[20:54:42] <cradek> SWPadnos: find anything from mesa?
[20:54:51] <SWPadnos> sort of
[20:54:55] <skunkworks> I have trunk as of last week. When I exit emc2 with the drives on - it plows the z into the table and x and y move randomly
[20:55:01] <SWPadnos> I can't find any connectors in stock, which is troubling
[20:55:06] <skunkworks> for a while - then stop
[20:55:11] <SWPadnos> they're the BL series, 3.5mm spacing, from Weidmuller
[20:55:17] <cradek> skunkworks: ouch
[20:55:23] <skunkworks> yah
[20:55:24] <SWPadnos> Peter will add the part numbers to the manual at some point
[20:55:28] <jepler> skunkworks: what interface? parport? pluto?
[20:55:37] <skunkworks> I guess normally I would shut off the drives first
[20:55:39] <skunkworks> axis
[20:55:43] <skunkworks> parport
[20:55:47] <jepler> parport stepper?
[20:55:51] <skunkworks> yes
[20:55:57] <cradek> ???
[20:56:00] <skunkworks> I did it twice
[20:56:21] <jepler> huh -- dunno how emc would continue issuing step pulses after it exited
[20:56:36] <cradek> have you checked with a real scope?
[20:56:49] <jepler> bbl .. quittin' time
[20:56:53] <cradek> woo
[20:56:57] <SWPadnos> oh crap
[20:56:58] <skunkworks> heh -if I turn the drives back on - it starts moving
[20:57:02] <SWPadnos> it's getting late again
[20:57:19] <SWPadnos> skunkworks, what if ou disconnect the drives from the PC?
[20:57:22] <SWPadnos> you
[20:57:43] <skunkworks> if I unplug the cable from the back of the computer - the drives stop
[20:58:07] <SWPadnos> but they're step/dir?
[20:58:12] <skunkworks> yes
[20:58:20] <SWPadnos> that makes no sense
[20:58:28] <skunkworks> something is coming out of the printer port
[20:58:30] <SWPadnos> not PWM / up/down?
[20:58:39] <skunkworks> step - dir
[20:58:57] <fenn> are you printing a file? :)
[20:59:06] <SWPadnos> well, I'd check to see what's coming out the printer port :)
[20:59:14] <skunkworks> heh - that should be disabled - isn't it?
[20:59:22] <SWPadnos> dunno - you tell us
[20:59:32] <fenn> it should be but once you idiot proof something..
[20:59:59] <skunkworks> this was a fresh - updated dapper install from the emc live cd
[21:00:30] <fenn> what's `lsmod | grep parport` say
[21:02:35] <skunkworks> parport 29640 2 ppdev,lp
[21:02:54] <fenn> slammin
[21:03:00] <skunkworks> thats good?
[21:03:12] <fenn> that's not supposed to be there, which is good because we figured out what went wrong
[21:03:18] <skunkworks> ah
[21:03:34] <SWPadnos> how about ps ax | grep -i cups
[21:04:15] <skunkworks> crap - let me see if I can get this machineon the internet
[21:05:00] <Guest666> wrong machine ;)
[21:05:39] <SWPadnos> how about ps ax | grep -i cups
[21:06:16] <Guest666> working on it - I don't want to have to copy and paste
[21:06:23] <Guest666> or type it in I mean;)
[21:06:38] <fenn> i prefer to draw on the touchscreen with my nose
[21:06:41] <SWPadnos> oh come on - it's only ~20 characters
[21:07:03] <SWPadnos> I can dcc it to you if you like :)
[21:07:08] <Guest666> 3 lines
[21:07:33] <SWPadnos> ok, if you have anything other than a line with "grep -i cups" on it, then cups is probably running
[21:07:54] <fenn> something like /usr/sbin/cupsd
[21:07:54] <Guest666> yes - 2 lines above it
[21:08:01] <SWPadnos> which is bad - that'll regularly try to make sure the printing daemons are running
[21:08:09] <SWPadnos> yeah, or acupsys or something
[21:09:45] <Guest666> yes - /usr/sbin/cupsd
[21:10:00] <Guest666> this stupid network card isn't activatin
[21:11:03] <Guest666> plus a line that has gnome-cups-icon --sm-client-id default3
[21:11:31] <Guest666> should i reboot?
[21:11:57] <SWPadnos> is this the first time you've left the PC on overnight before running the machine?
[21:12:01] <SWPadnos> (did you?)
[21:12:08] <Guest666> just turned it on
[21:12:12] <SWPadnos> hmmm
[21:12:35] <SWPadnos> there will be a program called either "printing" or "cups" in /etc/init.d
[21:12:57] <SWPadnos> whichever one it is, run `sudo /etc/init.d/cups stop` (or printing)
[21:13:21] <SWPadnos> you'll also want to turn it off so it doesn't run the next time you start the machine
[21:13:26] <SWPadnos> s/machine/PC/
[21:13:52] <fenn> there was also a hack to modprobe.conf that rendered the parport module benign
[21:14:18] <fenn> er. one of those files
[21:14:24] <Guest666> there is a cupsys
[21:14:36] <SWPadnos> I don't know if that works for any attempt to load the module, or just when it's initially detected at startup (or hot-plug, as the case may be)
[21:14:42] <SWPadnos> ok - that's the one
[21:14:54] <Guest666> let me reboot - maybe it is just a fluke - then hopefully the network card will work
[21:17:17] <SWPadnos> don't reboot
[21:17:31] <SWPadnos> it's much more helpful to see what the problem is and fix it
[21:17:49] <SWPadnos> you can start and stop services easily with Linux, rebooting will only hide the real problem
[21:18:11] <Guest666> sorry :(
[21:18:26] <Guest666> lets hope it still does it
[21:18:29] <SWPadnos> heh - it's the common response, but it isn't the best way to debug :)
[21:19:02] <Guest666> I am not going to be fast at all if I cannot copy and paste here
[21:19:16] <SWPadnos> heh - ok, it's good to get the net connection working
[21:22:26] <Guest666> duh - disabled onboard nic - plugged in card
[21:23:16] <Guest666> Guest666 is now known as skunkworks
[21:23:56] <skunkworks> let see if it still does it
[21:24:46] <SWPadnos> see if it does anything before you run EMC, with the drives enabled
[21:24:59] <skunkworks> crap
[21:25:04] <SWPadnos> he
[21:25:05] <SWPadnos> h
[21:25:08] <skunkworks> well - it does it on exit
[21:25:13] <skunkworks> just like before
[21:25:43] <skunkemc> 4102 ? Ss 0:00 /usr/sbin/cupsd
[21:25:44] <skunkemc> 4459 ? Ss 0:00 gnome-cups-icon --sm-client-id default3
[21:25:44] <skunkemc> 5322 pts/0 D+ 0:00 grep -i cups
[21:26:14] <skunkworks> do you want me to reboot and try the drives befor emc starts?
[21:26:54] <skunkemc> sam@sam:~/emc2-trunk$ lsmod | grep parport
[21:26:54] <skunkemc> parport 29640 2 ppdev,lp
[21:29:51] <fenn> skunkemc: try this: echo alias parport off >> /etc/modules.conf
[21:30:33] <fenn> um, and that wont do anything until you reboot
[21:32:21] <skunkworks> I just tried the xyza config just to be sure it wasn't something I did with the config - it does the same thing
[21:32:32] <skunkworks> fenn: so I run that command then reboot?
[21:33:23] <fenn> skunkworks: that will prevent the parport module from being loaded when the machine boots up
[21:33:29] <fenn> you can remove the module right now with rmmod parport
[21:33:52] <fenn> we need to figure out how to prevent this for other users though
[21:34:20] <skunkemc> bash: /etc/modules.con: Permission denied
[21:34:28] <skunkworks> that was sudo
[21:35:03] <fenn> try this: echo 'alias parport off' | sudo tee -a /etc/modules.conf
[21:35:15] <fenn> or edit it by hand
[21:35:51] <skunkemc> alias parport off
[21:36:04] <skunkworks> reboot?
[21:36:59] <fenn> sure
[21:39:28] <skunkworks> fenn: it is moving it before emc starts.
[21:40:11] <fenn> are there any other lines in modules.conf that say parport?
[21:42:19] <skunkworks> etc/modules.conf only has 'alias parport off' in it
[21:46:13] <fenn> does lsmod still show parport?
[21:47:09] <skunkemc> parport 29640 2 ppdev,lp
[21:52:52] <fenn> there was a thread on the mailing list with jon elson having his machine go wacko at midnight.. care to help me look for it?
[21:53:41] <skunkworks> sure - but I am almost positive that it was fixed. but let me look
[21:56:15] <fenn> skunkworks: do you have a file /etc/modprobe.d/emc2 ?
[21:56:23] <fenn> and what does it say
[21:57:15] <fenn> mine says #install parport_pc /bin/true which i presume would return 'true' after doing nothing (if it were uncommented)
[21:57:31] <skunkemc> install parport_pc /bin/true
[22:01:41] <skunkworks> fenn:
http://sourceforge.net/mailarchive/message.php?msg_id=42E906AF.6010300%40pico-systems.com
[22:01:44] <fenn> well does the temporary solution work at least? ( sudo rmmod parport)
[22:02:38] <fenn> and killall cupsd
[22:02:43] <skunkemc> sam@sam:~$ sudo rmmod parport
[22:02:43] <skunkemc> Password:
[22:02:43] <skunkemc> ERROR: Module parport is in use by ppdev,lp
[22:02:54] <fenn> and rmmod ppdev and lp
[22:02:57] <skunkworks> heh
[22:03:00] <fenn> KILL
[22:06:18] <skunkworks> hmm - did all that and the machine still moves
[22:07:09] <fenn> oh noes
[22:07:18] <fenn> well i dont know what's going on then
[22:08:37] <skunkemc> http://www.pastebin.ca/672831kill
[22:08:56] <skunkemc> http://www.pastebin.ca/672831
[22:09:03] <skunkworks> look right?
[22:09:21] <fenn> yes
[22:09:38] <fenn> lsmod and see if parport is still there :)
[22:09:55] <skunkemc> sam@sam:~$ lsmod | grep parport
[22:09:55] <skunkemc> sam@sam:~$
[22:10:17] <fenn> and the motors are moving?
[22:10:20] <skunkworks> yes
[22:10:41] <fenn> if you touch the ground on the parport cable does it stop?
[22:10:56] <skunkworks> if I start emc - they stop
[22:11:20] <fenn> yeah but if its floating or something and then emc drives the port, it will swamp out any noise on the lines
[22:11:50] <skunkworks> if I unplug the cable from the back of the comuter they stop
[22:12:09] <skunkworks> computere
[22:12:10] <skunkworks> jeez
[22:12:23] <fenn> um.. got a scope?
[22:12:37] <skunkworks> no - not here.
[22:12:46] <fenn> headphones?
[22:12:57] <fenn> well, i guess you can hear the motors well enough
[22:13:26] <skunkworks> I can see the cutter dive into the table.. I guess that is why you hook up the drive enables... ;)
[22:13:47] <fenn> should remove the cutter before testing
[22:14:03] <skunkworks> now you tell me :)
[22:14:42] <skunkworks> yep - the second I exit emc - z moves at a good clip down - and y moves a bit +
[22:15:04] <skunkworks> x I mean - don't know about
[22:15:06] <skunkworks> y
[22:50:57] <jepler> when emc exits, the parport is not changed from out mode, so it should stay driven by the last values
[22:51:23] <skunkworks> odd.
[22:51:38] <jepler> in the case of a stepper machine, that would be no edges on the step pin so it would stay where it is
[22:53:08] <skunkworks> That is what I understand.. But the printer port works just fine while emc is running. when emc isn't running - z moves at a good clip - y moves a bit slower.
[22:53:31] <jepler> theory and practice are the same, in theory...
[22:54:02] <skunkworks> heh
[22:54:23] <skunkworks> might just be this hardware.
[22:57:15] <jepler> you gave the impression that this was new behavior ..
[22:57:43] <skunkworks> new with this computer. (just noticed it today)
[22:58:36] <skunkworks> the computer was setup last thur or fridya
[22:58:39] <skunkworks> friday
[22:59:39] <jepler> same version of emc as before?
[23:00:59] <skunkworks> I had built head on it.
[23:01:17] <skunkworks> It is outputting pulses as the computer boots.
[23:01:49] <jepler> before the ubuntu splash screen? not much emc can do about that ..
[23:01:50] <skunkworks> I don't know at what point it starts - but as the computer boots.
[23:02:30] <skunkworks> no - I am pretty sure it is after but I will check at the next boot
[23:04:30] <skunkworks> jepler: when is the new toy coming?
[23:09:06] <jepler> skunkworks: dunno
[23:09:36] <jepler> skunkworks: supposedly tomorrow but it's still in lenexa, ks according to tracking
[23:09:48] <jepler> I'd expect it to have left ks today if it was going to be delivered tomorrow
[23:13:04] <skunkworks> sometimes ups misses scans - so it may just show up
[23:14:57] <jepler> it's fedex, but yeah that is my hope
[23:22:22] <skunkworks> jepler: I only have to setup the step pins to reset - corect?
[23:25:00] <jepler> skunkworks: you have to: set stepspace to 0 and doublestep to TRUE for each generator. set the -out-reset for each parport step pin to TRUE. addf stepgen.0.reset to base-thread at the end.
[23:25:08] <jepler> er, 'doublefreq' not 'doublestep'
[23:25:35] <jepler> oh, and set parport.0.reset-time to the minimum step HIGH time for your drivers
[23:36:29] <skunkworks> jepler: should the calculation for maximum velocity correct? (stepgen error)
[23:36:55] <jepler> skunkworks: I hope it is
[23:37:41] <skunkworks> I am getting a vel of 17200 is to high. (period set to 30000 and reset-time is set to 2000)
[23:38:06] <jepler> pastebin me 'halcmd show param stepgen.0'
[23:39:16] <skunkworks> crap - what is the command to be able to do this?
[23:39:22] <skunkworks> envorment something
[23:39:30] <jepler> ". scripts/emc-environment" ?
[23:39:37] <skunkworks> yes
[23:40:51] <jepler> I get this for BASE_PERIOD = 50000: STEPGEN: The maximum possible frequency is 20000 steps/second
[23:41:14] <jepler> it's what I expect -- units 50000ns Hz -> 20000
[23:42:09] <skunkworks> shit - hold on I didn't set stepspace to 0
[23:42:13] <jepler> that would do it
[23:43:01] <jepler> I'm thinking that either doublefreq should override stepspace, or stepspace=0 would indicate doublefreq (and get rid of the separate parameter doublefreq)
[23:47:05] <jepler> wb sk
[23:47:23] <fenn> what's the current default stepspace?
[23:47:54] <tfmacz> jepler: Hi Jeff, got a couple questions about I/O in axis???
[23:47:57] <jepler> "smallest nonzero value"
[23:48:12] <fenn> because stepspace 0 makes sense for a pulse-like behavior, but not if it messes up existing configs
[23:48:15] <jepler> tfmacz: best way to get questions is to toss 'em out there and see if anybody asks
[23:48:17] <jepler> er, answers
[23:50:08] <fenn> usually the answer will be another question
[23:50:11] <tfmacz> ON the AXIS screen the "E-Stop" button (F1) is associated with a hal thing "iocontrol.0.user-enable-out"
[23:50:57] <tfmacz> Is there an io thing for the the (F2) button?
[23:52:15] <tfmacz> I have the Realworld E-stop button wired to the "iocontrol.0.user-enable-out" If I push and pull the big red e-stop button the one on the axis screen follows.
[23:52:59] <jepler> tfmacz: axis.0.amp-enable-out goes TRUE when the machine is in 'on' mode but not when in estop or machine off mode
[23:53:12] <fenn> i think iocontrol.0.user-enable-out should be enabled when the machine is "on" but that's not what the documentation says
[23:53:24] <tfmacz> I want tho be able to "enable/disable" (F2) from the main power stop/start buttons and need to know how to do this/??
[23:53:56] <jepler> tfmacz: if you want to make a hardware button "do something" that is a user interface task, that's generally a part of "halui".
[23:54:32] <fenn> oh hey - halui.machine.is-on
[23:54:33] <jepler> tfmacz: the pins halui.machine.off and halui.machine.on are like the F2 key in axis
[23:55:17] <SWPadnos> I wouldn't use halui for a stop button (even not calling it estop) - a button can be directly tied to realtime "estop-latch" component in HAL
[23:55:20] <jepler> tfmacz: yes, that too
[23:55:28] <SWPadnos> unless it's meant for "program stop"
[23:56:40] <fenn> * fenn wonders where this halui thing came frmo
[23:56:40] <jepler> asserting halui.machine.off for a moment is like pressing F2 when the "machine on" button is already pressed in, and asserting halui.machine.on for a moment is like pressing F2 when the "machine on" button is popped out
[23:57:38] <jepler> and yes, halui is not real-time so is not the right choice for estop
[23:57:51] <tfmacz> I have to push the "start" button on the controller cabinet, then (F2) on the keyboard to enable emc. how can I "wire" an input into hal so I don;t have to F2???
[23:58:18] <SWPadnos> ok - that's a halui task :)
[23:58:58] <jepler> you would connect parport.0.pin-NN-in (or whatever) to halui.machine.on .. then pressing that button for a moment would be like pressing F2 when the "machine on" button is popped out
[23:59:48] <tfmacz> Also I would like to bring out(in) the run, pause and stop buttons on the axis display to real buttons on the machine.