If you don't watch IRC or the commit list, you are probably not aware of
what is going on in linuxcnc development from day to day. This e-mail
is intended to be a partial antidote to this.
Lately, I've been using a branch (git.linuxcnc.org branch
jepler/proposed-master) to organize my changes before they go in the
linuxcnc master branch. This branch is frequently rebased until I'm
happy with the commits, then it is merged or rebased onto the master
branch.
I welcome your comments on the below, particularly in the case that you
spot a problem with any of my proposed changes. (followups to list
please) I believe the changes below, with the possible exception of
"interp: use strings", are pretty much ready to go into master branch,
and plan to push them there soon.
Here's the most exciting thing: My odroid u3 board is now capable of
talking to a mesa hostmot2 board via an SPI interface.
6dc693f hostmot2: support boards on spi interface
This uses the kernel spi driver stack (spidev -> spi -> spi-s3c64xx),
which was not without its own set of latencies. However, I've fixed the
ones I'm aware of in my kernel tree and now got good latencies in an
overnight run. It's a testament to the good design of the linuxcnc
hostmot2 driver that in a mere 249 non blank lines it's possible to
implement a whole new physical interface to a hostmot2 board.
I guess this one goes under the heading of RT-hardening for uspace. It
can be a big deal for those of us who like to run halcmd at the
commandline, and then put it into the background with ctrl-z:
e485f4d uspace: don't let ctrl-z stop realtime
(a report from pcw served as a kick in the pants to figure out how to
fix this)
A nice little tool for monitoring worst-case thread execution time in
halscope:
e006a24 hal: an "increased" pin for thread time
Fixing some compiler warnings, but needs testing to make sure I got the
string-based versions right:
33088cb interp: use strings to avoid buffer hell
A tiny bit of modernization needed for recent kernels:
0516bbd configure: don't require linux/version.h
Some removals of old functionality with no maintainer and which we
suspect don't work or are otherwise not current:
4f0f964 rtapi: remove support for rtlinux 3.x
a05d29c rtapi: drop support for rtai "24.x"
018a0e2 rtapi: drop support for alternate math libs
4ff5d6d configure: drop never-used RTAI3_MOD variable
After some IRC discussion, I have another branch I'm less gung-ho to
push to master (this is jepler/revive-usrmot, not
jepler/proposed-master):
96df8b8 Fill out new required fields in emcmot_command_t
a79b413 Revert "usrmot: it was broken; remove it"
I consider usrmot a relic which should be forgotten when alternatives
like python's emcmodule and emcrsh exist. (if there's something you
could do with usrmot but can't with emcmodule, let's talk about *that*)
But "tjtr" on IRC made me curious just why it broke. It turns out that
at least the following additional fields need to be filled out in linear
move commands (EMCMOT_SET_LINE):
+ emcmotCommand.turn = -1;
+ emcmotCommand.vel = 1;
+ emcmotCommand.acc = 1;
+ emcmotCommand.ini_maxvel = 1;
+ emcmotCommand.motion_type = EMC_MOTION_TYPE_FEED;
"turn" is the number of the rotary axis (if any) which has to be
unlocked before this move can take place. To know whether the correct
value for this field, you have to parse the inifile's specification of
whether any axes are locking; determine which axes are moving in this
case; if one of them is locking, set the field accordingly; and reject
the move if other axes are moved.
vel, acc, and ini_maxvel all pertain to keeping this move within
constraints. task's canon interface has a bunch of math to figure out
the velocity and acceleration constraints of a particular move, which
depends on its orientation in space; this means more inifile parsing and
more math.
In my view, both of the above are reasons that usrmot shouldn't be
revived unless someone is *also* devoted to sharing code between task
and usrmot for purposes like correctly filling out emcmotCommand
structures.
Another problem with usrmot is that as far as I can tell there's nothing
guarding the single motion shared memory area from being written at the
same time by task and usrmot; without such protection, it seems like
there's an opportunity for unexpected and hard-to-reproduce flakiness
that would result from task filling out half a structure and usrmot
filling out the other half.
For all these reasons, I don't particularly want to see this branch
merged. On the other hand, if I don't use it it doesn't hurt me. With
an offer to maintain plus at least one test in tests/, it might be
reasonable to do it.
Jeff
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
