I meant to say, ...The motor-pos-fb at home will become the current motor offset...
Brian On Mon, Aug 9, 2010 at 12:50 PM, Brian <[email protected]> wrote: > John Kasunich, > > You are spot on with your description of with I have and what I want > to do. I am surprised that my configuration would be uncommon. It is > just a regular knee mill with a DRO. I put stepper motors on the X-Y > handles, and found out that I can wire the DRO's scales to my LPT port > and use them. Fairly basic I would think, and if it was common > knowledge how easy it is to interface with the DRO, I think more > people would do it. Additionally, there are lots of machining centers > that have scales, although there are existing methods to using them > with servo motors, I think this way makes more sense. > > Your thoughts on the HAL jumper are what I had in mind to keep > existing functionality. With respect to homing, I imaging the scale > counter will get zero'd when the home switch is triipper, and the > motor offset will become the current motor-pos-fb. This should solve > the homing issue. > > Thoughts? > > Brian > > On Mon, Aug 9, 2010 at 12:03 PM, John Kasunich <[email protected]> wrote: >> >> >> 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 >> > ------------------------------------------------------------------------------ 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
