homing of X axis causes "joint 0 on limit switch error"

[Klemen Zhivko]

Hi guys,

I am using machinekit client and use homing of X axis with following code:

pb.Message.Container.Builder builder = Container.newBuilder();

pb.Status.EmcCommandParameters emcCommandParameter = pb.Status.EmcCommandParameters.newBuilder().setIndex(0)

.build();

builder.setType(ContainerType.MT_EMC_AXIS_HOME);

builder.setEmcCommandParams(emcCommandParameter);

builder.setTicket(getNextTicket());

Container container = builder.build();

socket.send(container.toByteArray(),0);

When I check hal signal with command:

watch -n 2 halcmd show pin axis.0.pos-lim-sw-in

I see that on manual press signal changes... Documented in video: https://www.youtube.com/watch?v=-BAKEVgsQ6I

However when xmax home limit is touched, x axis continue moving on when finally it is stucked and cannot physically move further, having weird motor noise of stucked axis move. I need to power off machine (software).

Fom machinekit I get: 

21:51:12 MT_EMC_OPERATOR_ERROR 

21:51:12 joint 0 on limit switch error

It sounds like a hal problem but cannot find an error.

My ini file is in:

https://github.com/zhivko/PipeCutter/blob/master/src/main/resources/myini/machinekit/CRAMPS.ini

One of first hal files is in:

https://github.com/zhivko/PipeCutter/blob/master/src/main/resources/myini/machinekit/CRAMPS.hal

It seems I cannot make homing work. Can somebody check my ini and hal - is there an error?

Image of xmax home switch is on attached picture.

Hope for any reply.

[Klemen Zhivko]

I forgot to say I use  beaglebone black with cramps hat, NC (normally closed) home switch, and also debounce component as i saw from linuxcnc forum that not debouncing signal could be issue.

[Klemen Zhivko]

I also tried with 

HOME_IGNORE_LIMITS =    NO

in my ini, but then I get:

23:39:18 MT_EMC_OPERATOR_ERROR 

23:39:18 hit limit in home state 5

23:39:18 MT_EMC_OPERATOR_ERROR 

23:39:18 joint 0 on limit switch error

[justin White]

according to your hal file you don't have a negative X limit switch, it's commented out. Your home switch input is connected to your minimum limit. Your .ini is setup to "home ignore limits" on the X axis. By what you said it seems that your trying to home to the Xmax side, but your home switch is the Xmin side and homing is ignoring the limit switches so....crash.

Your hal file lines 339-341 are:

net limit-x-min => axis.0.home-sw-in

#net limit-x-min => axis.0.neg-lim-sw-in

net limit-x-max => axis.0.pos-lim-sw-in

Should be:

net limit-x-max => axis.0.home-sw-in

net limit-x-min => axis.0.neg-lim-sw-in

net limit-x-max => axis.0.pos-lim-sw-in

If you are using the max limit switch as your home switch you need to connect the signal from the actual switch to both pins as above. When homing is active the limit switches are ignored as per the .ini file but that is OK because it is your home switch.

[Klemen Zhivko]

I did required changes, now it happens that homing procedure is breaked with following output on machinekit console:

00:43:42 MT_EMC_OPERATOR_ERROR 

00:43:42 hit limit in home state 7

00:43:42 MT_EMC_OPERATOR_ERROR 

00:43:42 joint 0 on limit switch error

I updated hal and ini files... Maybe you can spot any other problem?

Thanks!

[justin White]

Did you change your .ini file back to HOME_IGNORE-LIMITS=YES? if you're using a limit switch as a home switch you need to use "yes" to ignore limits. You should set HOME_IS_SHARED=1 as well since you are sharing a home switch with a limit switch.

Besides that you may need to invert "HOME_LATCH_VEL". The idea is that HOME_SEARCH_VEL is the speed that the initial homing move runs at, then it backs off the limit switch to the HOME_OFFSET position, then it will retrigger the home switch at a slower speed for precision. your search and latch velocities are both negative, the sequence changes if you invert the latch direction. you should experiment with the latch direction until it's right. The type of switch you're using dictates how you should do this

Your HOME_OFFSET looks pretty suspect. This should be a small number but large enough to de-activate the switch you're using but not 250mm....this is not the "home" position.  Your min limit is -400, and your max limit is 400. So after homing  it is saying that your max limit of 400mm is actually 250mm away from where it found the home switch. HOME=0.00 will put your 

I would try this, then adjust from there:

HOME_IS_SHARED=1

HOME_OFFSET=10

HOME=0 (the way your min and max limits are set this should be the middle of the machine)

HOME_LATCH_VEL= -.5 (or .5 to see if inverting helps)

Another thing to note is that I personally never tried using a NC switch on a non inverted input. Whereas the limit switch is read as "true" when it is not being triggered. This should be OK I think but if all else fails you can use the "not" component to invert the signal between the switch and the axis.n.limit-inpin

[Klemen Zhivko]

I did all those changes and I still get: joint 0 on limit switch error

19:24:28,712 [Thread-94] 67801781 INFO commands.MachineKitStart: command #18 from ['56E58679-B43F81A0'] completed

19:24:28,764 [Thread-94] 67801833 INFO commands.MachineKitStart: process command called, id: ['56E58679-B43F81A0']

19:24:28,771 [Thread-94] 67801840 INFO commands.MachineKitStart: Issuing EMC_TASK_SET_STATE -- (+505,+16,    +5,    +4,)

19:24:28,782 [Thread-94] 67801851 INFO commands.MachineKitStart: joint 0 on limit switch error

19:24:28,786 [Thread-94] 67801855 INFO commands.MachineKitStart: emc/task/taskintf.cc 617: Error on axis 0, command number 148

I posted latest config files in my above github link.

I am trying to upgrade my BBB machinekit to latest version though - and I miss libzzmq ver.4 - I cannot pass this condition:

checking whether to build unstable development code... not building  development code

checking pkg-config is at least version 0.9.0... yes

checking for CZMQ... no

configure: error: Package requirements (libczmq > 4.0) were not met:

Requested 'libczmq > 4.0' but version of libczmq is 3.0.2

Consider adjusting the PKG_CONFIG_PATH environment variable if you

installed software in a non-standard prefix.

Alternatively, you may set the environment variables CZMQ_CFLAGS

and CZMQ_LIBS to avoid the need to call pkg-config.

See the pkg-config man page for more details.

[justin White]

https://github.com/zhivko/PipeCutter/blob/master/src/main/resources/myini/machinekit/CRAMPS.ini

If this is your current .ini file you did not make the changes, not for the right axis anyway. Your setup is still a mess. you now have a min/max limit of -251/251 with a home_offset of 250......why?

This is your joint/axis 0

[AXIS_0]

# 
# Step timing is 40 us steplen + 40 us stepspace
# That gives 80 us step period = 12.5 KHz step freq
#
# Bah, even software stepping can handle that, hm2 doesnt buy you much with
# such slow steppers.
#
# Scale is 200 steps/rev * 5 revs/inch = 1000 steps/inch
#
# This gives a maxvel of 12.5/1 = 12.5 ips
#
TYPE =              LINEAR
MAX_VELOCITY = 		20.0
MAX_ACCELERATION = 	5000.0
# Set Stepgen max 20% higher than the axis
STEPGEN_MAX_VEL = 	70.0
STEPGEN_MIN_VEL =    0.001

STEPGEN_MAX_ACC = 	5000.0
STEPGEN_MIN_VEL =    0.001

BACKLASH =           0.000

# scale is 1600 steps/rev * (1/8) revs/mm = 200
# scale is 800 steps/rev * (1/8) revs/mm = 100
SCALE =  -200

MIN_LIMIT =             -251.0
MAX_LIMIT =             251.0

#FERROR =     20.0
#MIN_FERROR = 5.00
FERROR =     5
MIN_FERROR = 0.25


HOME =                  0.000
HOME_OFFSET =           250.00
HOME_IGNORE_LIMITS =    NO
HOME_USE_INDEX =        NO
HOME_SEQUENCE =         0
HOME_IS_SHARED =		0

# Set to zero if you don't have physical home/limit switches
# Set to the desired homing and latch velocity if you have switches
# See: https://github.com/machinekit/machinekit-docs
HOME_SEARCH_VEL =       7
HOME_LATCH_VEL =        1

# these are in nanoseconds
DIRSETUP   =              2000
DIRHOLD    =              2000
STEPLEN    =             10000
STEPSPACE  =             10000

This is what it needs to be....no/0/false all mean the same thing on the boolean parameters:

HOME_IGNORE_LIMITS =  YES
HOME_IS_SHARED =      YES

For the rest of it you should read this:

http://linuxcnc.org/docs/html/config/ini-homing.html

The .ini is in too bad a shape to really help with until you make some changes but changing the above should get rid of the joint 0 error.

[Klemen Zhivko]

Hi Justin,

from machinekit docs: http://www.machinekit.io/docs/config/ini_homing/#home_offset

it says: ..."Contains the location of the home switch or index pulse, in joint coordinates. It can also be treated as the distance between the point where the switch or index pulse is latched and the zero point of the joint. After detecting the index pulse, Machinekit sets the joint coordinate of the current point to HOME_OFFSET."

Since my limit switch for X axis (axis 0) is at 250, I set this to 250. - middle of workpiece is at location 0.

"not for the right axis anyway" - why? I have only x limit switches and AXIS_0 IS x axis in my case? What do you mean not the right axis anyway ?

" you now have a min/max limit of -251/251 with a home_offset of 250......why?" 

limits of x axe are -251 and 251, and home_offset by definition from docs (quoted above) should be 250 ?? Please correct me if I do not understand correctly.

I am still getting "joint 0 on limit switch error" while homing axis 0. I updated git with latest configs.

For HOME_IGNORE_LIMITS documentation says "If you do not have a separate home switch set this to YES and case connect the limit switch signal to the home switch input in HAL".

I have separate home switch (cramps hat for bbb has XYZ for each min max pins available), therefore I set that to NO. But I also tried with YES and I get error in each case.

Regarding my 0 value instead YES - it must be because I read documentation you mention - in http://linuxcnc.org/docs/html/config/ini-homing.html - in there it says:

3.8. HOME_IS_SHARED

If there is not a separate home switch input for this axis, but a number of momentary switches wired to the same pin, set this value to 1 to prevent homing from starting if one of the shared switches is already closed. Set this value to 0 to permit homing even if the switch is already closed.

You will see linuxcnc is using 0, and machinekit NO.

This is output from log:

00:57:45,181 [Thread-314] 174198250 INFO commands.MachineKitStart: emcTaskPlanSynch() returned 0

00:57:45,183 [Thread-314] 174198252 INFO commands.MachineKitStart: joint 0 on limit switch error

00:57:45,197 [Thread-314] 174198266 INFO commands.MachineKitStart: NML_INTERP_LIST::append(nml_msg_ptr{size=12,type=EMC_TASK_PLAN_SYNCH}) : list_size=1, line_number=0

00:57:45,207 [Thread-314] 174198276 INFO commands.MachineKitStart: waiting for command #87 from ['56E58679-B43F81A0'] to complete

00:57:45,298 [Thread-314] 174198367 INFO commands.MachineKitStart: sending task message

00:57:45,656 [Thread-314] 174198725 INFO commands.MachineKitStart: sending motion message

00:57:46,104 [Thread-314] 174199173 INFO commands.MachineKitStart: send_pbcontainer: type: MT_PING

00:57:46,105 [Thread-314] 174199174 INFO commands.MachineKitStart: 

00:57:46,106 [Thread-314] 174199175 INFO commands.MachineKitStart: send_pbcontainer: type: MT_PING

00:57:46,106 [Thread-314] 174199175 INFO commands.MachineKitStart: 

00:57:46,167 [Thread-314] 174199236 INFO commands.MachineKitStart: D: 19-08-20 22:57:48 [017] 56E58679-B43F81A0

00:57:46,167 [Thread-314] 174199236 INFO commands.MachineKitStart: D: 19-08-20 22:57:48 [003] 08D201

00:57:46,167 [Thread-314] 174199236 INFO commands.MachineKitStart: handle_command_input: req=type: MT_PING

00:57:46,167 [Thread-314] 174199236 INFO commands.MachineKitStart: 

00:57:46,168 [Thread-314] 174199237 INFO commands.MachineKitStart: send_pbcontainer: type: MT_PING_ACKNOWLEDGE

00:57:46,168 [Thread-314] 174199237 INFO commands.MachineKitStart: uuid: "\265\371\254\026\303\235\021\351\265gTJ\026\305\320*"

00:57:46,168 [Thread-314] 174199237 INFO commands.MachineKitStart: 

00:57:47,166 [Thread-314] 174200235 INFO commands.MachineKitStart: D: 19-08-20 22:57:49 [017] 56E58679-B43F81A0

00:57:47,166 [Thread-314] 174200235 INFO commands.MachineKitStart: D: 19-08-20 22:57:49 [003] 08D201

00:57:47,166 [Thread-314] 174200235 INFO commands.MachineKitStart: handle_command_input: req=type: MT_PING

00:57:47,166 [Thread-314] 174200235 INFO commands.MachineKitStart: 

00:57:47,168 [Thread-314] 174200237 INFO commands.MachineKitStart: send_pbcontainer: type: MT_PING_ACKNOWLEDGE

00:57:47,168 [Thread-314] 174200237 INFO commands.MachineKitStart: uuid: "\265\371\254\026\303\235\021\351\265gTJ\026\305\320*"

00:57:47,168 [Thread-314] 174200237 INFO commands.MachineKitStart: 

00:57:48,104 [Thread-314] 174201173 INFO commands.MachineKitStart: send_pbcontainer: type: MT_PING

00:57:48,104 [Thread-314] 174201173 INFO commands.MachineKitStart: 

00:57:48,105 [Thread-314] 174201174 INFO commands.MachineKitStart: send_pbcontainer: type: MT_PING

00:57:48,105 [Thread-314] 174201174 INFO commands.MachineKitStart: 

00:57:48,167 [Thread-314] 174201236 INFO commands.MachineKitStart: D: 19-08-20 22:57:50 [017] 56E58679-B43F81A0

00:57:48,167 [Thread-314] 174201236 INFO commands.MachineKitStart: D: 19-08-20 22:57:50 [003] 08D201

00:57:48,167 [Thread-314] 174201236 INFO commands.MachineKitStart: handle_command_input: req=type: MT_PING

00:57:48,167 [Thread-314] 174201236 INFO commands.MachineKitStart: 

00:57:48,168 [Thread-314] 174201237 INFO commands.MachineKitStart: send_pbcontainer: type: MT_PING_ACKNOWLEDGE

00:57:48,168 [Thread-314] 174201237 INFO commands.MachineKitStart: uuid: "\265\371\254\026\303\235\021\351\265gTJ\026\305\320*"

00:57:48,168 [Thread-314] 174201237 INFO commands.MachineKitStart: 

00:57:49,165 [Thread-314] 174202234 INFO commands.MachineKitStart: D: 19-08-20 22:57:51 [017] 56E58679-B43F81A0

00:57:49,166 [Thread-314] 174202235 INFO commands.MachineKitStart: D: 19-08-20 22:57:51 [003] 08D201

00:57:49,167 [Thread-314] 174202236 INFO commands.MachineKitStart: handle_command_input: req=type: MT_PING

00:57:49,167 [Thread-314] 174202236 INFO commands.MachineKitStart: 

00:57:49,169 [Thread-314] 174202238 INFO commands.MachineKitStart: send_pbcontainer: type: MT_PING_ACKNOWLEDGE

00:57:49,169 [Thread-314] 174202238 INFO commands.MachineKitStart: uuid: "\265\371\254\026\303\235\021\351\265gTJ\026\305\320*"

00:57:49,169 [Thread-314] 174202238 INFO commands.MachineKitStart: 

00:57:50,104 [Thread-314] 174203173 INFO commands.MachineKitStart: send_pbcontainer: type: MT_PING

00:57:50,104 [Thread-314] 174203173 INFO commands.MachineKitStart: 

00:57:50,105 [Thread-314] 174203174 INFO commands.MachineKitStart: send_pbcontainer: type: MT_PING

00:57:50,105 [Thread-314] 174203174 INFO commands.MachineKitStart: 

00:57:50,166 [Thread-314] 174203235 INFO commands.MachineKitStart: D: 19-08-20 22:57:52 [017] 56E58679-B43F81A0

00:57:50,167 [Thread-314] 174203236 INFO commands.MachineKitStart: D: 19-08-20 22:57:52 [003] 08D201

00:57:50,169 [Thread-314] 174203238 INFO commands.MachineKitStart: handle_command_input: req=type: MT_PING

00:57:50,169 [Thread-314] 174203238 INFO commands.MachineKitStart: 

00:57:50,170 [Thread-314] 174203239 INFO commands.MachineKitStart: send_pbcontainer: type: MT_PING_ACKNOWLEDGE

00:57:50,170 [Thread-314] 174203239 INFO commands.MachineKitStart: uuid: "\265\371\254\026\303\235\021\351\265gTJ\026\305\320*"

00:57:50,170 [Thread-314] 174203239 INFO commands.MachineKitStart: 

00:57:50,593 [Thread-314] 174203662 INFO commands.MachineKitStart: command #87 from ['56E58679-B43F81A0'] completed

00:57:50,596 [Thread-314] 174203665 INFO commands.MachineKitStart: process command called, id: ['56E58679-B43F81A0']

00:57:50,612 [Thread-314] 174203681 INFO commands.MachineKitStart: Issuing EMC_TASK_SET_STATE -- (+505,+16,    +8,    +4,)

00:57:50,625 [Thread-314] 174203694 INFO commands.MachineKitStart: joint 0 on limit switch error

00:57:50,627 [Thread-314] 174203696 INFO commands.MachineKitStart: emc/task/taskintf.cc 617: Error on axis 0, command number 176

[justin White]

Here,

Read this post and hopefully you'll get a better idea of what's going on.

https://www.forum.linuxcnc.org/forum/32-documents/12146-an-explanation-of-limits-homing-hope-its-clear

If you DO have a home switch you did not make a connection for it in hal. The instructions I gave you to edit your hal file were based on the idea that I thought you were homing to a limit switch. If your home switch isn't at the very end of travel on the axis I suggest you don't bother with it and just home to the limit switch.

For HOME_IGNORE_LIMITS documentation says "If you do not have a separate home switch set this to YES and case connect the limit switch signal to the home switch input in HAL".

I have separate home switch (cramps hat for bbb has XYZ for each min max pins available), therefore I set that to NO. But I also tried with YES and I get error in each case.

Doesn't matter if you have a home switch if you haven't connected it to anything in hal. Are all of the switches connected to different pins on the BBB?

limits of x axe are -251 and 251, and home_offset by definition from docs (quoted above) should be 250 ?? Please correct me if I do not understand correctly.

No idea, I thought you were trying home to a limit switch. Where is your home switch located, how long is the axis exactly, and why bother with the home switch anyway?

You will see linuxcnc is using 0, and machinekit NO.

I assure you, it does not matter. Machinekit is built on an old version of LinuxCNC. This is the X axis on one of my machines running on LinuxCNC, you will see the word "NO"

#********************

# Axis X

#********************

[AXIS_X]

MIN_LIMIT = 0

MAX_LIMIT = 20.65

MAX_VELOCITY = 4

MAX_ACCELERATION = 15

[JOINT_0]

TYPE = LINEAR

HOME = 10.325

FERROR = 0.5

MIN_FERROR = 0.05

MAX_VELOCITY = 4

MAX_ACCELERATION = 15

# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION

# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.

STEPGEN_MAXVEL = 5

STEPGEN_MAXACCEL = 20

P = 1000

I = 0

D = 0

FF0 = 0

FF1 = 1

FF2 = 0

BIAS = 0

DEADBAND = 0

MAX_OUTPUT = 0

# these are in nanoseconds

DIRSETUP   = 7500

DIRHOLD    = 2000

STEPLEN    = 7500

STEPSPACE  = 1000

STEP_SCALE = -3446.67

#MIN_LIMIT = 0

#MAX_LIMIT = 20.65

HOME_OFFSET = -0.2500000

HOME_SEARCH_VEL = -0.7

HOME_LATCH_VEL = -0.2

HOME_FINAL_VEL = 1

HOME_USE_INDEX = NO

HOME_IGNORE_LIMITS = NO

HOME_SEQUENCE = 0

 

[Klemen Zhivko]

Hi,

I am feeling hopeless here so thank you bearing with me.

I think I have terminology misunderstanding. Please check picture:

I belive that this on picture is called home switch, and I actually dont care about limit switch - I want to have configuration that cares about this home switch only - and only for X axis - other axis should not be taken into acount while homing. Do I have correct configuration for  this?

You say limit switches are not connected in hal - have you seen my configuration? I am pasting it again below.

I also checked in halscope (my previous post picture) and I can see limit-x-max and limit-x-min behaving correctly when they are manually pressed by hand in halscope. So they must be correctly connected physiscally and on cramps hat and throu hal config?

I am not sure if other limit switches for y z are dissturbing homing proedure? Again can you check my hal (github link I posted befoore - here it is again for convenience: https://github.com/zhivko/PipeCutter/blob/master/src/main/resources/myini/machinekit/CRAMPS.hal) to see if this is the case?

My limitswitch section in CRAMPS.HAL file (have you saw this?) - So Why do you say I dont have connected it to hal?

# ################
# Limit Switches
# ################
newsig limit-x-min bit
newsig limit-x-max bit
newsig limit-y-min bit
newsig limit-y-max bit
#newsig limit-z-min bit
newsig limit-z-max bit

setp debounce.1.delay 50
#net limit-x-min <= bb_gpio.p8.in-08
sets limit-x-min 1
net X-unfilt bb_gpio.p8.in-07 => debounce.1.0.in
net limit-x-max <= debounce.1.0.out
net limit-y-min <= bb_gpio.p8.in-10
net limit-y-max <= bb_gpio.p8.in-09
#net limit-z-min <= bb_gpio.p9.in-13
net limit-z-max <= bb_gpio.p9.in-11

# Adjust as needed for your switch polarity
setp bb_gpio.p8.in-08.invert 1
setp bb_gpio.p8.in-07.invert 1
setp bb_gpio.p8.in-10.invert 1
setp bb_gpio.p8.in-09.invert 1
setp bb_gpio.p9.in-11.invert 1
#setp bb_gpio.p9.in-13.invert 1

# Uncomment if you actually have limit switches setup
# You probably want to setup homing in the INI file, as well
net limit-x-min => axis.0.home-sw-in

net limit-x-min => axis.0.neg-lim-sw-in
net limit-x-max => axis.0.pos-lim-sw-in

#net limit-y-min => axis.1.home-sw-in
#net limit-y-min => axis.1.neg-lim-sw-in
#net limit-y-max => axis.1.pos-lim-sw-in
#net limit-z-min => axis.2.home-sw-in
#net limit-z-min => axis.2.neg-lim-sw-in
net limit-z-max => axis.2.pos-lim-sw-in

[justin White]

That is a limit switch since it's at the very end of travel, but there's only one switch? The first hal file you posted had that whole section commented out.

That is either your min-limit, or your max limit, depending on how that thing is oriented. I would tend to call that the Min-limit but that's up to  you. If that's your minimum limit switch then you don't have a home or max limit switch.

[Klemen Živkovič]

Yes there is only one switch - this is enough for calibrating x axis - no?

It is max limit switch since it position is positive.

Have you seen anything weird in my last configuration because I still cannot make this work?

regards

On Wed, 21 Aug 2019 at 14:44, justin White <blaz...@gmail.com> wrote:

That is a limit switch since it's at the very end of travel, but there's only one switch? The first hal file you posted had that whole section commented out.

That is either your min-limit, or your max limit, depending on how that thing is oriented. I would tend to call that the Min-limit but that's up to  you. If that's your minimum limit switch then you don't have a home or max limit switch.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/6a9AUOleAXE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/e52adf48-2a4f-4eb2-bf1b-615648763e56%40googlegroups.com.

--

Klemen Živkovič

Župančičeva 34

1290 Grosuplje

Slovenia

mobile: 051 381 888

[justin White]

Yes you can make one switch work.

Change lines 340-342 to this:

net limit-x-max => axis.0.home-sw-in

net limit-x-min => axis.0.neg-lim-sw-in

net limit-x-max => axis.0.pos-lim-sw-in

Now your axis 0 max and home hal pins  are connected to the same signal. Keep HOME_INGNORE_LIMITS=YES because you have to ignore the fact that you will trip the limit switch signal while homing

As you see by the post I linked to it is not perefereable to have your switches reading true when they are not tripped, this is the case because your switches are NC and you are using a non-inverted input.. Whether this can work or not I don't know toggle this line to 0 or 1:

setp bb_gpio.p8.in-07.invert 1

....until the signal "limit-x-max" reads false when the switch is not tripped. It's still a NC switch and operates the same way, all you're doing here is changing the value that it is seen as in hal.

On Wednesday, August 21, 2019 at 9:40:47 AM UTC-4, Klemen Živkovič wrote:

Yes there is only one switch - this is enough for calibrating x axis - no?

It is max limit switch since it position is positive.

Have you seen anything weird in my last configuration because I still cannot make this work?

regards

On Wed, 21 Aug 2019 at 14:44, justin White <blaz...@gmail.com> wrote:

That is a limit switch since it's at the very end of travel, but there's only one switch? The first hal file you posted had that whole section commented out.

That is either your min-limit, or your max limit, depending on how that thing is oriented. I would tend to call that the Min-limit but that's up to  you. If that's your minimum limit switch then you don't have a home or max limit switch.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/6a9AUOleAXE/unsubscribe.

To unsubscribe from this group and all its topics, send an email to machi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/e52adf48-2a4f-4eb2-bf1b-615648763e56%40googlegroups.com.

[Klemen Živkovič]

Thanks Justin,

I will try this immediately.

As per your suggestion I changed switch to NO switch.

On halscope I saw that raw signal from beaglebone oscillates pretty much, and it is not clear to me why, as it is tied to 5v over resistor.

See x-max signal fro cramps schematic.

https://reprap.org/mediawiki/images/5/5a/CRAMPS.v2.1.sch.pdf

However I use debounce in my hal, and signal seems to be stable as saw from my previous halscope picture.

Regards

To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/58db6373-158b-4420-a136-e6ab6f172664%40googlegroups.com.

[justin White]

You didn't need to change the switch, just the "polarity" that it's seen as in hal. I don't use a BBB but since it has an "invert" parameter on the GPIO pins, that should do the job. I was actually incorrect in what I said before, that signal is prior to the pin input so it won't change by inverting the BB pin. looking at the BBB pin in hal should show it's value is inverted if you set the invert parameter. Otherwise you could also use the "not" component prior to the BBB pin to do the same thing.

Or if it's easier for you and you have extra switches laying around you can try the NO switch like you said.

To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/58db6373-158b-4420-a136-e6ab6f172664%40googlegroups.com.

[Klemen Zhivko]

Justin,

it is working, thank you SO MUCH!

Now I only need to set proper HOME_OFFSET through protobuffer and zmq. Maybe @machinekoder could help what is right procedure to build command that needs to be sent to MK.

regards,

To unsubscribe from this group and all its topics, send an email to machinekit+unsubscribe@googlegroups.com.