Back
[03:04:00] <cradek> if I'd export motion type to hal (g0 vs g1) I wonder if that would make a really simple way to do rasterization
[03:04:23] <cradek> (G0 and G1F9999 have the same feed rate)
[03:04:45] <cradek> if the segments are short you'd need pretty high acceleration, but I think these kinds of heads would be pretty light wouldn't they?
[03:05:14] <SWPadnos> that should have equivalent timing to M62/M63
[03:05:21] <SWPadnos> ie, at servo period rate
[03:05:25] <cradek> yes
[03:05:48] <cradek> not fast enough for a fast machine I guess
[03:05:53] <SWPadnos> so it should be equivalent, and the ~1ms delays are apparently problematic
[03:06:21] <cradek> a raster line (at encoder/step resolution?) in a mesa card is sure they way to go
[03:06:45] <cradek> or for software stepgen, hack it into stepgen and clock out according to steps at the base thread speed
[03:07:12] <SWPadnos> actually, a mesa card may not have enough memory
[03:07:22] <SWPadnos> yeah, that's what I was thinking earlier
[03:07:39] <SWPadnos> but you don't have to put it in stepgen, since steps can clock another component
[03:07:45] <cradek> I'd kinda hate to make it stepper-specific...
[03:08:01] <SWPadnos> clock input = more generic :)
[03:08:28] <cradek> yeah I guess - even doublestep steps would be able to do it I think
[03:08:47] <SWPadnos> hmmm, maybe
[03:09:10] <cradek> you just treat it as a level (high = a step happens in this period)
[03:09:10] <SWPadnos> well, maybe not, since the step output would always be high when the clocker sees it
[03:09:19] <SWPadnos> unless steplen > 1 period
[03:09:42] <cradek> I don't think that happens in doublestep mode, but you'd have to check
[03:09:42] <SWPadnos> so the clocker would have to know if doublestep is in use
[03:09:57] <SWPadnos> no, but normal mode with 3-period steps would be a problem
[03:10:24] <cradek> sure, your clock pulse reader needs to know whether its clock pulses are edge or level
[03:10:34] <SWPadnos> yep
[03:10:58] <SWPadnos> so this will only work with software-generated steps or software-read encoders
[03:11:21] <cradek> ... at full resolution
[03:11:24] <SWPadnos> unless a faster step/encoder hardware has support for clocking out some arbitrary data
[03:11:26] <SWPadnos> yes
[03:11:29] <cradek> yep
[03:35:35] <SWPadnos> hmmm, actually it's a little worse than just not being full resolution
[03:35:49] <SWPadnos> the resolution is limited to the rate at which the feedback can be read
[03:36:18] <SWPadnos> on a USC/UPC, that would be roughly 2-5 kHz
[03:36:28] <SWPadnos> probably 10 kHz or faster on Mesa
[03:37:25] <SWPadnos> and if you add PWM vs. on/off to the laser, the PWM base rate has to be mighty fast to get any intensity resolution
[14:35:17] <mozmck-6core> at the end of building packages in lucid I get: dh_python: This program is deprecated, you should use dh_pysupport or dh_pycentral instead.
[14:38:31] <jepler> luckily for us it still works for the moment. In general I want to get patches to fix package-building warnings for master, but not for v2.4_branch when they fix no specific problem
[14:48:15] <mozmck-6core> ok. I also get a warning that compat levels less than 5 are deprecated.
[14:48:32] <mozmck-6core> should I leave that at 4?
[16:15:40] <jepler> mozmck_work: Reading the debhelper list of changes at each compatiblity, I don't expect any problems due to increasing the compatibility level. so after testing it, on master we can increase the value to 6, as the oldest system we want to build packages on at the moment (hardy) supports this level. When we have most developers on lucid, we can increase it to 7. Again, no change on v2.4_branch except to fix specific problems.
[16:37:00] <dgarr> if there is interest, here is huge patch for scaling 3D_Chips:
http://www.panix.com/~dgarrett/stuff/0001-3D_Chips-allow-scaling-in-x-y-z-f.patch