Hello Guest it is January 25, 2020, 02:25:20 PM

Author Topic: DoButton vs DoOEMButton  (Read 6514 times)

0 Members and 1 Guest are viewing this topic.

DoButton vs DoOEMButton
« on: June 01, 2013, 10:47:04 AM »
I've been having difficulty auto squaring my slaved axis. The script that comes with Mach3 uses "DoButton(x)" but all the reference material I've seen says this is deprecated and should not be used. The references (2010 version) say DoOEMButton(x) is preferred. I'm also using a smoothstepper and apparently cannot use RefCombination() yet due to an issue with the plugin. The programmers reference says to look for "CB Constants" as a reference to the axis numbers to use with the DoOEMButton() call but I cannot find any such section in any of the programmers reference or other documentation. What gives?

Does someone have a listing of OEM button numbers that includes the axes and maybe an example using DoOEMButton to zero an axis? I want to be able to square the master and slaved axes separate. If I don't I end up with the slaved switch tripping after the master axis homes.

Offline ger21

*
  • *
  •  6,291 6,291
    • View Profile
    • The CNC Woodworker
Re: DoButton vs DoOEMButton
« Reply #1 on: June 01, 2013, 10:58:32 AM »
OEM Button codes are here:
http://www.machsupport.com/MachCustomizeWiki/index.php?title=OEM_Buttons
Home X would be DoOEMButton (1022)

But it's no different than DoButton(22) (which has always been used in the default Homing scripts.

I can't believe that the Smoothstepper continues to have homing issues that have been around since the initial release.
Gerry

2010 Screenset
http://www.thecncwoodworker.com/2010.html

JointCAM Dovetail and Box Joint software
http://www.g-forcecnc.com/jointcam.html
Re: DoButton vs DoOEMButton
« Reply #2 on: June 01, 2013, 11:05:38 AM »
OEM Button codes are here:
http://www.machsupport.com/MachCustomizeWiki/index.php?title=OEM_Buttons
Home X would be DoOEMButton (1022)

But it's no different than DoButton(22) (which has always been used in the default Homing scripts.

I can't believe that the Smoothstepper continues to have homing issues that have been around since the initial release.
Why does the reference say to use DoOEMButton and not use DoButton? Confusing...
So DoOEMButtion is DoButton plus 1000. But the original 22, 23, 24, 25 axis references are not in the reference list. Again, confusing. But I also understand how much work goes into writing these references and how long it can take to produce a mature reference document so thank you for helping.

I don't know why the ESS plugin does not support RefCombination yet. Greg at Warp9 says not to use it until he publishes his next plugin. I don't know if that means the just released version (v10h2d1a) or the to-be-released version. I asked over there and will hopefully get an answer soon.

Offline ger21

*
  • *
  •  6,291 6,291
    • View Profile
    • The CNC Woodworker
Re: DoButton vs DoOEMButton
« Reply #3 on: June 01, 2013, 11:20:52 AM »
DoButton was replaced by DoOEMButton at some point, but DoButton still works. Don't count on ever seeing mature reference docs.
Gerry

2010 Screenset
http://www.thecncwoodworker.com/2010.html

JointCAM Dovetail and Box Joint software
http://www.g-forcecnc.com/jointcam.html
Re: DoButton vs DoOEMButton
« Reply #4 on: June 01, 2013, 10:13:37 PM »
DoButton was replaced by DoOEMButton at some point, but DoButton still works. Don't count on ever seeing mature reference docs.

Yea, I found the reference and both DoButton and DoOEMButton work, but, having Y slaved with A I assumed they would home separately as-in "DoOEMButton(1023) and a separate DoOEMButton(1025)  but they don't. When I home Y with DoOEMButton(23) it homes the A slave axis first, then the master Y and DoOEMButton(1025) does nothing. Before you ask, no I do not have "slave with master axis" checked in general config. I'm having an issue with the gantry being slightly out of square before homing so after A homes to its sensor the gantry twists a tiny bit turning the slave (M4Home) home switch back on again. I can disable it as a limit switch but I'd rather solve the issue. I'd like to be able to set up an auto start script that homes all axes and either a fixture or user button to move to a "stop" position so its close to the sensors when I turn it back on.

My first order tomorrow is to loosen the gantry mounting bolts and twist it manually until it sits perfectly square before homing then hope it won't twist enough to reset the "prime" home/limit switch when the other side homes. I have fixtures that depend on the gantry being an exact distance from the metal stop on the end of the gantry travel and the way it is I can't depend on it homing correctly. I also would like to

Is there a way to home the axes separately?

Offline ger21

*
  • *
  •  6,291 6,291
    • View Profile
    • The CNC Woodworker
Re: DoButton vs DoOEMButton
« Reply #5 on: June 01, 2013, 10:20:54 PM »
You can  "un-slave" them, home separately, and "re-slave". Not sure what the actual command names are.
Gerry

2010 Screenset
http://www.thecncwoodworker.com/2010.html

JointCAM Dovetail and Box Joint software
http://www.g-forcecnc.com/jointcam.html

Offline Chaoticone

*
  • *
  •  5,634 5,634
  • Precision Chaos
    • View Profile
Re: DoButton vs DoOEMButton
« Reply #6 on: June 02, 2013, 12:09:25 AM »
Is it homing the slaved axis first because it sees the slaved axis home switch first?  I wonder how it would work if it sees the other axis home switch first?  Could you try that before squaring your gantry?  Squaring the gantry mechanically is a must IMO but I would be interested in the results if you do test.  I'm just wondering what the sequence should be and if it will make a difference.  I think it may well do it and if so, you will want to know before you square the gantry and set your limits.

Brett  
;D If you could see the things I have in my head, you would be laughing too. ;D

My guard dog is not what you need to worry about!
Re: DoButton vs DoOEMButton
« Reply #7 on: June 02, 2013, 12:58:22 PM »
Is it homing the slaved axis first because it sees the slaved axis home switch first? 

It does not seem to make a difference which switch it hits first, It seems to be looking only for the slave switch on the initial move. I don't think it's looking for both but I could try pushing the master switch forward and see what it does. As near as I can tell, during homing it moves the combined master/slave axis towards the switches then stops when it apparently hits the slave switch. It then backs off both axes together until the slave sensor opens. It then uncouples the axes/disables slaving, homes the slave side again only this time it moves ALONE and SEPARATELY, backs off the slave side till the switch opens, homes the master axis separately until it hits the master switch then backs off and stops. It definitely does a more complex move than if I home it to Y alone and it definitely homes the axes three times. I can hear it move the motors. Once with both motors then each motor separately. I'll see if I can get a video of it in action so I can see exactly what its doing.

The problem I'm having is that when it homes the slave side first it's twisting the gantry slightly in the process. Then it homes the master side releasing the twist in the gantry when it pulls the master side back to square but when it does so it moves the gantry towards the switches enough to trip the prime sensor again. Initially I just disabled the prime sensor as a limit switch and it works fine as long as you don't try to home twice in a row. But if you hit Ref All Home or try to home the Y twice it doesn't detect the prime switch being tripped and tries to home past it, even though it's tripped. Definitely something it should not do and what I consider a bug. I might be able to prevent this from happening by moving the switches to the far outside of the gantry so the twist has less effect. I'll go fiddle with it some more and see if I can get video to post. I may need to report this as a bug.

Quote
I wonder how it would work if it sees the other axis home switch first?  Could you try that before squaring your gantry?  Squaring the gantry mechanically is a must IMO but I would be interested in the results if you do test. 
I have tested auto squaring with the gantry out of square before the homing. The machine works fine except if you hit eStop or lock the operator and release holding torque on the motors which, of course, causes lost or gained steps. With the gantry square to begin with there isn't enough gantry twist to move the motors if you hit eStop. I discovered the issue when I was cutting a 3D shape. I hit eStop for some reason and didn't resquare the gantry and it changed the X axis path across the piece. Not enough to ruin it but I could clearly see the horizontal line where it lost or gained a step. What I need are encoders for the stepper motors but I don't think Mach will make use of them even if I install them. I'd only be able to use them to detect missed steps with an external comparator. It would be easy to set up a circuit that counts and compares pulses from the motor and the encoder, setting an error condition if the count is out of sync which I could trap using an input. I think there is just such a board somewhere. Unfortunately Mach does not support feedback steppers, only servos.

Tom

Quote
I'm just wondering what the sequence should be and if it will make a difference.
I can push the master switch forward while its squaring and see if it makes a difference.

  I think it may well do it and if so, you will want to know before you square the gantry and set your limits.

Brett   
[/quote]
Re: DoButton vs DoOEMButton
« Reply #8 on: June 02, 2013, 01:00:03 PM »

I don't know why the ESS plugin does not support RefCombination yet. Greg at Warp9 says not to use it until he publishes his next plugin. I don't know if that means the just released version (v10h2d1a) or the to-be-released version. I asked over there and will hopefully get an answer soon.


Greg at Warp9 says it will be the next plugin, not the recently released  (v10h2d1a) version.