running BBB + Machinekit newbie questions

More
23 Oct 2013 00:20 #40190 by ggpwnkthx
Making progress!
linuxcnc@arm:~$ halrun
rtapi:0 stopped
msgd:0 stopped
halcmd: loadrt threads
halcmd: loadrt stepgen step_type=0 ctrl_type=v
halcmd: addf stepgen.0 servo-thread
<stdin>:3: addf failed
halcmd: show funct
Exported Functions:
Owner   CodeAddr  Arg       FP   Users  Name
 00006  b6bffdc9  b6c1c3c8  YES      0   stepgen.capture-position
 00006  b6bffc19  b6c1c3c8  NO       0   stepgen.make-pulses
 00006  b6bffeb9  b6c1c3c8  YES      0   stepgen.update-freq

halcmd:

Log says:
hal_lib:2827:user HAL: ERROR: function 'stepgen.0' not found

Please Log in or Create an account to join the conversation.

More
23 Oct 2013 00:40 #40193 by andypugh

Making progress!

You would be making more if I had checked stuff before sending the message.

 00006  b6bffdc9  b6c1c3c8  YES      0   stepgen.capture-position
 00006  b6bffc19  b6c1c3c8  NO       0   stepgen.make-pulses
 00006  b6bffeb9  b6c1c3c8  YES      0   stepgen.update-freq
Log says:
hal_lib:2827:user HAL: ERROR: function 'stepgen.0' not found

You will see that there is no function called "stepgen.0". There is also no "servo-thread" either.
addf stepgen.capture-position thread1
addf stepgen.make-pulses thread1
addf stepgen.update-freq thread1
Might work better.

Please Log in or Create an account to join the conversation.

More
23 Oct 2013 00:52 - 23 Oct 2013 02:21 #40194 by ggpwnkthx
Yep, I jumped the gun. My apologies. Thank you for holding my hand.
In my defense, I figured it out before reading your response. :laugh:

So here's where I'm at now:
Trying to load hal_bb_gpio fails.
linuxcnc@arm:~$ halrun
rtapi:0 stopped
msgd:0 stopped
halcmd: loadrt threads
halcmd: loadrt stepgen step_type=0 ctrl_type=v
halcmd: addf stepgen.make-pulses thread1
halcmd: loadrt hal_bb_gpio output_pins=107,108,109,110
Waiting for component 'hal_bb_gpio' to become ready...........................................................
<stdin>:4: /home/linuxcnc/linuxcnc/libexec/rtapi_app_xenomai exited without becoming ready
<stdin>:4: insmod failed, returned -1
See the log and output of 'dmesg' for more information.
halcmd:
I'm assuming pins 107 to 110 are aliases to the physical pins P8_7 to P8_10, due to the error massage when I tried defining output_pins using the system pins numbers for P8_7 to P8_10.

No comment from the log, but dmesg does report:
Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6bbf134

All the default BB capes are disabled, and I have a device tree overlay enabled that I wrote: pastie.org/8421931
Could that be causing the problem?
Last edit: 23 Oct 2013 02:21 by ggpwnkthx. Reason: Incomplete thouight.

Please Log in or Create an account to join the conversation.

More
23 Oct 2013 02:36 #40201 by andypugh

All the default BB capes are disabled, and I have a device tree overlay enabled that I wrote: pastie.org/8421931
Could that be causing the problem?


I am afraid you have exceeded the limits of my knowledge. I own a BBB, but I haven't tried running it with LinuxCNC yet.

Please Log in or Create an account to join the conversation.

More
23 Oct 2013 03:04 #40202 by ggpwnkthx
Bugger! Well, I truly appreciate how far you have taken me.

I'll keep working on this and report back.

I think there is a lot to learn from the existing HAL files that come with MachineKit.

Thanks again!

Please Log in or Create an account to join the conversation.

More
23 Oct 2013 03:53 #40206 by ggpwnkthx
So I was just messing around and I would say there is definitely a correlation between a working device tree overlay and hal_bb_gpio.
linuxcnc@arm:~$ halrun
rtapi:0 stopped
msgd:0 stopped
halcmd: loadusr -w /home/linuxcnc/linuxcnc/configs/ARM/BeagleBone/BeBoPr/setup.sh
Loading BB-LCNC-BEBOPR overlay
Loading cape-bone-iio overlay
halcmd: loadrt trivkins
halcmd: loadrt motmod servo_period_nsec=1000000 num_joints=4
halcmd: loadrt hal_bb_gpio output_pins=103,105,107,120,128,140,141 input_pins=131,132,133,135,137,138
halcmd:
In this case, hal_bb_gpio is loading fine. So, what was obvious to me, does seem to be the case.

Now it's a matter of poking around in the exiting dts files... pastie.org/8422281

Looking at the existing BeBoPr dts file, the only obvious differences I can see are:
The use of "exclusive-use"
The output GPIOs are set to 0x3F (111111), which translates to:
  • Mode: 7 (GPIO)
  • Pad Pullup/Pulldown: Disabled
  • Pad Pullup/Pulldown Type: Pulldown
  • Receiver: Enabled (??? that's confusing)
  • Slew Rate: Slow (wouldn't Fast be better?)
Mine are set to 0x07, which was a mistake, because that only sets them to Mode7. My assumption would be that they should be 0x0F because that would set them to Mode 7, disable Pullup/Pulldown, the receiver would be disabled (making it an output pin [assumption]), and the slew rate would be set to fast.

I made a spread sheet to help figure some of this stuff out: docs.google.com/spreadsheet/ccc?key=0Ah0...LVnNhcGotajQ4Sk1heGc
Credit where it's due: derekmolloy.ie/gpios-on-the-beaglebone-b...evice-tree-overlays/

I've got to go pick up one of my minions, and do some food shopping; but I'll be back at this tonight.

Please Log in or Create an account to join the conversation.

Time to create page: 0.114 seconds
Powered by Kunena Forum