On 2022-02-07 03:52, Dewey Garrett wrote:
Ongoing work related to motmod:06feb22: I've completed work on branch dgarr/loadmodules and plan to squash all commits and merge to master in the next few days: 1) Trajectory planning and homing functions implemented as loadable modules 2) Current (master branch) tp and homing functions are loaded by default (so no in-tree nor user config changes are required) 3) Out-of-tree builds examples buildable with halcompile provided (src/hal/components/): homecomp.comp (complete but minimal functions) tpcomp.comp (demostrates using links to default src files) 4) Optional inifile settings to load user-built modules: [TRAJ]TPMOD=user_tpcomp [EMCMOT]HOMEMOD=user_homecomp 5) linuxcnc script support (overides any ini settings): linuxcnc -t user_tpcomp -m user_homecomp ... 6) runtests passes (rtpreempt,rtai) 7) out-of-tree halcompile builds work (rtpreempt,rtai) More details in the commit messages: https://github.com/LinuxCNC/linuxcnc/commits/dgarr/loadmodules Note: some of the preparatory commits include some refactoring and may duplicate some of Arvids's work: https://github.com/LinuxCNC/linuxcnc/commit/b95e90acb motion.[ch] always use struct_in_shmem
Wow, what are the chances of us taking care of STRUCTS_IN_SHMEM simultaneously (albeit in exactly opposite ways)! I've looked through your commits and I think it should be possible to base your work off mine - i.e. to use my commits as preparatory work for yours. * Your "always use struct_in_shmem" commit does the exact opposite of mine and will make it more difficult to encapsulate data going forward. Other than that much is similar (you've done more or course!): * "homing.c relocate/rename a homing function": We did the same thing to checkAllHomed() - i.e. moved it where it belongs, into homing.c. :) I just didn't rename it. If you rebase your work on mine, the above two commits would be redundant. * Your "tp module interface provisions" moves joint and axes into emcmot_status_t to be able to access it from tp, I think? My patch instead uses access functions in tp.c to get acc and vel limit data. This is the tricky commit which would have merge conflicts. In general, everything related to emcmotStatus would have to go, and tp.c's access of internal axis data would be - acc_bound->x = axis_array[0].acc_limit; //0==>x - acc_bound->y = axis_array[1].acc_limit; //1==>y - acc_bound->z = axis_array[2].acc_limit; //2==>z + acc_bound->x = axis_get_acc_limit(0); //0==>x + acc_bound->y = axis_get_acc_limit(1); //1==>y + acc_bound->z = axis_get_acc_limit(2); //2==>z rather than + vel_bound->x = emcmotStatus->axes[0].vel_limit; //0==>x + vel_bound->y = emcmotStatus->axes[1].vel_limit; //1==>y + vel_bound->z = emcmotStatus->axes[2].vel_limit; //2==>z What do you think? (BTW, nice work in general, removing those extern declaration, fixing tabs and more that I was annoyed at while doing my work!) Otherwise, as long as you don't add *more* users of internal data in shared memory (which it seems you don't at a quick glance), I guess I could rebase my commit off of yours'. It gets a little ugly though, first changing to ONLY shmem, then back to ONLY private. -- Arvid Brodin _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
