Looking for Hal/Ini file for BBB, Rosetta Bone, and Gecko G540 with MachineKit

[Tom M]

The makerspace I belong to (workshop88) just purchase a semi-completed sieg cnc-conversion which includes a Gecko G540 parallel port interphase.
I like to use machinekit running on a bbb for this machine.

A while back I had gotten a bare Rosetta board from Bart Dring(Inventables) that's been sitting in a parts bin, waiting for something to use it on.

This seems like this would be perfect for the application.
http://www.buildlog.net/blog/wp-content/uploads/2013/09/B32020_rev_1.pdf
http://www.geckodrive.com/images/cms_files/images/G540%20REV8%20Manual.pdf

Any chance someone is using the Rosetta Bone with Gecko G540 and has a Hal/Ini to share.
I can figure it but this could save me a few a little time if someone has it handy.

Tom
Btw.
I is there a more current board that can be used with Gecko G540 and a BBB?

[Tom M]

We a  have a gecko G540 and want to run with machinekit on a bbb using a Rosetta Bone to connect to the parallel port.

We copied a xylotex configuration over and renamed it and started making adjustments to it.
https://github.com/Workshop88/machinekit/tree/master/configs/ARM/BeagleBone/RIeosettaBoneGecko

At this point we're just trying to get the motors to move properly, before working on the endstops.

I talked to Marcus from gecko tech support and he said timing settings should be the same as the G250x
http://www.geckodrive.com/g250x.html

The current configuration is generating the following error messages:

Starting Machinekit...
io started
emc/iotask/ioControl.cc 752: can't load tool table.
halcmd loadusr io started
Loading cape-universal overlay
Loading cape-bone-iio overlay
task pid=4080
emcTaskInit: using builtin interpreter
libGL error: failed to authenticate magic 1
libGL error: failed to load driver: r300
hpg: stepgen.01.maxvel is too big for current step timings & position-scale, clipping to max possible

joint 1 following error
emc/task/taskintf.cc 617: Error on axis 1, command number 358

The clipping message is occurring when machine power is is toggled in axis.  The  demo gcode is still able to run and a  joint follower occurs when finishing the "T" in "MACHINE KIT"

At this point, the BBB is not connected to  the mill (it's in another state)).   I'm trying to understand the clipping to max possible message.
I had this issues working on my MPCNC project and Charles said.

"This means the PRU cannot meet your requested maximum velocity (or
step pulse frequency) given the PRU period and various other
parameters (step pulse high/low time).  You need to either lower the
maximum velocity in your INI file or reduce the PRU period"

How much can I/ should I reduce the PRU period?
(Reducing the period down to 5000 breaks something in the display.)
Here is  the current value. https://github.com/Workshop88/machinekit/blob/master/configs/ARM/BeagleBone/RosettaBoneGecko/RosettaBoneGecko.ini#L101

Is there a step by step calculation guide that I can use?
 
Any chance there is a configuration tool in the works(similar to the parport configuration tool) for the beaglebone PRU?

[Charles Steinkuehler]

On 10/9/2016 4:34 PM, Tom M wrote:
>
> hpg: stepgen.01.maxvel is too big for current step timings & position-scale,
> clipping to max possible
>
> joint 1 following error
> emc/task/taskintf.cc 617: Error on axis 1, command number 358
>

> The clipping message is occurring when I toggle machine power. I'm still able
> to run the demo gcode and I hit the joint follower when I'm finishing the T in
> machine kit.

The minimum stepper pulse times are one PRU task-cycle-time high and
one task-cycle-time low. So the maximum pulse frequency depends on
the requested step timings and the PRU task-period. Usually, the step
timings are in the range of a few hundred nS, and the PRU period is
thousands of nS, so usually the maximum step frequency is half the
task-period.

You get the following error at the end because the machine is trying
to do a rapid move (maximum velocity) instead of a controlled velocity
cut. The motion planner is setup with a maximum velocity for an axis
that requires a step rate that the PRU code cannot generate given the
pru task-period, and the step timings. Very soon as the motion
planner commands this unattainable velocity, you will get a following
error as the PRU stepgen cannot keep up with the commanded position.

> (at this point, I"m not connected to machine(it's in another state)). I'm

> trying to understand the clipping to max possible message

> I had this issues working on my MPCNC project and Charles said.
>
> "This means the PRU cannot meet your requested maximum velocity (or
> step pulse frequency) given the PRU period and various other
> parameters (step pulse high/low time). You need to either lower the
> maximum velocity in your INI file or reduce the PRU period"
>

> How much can I/ should I reduce the PRU period... Going down to 5000 is too
> much is it seems to break something else.

I typically run with a PRU period of 3000 to 5000 nS without issue,
but it depends on how many PRU tasks (stepgen/pwmgen) you are trying
to run. If you have access to a direct PRU output pin, you can set it
up to be a PRU busy indicator and monitor the PRU loading via an
oscilloscope.

To monitor the PRU busy time:

* set hpg.pru_busy_pin to 128 + the PRU direct pin number

* configure the selected pin to be a PRU direct output

By default, the PRU busy pin is enabled and routed to PRU direct
output 0 (hpg.pru_busy_pin = 0x80), so if you're using my universal
overlay and are not otherwise using P9.31, all you have to do is setup
the pin:

config-pin P9.31 pruout

...or for example to use P9.28:

halcmd setp hpg.pru_busy_pin 0x85
config-pin P9.28 pruout

> (Is there either a step by step calculation guide for this. It would be nice if
> there was a tool similar to the parport configuration tool for the beaglebone
> PRU configuration.

Yes it would...feel free to send a pull-request! :)

> The max velocities don't seem that unreasonable.

No, it's the very large scale values that are causing problems
(particularly the one that's 75000). That requires 75000 pulses per
second with a maximum velocity = 1.0 (75 KHz), and the stepgen
velocity limit is set to 1.2x that (90 KHz), but the maximum step
frequency when using the PRU defaults is only 50 KHz. If you can
reduce the micro-stepping or otherwise decrease the scale value (while
keeping the machine useful), that would help.

...but it should work as-is if you drop the PRU period to 3000 to 5000
nS, which should be very safe since you're only running 4 stepgen
instances.

> I tried halfing this variable,
> https://github.com/Workshop88/machinekit/blob/master/configs/ARM/BeagleBone/RosettaBoneGecko/RosettaBoneGecko.ini#L101
> by 1/2 and it seemed that I broke

That is the wrong place to change anything for the PRU.

Add "pru_period=5000" to CONFIG= in [PRUCONF]

https://github.com/Workshop88/machinekit/blob/master/configs/ARM/BeagleBone/RosettaBoneGecko/RosettaBoneGecko.ini#L3

...here's an example:

https://github.com/cdsteinkuehler/machine-configs/blob/master/configs/MendelMax/MendelMax.ini#L3

--
Charles Steinkuehler
cha...@steinkuehler.net

[Tom M]

Charles,
Thanks for the detailed response.  We have out cnc night tonight and given us much to look at.

I wouldn't mind giving it go developing it a go  coming up with a configuration tool/GUI for the BBB. (Best way to learn about this stuff)

I took a quick look at the source for stepconf and it appears to be glade/Python. 
I  was debating if I should copy the code and just refactor it to handle a BBB or start from scratch with QT Python c/c++.   Any thoughts?

--
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/mmbJ_CZUakA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Charles Steinkuehler]

On 10/11/2016 12:50 PM, Tom M wrote:
> Charles,
> Thanks for the detailed response. We have out cnc night tonight and given us
> much to look at.
>
> I wouldn't mind giving it go developing it a go coming up with a configuration
> tool/GUI for the BBB. (Best way to learn about this stuff)
>
> I took a quick look at the source for stepconf and it appears to be glade/Python.
> I was debating if I should copy the code and just refactor it to handle a BBB
> or start from scratch with QT Python c/c++. Any thoughts?

Code in whatever works best for you. I will say that I've recently
used glade, and it's a pain. I actually installed a LinuxCNC instance
because it was the easiest (only?) way to get a coherently working
instance of the (ancient) GUI editor you have to use to make the ui
files. :-/

...but that's for the HAL pyvcp stuff, you can probably use modern UI
tools for something like stepconf.

But I would suggest you start with pncconf instead of stepconf. The
hal_pru_generic driver was modeled after the Mesa hostmot2 driver, so
you'll have fewer things to modify starting with pncconf (which
already has no base-thread and very similar pin names) vs. stepconf
which uses software stepping.

Whatever it's written in, having a utility that would spit out a
custom config along with a pin file (for use with config-pin -f) would
be AWESOME!!! Good luck!

--
Charles Steinkuehler
cha...@steinkuehler.net

[Tom M]

It was a good night at the space.  Thanks for the help. You got is on the right track. We got the mill moving without error albeit a bit slow on the rapid (which is fine at the moment till we get things worked out).
I wasn't aware of pncconf it sounds like a good starting point.   I guess we should call it bbbconf?
I'm thinking a qt front end should be the way to go.
Tom

[schoo...@btinternet.com]

On 12/10/16 12:58, Tom M wrote:

I'm thinking a qt front end should be the way to go.

You would think so wouldn't you?

There are currently all sorts of problems, including distro versions lagging behind released versions

Even Jessie still uses Qt4 if you choose to install qt-sdk.  You can install Qt5, but that is extra dependencies that others will not have
(or want, if they are using an SD image on a tiny ARM board)

Qt5.5 and greater broke Alex's QtQuickVcp, I don't know if that is fixed in later versions, I still use 5.4

Qt5 broke and dropped QtXEmbedContainer, so programs that worked quite happily, embedding say the gremlin widget in Qt4.xx, no longer work.
Qt5 no longer works on some window managers, like icewm (these 2 may be linked to its implementation of the X standard)

My advice would be to overcome your quite natural antipathy for python and gtk (yughh) and use the existing pncconf as a template to achieve functionality initially.

Then look at a modern interface in Qt, as an eventual replacement.
In time hopefully ALL the tk/tcl stuff will be replaced with something far less offensive :)

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 machinekit+...@googlegroups.com.

[Tom M]

  I think refactoring a sticking with gtk at the moment will probably minimize the pain,

I was poking around the code, only 10k lines
https://github.com/machinekit/machinekit/blob/master/src/emc/usr_intf/pncconf/pncconf.py

I was trying firing up pncconf.py  It seems like a there are some dependencies missing..

Something to play with this weekend.

To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.