Hey all,

Working on setting up a lasercutter of my own design on MachineKit and have 
hit an issue I haven't been able to figure out. Hoping it's something easy 
that a more educated person will spot easily.

*Issue is this:* 
I start machinekit
Toggle the Estop
Motors are enabled and buzzing/holding position
Click the turn on machine button
Attempt to jog either axis
The axis readout will show the machine position as moving, but the steppers 
don't actually move
If I jog too far, I get the Joint 0 Following Error

*Per the Doc Page for the Joint Following Error I've tried:*
Increasing FError and FError_Min to larger values (1 and .5 respectively) 
but this just increases the distance I can attempt to jog before it errors 
out.
Decreasing acceleration and speed to no noticeable effect

*Speculation:*
I removed the X stepper driver and measured the X Direction pin with a 
multimeter while attempting to jog in either direction, which showed no 
voltage on the pin. This leads me to believe I have something wrong in my 
software that is causing some kind of disconnect between the motion planner 
and the step generators, or the step generators and the actual hardware 
pins. Also confusing to me that the software knows the joint isn't 
following anymore when it's an open loop stepper. I'm assuming this means 
that machinekit somehow "knows" that the step pulses aren't actually being 
generated.

*Machine:* 
2 Axis lasercutter. Y is a gantry with 2 steppers. 
Limit switches when looking into the bed, left end of the machine (what I 
want to be X=0) and on the deep end of the Y axis (what I want to be Y=24.5)
Xylotex 6 Pack Board with BBB, running a machinekit image (3.8 kernel 
version from here 
<http://www.machinekit.io/docs/getting-started/machinekit-images/>)
X motor is connected to X axis output on board, Y1 motor connected to Y, 
and Y2 motor to Z

Rough attempt at a ASCII blueprint
___________________
||y                              y|| <-- Y limit switches
||                                  ||
||x=============== || <--gantry with X limit switch
||                                  ||    ↑ +y direction
||_________________||      → +x direction
      front of machine

Attached and pastebinned .hal and .ini, as well as the setup script and my 
run script, though those are stock and straightforward (respectively). My 
hal and ini are based on the Xylotex examples given here 
<http://xylotex.netfirms.com/OSCommerce/catalog/product_info.php?products_id=134&osCsid=5777e82243b0cbbe24058a0b8bad2c4b>,
 
and modified to gantry support roughly following here 
<https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/Probotix/Comet.hal>
.

I've spent a very long time trying to figure this out and I thoroughly 
appreciate any insight you can lend. Kinda stuck now as I don't have an 
informative error to track down, I've just been trying to compare my .hal 
to others and see what I have different. Would also be happy for anyone to 
point out mistakes/dumb things/future problems in my configs.

Xylotex_6Pack.ini <https://pastebin.com/Tis82rwV>
Xylotex_6Pack.hal <https://pastebin.com/sdMw2Fz2>
setup6.sh <https://pastebin.com/1cBArGjQ>
run.sh <https://pastebin.com/4maBHsuG>

Thanks Again,
Dominic

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Attachment: Xylotex_6Pack.ini
Description: Binary data

echo "Starting Machinekit"
machinekit machinekit/configs/Xylotex_6Pack.ini
#!/bin/bash
# Copyright 2014
# Charles Steinkuehler <[email protected]>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

dtbo_err () {
	echo "Error loading device tree overlay file: $DTBO" >&2
	exit 1
}

pin_err () {
	echo "Error exporting pin:$PIN" >&2
	exit 1
}

dir_err () {
	echo "Error setting direction:$DIR on pin:$PIN" >&2
	exit 1
}

SLOTS=/sys/devices/bone_capemgr.*/slots

# Make sure required device tree overlay(s) are loaded
for DTBO in cape-universal cape-bone-iio ; do

	if grep -q $DTBO $SLOTS ; then
		echo $DTBO overlay found
	else
		echo Loading $DTBO overlay
		sudo -A bash -c "echo $DTBO > $SLOTS" || dtbo_err
		sleep 1
	fi
done;

if [ ! -r /sys/devices/ocp.*/helper.*/AIN0 ] ; then
	echo Analog input files not found in /sys/devices/ocp.*/helper.* >&2
	exit 1;
fi

if [ ! -r /sys/class/uio/uio0 ] ; then
	echo PRU control files not found in /sys/class/uio/uio0 >&2
	exit 1;
fi

# Export GPIO pins:
# One pin needs to be exported to enable the low-level clocks for the GPIO
# modules (there is probably a better way to do this)
# 
# Any GPIO pins driven by the PRU need to have their direction set properly
# here.  The PRU does not do any setup of the GPIO, it just yanks on the
# pins and assumes you have the output enables configured already
# 
# Direct PRU inputs and outputs do not need to be configured here, the pin
# mux setup (which is handled by the device tree overlay) should be all
# the setup needed.
# 
# Any GPIO pins driven by the hal_bb_gpio driver do not need to be
# configured here.  The hal_bb_gpio module handles setting the output
# enable bits properly.  These pins _can_ however be set here without
# causing problems.  You may wish to do this for documentation or to make
# sure the pin starts with a known value as soon as possible.

sudo $(which config-pin) -f - <<- EOF
# INPUTS
	P8.08	in	# IN1
	P8.07	in	# IN2
	P8.10	in	# IN3
	P8.09	in	# IN4
	P9.13	in	# IN5
	P9.11	in	# IN6
	
#OUTPUTS
#	P8.11	out	# OUT1	
	P9.15	out	# OUT2	
	P9.27	out	# OUT3	
	P9.21	out	# OUT4	
	P9.41	out	# OUT5	
	P9.22	out	# OUT6
	
	P9.14	out	# AXIS_ENA	
	P9.23	out	# MCH_PWR
        P8.17   in      # ESTOP_IN
	P8.26   out     # ESTOP_OUT	

        P8.13	out	# X STEP
        P8.12	out	# X DIR
	P8.15	out	# Y STEP
	P8.14	out	# Y DIR
	P8.19	out	# Z STEP
	P8.18	out	# Z DIR
	P9.16	out	# A STEP
	P9.12	out	# A DIR
	P9.17	out	# B STEP
	P9.18	out	# B DIR
	P9.24	out	# C STEP
	P9.26	out	# C DIR	
           
EOF

Attachment: Xylotex_6Pack.hal
Description: Binary data

Reply via email to