Re: [Machinekit] switching between kinematics modes in G code
Thanks Schooner! I'll try digging a little deeper to see if it makes sense to go that route. For now, I think I've got it working using a combination of custom M code commands to flip the hal pin on the kinematics module, and remapped G codes bound to a python functions that are executed at read ahead time. The G codes are what should be used in a G code program and the python script executes the custom M code and an extra G0. To do so, it implements the same kinematics math as the kinematics module. It may not be ideal to have to duplicate that, but it seems to be working! Still more testing to do... On Wednesday, April 25, 2018 at 8:50:40 AM UTC-6, Schooner wrote: > > Have a look at rs274ngc_interp.hh:L233 > > The functions starting *comp_get**_current(...)* appear to get and set > the values in the initial settings struct. > Initialised in rs274ngc_pre:L113 and struct detail in interp_setup.cc / > interp_internal.hh > > I haven't looked much at it, but assuming this struct is updated > throughout, to hold the current values for all the settings, it may be of > use. > > If you have a sim which can switch kinematic modes using your components, > I may be able to assist more. > > I don't have any machines that use anything other than trivkins. > > On 24/04/18 14:12, jo...@allwinedesigns.com wrote: > > I believe I found the culprit. While everything seems to be in order in > the motion controller, I believe the GCode interpreter still believes it's > at the previous position after a kinematics mode change. Manually executing > a g0 to the currently displayed coordinates after a change and then > executing another command seems to work perfectly. Now to find where to > change that... > -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > 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 . > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit https://groups.google.com/d/optout. > > > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- 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+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] switching between kinematics modes in G code
Have a look at rs274ngc_interp.hh:L233 The functions starting comp_get_current(...) appear to get and set the values in the initial settings struct. Initialised in rs274ngc_pre:L113 and struct detail in interp_setup.cc / interp_internal.hh I haven't looked much at it, but assuming this struct is updated throughout, to hold the current values for all the settings, it may be of use. If you have a sim which can switch kinematic modes using your components, I may be able to assist more. I don't have any machines that use anything other than trivkins. On 24/04/18 14:12, j...@allwinedesigns.com wrote: I believe I found the culprit. While everything seems to be in order in the motion controller, I believe the GCode interpreter still believes it's at the previous position after a kinematics mode change. Manually executing a g0 to the currently displayed coordinates after a change and then executing another command seems to work perfectly. Now to find where to change that... -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- 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+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout. -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- 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+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] switching between kinematics modes in G code
I took a closer look at the thread I linked earlier and it looks like they weren't as successful as I previously thought. I'm only able to switch between modes when the rotary axes are at 0, which is the same issue they were having in the other thread. Their solution in that thread was to write a post processor that ensured the rotary axes were zeroed before switching modes. I'd prefer a solution that didn't involve a post processor, so I dove a little deeper into MachineKit's source code. This is my first foray into MachineKit's source code, so I'd appreciate any feedback and/or tips! I am attempting to set up a mechanism to interface the motion module and the kinematics module using hal pins to get the desired kinematics switching behavior. I've created two pins on the motion module and the kinematics module: 1) carte_space_change_ok - output on the motion module, input on the kinematics module. When this pin is true, the kinematics module is safe to change kinematics modes. 2) carte_space_changed - input on the motion module, output on the kinematics module. This pin is set to true in the kinematicsForward function when a change to the hal pin that controls the mode has been detected. The idea is the motion module will detect when carte_space_changed is set to true and then follow up by setting carte_space_change_ok to true once the machine can change modes. I'm unsure exactly what conditions should be considered safe to change modes (i.e. is checking GET_MOTION_INPOS_FLAG enough?). I'm also unsure what internals need to be changed to successfully change carte_pos_cmd. I've tried setting carte_pos_cmd directly, clearing the trajectory planner (tpClear(emcmotQueue)), setting the current position (tpSetPos(emcmotQueue, carte_pos_cmd)), and draining the joint's cubic interpolators. It successfully transitions from five axis kinematics to trivial kinematics, but as soon as I issue a move with gcode from MDI mode I get a follow error. I must be missing something else that needs to change. Any thoughts? Does this seem like a reasonable way to do it? On Friday, April 13, 2018 at 9:07:25 AM UTC-6, Schooner wrote: > > > On 13/04/18 15:47, jo...@allwinedesigns.com wrote: > > I was able to apply some corrections in the kinematics module after > detecting changes to the mode, the way this module is doing it (found on > the thread previously linked): > > https://forum.linuxcnc.org/media/kunena/attachments/16665/xyzbc-trt-kins_2017-12-13.c > > I'm having trouble, though, accounting for tool length compensation. How > is tool length compensation incorporated into the values passed to and > returned from the forward and inverse kinematics functions? > > > No idea personally. > This should be relevant though > > http://www.linuxcnc.org/docs/devel/html/motion/5-axis-kinematics.html#_tool_length_compensation > > I would contact Dewey, he seems to have been very active in the JA changes > and wrote that code you linked to. > > As for why the Beaglebone, I'm working on the Pocket NC. > > On Thursday, April 12, 2018 at 9:52:44 AM UTC-6, Schooner wrote: >> >> >> On 12/04/18 16:00, jo...@allwinedesigns.com wrote: >> >> I definitely have to stick with Machinekit as I'm running the machine >> with a Beaglebone. What is the nature of the changes made to LinuxCNC that >> allowed this to work? Do you think I could get this going on Machinekit? >> >> >> It is completely non-trivial and I am far from sure if it exists as a >> series of commits which are easily accessible. >> Linuxcnc did not have a Github repo until recently and I don't know how >> they converted across. >> >> These are just the commits that actually specify 'JA' in the title (238 >> of them) >> https://github.com/LinuxCNC/linuxcnc/search?q=JA=Commits >> >> If the commit was relevant but did not have that tag in the commit text, >> the search would not find it. >> It may also have picked up 'ja*m*' and the likes, Github searches are >> not very good. >> >> You are welcome to try cherry-picking the commits and resolving all the >> major conflicts occurring because machinekit has completely >> diverged from linuxcnc in many respects. I would not recommend it. >> >> If I were you I would get an old computer with a parport, install >> Linuxcnc from a rtai kernel distro. >> Then you can find out if it actually works as you want. >> >> If it does, why do you need to use a BBB? >> >> I don't have an axe to grind either way, whatever works best IS best. >> >> >> On Thursday, April 12, 2018 at 8:28:29 AM UTC-6, Schooner wrote: >>> >>> >>> On 12/04/18 14:59, jo...@allwinedesigns.com wrote: >>> >>> Thanks for the advice! >>> >>> I started implementing this the other day and am running into follow >>> errors when switching between modes using a hal pin. >>> >>> >>> Yes I did predict that it would likely cause problems >>> >>> * "The actual instant of changeover could reek havoc if it occurred >>> midway through setting the
Re: [Machinekit] switching between kinematics modes in G code
I took a closer look at the thread I linked earlier and it looks like they weren't as successful as I previously thought. I'm only able to switch between modes when the rotary axes are at 0, which is the same issue they were having in the other thread. Their solution in that thread was to write a post processor that ensured the rotary axes were zeroed before switching modes. I'd prefer a solution that didn't involve a post processor, so I dove a little deeper into MachineKit's source code. This is my first foray into MachineKit's source code, so I'd appreciate any feedback and/or tips! I am attempting to set up a mechanism to interface the motion module and the kinematics module using hal pins to get the desired kinematics switching behavior. I've created two pins on the motion module and the kinematics module: 1) carte_space_change_ok - output on the motion module, input on the kinematics module. When this pin is true, the kinematics module is safe to change kinematics modes. 2) carte_space_changed - input on the motion module, output on the kinematics module. This pin is set to true in the kinematicsForward function when a change to the hal pin that controls the mode has been detected. The idea is the motion module will detect when carte_space_changed is set to true and then follow up by setting carte_space_change_ok to true once the machine can change modes. I'm unsure exactly what conditions should be considered safe to change modes (i.e. is checking GET_MOTION_INPOS_FLAG enough?). I'm also unsure what internals need to be changed to successfully change carte_pos_cmd. I've tried setting carte_pos_cmd directly, clearing the trajectory planner (tpClear(emcmotQueue)), setting the current position (tpSetPos(emcmotQueue, carte_pos_cmd)), and draining the joint's cubic interpolators. It successfully transitions from five axis kinematics to trivial kinematics, but as soon as I issue a move with gcode from MDI mode I get a follow error. I must be missing something else that needs to change. Any thoughts? Does this seem like a reasonable way to do it? On Friday, April 13, 2018 at 9:07:25 AM UTC-6, Schooner wrote: > > > On 13/04/18 15:47, jo...@allwinedesigns.com wrote: > > I was able to apply some corrections in the kinematics module after > detecting changes to the mode, the way this module is doing it (found on > the thread previously linked): > > https://forum.linuxcnc.org/media/kunena/attachments/16665/xyzbc-trt-kins_2017-12-13.c > > I'm having trouble, though, accounting for tool length compensation. How > is tool length compensation incorporated into the values passed to and > returned from the forward and inverse kinematics functions? > > > No idea personally. > This should be relevant though > > http://www.linuxcnc.org/docs/devel/html/motion/5-axis-kinematics.html#_tool_length_compensation > > I would contact Dewey, he seems to have been very active in the JA changes > and wrote that code you linked to. > > As for why the Beaglebone, I'm working on the Pocket NC. > > On Thursday, April 12, 2018 at 9:52:44 AM UTC-6, Schooner wrote: >> >> >> On 12/04/18 16:00, jo...@allwinedesigns.com wrote: >> >> I definitely have to stick with Machinekit as I'm running the machine >> with a Beaglebone. What is the nature of the changes made to LinuxCNC that >> allowed this to work? Do you think I could get this going on Machinekit? >> >> >> It is completely non-trivial and I am far from sure if it exists as a >> series of commits which are easily accessible. >> Linuxcnc did not have a Github repo until recently and I don't know how >> they converted across. >> >> These are just the commits that actually specify 'JA' in the title (238 >> of them) >> https://github.com/LinuxCNC/linuxcnc/search?q=JA=Commits >> >> If the commit was relevant but did not have that tag in the commit text, >> the search would not find it. >> It may also have picked up 'ja*m*' and the likes, Github searches are >> not very good. >> >> You are welcome to try cherry-picking the commits and resolving all the >> major conflicts occurring because machinekit has completely >> diverged from linuxcnc in many respects. I would not recommend it. >> >> If I were you I would get an old computer with a parport, install >> Linuxcnc from a rtai kernel distro. >> Then you can find out if it actually works as you want. >> >> If it does, why do you need to use a BBB? >> >> I don't have an axe to grind either way, whatever works best IS best. >> >> >> On Thursday, April 12, 2018 at 8:28:29 AM UTC-6, Schooner wrote: >>> >>> >>> On 12/04/18 14:59, jo...@allwinedesigns.com wrote: >>> >>> Thanks for the advice! >>> >>> I started implementing this the other day and am running into follow >>> errors when switching between modes using a hal pin. >>> >>> >>> Yes I did predict that it would likely cause problems >>> >>> * "The actual instant of changeover could reek havoc if it occurred >>> midway through setting the
Re: [Machinekit] switching between kinematics modes in G code
I took a closer look at the thread I linked earlier and it looks like they weren't as successful as I previously thought. I'm only able to switch between modes when the rotary axes are at 0, which is the same issue they were having in the other thread. Their solution in that thread was to write a post processor that ensured the rotary axes were zeroed before switching modes. I'd prefer a solution that didn't involve a post processor, so I dove a little deeper into MachineKit's source code. This is my first foray into MachineKit's source code, so I'd appreciate any feedback and/or tips! I am attempting to set up a mechanism to interface the motion module and the kinematics module using hal pins to get the desired kinematics switching behavior. I've created two pins on the motion module and the kinematics module: * carte_space_change_ok - output on the motion module, input on the kinematics module. When this pin is true, the kinematics module is safe to change kinematics modes. * carte_space_changed - input on the motion module, output on the kinematics module. This pin is set to true in the kinematicsForward function when a change to the hal pin that controls the mode has been detected. The idea is the motion module will detect when carte_space_changed is set to true and then follow up by setting carte_space_change_ok to true once the machine can change modes. I'm unsure exactly what conditions should be considered safe to change modes (i.e. is checking GET_MOTION_INPOS_FLAG enough?). I'm also unsure what internals need to be changed to successfully change carte_pos_cmd. I've tried setting carte_pos_cmd directly, clearing the trajectory planner (tpClear(emcmotQueue)), setting the current position (tpSetPos(emcmotQueue, carte_pos_cmd)), and draining the joint's cubic interpolators. It successfully transitions from five axis kinematics to trivial kinematics, but as soon as I issue a move with gcode from MDI mode I get a follow error. I must be missing something else that needs to change. Any thoughts? Does this seem like a reasonable way to do it? On Friday, April 13, 2018 at 9:07:25 AM UTC-6, Schooner wrote: > > > On 13/04/18 15:47, jo...@allwinedesigns.com wrote: > > I was able to apply some corrections in the kinematics module after > detecting changes to the mode, the way this module is doing it (found on > the thread previously linked): > > https://forum.linuxcnc.org/media/kunena/attachments/16665/xyzbc-trt-kins_2017-12-13.c > > I'm having trouble, though, accounting for tool length compensation. How > is tool length compensation incorporated into the values passed to and > returned from the forward and inverse kinematics functions? > > > No idea personally. > This should be relevant though > > http://www.linuxcnc.org/docs/devel/html/motion/5-axis-kinematics.html#_tool_length_compensation > > I would contact Dewey, he seems to have been very active in the JA changes > and wrote that code you linked to. > > As for why the Beaglebone, I'm working on the Pocket NC. > > On Thursday, April 12, 2018 at 9:52:44 AM UTC-6, Schooner wrote: >> >> >> On 12/04/18 16:00, jo...@allwinedesigns.com wrote: >> >> I definitely have to stick with Machinekit as I'm running the machine >> with a Beaglebone. What is the nature of the changes made to LinuxCNC that >> allowed this to work? Do you think I could get this going on Machinekit? >> >> >> It is completely non-trivial and I am far from sure if it exists as a >> series of commits which are easily accessible. >> Linuxcnc did not have a Github repo until recently and I don't know how >> they converted across. >> >> These are just the commits that actually specify 'JA' in the title (238 >> of them) >> https://github.com/LinuxCNC/linuxcnc/search?q=JA=Commits >> >> If the commit was relevant but did not have that tag in the commit text, >> the search would not find it. >> It may also have picked up 'ja*m*' and the likes, Github searches are >> not very good. >> >> You are welcome to try cherry-picking the commits and resolving all the >> major conflicts occurring because machinekit has completely >> diverged from linuxcnc in many respects. I would not recommend it. >> >> If I were you I would get an old computer with a parport, install >> Linuxcnc from a rtai kernel distro. >> Then you can find out if it actually works as you want. >> >> If it does, why do you need to use a BBB? >> >> I don't have an axe to grind either way, whatever works best IS best. >> >> >> On Thursday, April 12, 2018 at 8:28:29 AM UTC-6, Schooner wrote: >>> >>> >>> On 12/04/18 14:59, jo...@allwinedesigns.com wrote: >>> >>> Thanks for the advice! >>> >>> I started implementing this the other day and am running into follow >>> errors when switching between modes using a hal pin. >>> >>> >>> Yes I did predict that it would likely cause problems >>> >>> * "The actual instant of changeover could reek havoc if it occurred >>> midway through setting the
Re: [Machinekit] switching between kinematics modes in G code
I believe I found the culprit. While everything seems to be in order in the motion controller, I believe the GCode interpreter still believes it's at the previous position after a kinematics mode change. Manually executing a g0 to the currently displayed coordinates after a change and then executing another command seems to work perfectly. Now to find where to change that... -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- 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+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] switching between kinematics modes in G code
On 12/04/18 16:00, j...@allwinedesigns.com wrote: I definitely have to stick with Machinekit as I'm running the machine with a Beaglebone. What is the nature of the changes made to LinuxCNC that allowed this to work? Do you think I could get this going on Machinekit? It is completely non-trivial and I am far from sure if it exists as a series of commits which are easily accessible. Linuxcnc did not have a Github repo until recently and I don't know how they converted across. These are just the commits that actually specify 'JA' in the title (238 of them) https://github.com/LinuxCNC/linuxcnc/search?q=JA=Commits If the commit was relevant but did not have that tag in the commit text, the search would not find it. It may also have picked up 'jam' and the likes, Github searches are not very good. You are welcome to try cherry-picking the commits and resolving all the major conflicts occurring because machinekit has completely diverged from linuxcnc in many respects. I would not recommend it. If I were you I would get an old computer with a parport, install Linuxcnc from a rtai kernel distro. Then you can find out if it actually works as you want. If it does, why do you need to use a BBB? I don't have an axe to grind either way, whatever works best IS best. On Thursday, April 12, 2018 at 8:28:29 AM UTC-6, Schooner wrote: On 12/04/18 14:59, jo...@allwinedesigns.com wrote: Thanks for the advice! I started implementing this the other day and am running into follow errors when switching between modes using a hal pin. Yes I did predict that it would likely cause problems "The actual instant of changeover could reek havoc if it occurred midway through setting the joints say, so that would need to be catered for with a function that acted upon the changeover pin changing state, clearing old data and establishing new defaults or whatever." You might be able to get around it by forcing the position_fb to whatever the actual position changes to, perhaps by unlinking position_fb at the right point then re-linking, with it set to the same as the actual position after the move. I found this thread on the LinuxCNC forums which discusses the same desired behavior and the same errors I'm encountering. It seems like they were able to resolve the issues, so I'll give what they tried a shot: https://forum.linuxcnc.org/10-advanced-configuration/31813-tcp-5-axis-kinematics?limitstart=0 We don't have the joints / axes work backported into Machinekit, it caused a lot of problems in Linuxcnc initially, so interesting that it seems to help this succeed. Hopefully it will work for you too. On Thursday, April 12, 2018 at 2:48:29 AM UTC-6, Schooner wrote: On 12/04/18 09:29, 'schoo...@btinternet.com' via Machinekit wrote: This code snippet from my lathe pulley speed setting script shows the process to convert and use case / esac to switch the input to the correct call Just re-read and that gives the impression you need to use a case / esac switch All you need of course is a single call in place of the switch, as P contains the value to pass eg. halcmd setp combokins.state $int On 11/04/18 21:30, jo...@allwinedesigns.com wrote: Is there a way to switch between kinematics modules using G code in
Re: [Machinekit] switching between kinematics modes in G code
I definitely have to stick with Machinekit as I'm running the machine with a Beaglebone. What is the nature of the changes made to LinuxCNC that allowed this to work? Do you think I could get this going on Machinekit? On Thursday, April 12, 2018 at 8:28:29 AM UTC-6, Schooner wrote: > > > On 12/04/18 14:59, jo...@allwinedesigns.com wrote: > > Thanks for the advice! > > I started implementing this the other day and am running into follow > errors when switching between modes using a hal pin. > > > Yes I did predict that it would likely cause problems > > * "The actual instant of changeover could reek havoc if it occurred midway > through setting the joints say, so that would need to be catered for with a > function* > > > * that acted upon the changeover pin changing state, clearing old data and > establishing new defaults or whatever." *You might be able to get around > it by forcing the position_fb to whatever the actual position changes to, > perhaps by unlinking position_fb at the right point then re-linking, > with it set to the same as the actual position after the move. > > I found this thread on the LinuxCNC forums which discusses the same > desired behavior and the same errors I'm encountering. It seems like they > were able to resolve the issues, so I'll give what they tried a shot: > https://forum.linuxcnc.org/10-advanced-configuration/31813-tcp-5-axis-kinematics?limitstart=0 > > > We don't have the joints / axes work backported into Machinekit, it caused > a lot of problems in Linuxcnc initially, so interesting that it seems to > help this succeed. > > Hopefully it will work for you too. > > > On Thursday, April 12, 2018 at 2:48:29 AM UTC-6, Schooner wrote: >> >> >> On 12/04/18 09:29, 'schoo...@btinternet.com' via Machinekit wrote: >> >> >> >> This code snippet from my lathe pulley speed setting script shows the >> process to convert and use case / esac to switch the input to the correct >> call >> >> >> >> Just re-read and that gives the impression you need to use a case / esac >> switch >> >> All you need of course is a single call in place of the switch, as P >> contains the value to pass >> >> eg.halcmd setp combokins.state $int >> >> >> >> >> >> On 11/04/18 21:30, jo...@allwinedesigns.com wrote: >> >> Is there a way to switch between kinematics modules using G code in >> Machinekit? The desired effect is to be able to switch between trivkins and >> a 5 axis inverse kinematics module that allows for TCPC (Haas uses G234 to >> enable TCPC, see https://www.youtube.com/watch?v=HxPjH4v5iEg). I've >> implemented the 5 axis kinematics module for my machine. I was thinking I >> could incorporate the trivial kinematics into the same module and add a hal >> pin that would switch between the two. Then I could write a python script >> that flips the hal pin, and bind that to a custom G code. Would that work? >> Is there another way to do it? >> -- >> website: http://www.machinekit.io blog: http://blog.machinekit.io >> github: https://github.com/machinekit >> --- >> 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. >> Visit this group at https://groups.google.com/group/machinekit. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> website: http://www.machinekit.io blog: http://blog.machinekit.io >> github: https://github.com/machinekit >> --- >> 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. >> Visit this group at https://groups.google.com/group/machinekit. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > 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 . > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit https://groups.google.com/d/optout. > > > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- 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+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] switching between kinematics modes in G code
Thanks for the advice! I started implementing this the other day and am running into follow errors when switching between modes using a hal pin. I found this thread on the LinuxCNC forums which discusses the same desired behavior and the same errors I'm encountering. It seems like they were able to resolve the issues, so I'll give what they tried a shot: https://forum.linuxcnc.org/10-advanced-configuration/31813-tcp-5-axis-kinematics?limitstart=0 On Thursday, April 12, 2018 at 2:48:29 AM UTC-6, Schooner wrote: > > > On 12/04/18 09:29, 'schoo...@btinternet.com ' via Machinekit > wrote: > > > > This code snippet from my lathe pulley speed setting script shows the > process to convert and use case / esac to switch the input to the correct > call > > > > Just re-read and that gives the impression you need to use a case / esac > switch > > All you need of course is a single call in place of the switch, as P > contains the value to pass > > eg.halcmd setp combokins.state $int > > > > > > On 11/04/18 21:30, jo...@allwinedesigns.com wrote: > > Is there a way to switch between kinematics modules using G code in > Machinekit? The desired effect is to be able to switch between trivkins and > a 5 axis inverse kinematics module that allows for TCPC (Haas uses G234 to > enable TCPC, see https://www.youtube.com/watch?v=HxPjH4v5iEg). I've > implemented the 5 axis kinematics module for my machine. I was thinking I > could incorporate the trivial kinematics into the same module and add a hal > pin that would switch between the two. Then I could write a python script > that flips the hal pin, and bind that to a custom G code. Would that work? > Is there another way to do it? > -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > 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 . > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit https://groups.google.com/d/optout. > > > -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > 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 . > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit https://groups.google.com/d/optout. > > > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- 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+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] switching between kinematics modes in G code
On 12/04/18 09:29, 'schoone...@btinternet.com' via Machinekit wrote: This code snippet from my lathe pulley speed setting script shows the process to convert and use case / esac to switch the input to the correct call Just re-read and that gives the impression you need to use a case / esac switch All you need of course is a single call in place of the switch, as P contains the value to pass eg. halcmd setp combokins.state $int On 11/04/18 21:30, j...@allwinedesigns.com wrote: Is there a way to switch between kinematics modules using G code in Machinekit? The desired effect is to be able to switch between trivkins and a 5 axis inverse kinematics module that allows for TCPC (Haas uses G234 to enable TCPC, see https://www.youtube.com/watch?v=HxPjH4v5iEg). I've implemented the 5 axis kinematics module for my machine. I was thinking I could incorporate the trivial kinematics into the same module and add a hal pin that would switch between the two. Then I could write a python script that flips the hal pin, and bind that to a custom G code. Would that work? Is there another way to do it? -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- 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+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout. -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- 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+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout. -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- 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+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
Re: [Machinekit] switching between kinematics modes in G code
Interesting concept.
In theory there should be nothing to prevent the combination of two
kinematics types
and a conditional test based upon whether a pin is set, to decide
which is used.
Implementation might be a little more complicated.
The data structures would need combining so that any data storage
required was available irrespective of which mode it started in.
The actual instant of changeover could reek havoc if it occurred
midway through setting the joints say, so that would need to be
catered for with a function
that acted upon the changeover pin changing state, clearing old data
and establishing new defaults or whatever.
Regards activating, that is the simple bit.
Create a bit pin, called say combokins.state
Then just create a user M code which is a bash script which calls
`setp combokins.state 1` or 0 as required
The 1 or 0 can be passed in the first arg (P) to the M code, just
remember it will be passed as fp and needs conversion to an integer.
This code snippet from my lathe pulley speed setting script shows
the process to convert and use case / esac to switch the input to
the correct call
Like to hear how it goes.
~
#!/bin/bash
## sets scale gain to make output speed accurate
## for each of 4 pulley settings
if [ ! $# -ge 1 ]; then
echo "Usage: M101 n - where n is speed range 1 - 4"
exit 1
fi
echo "param 2 is $2"
## emc takes the M101 P3 for example and passes
## $1 as 3.00 and $2 as -1.00 (because Q was not set)
## to this script!!!
## need to convert to int first
float=$1
int=${float/\.*}
# DEBUG echo "$float converted to $int"
case $int in
1 ) halcmd setp scale.0.gain 0.595;;
# accurate at 1200 in M4 for turning
2 ) halcmd setp scale.0.gain 1.16;;
# accurate at 600 in M4 for turning
3 ) halcmd setp scale.0.gain 2.175;;
# accurate at 300 in M3 for threading
4 ) halcmd setp scale.0.gain 4.3;;
# accurate at 150 in M3 for threading
esac
exit 0
On 11/04/18 21:30,
j...@allwinedesigns.com wrote:
Is there a way to switch between kinematics modules
using G code in Machinekit? The desired effect is to be able to
switch between trivkins and a 5 axis inverse kinematics module
that allows for TCPC (Haas uses G234 to enable TCPC,
see https://www.youtube.com/watch?v=HxPjH4v5iEg). I've
implemented the 5 axis kinematics module for my machine. I was
thinking I could incorporate the trivial kinematics into the
same module and add a hal pin that would switch between the two.
Then I could write a python script that flips the hal pin, and
bind that to a custom G code. Would that work? Is there another
way to do it?
--
website: http://www.machinekit.io
blog: http://blog.machinekit.io
github: https://github.com/machinekit
---
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
[Machinekit] switching between kinematics modes in G code
Is there a way to switch between kinematics modules using G code in Machinekit? The desired effect is to be able to switch between trivkins and a 5 axis inverse kinematics module that allows for TCPC (Haas uses G234 to enable TCPC, see https://www.youtube.com/watch?v=HxPjH4v5iEg). I've implemented the 5 axis kinematics module for my machine. I was thinking I could incorporate the trivial kinematics into the same module and add a hal pin that would switch between the two. Then I could write a python script that flips the hal pin, and bind that to a custom G code. Would that work? Is there another way to do it? -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- 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+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
