if I'd export motion type to hal (g0 vs g1) I wonder if that would make a really simple way to do rasterization
(G0 and G1F9999 have the same feed rate)
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?
that should have equivalent timing to M62/M63
ie, at servo period rate
not fast enough for a fast machine I guess
so it should be equivalent, and the ~1ms delays are apparently problematic
a raster line (at encoder/step resolution?) in a mesa card is sure they way to go
or for software stepgen, hack it into stepgen and clock out according to steps at the base thread speed
actually, a mesa card may not have enough memory
yeah, that's what I was thinking earlier
but you don't have to put it in stepgen, since steps can clock another component
I'd kinda hate to make it stepper-specific...
clock input = more generic :)
yeah I guess - even doublestep steps would be able to do it I think
you just treat it as a level (high = a step happens in this period)
well, maybe not, since the step output would always be high when the clocker sees it
unless steplen > 1 period
I don't think that happens in doublestep mode, but you'd have to check
so the clocker would have to know if doublestep is in use
no, but normal mode with 3-period steps would be a problem
sure, your clock pulse reader needs to know whether its clock pulses are edge or level
so this will only work with software-generated steps or software-read encoders
... at full resolution
unless a faster step/encoder hardware has support for clocking out some arbitrary data
hmmm, actually it's a little worse than just not being full resolution
the resolution is limited to the rate at which the feedback can be read
on a USC/UPC, that would be roughly 2-5 kHz
probably 10 kHz or faster on Mesa
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
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.
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
ok. I also get a warning that compat levels less than 5 are deprecated.
should I leave that at 4?
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.
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