And this is how I load&connect my custom component in my HAL file: loadrt home_index_switch > newinst second_home_switch home-sw2 pincount=2 > ## micrometric&super accurate "second" home switch > net home-sw2-x <= bb_gpio.p8.in-12 > ## Max limit switch use as "first" home switch > net limit-x-max <= bb_gpio.p8.in-08 > ## connect signals between my custom component and Machinekit regular > signals > net limit-x-max => home-sw2.0.home-sw1-in > net home-sw2-x => home-sw2.0.home-sw2-in > net home-sw-x home-sw2.0.home-sw-out => axis.0.home-sw-in > net home-state-x home-sw2.0.home-state <= axis.0.home-state
... ## I also have similar config for another axis (*home-sw2.1...*) but there > is no really added value to show it here... On Monday, 24 February 2020 11:55:39 UTC+1, Damien Dando wrote: > > Hi John, > > It seems that in order to avoid a custom build of MachineKit, that I need >> a way to either trigger immediate homing or the ability to detect that a >> user initiated immediate homing from within HAL. Any ideas? > > You can write a custom ".icomp" component to handle your homing logic: > http://www.machinekit.io/docs/hal/instcomp_writing_a_component/ > I did something similar because I wanted to handle 2 home switches. In my > case, it goes "high" speed to touch the first home switch (with low > accuracy) and "low" speed to the second home switch (the expensive switch > with micrometer accuracy). > This allow you to make custom homing sequence without doing any custom > build of machinekit. > > Here is the component I did: > Filename "*second_home_switch.icomp*": > >> component second_home_switch "use a second home switch for homing"; >> pin in s32 #.home-state[pincount] "connect to the home-state of the join"; >> pin in bit #.home-sw1-in[pincount] "connect to the first home switch >> input pin"; >> pin in bit #.home-sw2-in[pincount] "connect to the second home switch >> input pin"; >> pin out bit #.home-sw-out[pincount] "connect to the home switch input of >> the join"; >> instanceparam int pincount = 4; >> option MAXCOUNT 16; >> function _; >> license "GPL"; >> author "Damien Dando"; >> ;; >> FUNCTION(_) { >> hal_s32_t n; >> for (n = 0; n < local_pincount; n++) { >> /* >> * 12 corresponds to the HOME_RISE_SEARCH_WAIT state of the homing sequence >> * where the home switch is detected with lower speed (HOME_LATCH_VEL) for >> a second time. >> */ >> if (_home_state(n) == 12) { >> _home_sw_out(n) = _home_sw2_in(n); >> } else { >> _home_sw_out(n) = _home_sw1_in(n); >> } >> } >> return 0; >> } > > > The code basically select between one of the 2 home switches depending of > the internal state in the homing sequence. (For your case it would be > obviously different code&signals). > > To detect the state of the homing sequence (or to know if there is a > homing sequence going on at all), I have used the signal > "axis.*N*.home-state". > This signal has a different value depending of the current state in the > homing sequence (see home_state_t enum in motion.h > <https://github.com/machinekit/machinekit/blob/master/src/emc/motion/motion.h#L417-L444> > and > do_homing() in homing.c > <https://github.com/machinekit/machinekit/blob/master/src/emc/motion/homing.c#L193>). > > If you don't feel digging into the source code you can also use the hal > meter and directly look at the values "axis.*N*.home-state" go through > during the homing sequence. > Note: Even if it might be unlikely, it is not guarantee that the signal > "axis.*N*.home-state" will keep same value in the homing sequence in > future versions of Machinekit so you should keep that in mind if your > homing stuff stop working after upgrading your Machinekit. > > > On Sunday, 23 February 2020 18:31:42 UTC+1, John Allwine wrote: >> >> The main reason why I’m not able to get it working out of the box is the >> Teknic motor stops being in homing mode if the machine is jogged at all >> after the enable pin is asserted. So I would like the enable pin to be a >> part of the homing sequence itself, to avoid any issues arising from that. >> >> I left out that I’ll need a homing sequence for a continuous rotary axis, >> as well. The Teknic motors can also very accurately home to a specific >> angle when enabled. We’ll have a 50:1 reducer on the motor, so it could >> feasibly home to 50 different locations without first moving to a limit >> switch. Because of that the motor must be enabled twice during the sequence >> (the first in order to command it until the limit switch is found, the >> second to accurately home to an angle once found). I plan on starting with >> the linear axes to see if I can learn anything helpful prior to starting on >> this more involved routine. >> >> It seems that in order to avoid a custom build of MachineKit, that I need >> a way to either trigger immediate homing or the ability to detect that a >> user initiated immediate homing from within HAL. Any ideas? >> >> John Allwine >> Owner of Allwine Designs >> https://www.allwinedesigns.com >> >> On Feb 22, 2020, at 11:25 AM, Bas de Bruijn <b...@basdebruijn.com> wrote: >> >> >> The google group fell off the reply. >> For completeness done manually :) >> >> On 22 Feb 2020, at 17:44, Bas de Bruijn <b...@basdebruijn.com> wrote: >> >> >> >> >> On 22 Feb 2020, at 15:25, John Allwine <jo...@allwinedesigns.com> wrote: >> >> Hi Bas, >> >> Thanks for your suggestion! I’ll definitely look into writing a custom >> component rather than a custom MachineKit build. >> >> I’m afraid, though, that I don’t completely follow the rest of your >> suggestion. Could you please expand a little? I have used immediate mode >> before. Let’s say a user clicks a home button in the Axis GUI. How could I >> tie into that event to start the process? Alternatively, if I created my >> own button to trigger something in Hal, how would I trigger immediate >> homing? How would you recommend setting the position on the rising edge? >> >> >> You might not have to do anything. I’m not an expert on the cnc stack. >> If you have wired the enable pin of the motor physically and in HAL to >> the enable pin of the motion component, then pressing the home button in >> the GUI should start homing. Thus moving towards the end of your >> guide/motor. >> Make sure you wire the smart pin to the home Hal pin. >> Would that not work out of the box? >> Does the special pin stay high after homing? >> >> >> I believe I have a good grasp on how Hal works, but my knowledge of the >> built in components is limited. >> >> Thanks again for the help! >> >> John Allwine >> Owner of Allwine Designs >> https://www.allwinedesigns.com >> >> On Feb 22, 2020, at 1:04 AM, Bas de Bruijn <b...@basdebruijn.com> wrote: >> >> >> >> >> On 21 Feb 2020, at 23:30, John Allwine <jo...@allwinedesigns.com> wrote: >> >> >> I'm looking into using Teknic SDSK servo motors with MachineKit. The SDSK >> models accept step and direction pulses like a stepper motor, so using >> hal_pru_generic's stepgen is straight forward. The major issue I see is >> attempting to use Teknic's precision homing routines, as it doesn't fit >> into MachineKit's limit switch routines. I'd really like to use their >> homing routine because it is accurate to less than 1/10,000 of an inch in >> my setup, which could be difficult to achieve using my own limit switch >> setup. It seems to me that in order to do so would require either a custom >> homing routine implemented in C++ (so a custom build of MachineKit). Any >> thoughts on this would be appreciated! >> >> The Teknic motors have 3 control pins and 1 feedback pin: >> >> Control Pins: >> Enable - Used to enable/disable the motor and plays a part in initiating >> the precision homing (see below). >> Step - Same as for a stepper motor >> Direction - Same as for a stepper motor >> >> Feedback - They refer to this as the HLFB (high level feedback) pin. Can >> be set to a number of different options, but the relevant one for homing >> would be ASG (all systems go) Position, which is high when the motor is in >> the commanded position, low while moving. >> >> The precision homing sequence is initiated as follows: >> >> 1) Put the motor into homing mode by toggling the enable pin on (if it's >> already on, then turn it off, then back on). >> 2) Command the motor with step and direction to move the joint to a hard >> stop. >> 3) The motor will detect the hard stop and stop accepting step pulses >> until it is commanded to go the opposite direction. >> 4) After the hard stop is detected the motor will back off to a precise >> location a configured number of internal encoder counts away. >> 5) After a configured number of milliseconds (default is 10), the HLFB >> pin asserts indicating that homing is complete. >> >> The hard stop detection and precision homing is fantastic. After the >> first homing sequence, the motor will return to a very precise location as >> long as the hard stop stays within ~2mm. I can physically put a shim (less >> than 2mm thick) in front of the hard stop and it still goes to a precise >> location that properly ignores the shim (so wearing on the hard stop over >> time doesn't affect the precision of the homing sequence). >> >> So, does anyone have recommendations for how to perform this sequence >> properly in MachineKit? Preferably, I'd avoid needing a custom build of >> MachineKit, but if it's required to make homing a simple click of a button >> then I'll have to go that route. >> >> >> Hi John, >> >> So if I understand correctly your homing sequence is started on the >> rising edge of the enable pin. >> >> Then you need to move to your chosen homing side. >> Your homing is done when the special pin rises. >> >> Maybe all parts are already there. >> Have you tried configuring as ‘immediate’ homing? So rising special pin >> sets the position? >> http://www.machinekit.io/docs/config/ini_homing/ >> >> Even if you decide you need a special component, you do not have to >> rebuild MK, just write the comp in C and install with instcomp. >> >> http://www.machinekit.io/docs/hal/instcomp/ >> >> Best, >> Bas >> >> >> -- >> 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 machi...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/machinekit/6b01a405-251f-4633-af72-abbcd6c78ab0%40googlegroups.com >> >> <https://groups.google.com/d/msgid/machinekit/6b01a405-251f-4633-af72-abbcd6c78ab0%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> 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 machi...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/machinekit/7E019B91-0888-4BE4-8F65-1F22B40EC7C6%40allwinedesigns.com >> >> <https://groups.google.com/d/msgid/machinekit/7E019B91-0888-4BE4-8F65-1F22B40EC7C6%40allwinedesigns.com?utm_medium=email&utm_source=footer> >> . >> >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/b1eeaaa8-3f3f-4716-9dd7-b375acc1b342%40googlegroups.com.
