Thanks Jeff for the current update & notes on the position of the branch
On 1 September 2014 13:20, Jeff Epler <[email protected]> wrote: > 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 > ------------------------------------------------------------------------------ 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
