Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: macdarren on December 22, 2010, 08:17:40 AM
-
I got my new software all installed along with a new controller and some other items.
Every seems ok but I have observed something odd.
I was testing my home switches and discovered that when the x axis is homed it moves pretty
much as expected however what is odd is that the y-axis also moves a small amount. At first I
thought I was seeing things then suspected I had a mechanical connection messed up but
no the machine coordinates DRO confirms the y is moving (I have no feed back system)
and I can feel it move as well.
Homing the z and y do not affect any of the other axes as far as I can see.
Could I have something mis-configured? it seems if the DRO moves then Mach must be aware it
is happening and doing it on purpose so probably not a hardware issue. (jogging moves the axes
independently as expected.)
Any Thoughts?
Thanks
Darren
P.S. I believe I am using the latest released version….R3.042.040
-
Hi Darren,
Just to verify ... are you homing the axis individually from the Diagnostics page and seeing the other axis move ?
Or are you using the RefAllHome from the RUN page which will move the other axis a slight amount if it is already at or near its switch.
Thanks
-
I have a "Shuttle Pro" hand controller that has buttons set up to home each axis individually. However if I ref all to home I think I see the same thing happening.
I will check and see if it occurs from the diagnostic page.
Question why would "RefAllHome from the RUN page which will move the other axis a slight amount if it is already at or near its switch." do this?
I suspect this is related.
-
I confirm that from the diag page the same thing happens. I also see that from here the refZ also moves the Y axis though only about 1/2 as much. And both X and Z ref only appear to move Y when Y is close to it's home position. If I move it off home it doesn't move. I am now thinking this is some sort of 'feature' but I don't understand it. Strangely if I do ref-Y then a ref-Z the Y will move about .025. If I do ref-y then ref-X it will move about .05. but if I do ref-Z first the Y will move the .025 and a subsequent ref-X will not move the Y axis at all so Y ends up in different places depending on the order I home the other axes.
If I have the Homing config set to zero the DRO on home everything seems to work and I end up at 0,0,0 according to the DROs anyway. I was trying to get a feeling of how repeatable the Home / Ref position was by doing a ref all with the zeroing active then jogging around and then doing individual axis homes with the zeroing inactive to see if I ended up back at 0 for each when I first saw this come up.
-
What I meant was, REF ALL HOME will reference all axis in sequence from where ever they are but if the axis was very near or at its switch, the movement would be slight. Thought that might have been what you were seeing.
If it happens from the Diag. screen, I would suspect it has something to do with the Shuttle Pro installation or plug-in.
Might try to disable the plugin to verify that it works properly just with the Mach screens. ?
-
I tried removing the Shuttle pro stuff but I get the same results.
I did learn that it seems to happen only if I have the y axis "Auto Zero" the homing/limits config page not checked. If this box is checked the axes seem to all move and will ref independently and one does not affect the other, and of course after they hit the switch they back off and zero. if the box is unchecked then this weird movement of the Y happens when ref-ing the X or Z, but only when it is near the switch.
-
Can you attach your xml and I will see if I can find a problem with your config.
Hood
-
Strange, never saw that before. Might need a complete description of your controller/components.
Could be some custom stuff running in there.
-
I think I have attached my XML correctly...(never tried posting an attachment before)
My basic setup is a Taig Mill converted to CNC. I use a smoothstepper for motion control and a Gecko 540 for the driver.
I have Limit Switches which serve for homing too. There is one at the top of Z, two for the Y one at either extreme
and a single switch in the center of the X with triggering ramps at either end of the table. Pretty standard stuff.
When I get home I have an XML file that was sent to me by someone with the same hardware I will try that to see if
it does the same thing.
-
You have a massive value in each of the filtering entries in the SS config, I think that is your problem. Try setting to 10 or less and see if that helps.
Hood
-
Are you talking about the Noise Filters in the smoothstepper config? They look like they are set to 200Microseconds to me...I can try 10 as you suggest but 200 didn't seem massive so I am thinking you are referring to something else I am not sure what that might be or where to change it.
-
It is a massive value for the SS or at least from any testing I have done.
Hood
-
okay I'll try 10 tonight and post my results.
I was wondering too about the max homing distance...I have no idea what that number is measured in....unless it is motor pulses or something very tiny
then my value of 500000 seems pretty large.
-
I would imagine the distance value is units (inch or mm depending on your setup)
Regarding the filtering, I have zero for most but I think on the Bridgeport I have 1.43 for the MPG. I remember messing with the filtering when it first came out and I set 50 in the E-Stop just to see and I see the delay when I pressed my E-Stop compared to before with 0 there. In fact I think the contactors for my servo drives had actually dropped out before Mach saw the signal but it was a while ago so could just be imagining it ;D
Hood
-
Well I tried 10 in the filters settings on the SS. I also tried 1 just to see what happened.
I didn't have any bounce problems so clearly 200 is probably excessive, however the new filter values didn't solve the problem.
Using smaller numbers seemed to change the amount of Y movement reported in the DRO but it still happens.
I have now set things to 10 just for reference and future testing.
What I have found in testing this that it only happens when the Y axis is non-zero. (the Ref-y led is red) if it is .0001 it will move to something like .025, if it is zero it will stay at zero.
Clearly something is happening here in Mach where it decides to move this non zero axis when zeroing another axis
darren
-
What version of the SmoothStepper plug-in are you using? Also, have you changed any of the homing macros?
-
Mach reports SS config version Beta2 0.015ogx
Device Manager reports: SmoothStepper v1.2 Driver Version: 2.4.6.0
I don't know what a homing macro is for sure, though I can guess, and I have no idea how to change it so I do not think I have.
How would I look at them?
-
I am presuming you have normally closed switches for your Home/Limit switches, have a look on the diagsnotics page and see if the LEDs are active when you are off the switches if they are then change the active state of them.
Hood
-
LEDs act as expected....lighted when on the switch off when off the switch.
-
What kind of switches are you using?
Cant see anything wrong with your xml and SS config other than the filtering as was mentioned earlier so not sure what to suggest.
Presume its a fairly recent version of Mach you are using?
Hood
-
Mach version R3.042.40
Switches are your basic sealed pin switch with roller lever.
Pretty sure it is not a switch thing or any other mechanical issue as Mach knows what is happening and is the one moving things...I can imagine no reason for a ref-x to ever move y but it seems to happen.
The idea of a modified macro seems possible...maybe something got changed by accident in the latest version of mach...pretty sure I didn't change anything
and I reverted to a alternate XML from someone with similar setup and I believe that would get me fresh macros too...at least looking in the macro directory
it appears they get created new when a new xml is used....at least the modification dates are old.
If anyone wants to try this here are the steps to see the problem..
First do a Ref-All with the homing/limits config set to auto zero the axes when homed. (kinda the normal situation)
now with the machine at zero, change the homing/limit screen so that Y is not auto zeroed on home.
now go to the diag screen
click ref y a few times y moves as expected.....typically mine ends up at .0001 or similar after a few moves I gather my switches are not super rigid and of course I have back lash and such.
At any rate Y is not zero but it is pretty close to its home position, this is important if it is zero you won't see the problem (also note that the ref-y led is red)
now click ref-x (I would expect only X to move as it seeks the switch)
what happens for me is X moves back toward the switch (since it is slightly backed off the switch from the previous ref-all)
as X is moving Y is also moving (in my case away from its switch)
X reaches the switch backs off it and resets it's DRO to zero
Y is now reading and presumably is at something like .05 not the .001 you last moved it to.
there are lots of combinations that result in this odd dual motion. note that if you followed the steps above and ended up where I did
now go to the main screen and hit ref-all x and z will of course end up at zero since they are still set to auto zero. Y should also (I think) end up close
to zero since we have nothing that should cause it to be anything but where it should be from the initial ref-all at the beginning but in my case it won't be close to zero, it will be around .05.
I don't think this really affects things too much in the normal course of events...typically you home all and have the auto zero set
But in some cases I do home an axis independently (often Z which exhibits the same behavior)
Seldom do I work so close to the home switches and being off them a more significant amount seems oddly to prevent the double motions.
I did have a case just recently where I am suspecting this odd motion resulted in a couple broken tools when Y moved unexpectedly
as I was trying to recover from a fault condition.
Darren
-
So are they normally Open contacts, just I would have expected Active Hi settings if Normally Closed.
Anyway regards testing, afraid I cant do that myself as on my machines I do the homing external to Mach via my servo drives. Hopefully someone else will do the test for you.
Hood
-
One question do you normally use the homing process to NOT zero the axis when you home???
(;-) TP
-
Sounds like you have a formula set for the Y axis. Check that first, UNder Function CFG's>Formulas.
click ref y a few times y moves as expected.....typically mine ends up at .0001 or similar after a few moves I gather my switches are not super rigid and of course I have back lash and such.
At any rate Y is not zero but it is pretty close to its home position, this is important if it is zero you won't see the problem (also note that the ref-y led is red)
Clicking Ref Y should result in a green LED. If it's red, it's not being Ref'd.
-
Noticed one thing, well 2.
Gerry, looking at the XML, formulas are not enabled and all are blank.
The other thing is Backlash is enabled and configured. SS is not there yet, is it ? If not, could that have any effect ?
Rc
-
SS? HUM Does not the SS control homing directly , not MACH ?
Just a thought, (;-) TP
-
I disabled the backlash adjustment to see if that might be the problem, but the problem persists.
SmoothStepper is installed and being used by Mach.
I notice from the SS site that maybe it does control the homing somehow....there is some old talk about that on their forum.
But I don't think it could just be the SS messing up if the DRO in mach changes, but I could be wrong there.
-
One other item looked strange to me.
(just suggesting thins that I would try, no expert by any means)
The Homing Speed % looks high, wonder if Mach is in control of that or not.
Might set them at 20% or so just to see ?
Grasping at straws here.
-
I have been pondering what might be happening here as I've used the SS with homing a lot and not experienced this issue. The only things i saw in your XML file was that you were using the same inputs for homing/limits on each axis. To simplify troubleshooting I would enable only the homing inputs. Also in the SS configuration you have really large numbers in for homing distance. I would back these down to something reasonable, you should never need anything more than the max axis travel in there. Also zero out the Max distance for master and slave axis distances, this may be confusing the plug-in.
There is also a beta plug-in out that has had a lot of work done on homing. If nothing else works it might be worthwhile to
http://warp9td.com/files/SmoothStepper_v16bdg.m3p (http://warp9td.com/files/SmoothStepper_v16bdg.m3p)
-
Hi Jeff,
I tried your suggestions in order, first turning off the limits then reducing my large homing numbers...I tested with the above test at both steps but no change.
I then installed the plugin you linked to and amazingly the problem was gone. So I think it is now related to the SS plugin. The new plugin however has some other issue
related to homing....first it seems to keep turning on the auto-zero in Mach...not sure how but I turn it off and then after I do a ref-all it is back turned on.
Even weirder is even when it is showing as on sometimes the Y-axis (the only one I tested) seems to not zero on home....getting stuck at .0001 usually.
It almost seems as if it is a false auto zero condition showing in mach .. maybe because somehow the plugin does something tricky but then things are not really auto zeroed.
I think this is clearly better than the previous condition where Y moved when it should not, though it might really be partly a mask for the condition as
it forces the Y to zero or .0001 depending on what I don't know but in that situation it doesn't move the Y and with the old plugin it only moved the
Y when it was non zero, and de-refed a condition which the new plugin seems to simply prevent from occurring.
Well at least this issue has lead to where the problem is and I guess the SS people are working on it since the function of this
new plugin is clearly different from the old one.
thanks
Darren
-
As a side note after playing around with the v16 SS plugin I note another odd sorta related issue and that is that I can no longer seem to set soft limits.
With x and y limit switches this is not a big deal though I miss the slow-down when jogging near the edge, since I have no lower Z limit switch I also
have to be careful here as I tended to use the soft limit and it's slow down factor to allow me time to react when jogging down...
Not a big deal but thought I mention it, for those who might have tried it out.
-
SoftLimits work fine for me with that plugin, are you saying you can not even enable them? I have also just tried with the xml you attached and I can enable/Disable softlimits and simulating here at home it slows down fine.
Might be worthwhile changing all SS plugins in the plugins folder back to m3p extensions except for this latest one and also maybe even make a new profile up just in case something is corrupt.
Hood
-
Just for the record I have spent some time going through the steps Darren outlined in post 20, and can not get it show Darren's issue.
v015ogx2
Greg
-
RE: the soft limits....
I can't seem to enable softlimits at all. Mach aways reports: "Machine is out of limits for softlimit activation".
This is even after just homing the machine with auto-zero on so it is sitting at 0,0,0
I have tried playing around with different max and min numbers and being sure the machine coordinates are
well inside but still it won't enable. I am starting to think a full remove and reinstall of the Mach, and SS software
might be the answer. I have removed and reinstalled the SS plugins and drivers already but maybe there is something
messed up in Mach...or I am just cursed.
-
Merry Christmas everyone....
Spent a couple fooling with the mill today ...
I have the soft limit enabling again. Not sure how but with all the switching around or something I must have changed my limits on the Z axis. I found I had it set to be 0 to 6 instead of 0 to -6.
Still not totally happy as for some reason once I got the soft limits to enable I found that homing all causes the X and Y to work as expected but the Z axis seems to obey the slow down near the extremes set in the soft limits even when homing...this would not be all bad except as it sneaks up on the zero position (up) it gets slower and slower then just before it trips the switch the soft limit is exceed (as zero is just in front of the switch) and this causes Z to be non referenced. My work around was to actually spec the soft Z max limit as .05 instead of 0.0 this allows the Z to actually hit the switch before the soft limit and thus it is referenced. I think there might be a slight bug that fails to turn off the soft limiting when refing the Z. X and Y do not exhibit this behavior.
Darren