search

LinuxCNC / linuxcnc

LinuxCNC controls CNC machines. It can drive milling machines, lathes, 3d printers, laser cutters, plasma cutters, robot arms, hexapods, and more.
http://linuxcnc.org/
GNU General Public License v2.0
1.76k stars 1.14k forks source link

touchoffs go to wrong axis #1311

Closed WOWElectronics closed 2 years ago

WOWElectronics commented 2 years ago

I have individual jogging dials on my Sheldon lathe. Essentially replacing the hand cranks that are no longer there. Except they have their own per click movements. For finding a touch off point, these are 100x handier than trying to jog the machine to a starting point with the keyboard and mouse based commands as I can dial it to .0001" accuracy with them.

There are no connections between the movements created by these dials and the active axis radio button on the left axis panel. So I find the point I want it touched off to, then find the mouse and apply the touch off, but because there is no connection to the state of those buttons, between my dials possible in axis, the touch off is applied to the wrong axis. And since a lathe has two axis's, it has probably destroyed the carefully done touch off to the first axis I've set because axis, the gui, is unaware the machine has been moved. The center panel with its DRO position displays, is properly updated.

I consider the lack of 9 axisui input pins I could use to keep this all in sync, or a numeric single input, I could drive either, that can be use to update those radio buttons, a bug and a PITA. It is a huge usability error and has cost my considerable cash in broken tooling. All because I have a better, faster and more accurate way to do it. It is my understanding that the people using pendents for this, are also victimized by this. Years ago I had a saitek game controller on a 4 axis mill, but took it off again to save broken tooling precisely because of this lack of an ability to keep things in sync.

Here are the steps I follow to reproduce the issue:

  1. find a point with the dial for z, and apply it. It is applied to whichever axis the keyboard last used to move the machine.
  2. find the other starting point desired with the other dial, apply the touch off, over writing the first touch off because axis has not been notified of the 2nd axis motion, so the radio button has not been updated by the axis last moved by logic.

This is what I expected to happen:

I expected the radio buttons to follow the "last moved by" logic in the axis gui. But there are no INPUT pins to accomplish this in the axisui. I DO have the signals available in my .hal files to tickle that logic and keep those buttons in sync with the machines movements.

This is what happened instead:

I have destroyed the first touch off done, and hitting r to start the operation sends the machine to the wrong coordinate, breaking tools costing real money.

It worked properly before this: Adding the dials that let me drive it by hand just as if it still had the cranks.

(If the behavior changed after making a particular change in hardware or software, describe the change you think is responsible. E.g., "after upgrading from LinuxCNC 2.7.3 to 2.7.4")

Information about my hardware and software:

c-morley commented 2 years ago

This is not actually a bug - it's a usability issue - a subtle but important distinction.

You haven't mentioned how you would select axes externally (or do you have three MPGs?) so I must make some assumptions.

The problem is if you add pins that select the axis externally then you can still select the wrong axis if you mix GUI and external selection.

Imagine you have a rotary selection switch for external axis selection. Set it to X and have the GUI honour that (though a HAL pin) so it display X as selected in the radio buttons. Ok this is what you want. You position X with the MPG and set it's offset with the GUI.

Now you need to zero Z without moving it. Because you didn't need to move the axis you forget to use the external rotary selector and you select Z with the GUI and zero it. Now the GUI and the external selector are out of sync and there is no way to work around this as described, because the GUI can not rotate the external selector switch.

I hope you can see that while we can add pins for axis selection and it might make things better for you, it can easily make things almost as bad.

There are several work around to the usability issue. -Use the keyboard for incremental jogging (ie don't use MPG) -customized AXIS to use HAL pin for selection and change the radio buttons to indicate only (ie can only use external switches) -customize AXIS to require you to always enter the axis you wish to set -add a way to undo offset setting, so you can fix a mistake (or try a GUI that already has this) -add HAL pins for external selection but only allow momentary buttons to be used (but you would need to tie this in to MPG jogging selection too - but i think AXIS has these already)

this is probably the easiest:

I'll leave this open in hopes someone else will think of something i didn't to help you.

WOWElectronics commented 2 years ago

On Saturday 16 October 2021 15:48:45 c-morley wrote:

This is not actually a bug - it's a usability issue - a subtle but important distinction.

Agreed.

You haven't mentioned how you would select axes externally (or do you have three MPGs?) so I must make some assumptions.

Please don't, a lathe only has two main axis's, and I have two dials you call mpgs. $20, 100 ppr, quad encoded, no index, from MPJA.com. But lcnc can do xyxabcuvw so figure on 9 while doing it. The fact that I can drive both, one with each hand simultainiously is a handy plus, but I can't really see 9 of them on a milling control panel. However, if you build it, there will be those like me that do explore the limits.
That .hal config has never been touched by pncconfig. It came 100% from my fingers.

I have two activity timers associated with two dials, its a lathe, so only x and z are needed in this instance, but to not leave the mill folks out, there ought to be one for each instance of xyzabcuvw. These two timers reset the time to disable the dials independently of each other, generating nominally 2 millisecond pulses, which if "ja_rbutton" for each axis had an input pin, could update the radio buttons to keep them in sync IF there were inputs for that in the "axisui" listing of halshow pins. Call it axis.L.select but make it an input pin that if true, updates the axis idea of "last moved by", keeping it all in sync with the machine. Make this signal true to do the exact same thing that occurs if the "wanted" radio_button is clicked on.

I do not generate this signal true, if the dial is disabled, all from logic I put in before I found the dials were ignored anyway if something was running. The dials are both dead if the interpretor is running the machine. Even if the bar under X or Z axis in the pyvcp display is still green, which is my active dial tally indicator. I could probably use the motion.mode state to turn them red and off but I'm lazy.

I must push a hard to push button beside the dial, which enables the dial to move the machine until the inactivity timer shuts it off, but while it is activated, any motion of the dial resets that timout to whatever its setp'd to. This reset pulse, a train of them as the dial is turned, if fed to an axis input to select that axis, is just an addition to my target list for that signal, and very easy to add to my hal files, with no need to screw around with trying to grok the antiquated python 1 or 2 logic in jogaxisget, that whole module is a PITA and just goes away forever.

The problem is if you add pins that select the axis externally then you can still select the wrong axis if you mix GUI and external selection.

No you cannot Chris, as I envision it, the dials can only set the axis rbutton to the axis corresponding to the dial. Anybody who would carve a hal file to do otherwise is an id10t and should find another line of work, for the same reason as our current sitting POTUS. I hear Jack-in-the-box is hiring janitors.

Even so, the first click of the activated dial will correct it.

And your suggestion of a way to undo an unwanted touch off is a good one, please do that too.

Imagine you have a rotary selection switch for external axis selection. Set it to X and have the GUI honour that (though a HAL pin) in the axisui pin list so it display X as selected in the radio buttons. Ok this is what you want. You position X with the MPG and set it's offset with the GUI.

correct. Then do the same thing for the next axis, in this case Z, until out of axis's to be set on that machine.

Enabling and turning the Z dial should automatically update the radio_buttons to show Z as the active axis. You are placeing the ability to actually make a mistake on an operator, to purposely make that mistake, taking away the probability that he will forget to click on the wanted next axis to adjust. It becomes automatic. Far fewer mistakes and they will be intentionaly done.

Now you need to zero Z without moving it. Because you didn't need to move the axis you forget to use the external rotary selector and you select Z with the GUI and zero it. Now the GUI and the external selector are out of sync and there is no way to work around this as described, because the GUI can not rotate the external selector switch.

If the external is not a closed contact, but generates a pulse, who cares, the touch off offset will be applied to the operator selected axis. If the pendent is outputting a full time logic signal, then hopefully the operator will sober enough to notice that he cannot mouse select to over-ride the pendant selection.

I still don't see a problem unless the operator is running the machine from a braile keyboard cuz he is blind. In that case it would be nice if linuxcnc, could emit a special two tone raucus beep to alert the operator of the error.

I hope you can see that while we can add pins for axis selection and it might make things better for you, it can easily make things almost as bad.

Or a heck of a lot better.

There are several work around to the usability issue. -Use the keyboard for incremental jogging (ie don't use MPG)

Now that I have them, and have had them for 4+ years, I cannot envision doing without them. Knowing how handy they are, if these die, I'd gladly pay 10x their original $20 cost to replace them. I'd first call MPJA to see if they still had a couple gatheriing dust on the shelf, failing that find out where they bought them and see if they still make a similar one. Failing that, I have some head motors from floppy drives that when fed to a pair of comparators, would also give me a quadrature signal pair to send up the cable to a mesa encoder. They might have a minumum speed below which they won't work, but the DRO's will tell you that. With good comparators, and the slip between skin and bone of the fingers turning them past their magnetic detents, I don't imagine the velocity will make much difference.

As a CET, I am pretty good at fixing hardware problems, sometimes by finding a better way to do it. But I am not that good at hacking python3. Thats your expertise, not mine. And I thank you, a lot.

-customized AXIS to use HAL pin for selection and change the radio buttons to indicate only (ie can only use external switches) -customize AXIS to require you to always enter the axis you wish to set -add a way to undo offset setting, so you can fix a mistake (or try a GUI that already has this) -add HAL pins for external selection but only allow momentary buttons to be used (but you would need to tie this in to MPG jogging selection too - but i think AXIS has these already)

It can only update hals image by halui, which is NOT connected to axis, no halui pin in my tests can update the radio buttons. In fact, I haven't found a use where doing something to hal's image of the machine, can do anything but screw it up. My dial driven hal goodies do not play with any halui stuff. Only the imported camera and alignment stuff does, issuing movement or coordinate commands thru mdi.

this is probably the easiest:

  • don't use external axis selection for the MPGs use AXIS's GUI radio buttons to select the MPG axis.

That of course will work, but remembering to click on the desired axis button, and the lack of precision without a lot of slider speed adjustments to slow it down to where you want to stop it, is so much less convienient there is no comparison. Apples to horse apples maybe.

Yes its usability, so not quite a bug, but its one hell of a bug in the usability.

I'll leave this open in hopes someone else will think of something i didn't to help you.

How can this not be a huge improvement in usability? Every argument you have given is a ghost that disappears the instant the hal net statements target list is written to tickle the added pins. All I'm asking for is an input pin per axis that if true, does exactly what mouse clicking on the wanted radio button does.

Thanks Chris. Stay well now.

Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable.

c-morley commented 2 years ago

Thank you for explaining how you currently connect everything together. Using a momentary signal to select an axis is of course perfect for what you describe and would work perfectly well if there was HAL pins for axis selection. HALUI uses this same momentary contact scheme to work around the problems I described.

But, as I said what may be good for you could be problematic for others.

We would need to program them in a way to enforce the pins need to be momentary. If someone connected (for instance) rotary switch to them then a similar problem shows up. I think that using rotary or slide switch would be a popular way to use it, (and it wouldn't work well) You process is complicated and pretty unique. That sound to me a frustrating support problem. While in my opinion obscure corner case problems shouldn't get in the way of good capabilities, I don't feel this is a corner case. I wouldn't recommend we add the pins as described. Keep in mind I'm not the gatekeeper of AXIS and other devs may have other opinions - so it still could happen.

But this is why I suggested customizing AXIS or using another GUI that is more customizable. Unfortunately AXIS is pretty difficult to modify and it's not my expertise or interest, but there are others around that do know it pretty well.

WOWElectronics commented 2 years ago

I have explored some of the other gui's in the sim list, but was unable to find a competing gui that even has this logic, but may have a touchoff function. Without a selector method being visible, how do other gui's implement a touchoff and get it applied to the correct axis?

I repeat, all I want is an input method to the 'last moved by" variable that sets those radiobuttons, one that if strobed true by the motion of the two totally independent dials, the X dial setting the X button, and the Z dial setting it to the Z button, which will set those buttons to the dial that moved the machine last. That would assure the touchoff goes to the correct axis as it wouldn't ever be "out of sync" then. Totally ignored if the hal code never touches the added pins. To get out of sync using those pins requires an idiot writing hal code. We are I think, well away from any of "us" fitting that description.

I have also trolled and grepped thru axis.py, looking for clues as to how this could be done, but my python expertise doesn't seem capable of following most of what is going on. Too abstract. So I can well appreciate it as a can of worms you'd rather not open. I sure don't feel qualified, and like Dirty Harry I know my limits. That's why I'm here, asking for help.

Thank you. Gene Heskett.

c-morley commented 2 years ago

Looks like Gene is getting some help to add custom pins to AXIS - which I think is not most appropriate fix. https://forum.linuxcnc.org/21-axis/44068-axis-vs-touch-offs I'm closing this issue.