Attempting to send simple g-code snippet and watch X motor move

[MantisClone]

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:

[MantisClone]

I tried adding this to the BeagleG.dts file:

  target = <&pruss>;  
    __overlay__ {  
      status = "okay";  
    };  
  }; 

But came out with the same results. :(

[hzeller]

Nice test-setup picture!

prussdrv_open() failed (-1) I have only seen on the BeagleBone when the code is not run as root.

FYI, some of your G-code looks funny, like G01 Z0. F5. My code doesn't really parse floating point numbers with a trailing dot not followed by a digit. I suggest removing that trailing dot for now (I might change the parsing to be able to deal with this). What program generated this ?

(Also, the G-code implementation is understanding mostly the commands in 3D printers; G17 is not a common one there. Be default, it will just be ignored, and skipping the whole line).

[MantisClone]

OH! okay I'll definitely try running as root.

And thanks for the G-code tips. I'll be honest, I'm not sure what generated that code there. I found it online and just copy-pasted it. Ill have to spend more time generating a real G-code file.

EDIT: Hmm after installing sudo I attempted it and received the same results:

root@beaglebone:~/Desktop/beagleg# sudo ./send-gcode -P circle.gcode
prussdrv_open() failed (-1)

[hzeller]

if run as root, the prussdrv_open() should succeed. So, not sure what is wrong in your set-up. Maybe dmesg spits out some message explaining things ?

[MantisClone]

I attempted dmesg right after receiving my prussdrv_open() failed (-1) message, but it didn't seem like anything significant. I saved the output to a text file if you're interested but the basic pattern can be seen in the last few lines of the file:

[38419.757331] gen_ndis_query_resp: RNDIS_OID_GEN_RCV_NO_BUFFER
[38419.761060]  gadget: rndis reqa1.01 v0000 i0000 l4096
[38419.761223]  gadget: rndis req21.00 v0000 i0000 l36
[38419.765074]  gadget: rndis reqa1.01 v0000 i0000 l4096
[38419.765255]  gadget: rndis req21.00 v0000 i0000 l36
[38419.769074]  gadget: rndis reqa1.01 v0000 i0000 l4096
[38419.769253]  gadget: rndis req21.00 v0000 i0000 l36
[38419.769314] gen_ndis_query_resp: RNDIS_OID_GEN_RCV_NO_BUFFER
[38419.773079]  gadget: rndis reqa1.01 v0000 i0000 l4096
[38419.773257]  gadget: rndis req21.00 v0000 i0000 l36
[38419.777069]  gadget: rndis reqa1.01 v0000 i0000 l4096
[38419.777254]  gadget: rndis req21.00 v0000 i0000 l36
[38419.781073]  gadget: rndis reqa1.01 v0000 i0000 l4096
[38419.781236]  gadget: rndis req21.00 v0000 i0000 l36
[38419.781311] gen_ndis_query_resp: RNDIS_OID_GEN_RCV_NO_BUFFER
[38419.785070]  gadget: rndis reqa1.01 v0000 i0000 l4096
[38419.785257]  gadget: rndis req21.00 v0000 i0000 l36
[38419.789077]  gadget: rndis reqa1.01 v0000 i0000 l4096
[38420.407012] [drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status updated from 2 to 2

[hzeller]

Ok, since I don't have your setup it is hard to diagnose what is wrong. The am335x package has a way to compile with debug enabled (have a look at their Makefile). That then prints more diagnostic message when linked to the program (so beagleg).

So

• compile a debug version of the pru package
• If the debug library is named differently or in a different dirctory: modify beagleg Makefile to reflect that
• in beagleg: make clean ; make

Now you should get more information on startup of beagleg that can help figure out what is wrong.

[MantisClone]

Quick question: What converter do you use to turn your 3D design files (.stl?) into .gcode files? My hope is to create .gcode files that use the same commands that your parser can handle.

Also! I managed to run your code. I'm pretty proud of myself. Here's what I had to do:

I took a look at the am335x_pru_package located at https://github.com/beagleboard/am335x_pru_package

I ran the example programs there using the following set of commands:

 cd am335x_pru_package/pru_sw/app_loader/interface
 CROSS_COMPILE="" make
 cd ../../utils/pasm_source
 ./linuxbuild
 mv ../../utils/pasm ../../utils/pasm_2
 cd ../../example_apps/
 CROSS_COMPILE="" make
 echo BB-BONE-PRU-01 > /sys/devices/bone_capemgr.8/slots
 modprobe uio_pruss
 cd bin
 ./PRU_memAccess_DDR_PRUsharedRAM

After that, I was stuck briefly on adding both the BB-BONE-PRU-01 and BeagleG overlays simultaneously but that's because I was using one of the pins marked as "exclusive-use" in the BB-BONE-PRU-01 overlay for a separate test. Once I removed that, however, the BB-BONE-PRU-01 and BeagleG overlays play nice together.

So all I had to do then was apply the BeagleG overlay and run "send-gcode" on a G-code file I found on the internet. Unfortunately there were numerous parsing errors as the file I found was meant for CNC milling and used commands not handled by your parser.

A quick video is located on my google drive: https://drive.google.com/file/d/0BzYhHLKSJYEMU09sQkVIYjlRUmM/edit?usp=sharing

[hzeller]

Wonderful, congrats to the progress, looks like it started to work.

As for stl -> gcode conversion, I usually use Slic3r. For testing, I typically just wrote G-code myself, e.g. G1 X10 Y10 G1 X0 Y0 Moves motor X and Y to position (10,10)mm and back to (0,0)mm.

Right now, I am working on a cape so that things are a bit easier ( https://github.com/hzeller/bumps ) ... and because I ended up submitting patches for more usability to KiCAD, that went slower than expected :)

(Once that is done, I'll come back to the BeagleG code.)