hzeller / beagleg Goto Github PK

The following does PostScript output does not seem to work anymore

make -C src clean && make -C src/ gcode2ps && ./src/gcode2ps -o/tmp/x.ps -T2 -c src/testdata/step-speed-same.config -s src/testdata/superellipse.gcode

With git-bisect with the following starting conditions:

git bisect start
git bisect bad
git bisect good 2922596044466d63c120605e31a2d619bc7d36a7

... it can be tracked to 12d3e14 (The M114 change). Possibly some reporting the postscript generator was relying on is not working anymore.

I'm trying to run repeated small move to approach the tool very closely to an object. The exact position of the object is not known before doing this operation. Thus while i'm pressing a button, small move commands (G0X0.005F300) are sended every 10ms. In previous versions of machine-control, this action worked well and allowed to get an accurate positioning of the tool.

Since the "new" planner has been released (2 years ago), this operation is not working anymore, moving only occurred when I stop sending commands. It seems to come from the planner. In the method Planner::Impl::issue_motor_move_if_possible, while the planning_buffer_ size is < to the planning_buffer_capacity, the planner wait to enqueue segments in motor_ops_.

 if (num_segments == 0 &&
      (planning_buffer_.size() == planning_buffer_.capacity()))
    ++num_segments;

In my use case, the move commands are thus treated when I stop sending commands, or when the planning_buffer get full.
In the past version, the segments were enqueue when at least 3 segments were requested.

Is there any idea to fix this ?

I tried another approach that is to send a large move G0X300, and send M0 to stop the move when I want. But it appears that the M0 is treated after G0X300. Maybe I missed something ?

m114 calls mprint_current_position

grbl has a 'parser state' command "$G", see https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands
which displays the parser modes, G0/G1, G90/G91, G20/G21 etc.

Having the parser state query-able enables GUIs to be restarted during GUI development. Upon reset, the GUI can query parser state and display modes of the running machine. Otherwise the GUI has a set machine's state to know values which are persisted across GUI reboots.

I am trying to get started with the CRAMPS tree overlay. My kernel version from /boot/uEnv.txt is uname_r=4.19.94-ti-r42

When I run sudo ./start-devicetree-overlay.sh CRAMPS/BeagleG-CRAMPS.dts
I get the following output:

`make: 'CRAMPS/BeagleG-CRAMPS-00A0.dtbo' is up to date.

Adding BeagleG-CRAMPS overlay
./start-devicetree-overlay.sh: line 69: /sys/devices/bone_capemgr.*/slots: No such file or directory
cat: '/sys/devices/bone_capemgr.*/slots': No such file or directory`

It seems that the bone_capemgr directory is no longer present. It seems that for newer kernel versions the we might not compile and load the device tree overlays in this way. I will try to read more to understand how this updated process works but wondering if someone else has had this issue.

Is there a plan to add more kinematics transformation to fit more different machine?

Hello Everyone,
do you have any thoughts about how to add jerk in the speed profile in order to smooth-out the accelerations and avoid machine trashing (for example for the arcs)?

It could be interesting to give motor-operations a feedback about the actual status and positioning of the motors. Since it's nice having beagleg agnostic regarding the external hardware it would be a nice plugin-like feature

So with a small feed-rate, the new M114 dynamic update of the current position does not seem to work:
With the configuration file below, let's do some move and watch the position update. Here we use some moderately fast feedrate:

G1 X100 F500
ok
M114
X:31.200 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:31.200 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok
M114
X:40.744 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:40.744 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok
M114
X:48.919 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:48.919 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok
M114
X:99.994 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:99.994 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok

Looks beautiful. Now let's move with a slow feedrate. Now, if we request M114, suddenly all values are shown to zero. Eventually, the M114 , when the motor stops and we ask again, it now has the final position.

G1 X50 F100
ok
M114
X:0.000 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok
M114
X:0.000 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok
M114
X:0.000 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok
M114
X:0.000 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok
M114
X:0.000 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok
M114
X:50.006 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:50.006 Y:0.000 Z:0.000] (Unsure: machine never homed!)

Here is the minimal configuration:

[ General ]
require-homing    = no
range-check       = no

[ X-Axis ]
steps-per-mm     = 16 * 200 / 60
max-feedrate     = 400 
max-acceleration = 2000
range            = 300 
home-pos         = min

[ Motor-Mapping ]
motor_1 = axis:x

[ Switch-Mapping ]
switch_1 = active:high min_x max_x

Program started with:

sudo ./machine-control --port 8888 -c minimal.config

Currently, we only support the Timer pins for PWM generation. But there is also other PWM dedicated hardware in the am335x (eHRPWM), which we also should support if possible. This would also expand the available Pins people can use for PWM (see limit mentioned in #24)

Should we update the first level Makefile inside src/ such that all the tests inside the other folders are run when running "make test"?

Or write another target such as test all etc..

I had a set-up where the step size was .053125mm

When I would run G28, homing would seem to work until it reached the endstop, but then the program would hang and there was not output to the steppers anymore. After I reduced the step size by adding more microstepping, the problem went away.

What I think was happening was that it would hit the endstop and then try to backoff with the smaller step size. Maybe due to rounding it would not actually issues any steps. I have not tried any modifications to the code, but I looked at line 698 in gcode-machine-control.cc to get an idea of what might be happening
const float kHomingMM = (backoff) ? 0.5 : 0.05; // TODO: make configurable? const float kBackoffMM = kHomingMM / 10.0; // TODO: make configurable?

In order to have a side-channel to communicate with the machine, a status server has been added recently, but at this point it is merely an experimental stub.

There can be multiple types of status services, one could be a fully fledged webserver that allows to interact with the machine, but having the simplicity of a very simple request/response socket service would allow for very easy interaction with some UI (which can be an LCD on the machine or something else).

Right now, the interaction is super simple: a single letter in, some JSON formatted variables back

p
{"x_axis":100.000, "y_axis":122.000, "z_axis":0.000, "note":"experimental"}

The request should probably be some json request, to be able to convey parameters easily. Or we go with query parameters similar to HTTP GET requests (?q=some_query). Output as JSON is probably an ok output though somewhat harder to parse than a token-delimited format; it is supported by many languages out of the box and allows flexible extension of what we send.

Anyway, let's discuss what we actually want and what should be provided, so that we then can design what would be a good request/response model. I think it should allow to have extensive support to read the current status of the machine. And limited ways to change parameters without messing with the current running GCode too much:

• Query options: dump positions and variables, somewhat related to this issue. In case of a 3D printer, would also output the temperatures etc.
• Limited capability to modify the current machine that does not mess with positioning, e.g. changing speed factors or acceleration parameters.
• Issuing pause and emergency stops
• Act as an input channel for other machine pauses (e.g. tool change etc.)
• Subscribing to variable changes (added in a comment below by @holla2040)

What else ? Hartley, you have added some functionality to your local status server, what did you add ?

The program compiled from the git repo fails with the message:

prussdrv_open() failed (-1) No such file or directory
machine-control: pru-motion-queue.cc:175: PRUMotionQueue::PRUMotionQueue(HardwareMapping*, PruHardwareInterface*): Assertion `success' failed.
Aborted

There seems to be previous discussions and patches for PRU issues, but nothing recent. I've followed all the instructions to the letter, including setting the overlay and starting the uio_pruss kernel module, but nothing works,

The only thing I've not tried is updating the kernel, since there doesn't seem the be any recent bone kernels released on the linked eLinux page. I'm currently using the kernel supplied with the latest image, namely 4.4.91-ti-r133.

Now, I test beagleG on debian 8.3.

I solve the problem of pruss,but now the step can't be enable .

The debian version is one-debian-8.3-lxqt-4gb-armhf-2016-01-24-4gb.img

Hi,

I have tried latest BeagleG code on xenomai-r79 (machinekit) but have some problems.
It is clear GIT checkout with all defaults.

If I run ./machine-control -p 3000 --nohoming-required -c sample.config after several G-code commands something goes bad, got following in console:

INFO  [2016-06-30 17:21:06.049176] Accepting new connection from 192.168.0.230
Bus error

G-codes transaction looks like this in terminal:

telnet beaglebone-02 3000
Trying 192.168.0.6...
Connected to beaglebone-02.
Escape character is '^]'.
G01 F10 X100 M114 M114
ok
X:0.000 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok
X:0.000 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok
M114
X:100.003 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:100.003 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok
G01 X1 M114 M114
ok
X:100.003 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:100.003 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok
X:100.003 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:100.003 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok
Connection closed by foreign host.

In syslog I only get this:

Jun 30 17:21:51 beaglebone-02 kernel: [ 1643.269886] Alignment trap: not handling instruction f843ec10 at [<00014c9a>]
Jun 30 17:21:51 beaglebone-02 kernel: [ 1643.277375] Unhandled fault: alignment exception (0x801) at 0xb6c88036

Any clue what can be wrong here?

There's an additional question at the bottom too.
I'm having trouble with your list of instructions (numbered for reference):

1 git clone [email protected]:beagleboard/am335x_pru_package.git
2 cd am335x_pru_package/
3 cd pru_sw/utils/pasm_source ; ./linuxbuild ; cd -
4 make -C pru_sw/app_loader/interface/
5 cd ..

on line 4, my BBB gives me this error:

root@beaglebone:~/Desktop/am335x_pru_package# make -C pru_sw/app_loader/interface/
make: Entering directory `/home/root/Desktop/am335x_pru_package/pru_sw/app_loader/interface'
arm-arago-linux-gnueabi-gcc -I. -Wall -I../include   -c -g -O0 -D__DEBUG -o debug/prussdrv.o prussdrv.c
make: arm-arago-linux-gnueabi-gcc: Command not found
make: *** [debug/prussdrv.o] Error 127
make: Leaving directory `/home/root/Desktop/am335x_pru_package/pru_sw/app_loader/interface'
root@beaglebone:~/Desktop/am335x_pru_package#

My full kernel version is (because I realized there was a -a flag I could use), it's the one that the board arrived with:

root@beaglebone:~/Desktop/am335x_pru_package# uname -a
Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l GNU/Linux

Additional Question:
So the README description talks of the "host pc." does that mean that the majority of this code is running on the host pc? or on the BBB processor itself? I know the .p file probably runs on the PRU, and that the g-code files come from the host pc, but I'm less sure where everything else is running.

And apologies if any of my questions seem tedious or simple. I'm new to linux and only slightly knowledgeable of C and assembly programming. I'm excited to see if I can get your code to work with my project though.

Hello @hzeller ,
is it possible, from the actual state of the code, to get the queue status from an external process (for example monitoring)? If the code is not ready yet and if you are interested in this feature, how would you like it to be implemented?

Actully,The endstop can be setted for A b or C axis , The motor will stop when the endstop is triggered ,but when G28 is runing ,the triggered endstop of A B or C will block the hole progress, untill I release the endstop by hand.
I think that means there is no walking-back move when running G28.
I want to know how to fix it.

Pin display loop only displays pin 0. I changed $SLOTS to have bone_capemgr.8 because I couldn't find .9 on my board. I'm unsure if the overlay actually changed the pin modes. Output is shown below.

I'm very interested in your work by the way. Is it okay if I come to you with specific questions about the code if they come up?

root@beaglebone:~/Desktop/beagleg# bash -x ./beagleg-cape-pinmux.sh > templog.txt
+ BIN_DTB=BeagleG-00A0.dtbo
+ '[' '!' -e BeagleG-00A0.dtbo ']'
+ PINS=/sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ SLOTS=/sys/devices/bone_capemgr.8/slots
++ grep 0x
++ awk '{printf("%03x\n", $1 + 2048);}'
++ cat BeagleG.dts
+ OFFSETS_800='800
800
800
800
800
800
800
800
800
800
800
800
800
800
800
800
800'
+ echo 'This is how these pins look before.'
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ cp BeagleG-00A0.dtbo /lib/firmware
+ echo
+ echo 'Adding BeagleG overlay'
+ echo BeagleG
+ cat /sys/devices/bone_capemgr.8/slots
+ echo
+ echo 'This is how these pins look afterwards'
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
+ for f in '$OFFSETS_800'
+ grep 800 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
root@beaglebone:~/Desktop/beagleg# 

Currently, PWM only works on the Timer pins, which are only a few. Either compilation should fail or startup should warn if such pins are mapped. Currently it just silently doesn't work if a PWM pin is mapped in the hardware-pin-mapping.h to an unsupported pin.

Currently the E-Stop input is not being checked.

On my machine, the E-Stop is connected up to disable the motors but BeagleG does not check the input at any time (that I can see).

The proper handling of the E-Stop should be something like this (open for discussion):

When the E-Stop is active BeagleG should abort any motion and ignore any incoming commands (i.e. do an internal M0 to set the Software E-Stop) until the E-Stop is deactivated. Once deactivated motion should not be allowed until the Software E-Stop is cleared by an M999.

I think this will involve hooking up the M0/M999 codes so that commands are not added to the PRU queue when the machine is in E-Stop.

After estop is triggered, the machine state is set to homing_state_ = GCodeMachineControl::HomingState::NEVER_HOMED;
and motors are shutdown. Segments could still be enqueued in the planner or in worse in the PRU.

We should enforce a clear state after that or an estop clear could lead to machine executing an unfinished PRU segment (at some undefined speed).

Using kernel ('uname -r'):

Linux beaglebone 3.8.13 #1 SMP Tue Jun 18 02:11:09 EDT 2013 armv7l GNU/Linux

Output from capemanager:

root@beaglebone:~/beagleg.new# cat $SLOTS
 0: 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU-01
 8: ff:P-O-L Override Board Name,00A0,Override Manuf,BeagleG

This is what I was getting before I fixed the problem (I added printf's based on the comments above blocks of code):

root@beaglebone:~/beagleg.new# ./machine-control -P casing_export.gcode
initilaize basic state and derived configuration
Always keep the steps_per_mm
Here we assign it to the 'const'
Mapping axes to physical motors
Now let's see what motors
-- Config --
X axis: 200.0mm/s,  4000.0mm/s^2, 160.000 steps/mm
Y axis: 200.0mm/s,  4000.0mm/s^2, 160.000 steps/mm
Z axis:  90.0mm/s,  1000.0mm/s^2, 160.000 steps/mm
E axis:  10.0mm/s, 10000.0mm/s^2,  40.000 steps/mm
A axis:   1.0mm/s,     1.0mm/s^2,   1.000 steps/mm
The parser keeps
geteuid
beagleg_init
map_gpio
Prepare all the pins
Bus error

The code was erroring out here:

gpio_0[GPIO_OE/4] = ~(MOTOR_OUT_BUTS | (1 << AUX_1_BIT) | (1 << AUX_2_BIT));

Per this discussion: https://groups.google.com/forum/#!topic/beagleboard/OYFp4EXawiI
It turns out the clocks for GPIO0 and GPIO1 are not necessarily initialized when you put an override cape on. The solution to this is manually activating at least one GPIO pin from GPIO0 and 1:

# echo 5 > /sys/class/gpio/export
# echo 65 > /sys/class/gpio/export
# echo 105 > /sys/class/gpio/export

At that point, I got normal output:

root@beaglebone:~/beagleg.new# ./machine-control -P casing_export.gcode
initilaize basic state and derived configuration
Always keep the steps_per_mm
Here we assign it to the 'const'
Mapping axes to physical motors
Now let's see what motors
-- Config --
X axis: 200.0mm/s,  4000.0mm/s^2, 160.000 steps/mm
Y axis: 200.0mm/s,  4000.0mm/s^2, 160.000 steps/mm
Z axis:  90.0mm/s,  1000.0mm/s^2, 160.000 steps/mm
E axis:  10.0mm/s, 10000.0mm/s^2,  40.000 steps/mm
A axis:   1.0mm/s,     1.0mm/s^2,   1.000 steps/mm
The parser keeps
geteuid
beagleg_init
map_gpio
Prepare all the pins
Prepare all the pins2
Prepare all the pins2
Prepare all the pins3
Get the interrupt
prussdrv_pru_write_memory
beagleg_init finished

Hello @hzeller ,
I was wondering if you are working on a version that supports the new kernel feature remoteproc to communicate with the PRUs and if not, if you would like beagleg to support that feature.

Hello again :)
I'm having trouble with the PRU I think.

After successfully building the am335_pru_package and beagleg code, I attempted to run the following line:

./send-gcode -P circle.gcode

my circle.gcode file looks like this:

G17 G20 G90 G94 G54
G0 Z0.25
X-0.5 Y0.
Z0.1
G01 Z0. F5.
G02 X0. Y0.5 I0.5 J0. F2.5
X0.5 Y0. I0. J-0.5
X0. Y-0.5 I-0.5 J0.
X-0.5 Y0. I0. J0.5
G01 Z0.1 F5.
G00 X0. Y0. Z0.25

My BBB spits out the following error:

prussdrv_open() failed (-1)

After reading up on the PRU a little bit, I wanted to ask you if you've ever seen this error before or if there was anything you did with the device tree overlay to get the PRU working? The sources I've looked at seem to suggest that there is something beyond just changing pins to mode 7 (GPIO mode) was necessary to get the PRU to interact with them.

A picture of my setup for reference:

Looks like some dependencies are not properly declared:

make clean
make -C src test-binaries  # now these should be built.
make -C src test-binaries  # ... however, this is not a no-op but also builds something

While we are in soft-estop, we can emit motor moves, but no error is reported:

Precondition here: we are in soft-estop (e.g. --nohoming-required but not yet emitted M999)

M114
X:0.000 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:95.000] [G54] (Unsure: machine never homed!)
ok
G1 Y100 F6000
ok
M114
X:0.000 Y:100.003 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:0.000 Y:100.003 Z:95.000] [G54] (Unsure: machine never homed!)
ok

... it looks like everything went fine, but since the motors are not enabled, there is actually no move, so now we're in the wrong physical position compared to the output of M114

I've been working on getting Machine control to work on beagle bone green wireless.

As a test case, I did an IO check. Setting up most of the motors and I/O and ran into a few issues.
attached, is a modified bumps.config file that has my comments so far and expands the sample.pins case.

I really appreciate the work done on this, unfortunately my lack of understanding matches my level of appreciation.
My ultimate goal is to build a wall mounted cnc router which will not need all the capabilities of this package. but to build understanding i've been trying to get all io to work.

One issue that did not make my notes and i noticed was closed before was regarding e-stop behavior. currently, a hard etsop will not stop a long gcode command, if you trigger the e-stop input during say G0 X50 F100 it will not be applied until the command completes.
bumps.pins.txt