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
