On Sun, 08 Aug 2010 00:51 -0400, "Brian" <[email protected]> wrote:
> Why is there so much resistance to this? I must not be effectively > explaining the situation. I suspect in person, I could better > describe the benefits to making it work the way I propose. Over email > however, it just doesn't seem to be hitting home with anyone. Heck, I > would take this on myself and submit it, but I don't have the time to > learn EMC internals just to implement this. Especially when I know > there are people who already know EMC inside, and could probably > implement such a change without a lot of trouble. > The reason why there is so much resistance is that you want to change to a core component of EMC - the motion controller - for a reason that is very specific to a very strange and rare setup. I've stayed out of this thread, but I need to put my two cents in here. (Maybe more like two dollars. Sorry for the length, but I needed to go into details.) One strength of HAL is that people can build HAL configurations as strange or complex as they want, without changing the core of EMC. When your problem can be solved in HAL, you can do your strangeness in a way that doesn't bother anyone else, so every- body is happy. But if you change the core, it DOES affect everyone else, and there WILL be resistance. Lets talk about the specifics of the change you want: joint-pos-fb is currently an output pin. You want to make it an input - but you clearly can't expect everyone who might have been using it as an output to simply stop doing so. What you really are asking is that we make it configurable. So now we have an additional piece of configuration data, the direction of the pin. How should we do that? An ini file parameter? Then we need to make sure it defaults to the "old" way of doing things, so we don't break everybody else's configuration. We need to document it clearly, which includes explaining why someone might want to use it as an input. We need to add code to the motion controller that switches the pin direction - this could be very complex, since the code exports the pins before the rest of the ini file data is available, and pin direction needs to be known at export time. And even after doing all this, and testing to make sure it all works, there is the risk of bit-rot. When the core has a feature that is almost never used, there is always the risk of future changes breaking that feature without it being noticed. The more complex the feature, the more likely that the feature will introduce new bugs, or get broken by accident later. An alternative way of making joint-pos-fb an input would be to make it always an input, provide a corresponding output that has the "de-compensated" position feedback (the existing joint-pos-fb pin), and use a HAL signal to "jumper" the two pins together for normal configurations. That has less risk of introducing new bugs, since there is no new logic. But it will break everybody's configuration when they upgrade, because their HAL files won't be installing the jumper, so that is still a bad idea. Another issue just occurred to me, which makes things even more complicated... It sounds like Brian already has a fairly good idea of the flow of positions through the motion controller, but to help clarify things, take a look at http://linuxcnc.org/docs/2.2/html/code_Code_Notes.html#r3_2 Note that both screw comp and "motor-offset" are added to the outgoing position command, and subtracted from the returning position feedback. Motor offset is used for homing - initially it is zero, and the motor and joint positions are considered to be the same. When the home switch trips, the joint position needs to instantly jump from wherever it was to the actual position associated with the switch. We don't want the motor position to jump though - that would send the motor flying off at full speed trying to get to the new position. EMC handles this by simultaneously changing the joint position command to the new value, and setting motor offset to the difference between the new and old values. The two changes cancel each other out, so the resulting motor position command doesn't change. When the feedback is evaluated, the joint feedback jumps to a new value that matches the command. This is the DRO jump you notice during homing, when the axis hits the switch. If you change joint-pos-fb to an input and start driving it with the scale, what happens when you home? The joint command will jump, motor offset will correct for that, motor command will remain the same, joint feedback (from the scale) will remain the same, and you will have a following error, because joint command jumped to the proper home value, but joint feedback still has whatever random offset was there when the scale was powered up. Some people who run CNC machines with a manual mindset never bother to home - they simply touch off wherever they are, and carry on. They might say this is no problem. But if you are using screw compensation like Brian is, you need to home the axis. Otherwise EMC might be applying screw comp for the left end of the screw, while you are actually at the right end. Instead of going on about what changes to EMC would be right or wrong, lets back up and look at exactly what you have, and what you want to do. Just to make it perfectly clear, let me spell out what I think you have, so you can either confirm or correct me: You have a mill, with ACME screws that are worn badly enough that there is not only significant backlash (how much?) but also the lash varies along the length of the axis. You have STEPPER motors, with no encoders on the motors or screws. You are using EMC's software based step generator, not Jon Elson's thing or a Mesa card, and you have no desire to buy such hardware. You have hand cranks on the screws. And finally, you have linear encoders. You are reading the encoders using EMC's software based encoder counter module, not Jon Elson's stuff or a Mesa card, and again you have no desire to buy such hardware. Do I have that all correct? Please correct any errors when you reply. Now, lets spell out exactly what you want your machine to do. Keep this as high-level as possible. In CNC mode (stepper drives enabled), you want it to: 1) display where the table actually is, as measured by the linear scale 2) move the table exactly where it is told to move, in spite of backlash and screw error In manual mode (stepper drives disabled), you want it to: 3) display where the table actually is, as measured by the linear scale 4) allow you to turn the cranks to move the table And finally, you want to be able to: 5) transition between manual and CNC modes without re-homing or moving during a transition Is that it? Are there any corrections to the five items above, or additional items that I've missed? This is long enough - once you've confirmed that I understand what you have and what you want, I'll start thinking and talking about how to get there. John Kasunich -- John Kasunich [email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
