On 01/26/2011 05:21 PM, andy pugh wrote: > The main change is that the number of gears is now set by a num_gears > modparam rather than "personality". This has allowed me to get rather > carried away and the component is now a bit polymorphic. > > With a num_gears modparam it creates a scale and select for each gear. > It also creates a pin to indicate which gear is in use. > Without the modparam it behaves like the old version, with a single > "sel" pin to swap between gears 1 and 2, and a "reverse" pin to > indicate that gear 2 runs backwards. In this mode it does not have > numerical gear input or output pins. > > Talking to Seb, he opined that this was all a bit too elaorate, and > having a component with two behaviours and one name is silly and > confusing. > > I tend to agree. > > So, should we use this version, which tries to be all things to all > men, or would it be better to drop the compatibility mode and break > any existing configs (of which there are probably rather few which use > it)y
gearchange was written in 2008 by SWP, to support the Tormach PCNC 1100, which has two gears settings between the motor and the spindle. It is used by the tormach sample config, and by no other sample configs in our git repo. I believe that no tormach users are using the emc2 sample config, because the spindle speed is wrong in that config. Maybe someone somewhere is using the gearchange comp in their private config, and they haven't told us about it. The 2.4 gearchange has some problems (only 2 gears supported, the low gear must have a 1:1 input:output ratio, and the high gear ratio is relative to the low gear ratio). It works, but it's not near as nice as the new version Andy wrote. My favourite things about Andy's new gearchange comp is that it supports an arbitrary and user-selectable number of gears (up to 32), each gear has an input:output scale pin, and it outputs the actual (possibly clipped) spindle speed on a pin. I am in favour of the new gearchange behavior and HAL interface. It is better than the old one. But more than anything I am opposed to cluttering up the gearchange comp with backwards compatibility. I don't think that backwards compatibility across major releases is a particularly important thing in general, and especially not when there are so few (maybe zero) affected users. (If you can get backwards compatibility for free, of course go for it, but don't let backwards compatibility hold you back from making improvements.) Optimize for folk reading the code: that's both the .comp code implementing it and the .hal code using it. Drop backwards compatibiliy with the old inferior way of doing things. Make the new implementation *functionally* backwards compatible (requiring some .hal changes if needed), but keep the implementation (and documentation) clean by not confusing things with the old 2.4 way of doing it. This is what UPDATING#Changes_between_2_4_x_and_2_5_x is for. :-) $.02 -- Sebastian Kuzminsky ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
