Back
[00:08:13] <LawrenceG> yup
[02:41:02] <fenn> how about a stepgen parameter "headroom" that is multiplied by the max-* pins to get the real values, seems simple enough and wont bloat anything
[02:41:47] <fenn> you could do the multiplication in C so there wouldnt be a need for multiplying values in .ini/hal commands
[02:43:48] <SWPadnos> we considered that before, and discarded the idea for some reason
[02:44:12] <skunkworks> it could default to 1.1 or something
[02:44:26] <skunkworks> wow dead tonight
[02:44:54] <SWPadnos> possibly because it's unclear as to what the headroom is - is it percent (0.1 = 10% over), scale factor (1.1 = 10% over), additive (10000 = 10000 steps/sec more) ...
[02:50:28] <skunkworks> fenn: how did you like marriss reply
[02:50:43] <skunkworks> mariss
[02:51:20] <fenn> * fenn looks
[02:51:33] <fenn> swp that's what manpages are for
[02:51:51] <SWPadnos> heh - if people would read the manuals, we wouldn't get as many questions
[02:52:23] <skunkworks> whatever - I can read manpages and still not figure out what is going on.
[02:55:05] <skunkworks> I wonder how the jeplers little mill did.
[02:55:19] <SWPadnos> you could ask the jepler :)
[02:55:28] <skunkworks> I figured he is in bed :)
[02:55:33] <skunkworks> it is past 9
[02:55:38] <SWPadnos> oh, right
[02:56:21] <fenn> i think scale factor makes the most sense and is consistent with other hal conventions
[02:57:01] <SWPadnos> scale is used to change the command input or results in just about every other place
[02:57:29] <SWPadnos> (ie, DAC scale sets the range or multiplies the hal pin by some scale)
[02:58:02] <jepler> skunkworks: just finished the blog for tonight's work ..
http://axis.unpy.net/index.cgi/01188441458
[02:58:13] <skunkworks> jepler: Hi :)
[02:58:25] <jepler> hi skunkworks
[02:58:27] <skunkworks> jeeze - I had just looked
[02:59:07] <jepler> now .. goodnight
[03:00:34] <skunkworks> nice - thanks for the update. BTW the emc2 splash screen isn't meant for milling ;)
[03:00:43] <skunkworks> Night
[03:02:19] <fenn> i think mariss' "never more than 10% of the rated power gets delivered to the load" is a red herring
[03:04:25] <SWPadnos> I noticed he forgot to mention that servos generally have a lot of dynamic torque available
[03:05:04] <SWPadnos> and that the load is a lot more constant than he alluded to (by his own analysis in an email on the gecko list)
[03:05:34] <SWPadnos> also that you still need torque to accel and decel, even at high speeds
[03:05:37] <fenn> the reason i think that is because you need excess voltage to run a stepper at max speed, and the rest of the time that power goes unused
[03:05:48] <SWPadnos> or wasted as heat
[03:06:18] <fenn> well hopefully you arent using a linear driver :)
[03:06:25] <SWPadnos> heh
[03:07:36] <fenn> the iron-losses thing is interesting to me, i dont think he says anything about it
[03:08:03] <fenn> the more poles you add to an ac motor the more magnetic field change per second per cm^3
[03:08:08] <SWPadnos> well, that's part of (or all of - I'm not sure) what causes the torque to fall off at high speeds
[03:08:13] <skunkworks> this makes me smile 72ipm rapids and no stalls. SCALE=8000, BASE_PERIOD=100000, doublestep
[03:08:49] <skunkworks> yes - 100000 input scale :)
[03:09:02] <SWPadnos> BASE_PERIOD
[03:09:06] <fenn> not all of - most of what does it in steppers is winding inductance vs voltage
[03:09:08] <skunkworks> oops yes
[03:09:16] <SWPadnos> hmmm. I just had an idea for another stepping improvement
[03:09:46] <SWPadnos> one problem double-step has is that the CPU busy-waits for the duration of the step (once other thread processing is done)
[03:09:49] <fenn> so you're not dissipating anything, the motor mostly just has higher impedance at higher frequency
[03:10:21] <fenn> any motor does - the "servos have a perfectly flat torque curve" is a myth and only true in relation to steppers
[03:10:31] <SWPadnos> so if you have something with 2us or 5us steplens, you end up burning a lot of CPU cycles waiting
[03:10:35] <fenn> s/relation/comparison/
[03:11:15] <fenn> how does the overall cpu usage compare vs using twice as many threads?
[03:11:24] <fenn> guess that depends on busy wait time
[03:11:25] <SWPadnos> and consequently you can't set BASE_PERIOD very low (which isn't necessary for step rate, but is for step frequency resolution)
[03:12:19] <SWPadnos> so, I think it's a 6-line change or so to make parport.reset capable of waiting more than one thread period, and only busy-waiting during the last wait time, or if the remaining wait time is short enough
[03:12:24] <fenn> jmk was talking earlier about "request an interrupt in xx ns" - could that be used to get an arbitrary frequency?
[03:12:52] <SWPadnos> yes, but it would totally destroy timing of slower threads (or get kind of complex making them work right)
[03:13:03] <fenn> so instead of BASE_PERIOD you'd have some parameter min_step_resolution
[03:13:17] <SWPadnos> also, you have multiple axes - what if you need steps on two pins that are only 0.3 uS apart?
[03:13:25] <fenn> hm that's tough
[03:13:43] <SWPadnos> yeah - the multi-rate thing is great for one axis, but it falls apart pretty quickly for >1
[03:14:35] <SWPadnos> anyway - the double-step change is to add a parameter which is something like "max_wait_time", and add a variable to keep track of elapsed time across thread executions
[03:14:49] <SWPadnos> (kind of how stepgen figures out when it's time fora step to occur)
[03:15:04] <SWPadnos> if the wait time is > period, subtract period and finish the thread
[03:15:07] <fenn> you could have a non-busy wait period where you "catch' any interrupts in approximately the same time period and chop the busy-wait into hunks
[03:15:14] <SWPadnos> if wait_time is < max_wait_time, then busy-wait
[03:15:22] <fenn> or do time slicing in the busy-wait and check for interrupts
[03:15:32] <fenn> i think that's called trapping
[03:15:37] <SWPadnos> actually, you could use the period/4 trick it has now for reset-time
[03:16:10] <SWPadnos> you could do that for multi-rate stepping, but remember it still takes 1 us or so to actually write to the port
[03:16:28] <SWPadnos> which is between 500 and 3000 CPU cycles these days
[03:16:32] <fenn> then you arent gonna get a better resolution than 1us
[03:16:37] <SWPadnos> right
[03:16:48] <fenn> that sounds fine to me :)
[03:17:47] <SWPadnos> well, remember that there is also time to set up the timer for the next interval, all sorts of magic numbers regarding when to actually do individual writes vs. combined writes, and keeping track of when to run the slow threads
[03:18:15] <SWPadnos> it isn't simple, even in a microcontroller. I thought about doing that with a uC, and gave up :)
[03:18:21] <fenn> woah what's this about combined writes? i dont think you'd have that with an arbitrary period
[03:19:00] <SWPadnos> if two channels need a step within some time period of each other, you might as well output both in one port write due to output timing resolution
[03:19:13] <fenn> it throws approx 1us jitter into the signal whether you do two at once or delay one until the next port write
[03:19:36] <SWPadnos> sure - you'd always have to delay, since you need to obey minimum timing (in general)
[03:19:37] <fenn> 'epsilon' vs uh.. whatever the opposite of epsilon is
[03:19:49] <SWPadnos> -epsilon
[03:19:59] <SWPadnos> 1/epsilon
[03:19:59] <fenn> ~epsiolon
[03:20:06] <SWPadnos> del cross B
[03:20:23] <fenn> silly mathematicians.. -1 should not mean inverse of a function
[03:21:02] <SWPadnos> I guess the opposite of epsilon (error) would be accuracy, but I;m not sure there's a common symbol for that
[03:21:12] <fenn> here's what i meant by epsilon
http://www.freesteel.co.uk/wpblog/2007/05/finding-points-in-triangles/
[03:21:28] <fenn> its basically whether you snap-to grid points or kick things off the edges by some amount
[03:22:27] <fenn> so if two write events are within N ns of each other, you have two options in how to deal with it
[03:22:37] <fenn> delay one or group them together
[03:22:55] <SWPadnos> those are both "grouping them together"
[03:23:05] <SWPadnos> you can either delay one, or advance the other
[03:23:21] <fenn> right
[03:23:27] <SWPadnos> advancing is better in that you don't busy-wait for the next time interval
[03:23:39] <SWPadnos> delaying is better because most timing settings are minimums
[03:23:42] <fenn> but having the two events separated in time seems less "grouped together" than having two separate pulses
[03:23:55] <fenn> er
[03:23:59] <SWPadnos> year -what?
[03:24:03] <SWPadnos> yeah
[03:24:04] <fenn> said that wrong
[03:24:09] <SWPadnos> phew
[03:24:19] <fenn> having the two events at the same time seems less "grouped together" than having two separate pulses
[03:24:31] <fenn> shit i messed up again
[03:24:58] <fenn> * fenn abandons the conversation
[03:25:04] <SWPadnos> ko, you're saying that when you calculate the next time events, just figure out whether you'll be able to group some together because they're too close
[03:25:23] <SWPadnos> so there's no extra busy-waiting
[03:25:54] <fenn> yeah i guess that's better. there's no advantage to separating them
[03:26:03] <SWPadnos> anyway - dropping it is good, because it is a real bitch to get to work, unless you actually have independent timing sources and non-sequential execution
[03:26:04] <SWPadnos> (like an FPGA)
[03:27:10] <SWPadnos> there will always be some stupid shit (like beat frequencies) that needs even more stupid and complex code to deal with when two or more asynchronous things are being done by one synchronous processor
[03:28:16] <fenn> beat frequencies? you mean on purpose, or its just something that happens and makes the code harder
[03:29:27] <SWPadnos> makes the code harder
[03:29:48] <SWPadnos> move from 0,0 to 1,1.0001 F10
[03:30:10] <SWPadnos> you now need just slightly less time between pulses on Y
[03:30:20] <SWPadnos> they get totally out of sync, slowly
[03:30:57] <fenn> then there would be a jump when you switch from combined writes to individual writes
[03:31:00] <SWPadnos> you may need a separate timing event for each step on axis involved (for a while, then they'll kind of synchronize, then they'll get out of sync ...)
[03:31:05] <SWPadnos> yep
[03:31:15] <SWPadnos> as I said, it'as a real PITA, and not likely to be worth the trouble
[03:31:31] <fenn> if you never did combined writes (separate the two writes in time) there wouldnt be a jump
[03:31:33] <SWPadnos> I think I read a paper in the last couple of years that proves that, actually :)
[03:31:49] <SWPadnos> but there will always be either combined writes or missed deadlines
[03:32:11] <fenn> only if your timing requirements are way strict
[03:32:22] <SWPadnos> if you need two steps (on different axes) 17 ns apart, they'll either be at the same time or they'll be ~1 us apart
[03:32:48] <SWPadnos> and then there are the problems when you add in multiple port writes (the parport is on 3 addresses, remember?)
[03:32:52] <fenn> for a milling machine type application, being 1us apart makes no difference
[03:33:22] <SWPadnos> it does screw up timing though. the second write acts like a busy-wait loop
[03:33:30] <fenn> but having a sudden jump in the timing will effect finish
[03:34:01] <fenn> a busy wait for each axis isnt impossible
[03:34:09] <SWPadnos> if you have 9 axes and you don't actively combine writes, you may spend 8 us waiting for writes to the same port, even if the events were all supposed to be within 1 us of each other
[03:34:15] <fenn> 1us per axis per period right?
[03:34:39] <SWPadnos> probably right
[03:35:00] <SWPadnos> direction changes could screw that up, but they shouldn't happen at the same time as steps anyway
[03:35:02] <fenn> for your hypothetical 1us paraport write time, which i have yet to see any real data for
[03:35:59] <SWPadnos> look anywhere for the data. everyone says it's somewhere between 500 us (I think Art said this once) and ~1.2 us (Jon Elson did lots of testing, and I think the 1.2 number was in there)
[03:36:20] <fenn> * fenn gallops in all directions
[03:37:39] <cradek> that seems trivially easy to measure (on a particular machine)
[03:37:59] <cradek> hmm I think jeff was tired when writing that - some doesn't quite make sense
[03:38:04] <SWPadnos> yep - write a HAL module (or whatever) that toggles the prt a few hundred thousand times
[03:38:09] <fenn> heh "parport write time microseconds" brings up the recent doublestep blog entry
[03:38:15] <SWPadnos> "deeper on the right than on the right"
[03:38:23] <cradek> yeah
[03:38:36] <SWPadnos> http://www.lvr.com/jansfaq.htm
[03:38:51] <SWPadnos> first question in the speed section (search for microsecond)
[03:39:44] <fenn> wow isa is 1.3MHz - that explains it
[03:40:21] <SWPadnos> ISA ran at 4.77 MHz, then 8 Mz, but there may have been address setup cycles thrown in
[03:40:21] <cradek> yeah you can't expect that to run at the full 4.77 MHz!
[03:42:04] <fenn> hmm i wonder if you could use EPP to send step bursts :D
[03:42:17] <SWPadnos> I also spoke to an engineer from SMSC (I think), and complained about parallel port timing
[03:42:20] <cradek> or a 16550
[03:42:25] <cradek> (kidding)
[03:42:42] <cradek> sorry, I ought to go to bed and stop being destructive of the conversation
[03:42:42] <SWPadnos> he was interested because strangely enough, he had a machine that he was trying to get some old BDI to work on :)
[03:42:47] <cradek> goodnight :-)
[03:42:55] <SWPadnos> nah - it's a degenerative topic anyway
[03:42:57] <SWPadnos> night
[03:43:10] <fenn> emc-devel: degenerate constructivism
[03:43:28] <SWPadnos> I like to thikn of it as constructive degenerativism
[13:57:17] <jepler> comments on
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ContributedComponents ?
[13:57:41] <SWPadnos> excellent idea
[14:04:28] <jepler> specifically, does the section "Legal" look OK? I want to head off the biggest problem with user submissions, that they do not clearly permit use and distribution.
[14:04:45] <jepler> or maybe I should say use, modification, and distribution
[14:04:50] <jepler> but I don't want to require a particular license..
[14:05:12] <jepler> * jepler adds "modification"
[14:06:51] <cradek> free according to the DFSGs?
[14:07:13] <cradek> then you can just link to their big list of acceptable licenses
[14:07:38] <cradek> (I agree this is the hardest part about hosting users' contributions)
[14:09:26] <jepler> Please clearly label each submission with its license, using MODULE_LICENSE("..."); for components compatible with EMC2.1 and later, or module "..."; for components compatible with EMC2.2 and later. Submissions must be released under a license that meets [Debian Free Software Guidelines]. Those without a license statement, or with a license that does not permit use, modification and redistribution, will be removed. GPL and LGPL are two examples of
[14:09:55] <SWPadnos> you can also say something to the effect that uploading something to the wiki explicitly grants permission for us to license it under the GPL or LGPL
[14:10:55] <cradek> why?
[14:11:28] <SWPadnos> err - so we could incorporate modules into EMC under GPL or LGPL?
[14:12:16] <SWPadnos> rather than "we're going to take them down", it's "if you don't specify, then we can stick GPL/LGPL on them"
[14:15:20] <jepler> I feel uncomfortable saying "by uploading a file, you place it under such-and-such a license". A person who can write a .comp file should be able to handle adding the line 'license "GPL";' to it.
[14:16:11] <cradek> how about: Please feel free to write components with any license you choose. However, to post them on linuxcnc.org, they must be as free or freer than EMC2 itself. This means approximately that they should have a license accepted under the [DFSG]. Please specify the license in your file using MODULE_LICENSE...
[14:17:31] <cradek> that avoids "will be removed", "grants us special powers", etc. It is a statement of what is allowed, nothing more.
[14:18:03] <cradek> maybe scratch "or freer than"
[14:18:16] <cradek> but for instance I don't see why we would decline to host a PD module
[14:18:31] <cradek> we can (obviously) distribute that under the GPL if we want
[14:20:24] <jepler> Clearly label each submission with its license. Submissions hosted on linuxcnc.org must be as free or freer than emc2. This means approximately that they should have a license accepted under the [
http://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines Debian Free Software Guidelines]. GPL and LGPL are two examples of permitted licenses. "Free For Noncommercial Use" is an example of a non-permitted license.
[14:20:30] <jepler> For ".comp" components, use <tt>MODULE_LICENSE("...");</tt> for components compatible with EMC2.1 and later, or <tt>module "...";</tt> for components compatible with EMC2.2 and later. For all types of file, include the standard license block indicated by the license being used.
[14:21:01] <cradek> that looks good to me
[14:21:04] <jepler> strike "should" from "they should have a license"
[14:21:28] <cradek> right
[14:29:27] <jepler> now we just need some submissions to that page
[14:38:12] <SWPadnos> heh
[19:00:44] <SWPadnos> has anyone tried reading/writing the parport with words or dwords (inw/outw, not sure if there's a 32-bit equivalent)?
[19:01:06] <jepler> inl/outl
[19:01:13] <SWPadnos> well, that would make sense :)
[19:09:58] <jepler> cradek: the "check for epp communication right after loading firmware" behavior doesn't seem to be in emc2.1.
[19:10:11] <cradek> I was wondering that too
[19:10:54] <alex_joni> hi all
[19:11:02] <SWPadnos> hi Alex
[19:11:09] <alex_joni> hi
[19:11:22] <cradek> hi
[19:15:54] <jepler> the more advanced EPP error clearing code is also not in 2.1.
[19:16:27] <cradek> maybe he should try trunk?
[19:16:49] <alex_joni> I'm sure he can handle
[19:16:51] <cradek> seems very capable of that
[19:16:55] <alex_joni> if he runs his own rtai
[19:24:34] <jepler> eek pluto doesn't reserve its ports!
[19:24:40] <jepler> * jepler hangs his head in shame
[19:24:57] <cradek> harrgh!
[19:31:54] <SWPadnos> though it's only about a 10-line fix to counter to give it up/down counting capability
[19:32:27] <SWPadnos> add a bit param, and check it ro decide whether to count++ or count--
[19:32:31] <SWPadnos> s/ro/to/
[19:32:54] <cradek> maybe someone will want to put that in trunk
[19:33:16] <jepler> in TRUNK counter is deprecated and encoder has a counter mode..
[19:33:22] <SWPadnos> ok
[19:33:27] <cradek> maybe someone will want to put that in encoder in trunk
[19:33:46] <SWPadnos> I can add that when I have an EMC2 dev machine running again (should be next week)
[19:33:50] <SWPadnos> if I remember
[19:34:03] <SWPadnos> skunkworks_, can you add that to your phone reminder list? :)
[19:38:37] <skunkworks_> yes :)
[19:40:18] <alex_joni> see you guys later
[20:08:51] <jepler> bye alex_joni
[20:31:23] <skunkworks_> SWPadnos: there woudn't be a way to atleast delete that out of the logger - pretty please?
[20:32:05] <SWPadnos> I can manually edit it out, but I may need to wait for the end of the day (so the file isn't open by the logger)
[20:32:26] <cradek> SWPadnos: just kill the logger? wouldn't want google to pick it up.
[20:32:47] <SWPadnos> I can probably do that, but I think only Alex can restart it
[20:32:54] <SWPadnos> one sec
[20:33:42] <SWPadnos> nope - the logger isn't running under the emc board logi
[20:33:43] <SWPadnos> n
[20:34:11] <SWPadnos> what's the format for robots.txt? I can do that until the log can be edited
[20:34:51] <jepler> killing the logger and editing it right away sounds good to me
[20:34:56] <jepler> chmod 000 todays-log would also work
[20:35:05] <cradek> true (even if the logger keeps it open)
[20:35:07] <cradek> good idea
[20:35:33] <SWPadnos> I can't see the logger processes under the emcboard login - I think Alex started them
[20:35:41] <jepler> yes, the logger has it open so it can continue to write to the file
[20:35:43] <SWPadnos> so I can't kill them
[20:35:50] <SWPadnos> and I'm not root, so I can't chmod
[20:35:56] <jepler> oh, hm
[20:36:01] <SWPadnos> (at least, not someone else's files)
[20:36:11] <SWPadnos> that's the downside to hosting ...
[20:36:13] <cradek> can you write to the directory?
[20:36:34] <SWPadnos> I think so
[20:36:47] <cradek> I think you could just copy the log somewhere, then delete it
[20:37:28] <cradek> hard to say without knowing how the logger works
[20:38:10] <skunkworks_> I really apreciate this.
[20:39:01] <skunkworks_> appreciate even
[20:39:55] <SWPadnos> ko, I think I made an appropriate robots.txt:
[20:39:57] <SWPadnos> User-agent: *
[20:39:58] <SWPadnos> Disallow: 2007-8-30*
[20:40:26] <SWPadnos> oops - typo... fixed
[20:40:33] <cradek> 08
[20:40:45] <SWPadnos> yep
[20:42:21] <SWPadnos> I'm not sure what would happen if I edit the log file while the logger is using it
[20:42:32] <SWPadnos> stick another reminder in your phone, will you? :)
[20:42:35] <cradek> it'll probably work fine
[20:43:10] <cradek> Failed to alloc shared memory (434c522b 32772 47768) !
[20:43:24] <cradek> I can't run sim_cl after cmorley's changes
[20:43:29] <SWPadnos> oops
[20:43:32] <cradek> jepler: what's the trick to removing the shm stuff?
[20:47:56] <jepler> ipcrm -M <magic hex number>
[20:48:15] <cradek> hm that still doesn't fix it
[22:31:34] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[23:57:47] <jepler> and debuting at #5 on a google search for 'zenbot cnc': my blog entry
[23:58:12] <jepler> (not much surprise that it's ranked pretty high once it appears, but it's a surprise that google only lags 1 or 2 days finding new entries on my boring blog..)
[23:59:43] <skunkworks> when is the circuit board mill going to comence?
[23:59:49] <skunkworks> commence