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.
[Machinekit] Loading machinekit config via systemd failed
Hello folks,
I have a machinekit config which works when I start my python script via
console. If I want to start the script at boot up with systemd, it will not
load machinekit.
The python script is:
#!/usr/bin/python
import sys
import os
import subprocess
import time
from machinekit import launcher
from machinekit import rtapi
os.chdir(os.path.dirname(os.path.realpath(__file__)))
launcher.set_debug_level(5)
try:
launcher.check_installation()
launcher.cleanup_session()
launcher.register_exit_handler() # needs to executed after HAL files
launcher.ensure_mklauncher()
launcher.start_process('configserver')
launcher.start_process('machinekit mkwrapper.ini')
while True:
launcher.check_processes()
time.sleep(1)
except subprocess.CalledProcessError:
launcher.end_session()
sys.exit(1)
sys.exit(0)
and the service file is:
[Unit]
Description=Starts my Uber-awesome Machinekit configuration
After=syslog.target network.target
[Service]
Type=simple
ExecStart=/usr/bin/python /home/machinekit/mkwrapper-sim/run.py
User=machinekit
[Install]
WantedBy=multi-user.target
Does anyone have an idea?
Best regards,
David
--
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.
[Machinekit] Guidance on 3 axis retrofit
Hello everyone! I was wondering if I could get a little direction/validation on a build I'm considering. First a little background on me. I run several CNC machines and 3D printers. I've modified several of them. Years ago I built a HobbyCNC machine with a kit. I've recently gotten into Linux (specifically fooling around with, and using Raspberry Pis for small projects) I'm looking to convert one of my small CNC machines to a different control interface. I used a PocketNC for a few months that was running with MachineKit and I really like it. Very stable, and I loved the non buffered, real time control. I've got a 3 axis machine that has a power supply, open loop steppers, and limit switches, and working control in it. I want to remove that control in favor of a Beaglebone Black, external screen, mouse, and keyboard. Aside from the Beaglebone black, I'm considering using this board: http://www.probotix.com/wiki/index.php/PBX-BB_rev5.2 It seems like a good choice because it works with LCD screens, MachineKit, and has the IO that I need. I don't know what I don't know so if anyone has any suggestions I'd be interested in hearing them! -- 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
