Re: [Machinekit] pru_generic.so: cannot open shared object file: No such file or directory

[John Allwine]

Maybe symlinking the other file would work?
sudo ln -s /usr/lib/linuxcnc/rt-preempt/hal_pru_generic.so
/usr/lib/linuxcnc/rt-preempt/pru_generic.so

Also, maybe specify the specific file for your prucode, which includes the
.bin?
loadrt prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.bin pru=0
halname=hpg

<https://www.pentamachine.com>



  John Allwine

  Principal Software Engineer

 1.406.451.3799

  https://www.pentamachine.com



<https://www.pentamachine.com>



On Fri, May 12, 2023 at 12:50 PM Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> You are missing the name of the HAL driver.  The loadrt command expects
> a driver name, then the arguments.  The error in your first command
> shows the HAL system trying to load the HAL driver named:
>
> "prucode=/usr/lib/linuxcnc/rt-preempt/hal_pru_generic"
>
> ...you need something like:
>
> loadrt hal_pru_generic 
>
>
> On 5/12/2023 1:06 PM, klemen dovrtel wrote:
> > Thank you for your reply,
> >
> > I tried both options, but with no luck:
> > 1. loadrt prucode=/usr/lib/linuxcnc/rt-preempt/hal_pru_generic pru=0
> > halname=hpg
> >
> > returns
> >
> > msgd:0 stopped
> > rtapi:0 stopped
> > rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0
> > --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288
> > rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_rt-preempt
> --instance=0
> > --debug=1
> > stat: No such file or directory
> > prutest.hal:6: insmod failed, returned -1:
> > do_load_cmd: dlopen:
> > prucode=/usr/lib/linuxcnc/rt-preempt/hal_pru_generic.so: cannot open
> shared
> > object file: No such file or directory
> > rpath=/usr/lib/linuxcnc/rt-preempt
> >
> > 2. loadrt prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.bin pru=0
> > halname=hpg
> >
> > returns
> >
> > msgd:0 stopped
> > rtapi:0 stopped
> > rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0
> > --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288
> > rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_rt-preempt
> --instance=0
> > --debug=1
> > stat: No such file or directory
> > prutest.hal:6: insmod failed, returned -1:
> > do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/
> pru_generic.bin.so:
> > cannot open shared object file: No such file or directory
> >
> > Regards
> > Klemen
> >
> >
> >
> >
> > On Fri, 12 May 2023 at 17:25, Charles Steinkuehler <
> char...@steinkuehler.net>
> > wrote:
> >
> >> Your output indicates dlopen is looking for "pru_generic.so" but your
> >> filesystem only has "hal_pru_generic.so".
> >>
> >> You need to fix the script(s) trying to load the PRU HAL module or make
> >> a symlink or something so the file dlopen is looking for actually
> exists.
> >>
> >> On 5/12/2023 9:38 AM, fogl wrote:
> >>> Hello everybody,
> >>>
> >>> I am stuck with machinekit and pru. I am running a single line .hal
> file:
> >>> loadrt prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic pru=0
> halname=hpg
> >>>
> >>> This returns:
> >>> msgd:0 stopped
> >>> rtapi:0 stopped
> >>> rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0
> >>> --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288
> >>> rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_rt-preempt
> >> --instance=0
> >>> --debug=1
> >>> stat: No such file or directory
> >>> prutest.hal:6: insmod failed, returned -1:
> >>> do_load_cmd: dlopen:
> prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so:
> >>> cannot open shared object file: No such file or directory
> >>> rpath=/usr/lib/linuxcnc/rt-preempt
> >>>
> >>> Even though the file is actually there:
> >>> $ ls /usr/lib/linuxcnc/rt-preempt | grep pru
> >>> hal_pru.so
> >>> hal_pru_generic.so
> >>> hal_prudebug.so
> >>> pru_decamux.bin
> >>> pru_decamux.dbg
> >>> pru_generic.bin
> >>> pru_generic.dbg
> >>>
> >>> This is my linuxcnc.log (export DEBUG=5):
> >>> May 12 14:19:23 beaglebone rtapi:0: do_load_cmd: dlopen:
> >>> prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot open shared
> >>> object file:$
> >>> May 12 14:19:23 beaglebone rtapi:0: rpath=/usr/lib/linuxcnc/rt-preempt
> >>> May 12 14:

Re: [Machinekit] pru_generic.so: cannot open shared object file: No such file or directory

[John Allwine]

Is it just a matter of adding the .bin to the file name? Something like
this:
loadrt prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.bin pru=0
halname=hpg

On Fri, May 12, 2023 at 8:38 AM fogl  wrote:

> Hello everybody,
>
> I am stuck with machinekit and pru. I am running a single line .hal file:
> loadrt prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic pru=0 halname=hpg
>
> This returns:
> msgd:0 stopped
> rtapi:0 stopped
> rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0
> --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288
> rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_rt-preempt
> --instance=0 --debug=1
> stat: No such file or directory
> prutest.hal:6: insmod failed, returned -1:
> do_load_cmd: dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so:
> cannot open shared object file: No such file or directory
> rpath=/usr/lib/linuxcnc/rt-preempt
>
> Even though the file is actually there:
> $ ls /usr/lib/linuxcnc/rt-preempt | grep pru
> hal_pru.so
> hal_pru_generic.so
> hal_prudebug.so
> pru_decamux.bin
> pru_decamux.dbg
> pru_generic.bin
> pru_generic.dbg
>
> This is my linuxcnc.log (export DEBUG=5):
> May 12 14:19:23 beaglebone rtapi:0: do_load_cmd: dlopen:
> prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot open shared
> object file:$
> May 12 14:19:23 beaglebone rtapi:0: rpath=/usr/lib/linuxcnc/rt-preempt
> May 12 14:19:23 beaglebone rtapi:0: 1:rtapi_app:4613:user do_load_cmd:
> dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot op$
> May 12 14:19:23 beaglebone rtapi:0: 1:rtapi_app:4613:user
> rpath=/usr/lib/linuxcnc/rt-preempt
> May 12 14:19:24 beaglebone msgd:0: rtapi_app exit detected - scheduled
> shutdown
> May 12 14:19:26 beaglebone msgd:0: msgd shutting down
> May 12 14:28:07 beaglebone rtapi:0: do_load_cmd: dlopen:
> prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot open shared
> object file:$
> May 12 14:28:07 beaglebone rtapi:0: rpath=/usr/lib/linuxcnc/rt-preempt
> May 12 14:28:07 beaglebone rtapi:0: 1:rtapi_app:4766:user do_load_cmd:
> dlopen: prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.so: cannot op$
> May 12 14:28:07 beaglebone rtapi:0: 1:rtapi_app:4766:user
> rpath=/usr/lib/linuxcnc/rt-preempt
> May 12 14:28:08 beaglebone msgd:0: rtapi_app exit detected - scheduled
> shutdown
> May 12 14:28:10 beaglebone msgd:0: msgd shutting down
>
>
> $ uname -a
> Linux beaglebone 4.19.120-bone-rt-r50 #1stretch PREEMPT RT Fri May 8
> 22:45:31 UTC 2020 armv7l GNU/Linux
>
> Every help would be very much appreciated,
> Regards,
> Klemen
>
> --
> 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/96db28f3-8676-472c-af15-d68fe2d1cab2n%40googlegroups.com
> 
> .
>

-- 
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/CAPEK9qaD7dtoBvcwdDxOWBxO-CLXMKKE4LJXfyvWbwmee6mSSw%40mail.gmail.com.

RE: [Machinekit] BBB Machinekit setup.sh differences

[John Dammeyer]

Thank you.  The HAL file does a 
loadusr -w ./setup.sh

So I'm going to guess standard linux text based shell script 
sudo $(which config-pin) -f - <<- EOF
P8.07   out # gpio2.2   DB25-1  Enable System
...

When I tried 
sudo $(which config-pin) P8.07 out

manually from the terminal it didn't work with "cannot read file P8.07".  It 
wasn't until I got this email that I realized I'd done a puTTY into the wrong 
beagle and tried it on one that wasn't running machinekit.

John

> -Original Message-
> From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
> Behalf Of Charles Steinkuehler
> Sent: April-21-21 4:57 AM
> To: John Dammeyer; machinekit@googlegroups.com
> Subject: Re: [Machinekit] BBB Machinekit setup.sh differences
> 
> On 4/20/2021 12:12 PM, John Dammeyer wrote:
> > I was looking at what is in my mill setup.sh and what is in a setup.sh 
> > Frederic Ribble sent me for his lathe on the BBB.  Notice one
> uses P8.12 and the other P8_12
> >
> > P8.12   out # gpio1.12 X_Step
> >
> > P8_12   out # X Step / DB25.2
> >
> > I suspect either will work but is there a preferred method?  Searching with 
> > "BBB setup.sh machinekit" doesn't provide any hits that
> make sense.  Like this one was 2018.  Is it too old or too new?
> > https://github.com/machinekit/machinekit/issues/1310
> >
> > Should I care?
> 
> The issue is whether you're running the shell script version of
> config-pin, or the newer compiled version.  The shell script was written
> to be pretty forgiving of pin number syntax and will accept a 2 or 3
> digit numeric value, optionally prefixed by "p" or "P", and with an
> optional separator (any non-numeric character) between the first digit
> and any remaining digits.  Two digit values are assumed to have an
> implicit zero in the pin number (eg: 82 -> P8_02).
> 
> I believe the compiled version of config-pin is somewhat more picky
> about naming conventions, but I haven't used it much.
> 
> --
> Charles Steinkuehler
> char...@steinkuehler.net
> 
> --
> 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/1797068e-ac3b-5644-57dd-
> c010f03d0698%40steinkuehler.net.

-- 
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/035b01d736ca%24b36cbaa0%241a462fe0%24%40autoartisans.com.

[Machinekit] BBB sharing limit/home switches.

[John Dammeyer]

For my MESA 7i92 I have this set up for sharing limit switches.

The Home and Minus Limit switch for the X axis are shared.
net min-home-x => axis.0.home-sw-in
net min-home-x => axis.0.neg-lim-sw-in

And the Positive Limits for X and Y along with the Minux Z are shared.
net max-x-y-min-z => axis.0.pos-lim-sw-in

Is there any reason that I can't share the home/min_limit switches to also be 
the positive limit?
As in:
net min-home-x => axis.0.pos-lim-sw-in

I imagine the system knows which direction it's going when it hits the limit 
and when the override limits is pressed all limits are overridden so it's still 
possible to back off?

The reason I'm asking is I've run into a snag with the BeagleBone and the 
Xylotex Cape.  The DB25-15 pin which I currently use as an input for the limits 
at the other end of the home switches happens to also be the QEP0 Index input 
for the spindle.  

The other QEP devices aren't available because the LCD_DATA pins are in use for 
the HDMI interface and without those no screen and therefore no AXIS interface. 
 There is QEP2 on GPIO1_12..14 but those are in use for step/dir pins.  Short 
of creating a brand new cape maintaining compatibility for the DB-25's from the 
MESA and the Xylotex cape doesn't seem possible.

Unless I'm missing something.  However if I can move the limit switches to be 
shared on just 3 pins then I can use the QEP0 and get that part working.

After that it looks like I'll need to make my own cape for the Beagle if I want 
to match the MESA 7i92H except that this cape would also add P9-19, P9-20 for 
CAN bus.
John


-- 
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/02c801d73643%2425880960%2470981c20%24%40autoartisans.com.

[Machinekit] BBB Machinekit setup.sh differences

[John Dammeyer]

I was looking at what is in my mill setup.sh and what is in a setup.sh Frederic 
Ribble sent me for his lathe on the BBB.  Notice one uses P8.12 and the other 
P8_12

P8.12   out # gpio1.12 X_Step

P8_12   out # X Step / DB25.2

I suspect either will work but is there a preferred method?  Searching with 
"BBB setup.sh machinekit" doesn't provide any hits that make sense.  Like this 
one was 2018.  Is it too old or too new?
https://github.com/machinekit/machinekit/issues/1310

Should I care?

Thanks
John


"ELS! Nothing else works as well for your Lathe"
Automation Artisans Inc.
www dot autoartisans dot com 


-- 
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/028401d73608%2453301fa0%24f9905ee0%24%40autoartisans.com.

RE: [Machinekit] BBB and charge pump

[John Dammeyer]

Thank you.
That worked.  The strange thing is that I actually had a comment in the file 
about interference but got my 8-- numbers mixed around and at one point did 
have the PWM pin removed from that list.  Then I put it back.  

I've now also added the ramp with slow spindle acceleration (although the 2HP 
Bergerda AC Servo is virtually instant on -- scary fast).

One other  question.  If the 8xx and 9xx numbers work for the loadrt 
hal_bb_gpio statement is it possible to also use them for the stepper motor pin 
selection here:

setp hpg.stepgen.00.steppin 0x4C
setp hpg.stepgen.00.dirpin  0x4D

Changing those to the 8-- and 9-- series would make the hal file more readable.

And ...  tada
Here's the evidence with how little is required to run a full 4 axis CNC 
machine to a PMDX-126 Break out Board.
Module to convert HDMI to VGA for the monitor.  Xylotex BBB_25/26 (now 
discontinued) and modified so outputs are always enabled so Charge Pump comes 
through and System Enable DB25-1 is active high.
http://www.autoartisans.com/beagle/BBB_SimplePP.jpg

And on the screen the MachineKit Axis interface.  If the code sets S3000 you 
can see Z motion is held off until the spindle is up to speed.  Really cool.  
Works now just like the PC with MESA 7i92H
http://www.autoartisans.com/beagle/BBB_Works.jpg

Here's the updated HAL file.
http://www.autoartisans.com/beagle/XylotexG3616.hal

and for reference the INI file.
http://www.autoartisans.com/beagle/XylotexG3616.ini

For anyone browsing through the files they will see that I'm also prepping to 
run the spindle with step/dir.  The wiring is already in place with a module 
that takes step/dir signals configured either as PWM/DIR or STEP/DIR.  The PWM 
goes into a small far east module to make 0-10V to a shielded cable to the 
servo drive.  The STEP/DIR signals are also converted to differential and go 
via the general DB25 cable with ENABLE and FAULT signals to the servo drive.  
All it takes is once parameter change on the servo to use step/dir.

With the BBB I can just use a different .HAL file.  With the MESA 7i92H the 
FPGA doesn't support PWM and STEP/DIR on the same pins so it requires 
reprogramming it which is why I've only done this with MACH3, LinuxCNC Parallel 
port and soon the Beagle. 

Again thanks
John


> -Original Message-
> From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
> Behalf Of Charles Steinkuehler
> Sent: April-18-21 7:08 AM
> To: machinekit@googlegroups.com
> Subject: Re: [Machinekit] BBB and charge pump
> 
> It looks like you have the PRU and the hal_bb_gpio both driving P8 pin
> 13, so they're stepping on each other.  Don't have the hal_bb_gpio
> driver talk to P8 pin 13 and things should work much better.  Also,
> unless you're using a _really_ old version of hal_bb_gpio, it will
> probably make more sense to use the newer 8xx/9xx pin numbering scheme
> like you are for the PRU pins.
> 
> Warning: lines below will probably wrap...the loadrt command needs to be
> all one line.
> 
> So turn this:
> loadrt hal_bb_gpio output_pins=107,113,119,126,214
> input_pins=109,110,114,118,241
> 
> ...into this:
> loadrt hal_bb_gpio output_pins=807,819,826,914
> input_pins=809,810,814,818,941
> 
> On 4/17/2021 6:14 PM, John Dammeyer wrote:
> > Things are not going well so I've attached the HAL file.
> > I've spent several days on this trying all sorts of different things and 
> > finally just reducing the HAL file to as simple as possible.
> >
> > I don't know if the photos would make it through so here are links to them. 
> >  Didn't have a USB stick handy to save them so I just
> photographed the entire scope.
> >
> > This one shows 50% PWM to the spindle as the yellow trace.
> > http://www.autoartisans.com/beagle/PWM50_ChgPmp-1.jpg
> > This one should be the same as the one above but isn't 50%.
> > http://www.autoartisans.com/beagle/PWM50_ChgPmp-2.jpg
> >
> > In fact the PWM appears to oscillate at about 2 hz with the falling edge 
> > synchronized to either edge of the blue trace which is the
> charge pump output.
> >
> > I've simplified the HAL file as much as possible.  It appears the PWM to 
> > the spindle is not being done in hardware and something is
> preventing it from staying at the requested 50%.
> > It doesn't matter if it's set from AXIS or if I do this.
> > setp hpg.pwmgen.00.out.00.value 25.0
> >
> >
> > I'm also not sure about this part:
> > # load low-level drivers
> > # Hex values of pins.  $6B,$71,$77,$7E,$D6
> > $6D,$6E,$72,$76,$F1
> > loadrt hal_bb_gpio output_pins=107,113,119,126,214 
> > input_pins=109,110,114,118,241
> > loadrt [PRUCONF](DRIVER) prucode=$(HAL_RTMOD_DIR)/[PRUCONF](PRUBIN) 
> >

RE: [Machinekit] BBB and charge pump

[John Dammeyer]

Things are not going well so I've attached the HAL file.
I've spent several days on this trying all sorts of different things and 
finally just reducing the HAL file to as simple as possible.
 
I don't know if the photos would make it through so here are links to them.  
Didn't have a USB stick handy to save them so I just photographed the entire 
scope.
 
This one shows 50% PWM to the spindle as the yellow trace.
http://www.autoartisans.com/beagle/PWM50_ChgPmp-1.jpg
This one should be the same as the one above but isn't 50%.
http://www.autoartisans.com/beagle/PWM50_ChgPmp-2.jpg
 
In fact the PWM appears to oscillate at about 2 hz with the falling edge 
synchronized to either edge of the blue trace which is the charge pump output.
 
I've simplified the HAL file as much as possible.  It appears the PWM to the 
spindle is not being done in hardware and something is preventing it from 
staying at the requested 50%.  
It doesn't matter if it's set from AXIS or if I do this.
setp hpg.pwmgen.00.out.00.value 25.0 
 

I'm also not sure about this part:
# load low-level drivers
# Hex values of pins.  $6B,$71,$77,$7E,$D6
$6D,$6E,$72,$76,$F1
loadrt hal_bb_gpio output_pins=107,113,119,126,214 
input_pins=109,110,114,118,241
loadrt [PRUCONF](DRIVER) prucode=$(HAL_RTMOD_DIR)/[PRUCONF](PRUBIN) 
[PRUCONF](CONFIG) halname=hpg
 
Depending on which machinekit and BBB web page I read the values for the 
output_pins have different numbers with the latest supposedly 813 for P8 Pin 13.
 
Setting up the spindle pin I do use 813 which appears to work.  However, again 
according to one of the web pages if I want the PRU to control this I'd use 
1813 rather than 813 or 0813.  However, no output appears when I use 1813.
 
So I'm still missing something with a hardware generated (or PRU generated PWM 
that has a  period of 1mS.)
 
No matter what I do the PWM oscilates between 0 and 50% synchronized to the 
edges of the charge_pump.
 
Any suggestions on what to do next?
Thanks
John
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of John Dammeyer
Sent: April-13-21 8:26 PM
To: 'Charles Steinkuehler'; machinekit@googlegroups.com
Subject: RE: [Machinekit] BBB and charge pump
 
Making progress. 
 
Scope shows PWM and DIR on correct pin.  Buttons work.  + button however 
increases speed reported value above 3000 RPM when examined with HAL meter even 
though PWM reached 100% at 3000 RPM.  (50 RPS)
Still missing something.
 
#(JCD) Add PWM Spindle control
#  
# Spindle 
#  
# This output is on DB25-14 
 
setp hpg.pwmgen.00.pwm_period   10 
setp hpg.pwmgen.00.out.00.pin   813 
setp hpg.pwmgen.00.out.00.enable1 
setp hpg.pwmgen.00.out.00.scale 50.0 
setp hpg.pwmgen.00.out.00.value 0 
 
net spindle-enable  <= motion.spindle-on
net spindle-vel-cmd-rps <= motion.spindle-speed-out-rps
net spindle-vel-cmd-rpm <= motion.spindle-speed-out
net spindle-vel-cmd-rpm-abs <= motion.spindle-speed-out-abs
net spindle-cw  <= motion.spindle-forward
net spindle-ccw <= motion.spindle-reverse
net spindle-brake   <= motion.spindle-brake
net spindle-revs=> motion.spindle-revs
 
net spindle-enable  => hpg.pwmgen.00.out.00.enable
net spindle-vel-cmd-rps => hpg.pwmgen.00.out.00.value
 
# This output is on DB25-16 and is Spindle Direction.
net spindle-ccw  =>  bb_gpio.p8.out-19
 
 
# This output is on DB25-17 
net charge-pump => bb_gpio.p9.out-14
 
 
> -Original Message-
> From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
> Behalf Of John Dammeyer
> Sent: April-13-21 7:46 PM
> To: 'Charles Steinkuehler'; machinekit@googlegroups.com
> Subject: RE: [Machinekit] BBB and charge pump
> 
> That's what I'm trying to get going now.  Actually first the PWM for spindle 
> speed and then I'll create the second PWM for charge
> pump.
> 
> Having a lot of trouble with the PWM for the spindle.  I've added what I 
> think are the correct motion.spindle- ... but all I can get on
> the AXIS screen are the +/- and STOP button along with the BRAKE checkbox.  
> And the +/- buttons do flip the DB25-16 port pin so
> that's all working.
> 
> But the set speed button is missing and I can't seem to link to the PWM 
> value.  Which means I'm missing something.  I'm using my
> MESA 7i92H as a guide although it's complicated by the extra ramping stuff I 
> have in there.
> 
> What makes the speed button show up on the screen?
> Thanks
> John
> 
> 
> > -Original Message-
> > From:  <mailto:machinekit@googlegroups.com> machinekit@googlegroups.com [ 
> > <mailto:machinekit@googlegroups.com> mailto:machinekit@googlegroups.com] On 
> > Behalf Of Charles Steinkuehler
> > Sent: April-13-21 6:50 PM
> > To:  <mailto:machin

RE: [Machinekit] BBB and charge pump

[John Dammeyer]

Making progress. 
 
Scope shows PWM and DIR on correct pin.  Buttons work.  + button however 
increases speed reported value above 3000 RPM when examined with HAL meter even 
though PWM reached 100% at 3000 RPM.  (50 RPS)
Still missing something.
 
#(JCD) Add PWM Spindle control
#  
# Spindle 
#  
# This output is on DB25-14 
 
setp hpg.pwmgen.00.pwm_period   10 
setp hpg.pwmgen.00.out.00.pin   813 
setp hpg.pwmgen.00.out.00.enable1 
setp hpg.pwmgen.00.out.00.scale 50.0 
setp hpg.pwmgen.00.out.00.value 0 
 
net spindle-enable  <= motion.spindle-on
net spindle-vel-cmd-rps <= motion.spindle-speed-out-rps
net spindle-vel-cmd-rpm <= motion.spindle-speed-out
net spindle-vel-cmd-rpm-abs <= motion.spindle-speed-out-abs
net spindle-cw  <= motion.spindle-forward
net spindle-ccw <= motion.spindle-reverse
net spindle-brake   <= motion.spindle-brake
net spindle-revs=> motion.spindle-revs
 
net spindle-enable  => hpg.pwmgen.00.out.00.enable
net spindle-vel-cmd-rps => hpg.pwmgen.00.out.00.value
 
# This output is on DB25-16 and is Spindle Direction.
net spindle-ccw  =>  bb_gpio.p8.out-19
 
 
# This output is on DB25-17 
net charge-pump => bb_gpio.p9.out-14
 
 
> -Original Message-
> From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
> Behalf Of John Dammeyer
> Sent: April-13-21 7:46 PM
> To: 'Charles Steinkuehler'; machinekit@googlegroups.com
> Subject: RE: [Machinekit] BBB and charge pump
> 
> That's what I'm trying to get going now.  Actually first the PWM for spindle 
> speed and then I'll create the second PWM for charge
> pump.
> 
> Having a lot of trouble with the PWM for the spindle.  I've added what I 
> think are the correct motion.spindle- ... but all I can get on
> the AXIS screen are the +/- and STOP button along with the BRAKE checkbox.  
> And the +/- buttons do flip the DB25-16 port pin so
> that's all working.
> 
> But the set speed button is missing and I can't seem to link to the PWM 
> value.  Which means I'm missing something.  I'm using my
> MESA 7i92H as a guide although it's complicated by the extra ramping stuff I 
> have in there.
> 
> What makes the speed button show up on the screen?
> Thanks
> John
> 
> 
> > -Original Message-
> > From:  <mailto:machinekit@googlegroups.com> machinekit@googlegroups.com [ 
> > <mailto:machinekit@googlegroups.com> mailto:machinekit@googlegroups.com] On 
> > Behalf Of Charles Steinkuehler
> > Sent: April-13-21 6:50 PM
> > To:  <mailto:machinekit@googlegroups.com> machinekit@googlegroups.com
> > Subject: Re: [Machinekit] BBB and charge pump
> >
> > If you just need a charge pump signal, use the PWM function on the PRU
> > (alternately, you could use a stepgen instance, but that's more code
> > overhead).
> >
> > On 4/13/2021 11:56 AM, John Dammeyer wrote:
> > > Just an update.  I have a 501.9 Hz square wave now coming out DB25-17.  
> > > The simple answer was that I needed to change to
> > >
> > > addf  charge_pump.0   servo-thread
> > >
> > > The .0 was the issue.
> > >
> > > The next issue, and I'm not sure how to get around this is the servo 
> > > thread is too slow and doing something like this:
> > > loadrt threads name1= fast-thread period1=10
> > >
> > > is not allowed. Probably because
> > > loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD 
> > > num_joints=[TRAJ]AXES tp=tp kins=trivkins
> > >
> > > loads 'motmod' which does what 'threads' does.
> > >
> > > I can try the standard parallel port generated version like:
> > > loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD 
> > > servo_period_nsec=[EMCMOT]SERVO_PERIOD
> > num_joints=[TRAJ]AXES
> > >
> > > But I'll have to dig deeper to see why that may or may not work.  Unless 
> > > someone has a better suggestion like doing it the way the
> > MESA does with an extra step/dir interface.
> > >
> > > Next part is I also want 1kHz PWM.  The MESA does this with hardware 
> > > again. Can the BBB can do it with the PRU?  If not it will
> have
> > to also be done with a base thread of about 10KHz.
> > >
> > > John
> > >
> > >
> > >
> > >> -Original Message-
> > >> From:  <mailto:machinekit@googlegroups.com> machinekit@googlegroups.com 
> > >> [ <mailto:machinekit@googlegroups.com> 
> > >> mailto:machinekit@googlegroups.com] On Behalf Of John Dammeyer
> >

RE: [Machinekit] BBB and charge pump

[John Dammeyer]

That's what I'm trying to get going now.  Actually first the PWM for spindle 
speed and then I'll create the second PWM for charge pump.

Having a lot of trouble with the PWM for the spindle.  I've added what I think 
are the correct motion.spindle- ... but all I can get on the AXIS screen are 
the +/- and STOP button along with the BRAKE checkbox.  And the +/- buttons do 
flip the DB25-16 port pin so that's all working.  

But the set speed button is missing and I can't seem to link to the PWM value.  
Which means I'm missing something.  I'm using my MESA 7i92H as a guide although 
it's complicated by the extra ramping stuff I have in there.

What makes the speed button show up on the screen?
Thanks
John


> -Original Message-
> From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
> Behalf Of Charles Steinkuehler
> Sent: April-13-21 6:50 PM
> To: machinekit@googlegroups.com
> Subject: Re: [Machinekit] BBB and charge pump
> 
> If you just need a charge pump signal, use the PWM function on the PRU
> (alternately, you could use a stepgen instance, but that's more code
> overhead).
> 
> On 4/13/2021 11:56 AM, John Dammeyer wrote:
> > Just an update.  I have a 501.9 Hz square wave now coming out DB25-17.  The 
> > simple answer was that I needed to change to
> >
> > addf  charge_pump.0   servo-thread
> >
> > The .0 was the issue.
> >
> > The next issue, and I'm not sure how to get around this is the servo thread 
> > is too slow and doing something like this:
> > loadrt threads name1= fast-thread period1=10
> >
> > is not allowed. Probably because
> > loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD 
> > num_joints=[TRAJ]AXES tp=tp kins=trivkins
> >
> > loads 'motmod' which does what 'threads' does.
> >
> > I can try the standard parallel port generated version like:
> > loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD 
> > servo_period_nsec=[EMCMOT]SERVO_PERIOD
> num_joints=[TRAJ]AXES
> >
> > But I'll have to dig deeper to see why that may or may not work.  Unless 
> > someone has a better suggestion like doing it the way the
> MESA does with an extra step/dir interface.
> >
> > Next part is I also want 1kHz PWM.  The MESA does this with hardware again. 
> > Can the BBB can do it with the PRU?  If not it will have
> to also be done with a base thread of about 10KHz.
> >
> > John
> >
> >
> >
> >> -Original Message-
> >> From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
> >> Behalf Of John Dammeyer
> >> Sent: April-12-21 8:52 PM
> >> To: 'Machinekit'
> >> Subject: [Machinekit] BBB and charge pump
> >>
> >> I'm using the Xylotex DB25 cape for the BBB.  I've been trying to add the 
> >> charge pump component without much luck.
> >> In the HAL file I can do a
> >> loadrt charge_pump
> >> but an
> >> addf charge_pump
> >> fails with
> >> function 'charge_pump' not found.
> >>
> >> If I leave that out and run MachineKit on the Beagle I do see
> >> charge-pump.0.enable
> >> charge-pump.0.out
> >> charge-pump.0.out-2
> >> charge-pump.0.out-4
> >> charge-pump.0.func.time
> >> charge-pump.0.func.tmax
> >> charge-pump.0.func.tmax-inc
> >>
> >> But since the this HAL file only has a servo thread and no base thread is 
> >> there a way to get this to work?
> >>
> >> Ultimately I want the ChargePump output on DB25-17 working in the same way 
> >> I have the PC with MESA 7i92H
> >> # DB25-10 actvive low ESTOP signal mapped to 7i92 pin 13
> >> # Pin#  I/O   Pri. funcSec. func   Chan  Pin funcPin 
> >> Dir
> >> # 10 13   IOPort   QCount   0Quad-A  (In)  
> >> estop-external-in (input)
> >>
> >> # MESA 7i92H P2 connections mapped to estop-external-in
> >> net estop-external-in <= hm2_7i92.0.gpio.013.in_not
> >>
> >> # Stepper #4 is the charge pump on the MESA card and is enabled with the 
> >> estop-external -in
> >> net estop-external-in => hm2_7i92.0.stepgen.04.enable
> >>
> >> which is output on DB25-17 from the MESA pin 7.
> >> # 17  7   IOPort   StepGen  4Step/Table1 (Out) 
> >> Charge Pump frequency (output)
> >>
> >>
> >> --
> >> website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
> >> https://github.com/machinekit
> &g

RE: [Machinekit] BBB and charge pump

[John Dammeyer]

Just an update.  I have a 501.9 Hz square wave now coming out DB25-17.  The 
simple answer was that I needed to change to

addf  charge_pump.0   servo-thread

The .0 was the issue.

The next issue, and I'm not sure how to get around this is the servo thread is 
too slow and doing something like this:
loadrt threads name1= fast-thread period1=10

is not allowed. Probably because 
loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD 
num_joints=[TRAJ]AXES tp=tp kins=trivkins

loads 'motmod' which does what 'threads' does.  

I can try the standard parallel port generated version like:
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD 
servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES

But I'll have to dig deeper to see why that may or may not work.  Unless 
someone has a better suggestion like doing it the way the MESA does with an 
extra step/dir interface.

Next part is I also want 1kHz PWM.  The MESA does this with hardware again. Can 
the BBB can do it with the PRU?  If not it will have to also be done with a 
base thread of about 10KHz.

John



> -Original Message-
> From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
> Behalf Of John Dammeyer
> Sent: April-12-21 8:52 PM
> To: 'Machinekit'
> Subject: [Machinekit] BBB and charge pump
> 
> I'm using the Xylotex DB25 cape for the BBB.  I've been trying to add the 
> charge pump component without much luck.
> In the HAL file I can do a
> loadrt charge_pump
> but an
> addf charge_pump
> fails with
> function 'charge_pump' not found.
> 
> If I leave that out and run MachineKit on the Beagle I do see
> charge-pump.0.enable
> charge-pump.0.out
> charge-pump.0.out-2
> charge-pump.0.out-4
> charge-pump.0.func.time
> charge-pump.0.func.tmax
> charge-pump.0.func.tmax-inc
> 
> But since the this HAL file only has a servo thread and no base thread is 
> there a way to get this to work?
> 
> Ultimately I want the ChargePump output on DB25-17 working in the same way I 
> have the PC with MESA 7i92H
> # DB25-10 actvive low ESTOP signal mapped to 7i92 pin 13
> # Pin#  I/O   Pri. funcSec. func   Chan  Pin funcPin Dir
> # 10 13   IOPort   QCount   0Quad-A  (In) 
> estop-external-in (input)
> 
> # MESA 7i92H P2 connections mapped to estop-external-in
> net estop-external-in <= hm2_7i92.0.gpio.013.in_not
> 
> # Stepper #4 is the charge pump on the MESA card and is enabled with the 
> estop-external -in
> net estop-external-in => hm2_7i92.0.stepgen.04.enable
> 
> which is output on DB25-17 from the MESA pin 7.
> # 17  7   IOPort   StepGen  4Step/Table1 (Out)
> Charge Pump frequency (output)
> 
> 
> --
> 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/0a0a01d73018%245f04d6e0%241d0e84a0%24%40autoartisans.com.

-- 
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/0a9d01d73085%24e9fe9c00%24bdfbd400%24%40autoartisans.com.

[Machinekit] BBB and charge pump

[John Dammeyer]

I'm using the Xylotex DB25 cape for the BBB.  I've been trying to add the 
charge pump component without much luck.
In the HAL file I can do a 
loadrt charge_pump
but an 
addf charge_pump 
fails with  
function 'charge_pump' not found.

If I leave that out and run MachineKit on the Beagle I do see 
charge-pump.0.enable
charge-pump.0.out
charge-pump.0.out-2 
charge-pump.0.out-4
charge-pump.0.func.time
charge-pump.0.func.tmax
charge-pump.0.func.tmax-inc

But since the this HAL file only has a servo thread and no base thread is there 
a way to get this to work?

Ultimately I want the ChargePump output on DB25-17 working in the same way I 
have the PC with MESA 7i92H 
# DB25-10 actvive low ESTOP signal mapped to 7i92 pin 13
# Pin#  I/O   Pri. funcSec. func   Chan  Pin funcPin Dir
# 10 13   IOPort   QCount   0Quad-A  (In)   
estop-external-in (input)

# MESA 7i92H P2 connections mapped to estop-external-in
net estop-external-in <= hm2_7i92.0.gpio.013.in_not

# Stepper #4 is the charge pump on the MESA card and is enabled with the 
estop-external -in
net estop-external-in => hm2_7i92.0.stepgen.04.enable

which is output on DB25-17 from the MESA pin 7.
# 17  7   IOPort   StepGen  4Step/Table1 (Out)  
Charge Pump frequency (output)


-- 
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/0a0a01d73018%245f04d6e0%241d0e84a0%24%40autoartisans.com.

Re: [Machinekit] Happy Birthday Machinekit!

[John Morris]

https<https://m.youtube.com/watch?v=ix68oRfI5Gw>://<https://m.youtube.com/watch?v=ix68oRfI5Gw>m.youtube.com<https://m.youtube.com/watch?v=ix68oRfI5Gw>/watch?v=ix68oRfI5Gw<https://m.youtube.com/watch?v=ix68oRfI5Gw>

Here's the Tormach robot on Shane Wighton's YouTube channel.

John

From: machinekit@googlegroups.com  on behalf of 
John Morris 
Sent: Saturday, April 3, 2021 9:45:36 PM
To: machinekit@googlegroups.com 
Subject: Re: [Machinekit] Happy Birthday Machinekit!

Happy Birthday Machinekit!

I haven't contributed much to Machinekit over the last year, but I've been 
working with a few other folks here in the community to integrate it into 
Tormach's new ZA6 robot, now in beta testing.  It has been gratifying to see 
how versatile Machinekit is and how easily it has integrated with ROS to play 
out trajectories.  I hope to have more related news to tell the community soon.

John


From: machinekit@googlegroups.com  on behalf of 
John Morris 
Sent: Friday, April 3, 2020 7:41 AM
To: machinekit@googlegroups.com
Subject: Re: [Machinekit] Happy Birthday Machinekit!

Happy sixth birthday, Machinekit!

Over the last year, the spun-out HAL repo has enjoyed major
improvements from over a dozen contributors in several areas.  The HM2
drivers and several HAL comps have new features, HAL now supports the
`arm64` architecture, Machinetalk sports a new OpenCV-based video
server, and many changes went into the build, packaging and CI
infrastructure to support the HAL/CNC repo split.  And after years of
wishing for it, I'm happy to see a new CMake build system ready to be
merged.

Along with progress, the year had its challenges, too.  The CI service
was suddenly and unexpectedly dismantled, leaving the project without
continuously updated packages; fortunately, an effort to resolve it is
underway.

Most saddening, a few, highly esteemed contributors have gone on
hiatus.  I appreciate everything they've done, and only hope to see
them more in the future, even if only on occasion.

I'm just grateful to all of you keeping the project going on a daily
basis.  Thank you for submitting all your PRs on GitHub, and thank you
for merging them.  Thank you for your chatter on the mailing list.
Thanks to you new, enthusiastic contributors joining the community.  I
look forward to collaborating with you over a new CI system and
porting LinuxCNC-EMC to run on Machinekit-HAL over the next year, and
over the next year, I'm looking forward to seeing what other advances
you all bring in.

 John


On 4/3/19 10:19 AM, John Morris wrote:
> Happy Birthday Machinekit!  5 years old now.
>
> This year, I'm very excited about the progress underway in the
> `machinekit-hal` repository.  HAL is the crown jewel of the Machinekit
> project, and splitting it off into its own repository brings it out
> from under the shadow of the EMC application and at last into the
> visibility of its own light.  There's a lot of polishing left to do,
> but it's huge progress that it is already usable, with its own
> independent code base and package stream.  Congratulations, and thanks
> to everyone who helped make this happen!
>
>  John
>
> On Wednesday, April 4, 2018 at 7:37:16 AM UTC+8, John Morris wrote:
>
> Happy Birthday #4 Machinekit!
>
> While I've probably *contributed to* Machinekit *less* in the last year
> than ever before, it turns out I've *used* Machinekit *more*, whether
> for the EMC app on my 3D printer, or whether for straight HAL and
> QtQuickVCP for Golibox, autoclave and robot controls.  Thanks to all
> the
> devs and maintainers for the great work.
>
>  John
>
>
> On 04/03/2017 12:19 AM, John Morris wrote:
>  > It's been three years.  Happy Birthday, Machinekit!
>  >
>  >  John
>  >
>  >
>  > On 04/03/2016 04:48 PM, John Morris wrote:
>  >> Happy two-year birthday, Machinekit!  Another great year and
> more great
>  >> leaps forward.  Keep it up!
>  >>
>  >> John
>  >>
>  >>
>  >> On 04/03/2015 03:59 AM, John Morris wrote:
>  >>> A year ago today on April 3, Michael posted the [Machinekit
>  >>> announcement] on the Emc-developers list.  IMO, that marks the
> official
>  >>> birthday of Machinekit, so,
>  >>>
>  >>> Happy Birthday!
>  >>>
>  >>> I'm incredibly pleased (and surprised!) by the huge leaps the
> project
>  >>> has made in such a short time, and by the explosive growth of the
>  >>> project's community.  In the [ZeroMQ Guide Chap. 6], Pieter
> Hint

Re: [Machinekit] Happy Birthday Machinekit!

[John Morris]

Happy Birthday Machinekit!

I haven't contributed much to Machinekit over the last year, but I've been 
working with a few other folks here in the community to integrate it into 
Tormach's new ZA6 robot, now in beta testing.  It has been gratifying to see 
how versatile Machinekit is and how easily it has integrated with ROS to play 
out trajectories.  I hope to have more related news to tell the community soon.

John


From: machinekit@googlegroups.com  on behalf of 
John Morris 
Sent: Friday, April 3, 2020 7:41 AM
To: machinekit@googlegroups.com
Subject: Re: [Machinekit] Happy Birthday Machinekit!

Happy sixth birthday, Machinekit!

Over the last year, the spun-out HAL repo has enjoyed major
improvements from over a dozen contributors in several areas.  The HM2
drivers and several HAL comps have new features, HAL now supports the
`arm64` architecture, Machinetalk sports a new OpenCV-based video
server, and many changes went into the build, packaging and CI
infrastructure to support the HAL/CNC repo split.  And after years of
wishing for it, I'm happy to see a new CMake build system ready to be
merged.

Along with progress, the year had its challenges, too.  The CI service
was suddenly and unexpectedly dismantled, leaving the project without
continuously updated packages; fortunately, an effort to resolve it is
underway.

Most saddening, a few, highly esteemed contributors have gone on
hiatus.  I appreciate everything they've done, and only hope to see
them more in the future, even if only on occasion.

I'm just grateful to all of you keeping the project going on a daily
basis.  Thank you for submitting all your PRs on GitHub, and thank you
for merging them.  Thank you for your chatter on the mailing list.
Thanks to you new, enthusiastic contributors joining the community.  I
look forward to collaborating with you over a new CI system and
porting LinuxCNC-EMC to run on Machinekit-HAL over the next year, and
over the next year, I'm looking forward to seeing what other advances
you all bring in.

 John


On 4/3/19 10:19 AM, John Morris wrote:
> Happy Birthday Machinekit!  5 years old now.
>
> This year, I'm very excited about the progress underway in the
> `machinekit-hal` repository.  HAL is the crown jewel of the Machinekit
> project, and splitting it off into its own repository brings it out
> from under the shadow of the EMC application and at last into the
> visibility of its own light.  There's a lot of polishing left to do,
> but it's huge progress that it is already usable, with its own
> independent code base and package stream.  Congratulations, and thanks
> to everyone who helped make this happen!
>
>  John
>
> On Wednesday, April 4, 2018 at 7:37:16 AM UTC+8, John Morris wrote:
>
> Happy Birthday #4 Machinekit!
>
> While I've probably *contributed to* Machinekit *less* in the last year
> than ever before, it turns out I've *used* Machinekit *more*, whether
> for the EMC app on my 3D printer, or whether for straight HAL and
> QtQuickVCP for Golibox, autoclave and robot controls.  Thanks to all
> the
> devs and maintainers for the great work.
>
>  John
>
>
> On 04/03/2017 12:19 AM, John Morris wrote:
>  > It's been three years.  Happy Birthday, Machinekit!
>  >
>  >  John
>  >
>  >
>  > On 04/03/2016 04:48 PM, John Morris wrote:
>  >> Happy two-year birthday, Machinekit!  Another great year and
> more great
>  >> leaps forward.  Keep it up!
>  >>
>  >> John
>  >>
>  >>
>  >> On 04/03/2015 03:59 AM, John Morris wrote:
>  >>> A year ago today on April 3, Michael posted the [Machinekit
>  >>> announcement] on the Emc-developers list.  IMO, that marks the
> official
>  >>> birthday of Machinekit, so,
>  >>>
>  >>> Happy Birthday!
>  >>>
>  >>> I'm incredibly pleased (and surprised!) by the huge leaps the
> project
>  >>> has made in such a short time, and by the explosive growth of the
>  >>> project's community.  In the [ZeroMQ Guide Chap. 6], Pieter
> Hintjens
>  >>> writes that the two go hand-in-hand, and says "It's hard to
>  >>> overemphasize the power and persistence of a working open source
>  >>> community."  That's exactly what I see here, an amazing bunch
> of folks
>  >>> continually attracting new amazing folks, and the result is
> brilliance.
>  >>>   Congratulations to everybody, both those participating in the
>  >>> Machinekit project today, and also those

RE: [Machinekit] Re: running EMCApplication basic steps

[John Dammeyer]

Hi Caludio,
I'm currently also working with CANopen (and CAN in general).  Busy trying to 
get socketCAN to work with Lazarus (Free Pascal).  
 
At the moment the program compiles/runs on a PC, Raspberry Pi and a BeagleBone. 
 With the PC I'm using the Lawicel CANUSB dongle and have it also working on 
the Pi and the BBB without issues as a USB serial device.  
 
With socketCAN the standard candump.c program also works with the Lawicel 
CANUSB and either an MCP2515 HAT for the Pi or the internal CAN device on the 
BBB.  So I know the hardware can function with the socketCAN driver.  Just 
making it work with Lazarus is still the challenge.
 
The full source code will be released when I have it working.   Here are a 
couple of screen shots.
 
This is just a terminal program for dealing with the CANUSB or any other serial 
port based CAN dongle.
 
cid:image001.png@01D6A7A9.546057C0
 
 
Now we're more into CANopen with the ability to send a number of SDO messages 
to find the node ID etc.
cid:image002.png@01D6A7A9.546057C0
 
And finally the ability to send specific CANopen SDO messages to a CANopen 
device.
cid:image003.png@01D6A7A9.546057C0
 
Ultimately I'll add a logging/playback function so I can receive and timestamp 
messages.  Then be able to parse that file and play back specific nodes 
messages to simulate a larger system without all the hardware in place.
 
And of course instead of the serial port CANUSB be able to use the socketCAN 
interface on the Pi and BBB.  
 
This will run on MachineKit (I do have a microSD card with MachineKit for the 
BBB) and once I add Lazarus to my LinuxCNC (on Pi or a PC) can also run it on 
the milling machine system.
 
I'm almost at the point where I can start building a power draw bar and would 
like to make it and an automatic tool changer be CANopen based.
 
John Dammeyer
 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of Claudio Lorini
Sent: October-22-20 4:32 AM
To: Machinekit
Subject: [Machinekit] Re: running EMCApplication basic steps
 
I'm currently working on this: myd-czu3eg-4e4d-1200-c 
http://www.myirtech.com/list.asp?id=613
 
my main interest is motor in control applications using field busses (CAN and 
Ethercat)
i'm currently developing some can bus hal driver (for a can motor controller) 
for machinekit-hal,   
so not closely related to mesanet stuff, but yes, if i can help someway, why 
not?
 
the machinekit-hal stuff is working fine, i have had no luck in running cnc 
stuff yet, but i'm following 
current developments on EMCapplication really close...
 
 
  
On Wednesday, 21 October 2020 at 22:40:48 UTC+2 Michael Brown wrote:
I would like to hear some more about you new soc board porting.
Can you input the name of the MyirTech board you are using ?
 
-->   ImportError: No module named _hal
 
This seems to be related to python2/3 compatibility problems
 
Are you interested in adding your board to the Mksocfpga repo ?
 
Best wishes
Michael
On Saturday, October 3, 2020 at 7:49:44 PM UTC+2 Claudio Lorini wrote:
Hello, 
i'm trying running EMCApplication on a MYIR Ultrascale board, with kernel: 
Linux zus-cl 5.4.0-rt1+ #7 SMP PREEMPT_RT Wed Sep 30 13:21:36 CEST 2020 aarch64 
GNU/Linux
with Debian strech
 
I think i managed to install nachinekit-hal, all tests are passing and i can 
get some very 
nice result on latency tests:
Image removed by sender. 5.4RT.png
i built EMCA from sources and configured to use hachinekit-hal (i think)
./configure --with-hal=machinekit-hal
 
but launching any configuration for linuxcnc i get some sort of this error:

4:rtapi_app:5413:user pid=5413 flavor=rt-preempt gcc=6.3.0 20170516 git=unknown
Traceback (most recent call last):
  File "/home/zus/EMCApplication/bin/hal_manualtoolchange", line 11, in 
import linuxcnc, hal
  File "/home/zus/EMCApplication/lib/python/hal.py", line 30, in 
import _hal
ImportError: No module named _hal
 
 I think i miss some very basic step, i tried to look for some basic how-to but 
could not find anything useful... 
can someone point me in the right direction?
 
 
 
-- 
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/56395dda-e594-4d81-9a68-3a411c4ac6f4n%40googlegroups.com
 
<https://groups.google.com/d/msgid/machinekit/56395dda-e594-4d81-9a68-3a411c4ac6f4n%40googlegroups.com?utm_medium=email_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 t

Re: [Machinekit] How to write to /var/log/linuxcnc.log with Python?

[John Allwine]

I agree it’s not a high priority and if it becomes one for us, I’ll certainly 
contribute where I am able. 

I still need to get my pull request in order for getting hal_pru_generic 
working on the BeagleBone AI, as well as making it an instantiable component to 
be able to leverage multiple PRUs. It’s working, but needs some polish first.

> On Jul 29, 2020, at 5:09 PM, c...@tuta.io wrote:
> 
> Jul 28, 2020, 22:23 by j...@pocketnc.com:
> 
>> Thanks for all the info, Cern!
>> 
>> I dug a little deeper and on my Beaglebone that has a prebuilt MachineKit 
>> image from July of 2019 does not log rtapi_print_msg(RTAPI_MSG_ERR, ... ) 
>> calls to the msgd socket, nor the linuxcnc.error_channel. I also have 
>> another Beaglebone with a RIP install built from source back in March of 
>> this year. It behaves a little differently, but I haven't investigated too 
>> far. I know that some of my rtapi_print_msg calls were getting picked up by 
>> linuxcnc.error_channel and given there's work in progress to address logging 
>> issues, I'm not all that surprised by the difference in behavior. I'll let 
>> things shake out a little more before going further, but I appreciate all 
>> the help!
>> 
> I recently shallowly investigated  the logging because I was interested in 
> what pats would need to be changed to kick the RTAPI/ULAPI compiler switches 
> down to the trashbin of history. The logger is based on Simon Kelley's 
> syslog_async code from http://www.thekelleys.org.uk/syslog-async/ . But time 
> moves ever forward and today there are nice libraries for quick logging like  
> https://github.com/RafaGago/mini-async-log-c , 
> https://github.com/HardySimpson/zlog , https://github.com/zma/zlog/ and many 
> others. None or very few of these are implemented with real-time systems in 
> mind, so there is always work associated.
> 
> One of the reasons why I looked at it is because of the speed of logging, 
> respective what is done on the producer side (i.e. in real-time thread) and 
> what is done on the consumer side. (With rt preempt it is not going to be an 
> issue, given the minimal latency, but with EVL Core I have been able to reach 
> very nice lattencies where the logging speed and load will be important). But 
> I haven't done any real testings yet.
> 
> However, all this being said - to be honest - in the set of things which must 
> be done and issues needing repair in Machinekit, I consider this pretty low 
> priority. (Sorry.) Any patches will be welcomed by me, and I am sure by other 
> members of Machinekit community.
> 
> Cern.
> 
>> 
>> In case it helps anyone, I was able to connect to the msgd socket and did 
>> have to decode the messages in python like so:
>> import zmq 
>> import time 
>> from machinetalk.protobuf.message_pb2 import Container 
>> from machinetalk.protobuf.types_pb2 import * 
>> 
>> context = zmq.Context() 
>> sub = context.socket(zmq.SUB) 
>> sub.setsockopt(zmq.SUBSCRIBE, "") 
>> sub.connect("ipc:///tmp/0.log.") 
>> rx = Container()
>> while True: 
>>   msg = sub.recv() 
>>   rx.ParseFromString(msg)
>>   print("Received message: %s" % (rx,))
>> 
>>> On Tue, Jul 28, 2020 at 2:08 PM <> c...@tuta.io> > wrote:
>>> 
>>> When I was playing with it some year or two back, I just looked at exported 
>>> mDNS/DNS-SD/Bonjour services (there is a ton of programs for it on any 
>>> platform), got the address of the socket and then simply used quick'n'dirty 
>>> program written by the simple tutorial on >> zeromq.org 
>>> >> . I am not sure if the logs are sent as a plain-text 
>>> or encoded in Protocol Buffers messages. I think it is plaint-text, but if 
>>> not, you would then need to decode it.
>>> 
>>> I was doing it this way because I was using C#. But for Python there is 
>>> PyMachinetalk: >> https://github.com/machinekit/pymachinetalk>>  (But I 
>>> have no idea if and how it works).
>>> 
>>> Cern.
>>> 
>>> 
>>> Jul 27, 2020, 16:00 by >> j...@pocketnc.com>> :
>>> 
 What's the easiest way to connect directly to the msgd socket?
 
 On Fri, Jul 24, 2020 at 6:54 PM <> >> c...@tuta.io>> > > wrote:
 
> What about the ZMQ socket on the msgd process, can you see the messages 
> there? Given that I cannot find the error_channel() definition in 
> Machinekit-HAL, I am not sure if the support for it is done in rtapi 
> logging. I have a mounting anxiety that it is one of the things which 
> were in LinuxCNC but were superseded in Machinekit and now it is a bloody 
> stump. (In other words, something which on some nice day somebody will 
> have to solve/repair).
>   
>   However, still it is odd that C call to rtapi_print_msg you can see and 
> python call to RTAPILogger you cannot - when it uses the exact same 
> function - or at least it looks like it. As I said, I don't know Python 
> well, but can you stop/step into (debug) when the python calls the 
> rtapi_print_msg?
>   
>   BTW, are you 

Re: [Machinekit] How to write to /var/log/linuxcnc.log with Python?

[John Allwine]

Thanks for all the info, Cern!

I dug a little deeper and on my Beaglebone that has a prebuilt MachineKit
image from July of 2019 does not log rtapi_print_msg(RTAPI_MSG_ERR, ... )
calls to the msgd socket, nor the linuxcnc.error_channel. I also have
another Beaglebone with a RIP install built from source back in March of
this year. It behaves a little differently, but I haven't investigated too
far. I know that some of my rtapi_print_msg calls were getting picked up by
linuxcnc.error_channel and given there's work in progress to address
logging issues, I'm not all that surprised by the difference in behavior.
I'll let things shake out a little more before going further, but I
appreciate all the help!

In case it helps anyone, I was able to connect to the msgd socket and did
have to decode the messages in python like so:
import zmq
import time
from machinetalk.protobuf.message_pb2 import Container
from machinetalk.protobuf.types_pb2 import *

context = zmq.Context()
sub = context.socket(zmq.SUB)
sub.setsockopt(zmq.SUBSCRIBE, "")
sub.connect("ipc:///tmp/0.log.")
rx = Container()
while True:
  msg = sub.recv()
  rx.ParseFromString(msg)
  print("Received message: %s" % (rx,))

On Tue, Jul 28, 2020 at 2:08 PM  wrote:

> When I was playing with it some year or two back, I just looked at
> exported mDNS/DNS-SD/Bonjour services (there is a ton of programs for it on
> any platform), got the address of the socket and then simply used
> quick'n'dirty program written by the simple tutorial on zeromq.org. I am
> not sure if the logs are sent as a plain-text or encoded in Protocol
> Buffers messages. I think it is plaint-text, but if not, you would then
> need to decode it.
>
> I was doing it this way because I was using C#. But for Python there is
> PyMachinetalk: https://github.com/machinekit/pymachinetalk (But I have no
> idea if and how it works).
>
> Cern.
>
>
> Jul 27, 2020, 16:00 by j...@pocketnc.com:
>
> > What's the easiest way to connect directly to the msgd socket?
> >
> > On Fri, Jul 24, 2020 at 6:54 PM <> c...@tuta.io> > wrote:
> >
> >> What about the ZMQ socket on the msgd process, can you see the messages
> there? Given that I cannot find the error_channel() definition in
> Machinekit-HAL, I am not sure if the support for it is done in rtapi
> logging. I have a mounting anxiety that it is one of the things which were
> in LinuxCNC but were superseded in Machinekit and now it is a bloody stump.
> (In other words, something which on some nice day somebody will have to
> solve/repair).
> >>
> >>  However, still it is odd that C call to rtapi_print_msg you can see
> and python call to RTAPILogger you cannot - when it uses the exact same
> function - or at least it looks like it. As I said, I don't know Python
> well, but can you stop/step into (debug) when the python calls
> the rtapi_print_msg?
> >>
> >>  BTW, are you watching with right logging level?
> >>
> >>  Cern.
> >>
> >>
> >>  Jul 25, 2020, 02:27 by >> j...@pocketnc.com>> :
> >>
> >>  > I’ll have to dig a little deeper. I’m monitoring the error channel
> in Python using something like this (this is the only process calling poll
> on the error_channel):
> >>  >
> >>  > import linuxcnc
> >>  > e = linuxcnc.error_channel()
> >>  >
> >>  > while True:
> >>  >  error = e.poll()
> >>  >  if error:
> >>  >  print error
> >>  >  sleep(.1)
> >>  >
> >>  > I don’t see error messages come through when I use a separate Python
> process to log messages using RTAPILogger, but I do when using
> rtapi_print_msg in a real time component. I wasn’t aware of the debugging
> issues, so I’ll take a closer look. Thanks for the info!
> >>  >
> >>  >
> >>  >> On Jul 24, 2020, at 5:03 PM, >> c...@tuta.io>>  wrote:
> >>  >>
> >>  >> Hi,
> >>  >>
> >>  >> Jul 24, 2020, 23:14 by >> j...@pocketnc.com>> :
> >>  >>
> >>  >>> Unlike rtapi_print_msg, this doesn't seem to append messages to
> the linuxcnc.error_channel. Is there anyway to do so in python?
> >>  >>>
> >>  >> maybe I don't understand the question (and this python stuff is a
> little bit outside my comfort zone), however isn't the RTAPILogger
> implemented as a Cython wrapper of rtapi_print_msg? (In
> src/hal/cython/machinekit/rtapi.pyx.) And as such it should have the same
> output.
> >>  >>
> >>  >> Of course like many things in Machinekit, the logging project was
> started, implemented to a functioning state but then unfortunately left
> without much support and bugfixing, so there are problems. For example >>
> https://github.com/machinekit/machinekit-hal/issues/199
> >>  >>
> >>  >> Cern.
> >>  >>
> >>   On Thursday, July 16, 2015 at 12:19:57 AM UTC-6 >>
> al...@machinekoder.com>>  wrote:
> >>  
> >>  
> >>   Yishin Li writes:
> >>  
> >>  > Hi Michael,
> >>  >
> >>  > On Thursday, July 16, 2015 at 12:17:06 AM UTC+8, Michael
> Haberler wrote:
> >>  >
> >>  >>
> >>  >>
> >>  >> HOWEVER it does not log in sequence with the other events in
> HAL/RTAPI and
> >>  >> 

Re: [Machinekit] How to write to /var/log/linuxcnc.log with Python?

[John Allwine]

What's the easiest way to connect directly to the msgd socket?

On Fri, Jul 24, 2020 at 6:54 PM  wrote:

> What about the ZMQ socket on the msgd process, can you see the messages
> there? Given that I cannot find the error_channel() definition in
> Machinekit-HAL, I am not sure if the support for it is done in rtapi
> logging. I have a mounting anxiety that it is one of the things which were
> in LinuxCNC but were superseded in Machinekit and now it is a bloody stump.
> (In other words, something which on some nice day somebody will have to
> solve/repair).
>
> However, still it is odd that C call to rtapi_print_msg you can see and
> python call to RTAPILogger you cannot - when it uses the exact same
> function - or at least it looks like it. As I said, I don't know Python
> well, but can you stop/step into (debug) when the python calls
> the rtapi_print_msg?
>
> BTW, are you watching with right logging level?
>
> Cern.
>
>
> Jul 25, 2020, 02:27 by j...@pocketnc.com:
>
> > I’ll have to dig a little deeper. I’m monitoring the error channel in
> Python using something like this (this is the only process calling poll on
> the error_channel):
> >
> > import linuxcnc
> > e = linuxcnc.error_channel()
> >
> > while True:
> >  error = e.poll()
> >  if error:
> >  print error
> >  sleep(.1)
> >
> > I don’t see error messages come through when I use a separate Python
> process to log messages using RTAPILogger, but I do when using
> rtapi_print_msg in a real time component. I wasn’t aware of the debugging
> issues, so I’ll take a closer look. Thanks for the info!
> >
> >
> >> On Jul 24, 2020, at 5:03 PM, c...@tuta.io wrote:
> >>
> >> Hi,
> >>
> >> Jul 24, 2020, 23:14 by j...@pocketnc.com:
> >>
> >>> Unlike rtapi_print_msg, this doesn't seem to append messages to the
> linuxcnc.error_channel. Is there anyway to do so in python?
> >>>
> >> maybe I don't understand the question (and this python stuff is a
> little bit outside my comfort zone), however isn't the RTAPILogger
> implemented as a Cython wrapper of rtapi_print_msg? (In
> src/hal/cython/machinekit/rtapi.pyx.) And as such it should have the same
> output.
> >>
> >> Of course like many things in Machinekit, the logging project was
> started, implemented to a functioning state but then unfortunately left
> without much support and bugfixing, so there are problems. For example
> https://github.com/machinekit/machinekit-hal/issues/199
> >>
> >> Cern.
> >>
>  On Thursday, July 16, 2015 at 12:19:57 AM UTC-6
> al...@machinekoder.com wrote:
> 
> 
>  Yishin Li writes:
> 
> > Hi Michael,
> >
> > On Thursday, July 16, 2015 at 12:17:06 AM UTC+8, Michael Haberler
> wrote:
> >
> >>
> >>
> >> HOWEVER it does not log in sequence with the other events in
> HAL/RTAPI and
> >> that can be key for determining causality
> >>
> >> that is the primary reason for the unified logging architecture
> which
> >> funnels every log message through a message queue regardless of
> origin so
> >> sequencing is retained - RT, user (remember logging being a mess
> :-? like a
> >> bit here, a bit there, and a bit in dmesg and _no_ sequencing? )
> >>
> >> if you dont care about sequencing for one reason or the other, then
> the
> >> Python syslog package is fine
> >>
> > RTAPILogger works!
> >
> > Here's the RTAPILogger example:
> > from machinekit import rtapi
> > rtapi.init_RTAPI()
> >
>  No need to call init_RTAPI for logging -> it does only initialize
> RTAPICommand so it
>  can be used from the module e.g. rtapi.loadrt('blbla')
> 
> > log = rtapi.RTAPILogger(level=rtapi.MSG_ERR,tag="marker")
> > print >> log, "some message"
> > Here's the /var/log/linuxcnc.log:
> > Jul 16 10:34:17 interlaken msgd:0: marker:10350:user some message
> >
> > Awesome!
> >
> > Thank you very much,
> >
> > -Yishin
> >
> 
>  --
>  Alexander
> 
> >>>
> >>>
> >>>
> >>> --
> >>> 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/d3244a63-a003-4fa3-9ec0-2c44f1a0543an%40googlegroups.com
> <
> https://groups.google.com/d/msgid/machinekit/d3244a63-a003-4fa3-9ec0-2c44f1a0543an%40googlegroups.com?utm_medium=email_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 

Re: [Machinekit] How to write to /var/log/linuxcnc.log with Python?

[John Allwine]

I’ll have to dig a little deeper. I’m monitoring the error channel in Python 
using something like this (this is the only process calling poll on the 
error_channel):

import linuxcnc 
e = linuxcnc.error_channel()

while True:
  error = e.poll()
  if error:
print error
  sleep(.1)

I don’t see error messages come through when I use a separate Python process to 
log messages using RTAPILogger, but I do when using rtapi_print_msg in a real 
time component. I wasn’t aware of the debugging issues, so I’ll take a closer 
look. Thanks for the info!


> On Jul 24, 2020, at 5:03 PM, c...@tuta.io wrote:
> 
> Hi,
> 
> Jul 24, 2020, 23:14 by j...@pocketnc.com:
> 
>> Unlike rtapi_print_msg, this doesn't seem to append messages to the 
>> linuxcnc.error_channel. Is there anyway to do so in python?
>> 
> maybe I don't understand the question (and this python stuff is a little bit 
> outside my comfort zone), however isn't the RTAPILogger implemented as a 
> Cython wrapper of rtapi_print_msg? (In src/hal/cython/machinekit/rtapi.pyx.) 
> And as such it should have the same output.
> 
> Of course like many things in Machinekit, the logging project was started, 
> implemented to a functioning state but then unfortunately left without much 
> support and bugfixing, so there are problems. For example 
> https://github.com/machinekit/machinekit-hal/issues/199
> 
> Cern.
> 
>> 
>>> On Thursday, July 16, 2015 at 12:19:57 AM UTC-6 al...@machinekoder.com 
>>> wrote:
>>> 
>>> 
>>> Yishin Li writes: 
>>> 
 Hi Michael, 
 
 On Thursday, July 16, 2015 at 12:17:06 AM UTC+8, Michael Haberler wrote: 
> 
> 
> HOWEVER it does not log in sequence with the other events in HAL/RTAPI 
> and 
> that can be key for determining causality 
> 
> that is the primary reason for the unified logging architecture which 
> funnels every log message through a message queue regardless of origin so 
> sequencing is retained - RT, user (remember logging being a mess :-? like 
> a 
> bit here, a bit there, and a bit in dmesg and _no_ sequencing? ) 
> 
> if you dont care about sequencing for one reason or the other, then the 
> Python syslog package is fine 
> 
> 
 RTAPILogger works! 
 
 Here's the RTAPILogger example: 
 from machinekit import rtapi 
 rtapi.init_RTAPI() 
>>> No need to call init_RTAPI for logging -> it does only initialize 
>>> RTAPICommand so it 
>>> can be used from the module e.g. rtapi.loadrt('blbla') 
 log = rtapi.RTAPILogger(level=rtapi.MSG_ERR,tag="marker") 
 print >> log, "some message" 
 Here's the /var/log/linuxcnc.log: 
 Jul 16 10:34:17 interlaken msgd:0: marker:10350:user some message 
 
 Awesome! 
 
 Thank you very much, 
 
 -Yishin 
>>> 
>>> -- 
>>> Alexander 
>>> 
>> 
>> 
>> 
>> --
>> 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/d3244a63-a003-4fa3-9ec0-2c44f1a0543an%40googlegroups.com
>>  
>> >
>>  .
>> 
> 

-- 
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/EC8705B1-4EE5-4F9E-896A-48C4446AB8A5%40pocketnc.com.

Re: [Machinekit] Should I consider Machinekit?

[John Morris]

On 6/27/20 12:49 PM, Anthony Clay wrote:


I'm building a "big" SMT pick and place machine.  I hope to use Mesa 
anything i/o for interfacing, big stepper drives, linear encoders, and a 
number of sensors and other actuators, along with a communications bus 
for feeders.  Instead of using 3d printer firmwares, I'd prefer a 
linuxcnc-like interface for the machine itself - with visual elements 
for sensors like pressure/vacuum sensors, etc.  Also, I'll have to have 
G/M codes for "all of the things".  For the jobs themselves, I plan to 
use openpnp.  This will require some kind of driver to pipe gcode 
commands in MDI from openpnp to the linuxcnc stack. (I know there's a 
few more steps


Machinekit has the Machinetalk wrapper that provides an interface for 
remote interaction, including a facility for sending remote MDI commands 
and uploading and running .ngc files.


At the moment, however, this project is moving towards porting the 
LinuxCNC EMC application to run on Machinekit HAL.  While this appears 
to be working, the Machinetalk wrapper hasn't yet been ported over, AFAIK.


Until that work is finished, I don't see an advantage to your using MK 
in your application.


My question is, should I be looking towards machinekit/machinetalk to 
accomplish this? Or should I just default to linuxcnc and python/nml?  
(I'm hard-pressed to tell the difference between the two!) What is the 
difference? I'm seeing things that imply that machinekit can be used for 
machines that aren't specifically cutting machines, but very few examples.


Neither Machinekit nor LinuxCNC have any built-in support for PNP 
machines, AFAIK.  This application is something you'll have to integrate 
yourself.  There are probably others who have done some of this in the 
past; search the LCNC forums.


John

--
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/b9e96ad9-8790-cc12-a367-95c1260effe7%40dovetail-automata.com.

Re: [Machinekit] Sending gcode to Machinekit from remote source

[John Morris]

Check out the Machinetalk wrapper.  It has this functionality built in for 
remote UIs.

John


From: machinekit@googlegroups.com  on behalf of 
Michael Labuda 
Sent: Tuesday, June 16, 2020 11:33 PM
To: Machinekit
Subject: [Machinekit] Sending gcode to Machinekit from remote source

Greetings fellow Machinekit users,

I am wondering if Machinekit has any method of remotely receiving gcode 
commands from another application, similar to MDI mode except code is not typed 
directly at the UI. I am not concerned about security or latency and the gcode 
instructions I intend to send over are very simple, just G00/G01 and an 
occasional M code. I have found some unresolved posts asking a similar question 
however they are all several years old. Has such a capability been added on 
since then? Could someone point me in the best direction in which to implement 
such an option? I am open to developing a solution myself is necessary. Any 
advice would be greatly appreciated.

Thanks,
Michael

--
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<mailto:machinekit+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/0a67eaea-755a-4cb1-87c9-d82789169d06o%40googlegroups.com<https://groups.google.com/d/msgid/machinekit/0a67eaea-755a-4cb1-87c9-d82789169d06o%40googlegroups.com?utm_medium=email_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/BYAPR12MB3589286E8DA6CBAD130DEAC4859A0%40BYAPR12MB3589.namprd12.prod.outlook.com.

RE: [Machinekit] BBB RootCape - New Cape for BBB

[John Dammeyer]

Hi Jason,
I think you've pointed out something interesting here.  The fundamental center 
of pretty well any CNC system isn't the processor or the motors.  It's in fact 
the Break Out Board!
 
The question then becomes what goes on the Break Out Board and how much does it 
do.
 
My box of unused break out boards, accumulated about 14 years ago consists of:
https://www.probotix.com/CNC-CONTROL-SYSTEMS/BREAKOUT-BOARDS/PBX-RF
This now goes for 
 
BTW, Probotix makes a cape for the BBB which I don't have.
https://www.probotix.com/CNC-CONTROL-SYSTEMS/BREAKOUT-BOARDS/PBX-BB
but also states they don't offer support.  At $159.95 it's pretty expensive I 
think but does allow LCD capes like the LCD4 (which I also have).  Note it's 
also not so much as a BoB as an interface to the rest of the products that they 
sell.
 
I've also got an Ohmikron PPT1006 (discontinued) Here's a link to a posting and 
a photo
https://buildbotics.com/archive/cad_cam_edm_dro/messages/91260
Like the Probotix designed for their own stepper boards with minimal screw 
terminals.
 
Finally a small board with a male DB-25 and screw terminals along with some 
opto isolators.
 
Other than the Ohmikron setup which runs my ELS controlled Gingery Lathe the 
others never made it into a CNC project.  I did use the Xylotex Cape I have to 
run to the Probotix BoB to do MachineKit testing with the BBB on my mill.
 
But ultimately I've ended up with the newer PMDX-126 on the mill and still have 
the older PMDX-125 on the CNC router run with MACH3 and a PC.  But this PC 
talks to the hardware with a USB Smooth Stepper (ribbon cables) while the mill 
is either parallel port or MESA 7i92H (Ethernet) into the PMDX-126 DB-25.
 
The PMDX-125/126 are tailored for the Smooth Steppers with registered mounting 
holes and the ribbon cable sockets positioned for easy access to the Smooth 
Stepper.   There's an FPGA on the BoB that deals with charge pump input, fault 
and errors and the BoB has a transformer for a power supply and a couple of 
relays.
 
http://www.pmdx.com/PMDX-126
 
So you plop the BoB in the middle of the cabinet, add perhaps a DIN rail for 
some relays and extra screw terminals.  Mount the external motor drives and 
power supplies and run the wires.  True it's $174 w/o cables.
 
I question the need for the MESA 7i92H or the Smooth Stepper when instead of 
either of those at a much lower price you could plug in a BeagleBone.  
 
If I was going to design something I think I'd marry the concept of the LCD 
support that is provided by the Probotix PBX-BB along with the PMDX-126 but 
let's call it a PMDX-BB.
 
Then it becomes a choice of a system with LCD display, touch screen and a 
Pendant on a pedestal.  Or a system with Pendant, HDMI screen and 
keyboard/mouse with the electronics buried inside the control box.
 
No one BoB is going to be able to address all types of machines.  But I'd build 
on the success of the PMDX-125/126 systems. Especially their FAULT and ERROR 
and ESTOP handling along with their expansion for things like PWM to 0-10V for 
Spindle speed control.
 
And instead of an FPGA on the BoB, I'd look at CAN bus and CANopen as a 
connection to specialty hardware and the outside world.  
 
Anyway.  Even if the PC is free the WIN-10 OS and either MACH c/w Smooth 
Stepper is not.  Or if the PC is free, as is LinuxCNC, the MESA interface 
(which it appears most use for LinuxCNC) is not.  And the Break Out Board in 
some form is still required.  Whether it be from MESA or something like the 
PMDX-126.
 
The BBB with the two co-processors can create a reasonable 5 axis CNC system 
with spindle speed control and feedback for power tapping.  Add CAN bus (don't 
use the CAN pins for I/O) expansion for the slower I/O like coolant, tool 
changers, automatic clamps etc. you have the basics of an industrial controller 
for pick and place or CNC or 3D printing.
 
IMHO
John Dammeyer
 
 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of Jason Kridner
Sent: May-14-20 6:46 AM
To: Peter RCNC Newbery
Cc: Machinekit
Subject: Re: [Machinekit] BBB RootCape - New Cape for BBB
 
All of this is why I'd started a thread about making a Machinekit-focused cape 
with Seeed. Also, I'd want to bake-in support for the BeagleBone AI, which 
should give people a big boost in UI performance.
 
I started making a feature priority list, but then got distracted: 
https://github.com/beagleboard/capes/wiki/Motion-Control-Cape
 
What you've put together looks pretty nice. The drivers vs. no-drivers on-board 
debate is an interesting one. You can source these things on their own a whole 
lot cheaper than you can get the break-out boards. And putting break-out boards 
in your designs add a lot of cost and space. Maybe the space isn't so much a 
concern. The biggest concern in my mind is having more points of failure. How 
do we make something "just work" for those trying to get into this space for 
the first time?
 
I certainly 

[Machinekit] vfdb_vfd missing from latest machinekit-hal

[John Allwine]

It looks like the vfdb_vfd HAL module was removed when machinekit-hal 
separated from the main machinekit repository (this commit 
).
 
Was there any reason for this or did it just get lost in the separation 
process? I'm looking into using a Delta VFD and am wondering if I should 
try to get that module working or is there another recommended process?

-- 
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/7ec7127d-1349-4533-bb2e-f172836defc9%40googlegroups.com.

RE: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI

[John Dammeyer]

I too have looked at the BBB as a machine controller.  Using the Xylotex Cape I 
temporarily hooked it up to my mill conversion that had Z and Y completed.  
MachineKit.  The Xylotex DB-25 PP Port output to a PMDX-126 Break out board.
https://youtu.be/9GF709ZfLRQ
Although it worked I found the BBB video a bit laggy.  And I needed more and 
the either the limit switch or the ESTOP were for N/O switches which I don't 
believe is safe. It was the extra I/O and NO switches that moved me to a stock 
PC and for LinuxCNC I'm using the MESA 7i92 which is similar to a Ethernet 
Smooth Stepper for MACH.
 
The new Xylotex Cape for the BBB doesn't have this NO Switch problem.
They are also working on a larger cape that has drivers built in so a Break Out 
Board isn't needed.
 
I also own but haven't used the Replicape to install on a POS Delta 3D printer. 
 Both are sitting collecting dust as other projects have a higher priority.  
The Replicape, now discontinued, could also have run small CNC milling machines 
with the on board drivers although still more targeted at 3D printing hardware. 
 For example I don't think it will support an encoder on the spindle.
 
I think most of the small stepper drivers out there are for motors under 2A and 
24V.  Realistically it might be better to aim at using modules like the Gecko 
G250X to plug into the cape.  
https://www.geckodrive.com/g250x-digital-stepper-drive.html
Perhaps add a second socket for the cheaper drives used on 3D printers.  Google 
" 3D Printer Parts StepStick Motor Driver With Heat Sink A4988"
This way at least you can switch up to 3.5A motors at 48V which is handier for 
say Sherline Mills and lathes.
 
Perhaps the best way to make this cape is with the headers for the Gecko on the 
bottom like their G540
https://www.geckodrive.com/g540-4-axis-digital-stepper-drive.html
 
Add enough I/O for both types of heaters and also encoders and you might have 
something that works for both types of products.
 
The question is.  If you have a small Sherline Mill or Lathe would you even buy 
something like that?
John
 
 
 
From: 'David benson' via Machinekit [mailto:machinekit@googlegroups.com] 
Sent: May-05-20 1:08 AM
To: Machinekit
Subject: Re: [Machinekit] Seeed to design and build Machinekit focused Cape for 
BeagleBone Black/AI
 


On Wednesday, March 18, 2020 at 11:12:49 PM UTC+11, Jason Kridner wrote:
I think we have to reliably enable hobby-class machines first. Now, some people 
take hobby pretty far and I'm not trying to cap this off too small, I just 
don't want to boil the oceans. I'd say if we can do a bit more than what CRAMPS 
can do today, we should.
 
Personally, I'd want to at least be able to handle the larger 3D printers, 
smaller CNC mills and some pick-and-place machines. Looking around for some 
open source ones where the controller could be swapped:
* Aleph Objects LulzBot Tax Pro
* SeeMeCNC Rostock Max v3
* PocketNC V2
* Charmhigh CHM-T36VA (not open source, but affordable and hackable)
* Lasersaur
 
The desire for the above is mostly to be a vehicle for demonstrating motion 
control in a familiar way. Something CRAMPS-like could largely serve the above, 
though would need to be done regarding the price to make it sufficiently 
attractive, perhaps bundling as a kit.
 
Getting to the standard DB25 seems like a required thing to be widely usable in 
the community, no?
 
Hi Jason
 
I've just found this discussion regarding a new cape for the BBB\BBAI for the 
hobby focused 
cnc community.
A little background, so you know where I'm coming from, and what my biases are 
:P.
I've been using Mach3 Hobby grade mills and lathes for not quite 20 years now.
Three years ago I cnc'ed a 9 X 20 Lathe and was very happy with it's 
performance.
Two years ago I made a AI tool changer for it. 
build blog here: https://cambamcnc.com/forum/index.php?topic=6844.0 
<https://cambamcnc.com/forum/index.php?topic=6844.0> 
The blog is a bit dated now and goes to MK6, I'm currently at MK8. Here is a 
video of it running on the bench 
for the battery torture tests and AI detecting the tools.
Here: https://www.youtube.com/watch?v=FH2_B-Vgblc 
<https://www.youtube.com/watch?v=FH2_B-Vgblc=413s> =413s
 
I'm here because, I'm working on the Linuxcnc version of the software and have 
a BBB
with Machinekit installed, so that I can write a Linuxcnc component for it as 
well.
 
I don't know if you are aware, but Centroid have a Beagle Bone Green powered 
Acorn
CNC controller, and that board may be worth a look for some Ideas as it has 
some serious
thought gone into it.
 
A lot of the existing Hobby CNC installations I've seen have been as a general 
rule 
Mach3/4 or Linux cnc powered machines. either using the DB25 and a parallel port
or with an external motion controller like for example a Smoothstepper or UCCNC 
UC100
200,300 or 400. The UC stuff retrofits into existing systems people have very 
easily as they have 
a DB25 connector. All you do i

Re: [Machinekit] Machinekit + Ros for Scorbot Er-3

[John Morris]

Hi Tom,

You've had some good advice on the low-level HAL integration already.

Once you have all your joints and I/O connected up to HAL and you're 
ready to connect the robot up to MoveIt! and the rest of ROS, check out 
the hal_ros_control software [1] that @luminize, @machinekoder and I 
have written.  It will hook into your `moveit_setup_assistant` 
configuration with little fuss, and you'll be moving your robot through 
RViz in no time.


Good luck!

[1]: https://github.com/zultron/hal_ros_control/

John


On 5/4/20 2:18 AM, Tom M wrote:

Hi Guys,

Members of our hackerspace Workshop 88 <http://www.workshop88.com/> have 
acquired 3 Scorbot Er-3 with controllers.    We've tested them out and 
the bot's who we've named Huey, Dewey and Louie all seem to be working well.


We'd like to use Ros on those bots, but the issue is how to get there.

I was reading Alex Rössler post about machinekit and Ros at 
https://machinekoder.com/machinekit-ros-open-source-robots/ and it seems 
like this might be an approach worth trying.


Seb Kuzminsky used linuxcnc on a scorbot Er-3 with the existing control
https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/user_comps/scorbot-er-3.py 
<https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/user_comps/scorbot-er-3.py>



https://github.com/LinuxCNC/linuxcnc/tree/master/configs/by_machine/scorbot-er-3 
<https://github.com/LinuxCNC/linuxcnc/tree/master/configs/by_machine/scorbot-er-3>

I've been corresponding with him on this and he said that this approach 
resulted in jerky motion since linuxcnc was communicating of a 9600 baud 
serial line.
He wound up replacing the control and creating a new controller with  
Mesa 7i43 (EPP Hostmot2 card), a Mesa 7i54 (Six channel 3A 40V Servo 
interface),


We've been toying with a couple approaches:
One approach would be to replace the controller and build a servo 
interphase using arduino nano's and a L298 motor drivers: 
https://www.youtube.com/watch?v=vHufLMh4xEI

and either use a pc or bbb to handle the motion planning.

We've been studying the Scorbot controller and it is well made and fully 
socketed.   We were thinking that we could lobotimizing  the control by 
yanking the 8031 control.   15 pins basically access everything on the 
board.
  It would be sort of cool, if we could create a cape and socket adapter 
and just plug in a bbb to the control and get it to run.
We're still in the process of figuring out the motor drivers and the 
encoders.   Have people done this sort of thing is a dumb idea?  Is 
machinekit via a BBB able to handle this type of multiplexing out of the 
box or with minor modification or would this be a major modification and 
a cludge not worth doing?  If there is a project that's done this 
already, could someone point me to a project that I could template from?


Any thoughts on this would be appreciated,
Thanks,
Tom

--
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 
<mailto:machinekit+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/2b219361-5664-4576-8e81-08c055309bb2%40googlegroups.com 
<https://groups.google.com/d/msgid/machinekit/2b219361-5664-4576-8e81-08c055309bb2%40googlegroups.com?utm_medium=email_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/3e963f0f-3e1a-076f-bc3c-de1f5c6bcafe%40dovetail-automata.com.

Re: [Machinekit] problems with realtime kernel on Beaglebone AI

[John Allwine]

Thanks Cern! I simply took out that chunk of code and everything seems to
work.

On Fri, May 1, 2020 at 6:58 PM  wrote:

> Hi,
> May 1, 2020, 23:36 by j...@pocketnc.com:
>
> > This seems to be the source of the problem: >
> https://github.com/machinekit/machinekit-hal/blob/9fca994e08e3f8384498e78ea8e8baa1c899e4db/src/rtapi/rtapi_app.cc#L1457
> >
> You are not the only one bitten. There is/was discussion in Machinekit
> Matrix room, history:
> https://view.matrix.org/room/!CLLXbpAoUbAfHmWDXt:matrix.org/?anchor=$158837589690473CEniQ:matrix.org=0
>
> Personally, I consider it premature and think that the program should
> cross that bridge when it comes at it and not when everything it sees is
> flat land. So I would remove it.
>
> Cern.
>
> >
> > The system call iopl seems to be returning an error:
> > http://man7.org/linux/man-pages/man2/iopl.2.html
> >
> > On Fri, May 1, 2020 at 2:49 PM John Allwine <> j...@pocketnc.com> >
> wrote:
> >
> >> I posted this on the >> Beaglebone forums <
> https://groups.google.com/forum/#!category-topic/beagleboard/FOEDBLvmu2c>>>
> and figured someone here may be able to help too:
> >>
> >> I'm trying to use a real time kernel on the Beaglebone AI to get
> MachineKit running. I'm able to run MachineKit on a non-rt kernel
> (4.14.108-ti-r113), but when I update to the latest ti-rt kernel
> (4.14.108-ti-rt-r134), I get an error:
> >>
> >> user cannot gain I/O privileges - forgot 'sudo make setuid'?
> >>
> >> In dmesg, I see this:
> >> [  811.654246] warning: process `rtapi:0' used the deprecated sysctl
> system call with 8.1.2.
> >>
> >> Robert Nelson offered to tweak the rt kernel config to support that
> call. Is that what needs to happen?
> >>
> >>
> >>
> >> --
> >>  website: >> http://www.machinekit.io>>  blog: >>
> http://blog.machinekit.io>>  github: >> https://github.com/machinekit
> >>  ---
> >>  You received this message because you are subscribed to a topic in the
> Google Groups "Machinekit" group.
> >>  To unsubscribe from this topic, visit >>
> https://groups.google.com/d/topic/machinekit/1iYGU9VfvPM/unsubscribe>> .
> >>  To unsubscribe from this group and all its topics, send an email to >>
> machinekit+unsubscr...@googlegroups.com>> .
> >>  To view this discussion on the web visit >>
> https://groups.google.com/d/msgid/machinekit/5221d20d-643b-4a7a-bab6-42a2886b59c9%40googlegroups.com
> <
> https://groups.google.com/d/msgid/machinekit/5221d20d-643b-4a7a-bab6-42a2886b59c9%40googlegroups.com?utm_medium=email_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/CAPEK9qbEdq5hL4p5yNsWa6DSTthhed-vM7CBdSBX%3DFPHMZ0BBg%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/machinekit/CAPEK9qbEdq5hL4p5yNsWa6DSTthhed-vM7CBdSBX%3DFPHMZ0BBg%40mail.gmail.com?utm_medium=email_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/CAPEK9qbZMcY8fGmU5RfgoHshP5rphkB-VBPsYFdG2NE9TWw17g%40mail.gmail.com.

Re: [Machinekit] problems with realtime kernel on Beaglebone AI

[John Allwine]

This seems to be the source of the problem:
https://github.com/machinekit/machinekit-hal/blob/9fca994e08e3f8384498e78ea8e8baa1c899e4db/src/rtapi/rtapi_app.cc#L1457

The system call iopl seems to be returning an error:
http://man7.org/linux/man-pages/man2/iopl.2.html

On Fri, May 1, 2020 at 2:49 PM John Allwine  wrote:

> I posted this on the Beaglebone forums
> <https://groups.google.com/forum/#!category-topic/beagleboard/FOEDBLvmu2c>
> and figured someone here may be able to help too:
>
> I'm trying to use a real time kernel on the Beaglebone AI to get
> MachineKit running. I'm able to run MachineKit on a non-rt kernel
> (4.14.108-ti-r113), but when I update to the latest ti-rt kernel
> (4.14.108-ti-rt-r134), I get an error:
>
> user cannot gain I/O privileges - forgot 'sudo make setuid'?
>
> In dmesg, I see this:
> [  811.654246] warning: process `rtapi:0' used the deprecated sysctl
> system call with 8.1.2.
>
> Robert Nelson offered to tweak the rt kernel config to support that call.
> Is that what needs to happen?
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Machinekit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/machinekit/1iYGU9VfvPM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> machinekit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/5221d20d-643b-4a7a-bab6-42a2886b59c9%40googlegroups.com
> <https://groups.google.com/d/msgid/machinekit/5221d20d-643b-4a7a-bab6-42a2886b59c9%40googlegroups.com?utm_medium=email_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/CAPEK9qbEdq5hL4p5yNsWa6DSTthhed-vM7CBdSBX%3DFPHMZ0BBg%40mail.gmail.com.

[Machinekit] problems with realtime kernel on Beaglebone AI

[John Allwine]

I posted this on the Beaglebone forums 
 
and figured someone here may be able to help too:

I'm trying to use a real time kernel on the Beaglebone AI to get MachineKit 
running. I'm able to run MachineKit on a non-rt kernel (4.14.108-ti-r113), 
but when I update to the latest ti-rt kernel (4.14.108-ti-rt-r134), I get 
an error: 

user cannot gain I/O privileges - forgot 'sudo make setuid'?

In dmesg, I see this:
[  811.654246] warning: process `rtapi:0' used the deprecated sysctl system 
call with 8.1.2.

Robert Nelson offered to tweak the rt kernel config to support that call. 
Is that what needs to happen?

-- 
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/5221d20d-643b-4a7a-bab6-42a2886b59c9%40googlegroups.com.

Re: [Machinekit] C instantiable components and hal_pru_generic

[John Allwine]

I'm not convinced of that. Since the register table is fully allocated it 
would likely require swapping registers out to scratch pads and assigning 
pin numbers that are larger than a byte (this would significantly affect 
the SET_CLR_BIT and PINTABLE implementation) and at the very least adding 
twice as many memory writes. I don't fully understand the ramifications of 
making some of those changes, but it would certainly have a performance 
penalty by writing to more registers, even if it is easy to implement. I'm 
concerned with performance, so any modifications that slow down 
hal_pru_generic I'd like to avoid. I'm trying to reach high step 
frequencies with 5 different axes. I'm hoping to achieve them with 
hal_pru_generic, so I'm thinking of even adding build macros so 
hal_pru_generic could have access to PRU code that doesn't perform any 
memory writes (but rather uses only direct outputs). I'm still testing 
what's feasible, but being able to divide up that work between different 
PRUs could also be key, so I like the idea of hal_pru_generic being 
instantiable. 

On Thursday, April 30, 2020 at 3:28:51 PM UTC-6, Charles Steinkuehler wrote:
>
> I think it would be easier to extend the existing logic to simply write 
> to more registers, but an icomp version of hal_pru_generic could still 
> be helpful.  With four PRU cores in the BBAI, I can definitely see the 
> benefit to having more than one PRU running either to divide the work or 
> to allow the PRUs to run with different cycle times. 
>
> On 4/29/2020 10:13 PM, John Allwine wrote: 
> > Is there documentation on how to write an instantiable HAL component in 
> C? I’ve been making modifications to hal_pru_generic to work on the 
> BeagleBone AI. hal_pru_generic is implemented in such a way that only 4 
> GPIO ports can be used. The BBB only has 4 GPIO ports, so any pin on the P8 
> and P9 headers can be used on a single instance of hal_pru_generic. The 
> BeagleBone AI has 8 GPIO ports, so without significant changes to 
> hal_pru_generic, not all pins on the P8 and P9 headers can be accessed from 
> a single instance. The BeagleBone AI does expose many more pins as direct 
> outputs, but I’m unable to instantiate more than one instance of 
> hal_pru_generic in order to take advantage of certain pin configurations. 
> Is it possible to make hal_pru_generic instantiable? 
> > 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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/50289540-1f4a-4903-912d-a9c27aed7839%40googlegroups.com.

RE: [Machinekit] C instantiable components and hal_pru_generic

[John Allwine]

Thanks Bas, but I don’t think your link came through!

-- 
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/f2529915-8c70-42ea-8e77-2fa79a6c9009%40googlegroups.com.

[Machinekit] C instantiable components and hal_pru_generic

[John Allwine]

Is there documentation on how to write an instantiable HAL component in C? I’ve 
been making modifications to hal_pru_generic to work on the BeagleBone AI. 
hal_pru_generic is implemented in such a way that only 4 GPIO ports can be 
used. The BBB only has 4 GPIO ports, so any pin on the P8 and P9 headers can be 
used on a single instance of hal_pru_generic. The BeagleBone AI has 8 GPIO 
ports, so without significant changes to hal_pru_generic, not all pins on the 
P8 and P9 headers can be accessed from a single instance. The BeagleBone AI 
does expose many more pins as direct outputs, but I’m unable to instantiate 
more than one instance of hal_pru_generic in order to take advantage of certain 
pin configurations. Is it possible to make hal_pru_generic instantiable?

-- 
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/abec4012-38d3-4534-8b04-e2734c6a9e7e%40googlegroups.com.

[Machinekit] Re: hal_pru_generic and hal_bb_gpio on the Beaglebone AI

[John Allwine]

I took a stab at writing my own HAL component to replace hal_bb_gpio that 
uses sysfs:
https://github.com/PocketNC/sysfs_gpio

Sysfs is deprecated, so it is more of an experiment for me than anything, 
but maybe someone will find it useful. It does seem to work on the AI right 
now.

On Wednesday, March 25, 2020 at 11:19:02 AM UTC-6, John Allwine wrote:
>
> Has anyone made any progress getting hal_pru_generic and hal_bb_gpio 
> modules (or their analogs) running on the Beaglebone AI?
>
>

-- 
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/8ffe42f2-9cc9-4936-8225-f039ae3c0567%40googlegroups.com.

Re: [Machinekit] BeagleBone with Cramps X steppers Stop during program execution

[John Hammond]

Not sure how to capture Axis program startup log. Sometimes when I hold down 
continuous button in Axis for X-Axis it translates less than one inch and 
sometimes it will translate 10 inches without pausing. What values for velocity 
and acceleration should I start with to eliminate pausing? Is the machine not 
entering real time?

-- 
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/f7e31abe-1f8b-46ff-a957-b544433c57dd%40googlegroups.com.

RE: [Machinekit] Re: Breakout board for BeagleBone Black (BBB)

[John Dammeyer]

Hi Benjamin,
I can see that your layout was done for easy of routing with minimal feed 
throughs. Only once I plopped the CAN transceiver onto the schematic and used a 
copy of one of your resistors did I realize you'd used 0403 parts.  I've 
soldered as small as 0602 by hand but not sure I want to try the smaller ones.  
Since 8 pins of the parallel port are outputs no matter what I'm thinking two 
SOIC 8 channel level translators are a more effective use of board space since 
the other 5 outputs also can use part of those.
 
My goal is to create a cape that has these which exceed what is available on 
the standard single parallel port
 
Outputs:
  4 x STEP/DIR --> X,Y,Z and A
  1 x Spindle STEP/DIR or PWM/DIR 
  1 x Enable   (One signal Open Collector active high, one signal Open 
Collector low)
  1 x Mist Coolant 12V relay driver
  1 x Flood Coolant 12V relay driver
 
Inputs:
  1 ESTOP input (Pin 10 on the DB-25)
  5 Limit/Home  (X,Y,Z,A Home + Combined Limit)
  1 FAULT input 
  1 High Speed Encoder A,B and I
  1 Low speed Encoder A,B for MPG.
 
I/O combinations.  
  1 x CAN bus  (Tx/Rx for CANopen)
  1 x UART (Tx/Rx for MODBUS or Nextion LCD Screen)
  1 x I2C for LCD Touch Screen
  1 x SPI for LCD Screen and I/O  (includes 2 outputs for mux to Chip Select 4 
devices).
 
This all has to exist on one board at a cost far lower than the MESA Raspberry 
interface board or there's just no point to it.
 
MachineKit has demonstrated that we can use the PRUs in the Beagle to deal with 
both spindle encoders and higher speed stepping.
 
So theoretically the above list implemented on a cape that has pluggable screw 
terminal connections to run a small CNC mill or Lathe with MachineKit and a USB 
hub for mouse, keyboard, USB stick (G-Code transfer) and USB based Pendant.  If 
that sort of board could be built for under $100 then there's hope for the BBB.
 
And the SPI, I2C, CAN and UART allow expansion to an 800x600 LCD display, 
Keypad and things like VFD (ModBus) and Tool Changer (CANopen or MODbus).
 
And if someone wants more than that the better solution is a PC with full MESA 
expansion boards.  If you are retrofitting some sort of mill that uses +/- 10V 
control with an encoder or resolver Jon Elson and others have LinuxCNC 
solutions that again are a better solution.
 
The market for BBB and 3D printers is gone.  Other than as an exercise.  I use 
a a Pi2B (I think) Octoprint and the Arduino Atmel based controller.  It prints 
what I need.  The BBB with Replicape will eventually end up controlling my POS 
Delta printer if I ever get the rest of the mechanical issues sorted out. 
 
But past that.  The opportunity for a BBB with a CNC cape is really that group 
of people who don't want CNC on their mill but do want a DRO and power feed.   
And if you suddenly plugged in an Ethernet connection to something running on 
the latest high tech hardware you have full Linux or MachineKit CNC.
 
If you want.
 
John Dammeyer
 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of Benjamin Balga
Sent: April-04-20 1:53 AM
To: Machinekit
Subject: Re: [Machinekit] Re: Breakout board for BeagleBone Black (BBB)
 
Hello,
 
I'm also interested by what you can come up with. My goals with my 
"BBB-DB25-CNC-Cape" were to have a simple board with 5V compatible IOs that can 
be expanded upon, using only the "truly free" I/Os, and obviously not 
full-featured because I don't need it and it's hard to get it right. The cape 
routes one hardware encoder to the DB25 header, might be fast enough for a 
spindle encoder.
I ordered some boards a few days ago, hopefully they will arrive soon-ish.
 
If I were to redo it one day, I would probably maximise the 5V I/Os and use 
several 10-pin or less headers that can be each connected to "single-job" 
breakout boards in a very modular fashion. That way adding or swapping features 
is easy. Like a direct ribbon-to-driver adapter, ribbon-to-spindle adapter, 
ribbon-to-home-and-limit-switches, ribbon-to-magic... Dang I want that badly 
now xD
 
Cheers,
Benjamin


Le samedi 4 avril 2020 06:28:11 UTC+2, John Dammeyer a écrit :
I'm about halfway through modifying the cape PC board.  Correct me if I'm wrong 
but because the BBB has internal flash it's expected that the OS and all run on 
that.  That then frees up the pins on P8 marked MMC1_--  ?
 
I'm basing this off the charts from www.ExploringBeagleBone.com.  I have both 
editions of the Derek Molloy's book.
 
I've added a CAN driver to the cape and I'm going to shift some pins down so 
the I2C pins can be brought to the header.  What I'd like on the first 
connector is standard I/O and PWM out for spindle.  Maybe even add the 
circuitry to create 0-10VDC.  But there aren't enough pins on a standard 
parallel port to be able to do a spindle encoder or mpg.  That's why I was 
looking at the RS232 and connecting to something like a MODIO or for that 
matter something similar that runs

RE: [Machinekit] Re: Breakout board for BeagleBone Black (BBB)

[John Dammeyer]

I'm about halfway through modifying the cape PC board.  Correct me if I'm wrong 
but because the BBB has internal flash it's expected that the OS and all run on 
that.  That then frees up the pins on P8 marked MMC1_--  ?
 
I'm basing this off the charts from www.ExploringBeagleBone.com.  I have both 
editions of the Derek Molloy's book.
 
I've added a CAN driver to the cape and I'm going to shift some pins down so 
the I2C pins can be brought to the header.  What I'd like on the first 
connector is standard I/O and PWM out for spindle.  Maybe even add the 
circuitry to create 0-10VDC.  But there aren't enough pins on a standard 
parallel port to be able to do a spindle encoder or mpg.  That's why I was 
looking at the RS232 and connecting to something like a MODIO or for that 
matter something similar that runs on CAN bus with CANopen protocol.
 
If you can afford it there are some pretty nice robust displays with CANopen or 
J1939 used for industry.
 
More as I work out what I'm trying to accomplish.
John
 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of Rob M
Sent: April-03-20 7:05 PM
To: Machinekit
Subject: [Machinekit] Re: Breakout board for BeagleBone Black (BBB)
 
 
 
I did the same when I did minehad a lapse along the way and screwed up the 
signal to pin mapping. As long as the daughter boards match the cape no probs. 
In my defense I was looking after a Beagle pup we got at 8 weeks old. 
 
There's also the raw pins brought out for the ADC, an I2C bus and for an 
external power switch.
 
I don't know if you've seen my spread sheet but I've thrown it up (hopefully 
without any major typos). With a bit more thought some pins would have been 
better elsewhere, but I was aiming at a simple conversion from a 2 port PP 
setup. Hence the "output daughter board" resembling a Std PP and the Input 
resembling a PP setup for input.
 
I figured that the main cape could be used on it's own for experimenting with 
external devices without the daughter board.
 
But I'd be interested to see your progression, as I have time on my hands now 
as I stopped the Linuxcnc Mint ISO's, the devs prefer seem just to support 
Debian. So you want someone to bounce ideas off my old noggin is pretty hard & 
dense.
 
Cheers
Rob
 
 
 
 
-- 
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/2bfd00d0-0278-4eb4-b8ab-484205f74260%40googlegroups.com
 
<https://groups.google.com/d/msgid/machinekit/2bfd00d0-0278-4eb4-b8ab-484205f74260%40googlegroups.com?utm_medium=email_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/082c01d60a39%24679dd960%2436d98c20%24%40autoartisans.com.

Re: [Machinekit] Happy Birthday Machinekit!

[John Morris]

Happy sixth birthday, Machinekit!

Over the last year, the spun-out HAL repo has enjoyed major
improvements from over a dozen contributors in several areas.  The HM2
drivers and several HAL comps have new features, HAL now supports the
`arm64` architecture, Machinetalk sports a new OpenCV-based video
server, and many changes went into the build, packaging and CI
infrastructure to support the HAL/CNC repo split.  And after years of
wishing for it, I'm happy to see a new CMake build system ready to be
merged.

Along with progress, the year had its challenges, too.  The CI service
was suddenly and unexpectedly dismantled, leaving the project without
continuously updated packages; fortunately, an effort to resolve it is
underway.

Most saddening, a few, highly esteemed contributors have gone on
hiatus.  I appreciate everything they've done, and only hope to see
them more in the future, even if only on occasion.

I'm just grateful to all of you keeping the project going on a daily
basis.  Thank you for submitting all your PRs on GitHub, and thank you
for merging them.  Thank you for your chatter on the mailing list.
Thanks to you new, enthusiastic contributors joining the community.  I
look forward to collaborating with you over a new CI system and
porting LinuxCNC-EMC to run on Machinekit-HAL over the next year, and
over the next year, I'm looking forward to seeing what other advances
you all bring in.

John


On 4/3/19 10:19 AM, John Morris wrote:

Happy Birthday Machinekit!  5 years old now.

This year, I'm very excited about the progress underway in the
`machinekit-hal` repository.  HAL is the crown jewel of the Machinekit
project, and splitting it off into its own repository brings it out
from under the shadow of the EMC application and at last into the
visibility of its own light.  There's a lot of polishing left to do,
but it's huge progress that it is already usable, with its own
independent code base and package stream.  Congratulations, and thanks
to everyone who helped make this happen!

     John

On Wednesday, April 4, 2018 at 7:37:16 AM UTC+8, John Morris wrote:

Happy Birthday #4 Machinekit!

While I've probably *contributed to* Machinekit *less* in the last year
than ever before, it turns out I've *used* Machinekit *more*, whether
for the EMC app on my 3D printer, or whether for straight HAL and
QtQuickVCP for Golibox, autoclave and robot controls.  Thanks to all
the
devs and maintainers for the great work.

 John


On 04/03/2017 12:19 AM, John Morris wrote:
 > It's been three years.  Happy Birthday, Machinekit!
 >
 >  John
 >
 >
 > On 04/03/2016 04:48 PM, John Morris wrote:
 >> Happy two-year birthday, Machinekit!  Another great year and
more great
 >> leaps forward.  Keep it up!
 >>
 >>     John
 >>
 >>
 >> On 04/03/2015 03:59 AM, John Morris wrote:
 >>> A year ago today on April 3, Michael posted the [Machinekit
 >>> announcement] on the Emc-developers list.  IMO, that marks the
official
 >>> birthday of Machinekit, so,
 >>>
 >>> Happy Birthday!
 >>>
 >>> I'm incredibly pleased (and surprised!) by the huge leaps the
project
 >>> has made in such a short time, and by the explosive growth of the
 >>> project's community.  In the [ZeroMQ Guide Chap. 6], Pieter
Hintjens
 >>> writes that the two go hand-in-hand, and says "It's hard to
 >>> overemphasize the power and persistence of a working open source
 >>> community."  That's exactly what I see here, an amazing bunch
of folks
 >>> continually attracting new amazing folks, and the result is
brilliance.
 >>>   Congratulations to everybody, both those participating in the
 >>> Machinekit project today, and also those who contributed to the
15+ year
 >>> legacy of the code base.  I can't wait to see what the next
year will
 >>> bring.
 >>>
 >>> [Machinekit announcement]:
 >>> http://sourceforge.net/p/emc/mailman/message/32182244/

<http://www.google.com/url?q=http%3A%2F%2Fsourceforge.net%2Fp%2Femc%2Fmailman%2Fmessage%2F32182244%2F=D=1=AFQjCNEO4wlwp94BB-S3U8wscDMdmHmswA>

 >>>
 >>> [ZeroMQ Guide Chap. 6]: http://zguide.zeromq.org/php:chapter6
<http://zguide.zeromq.org/php:chapter6>
 >>>
 >>>  John
 >>>

--
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 

RE: [Machinekit] Re: Breakout board for BeagleBone Black (BBB)

[John Dammeyer]

Since I'm sitting around trying to figure out what to do with myself due to 
this COVID-19 I thought I'd put together a spreadsheet that shows how the pins 
are used on my Xylotex BBB_DB25_26 and how they are on the BBB-DB25-CNC-Cape.
 
There are issues with both of them.  The Xylotex is no longer made and what 
they sell now is more like the CNC although I've not yet looked at what pins 
are used for what.
 
What is missing is the ability to access the CAN bus and no I2C pins brought 
out for external devices.
 
What's in the spread sheet is preliminary in the sense that I've not even 
assigned pins for the step/dir and inputs.  
 
The Xylotex would have to lose the Home A in order to have a series string of 
limit switches.  Ie. The Home switches for each axis can also be Limit at the 
Home position end.  And then the other end a string of N/C switches in series.  
 
Martin Berriman added an encoder MPG but his pins also interfere with some of 
the others on these two capes.  Assigning the two inputs to free pins not used 
by some of the standard CNC signals but capturing the channel # and distance to 
step could be done from an SPI expansion I/O set of chips.
 
I don't know if the software polling of the encoder is fast enough for a 
spindle encoder but if power tapping was required then we definitely need to 
add that feature too.
 
All that says is that making up a BBB Break Out Board Cape should probably have 
either a second DB-25 to expand the I/O or just forget the DB-25 completely and 
create an actual cape that is also a Break Out board for a 4 Axis Mill.  
Complete with MPG support, Spindle Encoder Support, Home/Limit switches, CAN 
bus for say CANopen peripheral/motor expansion, RS232/485 for VFD control for 
spindle speed if the 0-10V output isn't available.  And in fact this sort of 
BoB should have a 0-10V with DIR signal for the spindle.
 
It also needs to be able to deal with FAULT/ENABLE signals in order to 
disable/reset a drive that has faulted or for that matter an ESTOP in 
automatically sets the ENABLE false.  That pin output should probably be 
available as both an active high and active low.
 
So much more I/O would be available if the Beagle did not use the HDMI LCD_DATA 
interface occupying much of the P8 connector.  Looking at the NEXTION displays 
that are run from an RS232 port is one option.  Or using SPI and I2C based 
signals for an LCD display that uses the LittlevGL library.  I've been looking 
into that one with an ESP32.
 
But in many ways it would be easiest to keep the HDMI, slow as it is, with the 
MachineKit code inside the BBB.  At least as a first step and just make it so 
the I/O on the LCD pins is available for expansion and a MachineKit version 
that uses Ethernet to something else for the standard AXIS type user interface. 
 
John
 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of Benjamin B (BBenj)
Sent: March-22-20 7:50 AM
To: Jirí Procházka; Machinekit
Subject: Re: [Machinekit] Re: Breakout board for BeagleBone Black (BBB)
 
Hello Jiri,
 
I finally took some time to finish the PCBs, and upload everything, with some 
infos : https://github.com/GIPdA/BBB-DB25-CNC-Cape
 
I didn't ordered anything yet, but I'll let you know when I have something 
tested and operational.
 
 
Cheers,
Benjamin
 
Le 18 mars 2020 à 12:24:06, Jiří Procházka (jiriprochazka...@gmail.com) a écrit:
Hey Bejnamin,
 
I would definitely be interested. There is no need to rush, because we are 
confined too (Czech Republic).
 
If you gave the files I would definitely give you some contribution to your 
project and feedback from my testing.
And for sure let me know when your cape is tested.
 
Thanks 
 
Jiri
 
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
---
You received this message because you are subscribed to a topic in the Google 
Groups "Machinekit" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/machinekit/f1JJBTSNuVI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/457b4481-bc67-40e8-8502-3f10cb9e56ab%40googlegroups.com
 
<https://groups.google.com/d/msgid/machinekit/457b4481-bc67-40e8-8502-3f10cb9e56ab%40googlegroups.com?utm_medium=email_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 
<mailto:machinekit+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CAGiu9V-%3DVQjip2P%2B9Nf7WBdY743QwYzuO0E

Re: [Machinekit] BeagleBone with Cramps X stepper vibrates but does not move

[John Hammond]

Hello Charles,
Attached are the hal and ini files that I believe are being used. Now all 
of the steppers are working. The CNC is moving. The X and Z are moving in 
the wrong direction. I suppose there is some documentation that shows me 
what to do next. I need to adjust the scale, I think. Sorry that it took me 
so long to remember how to copy the files to the SD card so I could send 
them.

On Friday, March 13, 2020 at 7:37:15 PM UTC-7, Charles Steinkuehler wrote:
>
> On 3/12/2020 7:17 AM, John Hammond wrote: 
> > The Y and Z steppers rotate but the X one does not. I have switched 
> > the Polulu driver from the X to Z and it works fine. Where is the 
> > pulse rate determined in Linux? Does Machinekit have linuxcnc files 
> > that I haven’t seen? 
>
> Typically the pulse rates will be determined by settings in your HAL 
> file.  Using the BBB, it is quite easy to generate rates so high you 
> overwhelm the stepper driver and get no actual movement from the 
> steppers.  Often, this is an issue with the scale values, but there can 
> be other causes as well.  Provide your HAL and INI config files, and we 
> can review. 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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/c61b9ea5-1dac-4466-bf8e-0d6dff171467%40googlegroups.com.


CRAMPS.hal
Description: Binary data


CRAMPS.ini
Description: Binary data

[Machinekit] hal_pru_generic and hal_bb_gpio on the Beaglebone AI

[John Allwine]

Has anyone made any progress getting hal_pru_generic and hal_bb_gpio 
modules (or their analogs) running on the Beaglebone AI?

-- 
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/20f11804-0a35-4ae6-8506-2c84da22f576%40googlegroups.com.

RE: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI

[John Dammeyer]

 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of justin White
Sent: March-18-20 5:24 PM
To: John Dammeyer
Cc: Machinekit; beaglebo...@googlegroups.com
Subject: Re: [Machinekit] Seeed to design and build Machinekit focused Cape for 
BeagleBone Black/AI
 
Wow that has absolutely nothing to do with seeed's cape.
Yes it does!  My previous posting suggested that a cape by SEED should include 
the infrastructure to have a display and function as a standalone electronic 
lead screw for a mill.  And accept the motion information from something like a 
Pi or PC via Ethernet if full CNC was required.  
 
That means the software running on the BBB would not be conventional 
MachineKit.  In fact the software might be straight C code developed with the 
TI IDE as a standalone project with display that can service as a multi-axis 
power feed and DRO.  Or if could be a subset of MachineKit without the HDMI 
interface.
 
So it could do motion.  The idea is that it could also, via Ethernet, like the 
MESA 7i92H receive information that would generate the stepping pulses and 
feedback the DRO information. 
 
It's time to think outside the box because with the much more powerful Pi4 
coupled to MESA hardware there is no way that SEED or anyone else can produce 
something as good.  So it has to be something different.
 
Seriously.  Why pay $150 for a full blown BBB Cape that serves as a Break Out 
Board and $50 for a BBB that then gives you sub par video compared to a much 
faster quad core Pi4 running LinuxCNC and Ethernet to a MESA board where the 
total price ends up pretty well the same.
 
Technologically the BBB is now old.  Very old.  And it's just plain silly to 
continue to try and make it a be all end all.  I'd say 99% of the people I talk 
to who have CNC are running either MACH or maybe LinuxCNC.  Mostly they aren't 
interested in changing.  The ones who have mill but not CNC either want to add 
power feed and perhaps DRO but again most of them are not interested in CNC.
 
So where's the market?  It's easy.  The DRO and Power feed controller that can 
magically turn into a CNC controller.
 
John  Dammeyer
 
 
On Wed, Mar 18, 2020, 7:37 PM John Dammeyer  wrote:
Would someone perhaps be able to describe simply (like MachineKit for Dummy's) 
how exactly the step pulse and direction shows up on the Beagle pin relative to 
the motion command from a G00 X1.0 where current X position is 0.0.
 
Clearly we accelerate and move and then decelerate to arrive at the end point 
of 1.0.  I do this in my ELS code inside the interrupt routine which happens at 
a 20kHz rate.  If a step is required I set the output at the beginning of the 
routine and then clear it at the end after a whole bunch of other stuff is 
done.  
 
Whether to step or not is done by the equivalent of a trajectory planner.  For 
example in simple terms if the motor could accelerate instantly and the step 
rate was 10kHz then every second interrupt the axis is pulsed.  Also for every 
pulse the position is incremented if going in the positive direction.  
Decremented if going in the other direction.  When it matches the end position 
the stepping is terminated and we have a move to position.
 
Inside my ELS interrupt code I do the accel/decel too.  The interrupt routine 
changes the number of 20kHz intervals between step rates and also tracks the 
half way point.  If we're not up to speed yet but the halfway point is reached 
then deceleration is started and by the time the stepping rate reaches 0 the 
motor has also reached it's desired position.
 
Otherwise once the step output pulse rate matches the desired velocity the 
acceleration part is terminated and the number of steps it took recorded, and 
now a pulse happens every second interrupt (for 10kHz step rate).  When the 
destination location minus the time it took to accelerate is reached 
deceleration begins.  And since we decelerate at the same rate as accelerating 
and we have that same distance to move, once we reach 0 speed we've also 
reached the destination.
 
Now this could all be done outside the interrupt routine in a trajectory 
planner.  One could determine that it will take time X to reach either target 
speed or midpoint of the distance to move.  Broken into the 20kHz steps then 
the information could be fed into a FIFO so no math is done at all inside the 
interrupt routine.  It's only task would be to read this from FIFO one byte 
during each interrupt and write it to the port.   The interrupt routine could 
then run 40kHz and clear the port of step signals every second pulse.If 
there is no motion the FIFO, flagged as empty, holds the last entry for the 
port and it's just mirrored out to the port.  
 
So how is it done in the Beaglebone with MachineKit.  Is there a function that 
reads a FIFO filled by the trajectory planner or is it done yet some other way? 
  I would look it up but don't even know where to start.
 
Obviously there's probably

RE: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI

[John Dammeyer]

Would someone perhaps be able to describe simply (like MachineKit for Dummy's) 
how exactly the step pulse and direction shows up on the Beagle pin relative to 
the motion command from a G00 X1.0 where current X position is 0.0.
 
Clearly we accelerate and move and then decelerate to arrive at the end point 
of 1.0.  I do this in my ELS code inside the interrupt routine which happens at 
a 20kHz rate.  If a step is required I set the output at the beginning of the 
routine and then clear it at the end after a whole bunch of other stuff is 
done.  
 
Whether to step or not is done by the equivalent of a trajectory planner.  For 
example in simple terms if the motor could accelerate instantly and the step 
rate was 10kHz then every second interrupt the axis is pulsed.  Also for every 
pulse the position is incremented if going in the positive direction.  
Decremented if going in the other direction.  When it matches the end position 
the stepping is terminated and we have a move to position.
 
Inside my ELS interrupt code I do the accel/decel too.  The interrupt routine 
changes the number of 20kHz intervals between step rates and also tracks the 
half way point.  If we're not up to speed yet but the halfway point is reached 
then deceleration is started and by the time the stepping rate reaches 0 the 
motor has also reached it's desired position.
 
Otherwise once the step output pulse rate matches the desired velocity the 
acceleration part is terminated and the number of steps it took recorded, and 
now a pulse happens every second interrupt (for 10kHz step rate).  When the 
destination location minus the time it took to accelerate is reached 
deceleration begins.  And since we decelerate at the same rate as accelerating 
and we have that same distance to move, once we reach 0 speed we've also 
reached the destination.
 
Now this could all be done outside the interrupt routine in a trajectory 
planner.  One could determine that it will take time X to reach either target 
speed or midpoint of the distance to move.  Broken into the 20kHz steps then 
the information could be fed into a FIFO so no math is done at all inside the 
interrupt routine.  It's only task would be to read this from FIFO one byte 
during each interrupt and write it to the port.   The interrupt routine could 
then run 40kHz and clear the port of step signals every second pulse.If 
there is no motion the FIFO, flagged as empty, holds the last entry for the 
port and it's just mirrored out to the port.  
 
So how is it done in the Beaglebone with MachineKit.  Is there a function that 
reads a FIFO filled by the trajectory planner or is it done yet some other way? 
  I would look it up but don't even know where to start.
 
Obviously there's probably more going on under the covers to deal with hard 
limits.  Seems like soft limits are dealt with before motion starts with the 
option to not move because it will exceed machine limits.
 
Thanks
John Dammeyer
 
 
 

-- 
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/023801d5fd7e%242a472570%247ed57050%24%40autoartisans.com.

Re: [Machinekit] BeagleBone with Cramps X stepper vibrates but does not move

[John Hammond]

I have a DIY CNC. It was powered before with LinuxCNC on an old laptop. The 
laptop became unreliable soI have been attempting to get it to work with 
Machinekit on a BeagleBone Black with Cramps board.

-- 
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/0c625d0b-86e3-4afe-b358-d3ad968551ea%40googlegroups.com.

Re: [Machinekit] BeagleBone with Cramps X stepper vibrates but does not move

[John Hammond]

I noticed that one of the connectors had slipped back a little in its housing. 
When I pressed it in and increased the voltage to the stepper from 12 to 24 
volts, it started working. When I hooked up all three steppers in place in the 
CNC, the fuse in the power supply blew. I will work on a better power supply 
which eliminates spikes. Perhaps it was a spike that bricked the last two 
BeagleBone Blacks. Thanks all for your help.

-- 
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/6f0c5ee0-8fa7-4351-85d7-24523418%40googlegroups.com.

Re: [Machinekit] how to use webtalk

[John Allwine]

Thanks for the info, Cern!

On Mon, Mar 16, 2020 at 1:10 PM  wrote:

>
> Mar 16, 2020, 17:15 by j...@allwinedesigns.com:
>
> > What steps are necessary to use webtalk?
> >
> Hi,
> WebTalk seems to be just a proxy between ZeroMQ and Websockets. It looks
> like nobody cared about it and it was not touched since Michael Haberler
> left. From Git it was left as is for about six years from inception and two
> years from any work. Machinekit codebase didn't really follow the ZeroMQ
> changes and now there is some support for Websockets directly in ZeroMQ
> Project, so maybe this whole idea is superfluous now. (
> https://github.com/zeromq/libzmq/issues/3581 )
>
> To use it, the README is probably only only help you will get aside
> studying the code:
> https://github.com/machinekit/machinekit-hal/blob/master/src/machinetalk/webtalk/README
>
> > This thread seems to indicate that it's no longer compiled by default: >
> https://groups.google.com/forum/#!searchin/machinekit/webtalk%7Csort:date/machinekit/rc7aSsjdU8k/FxeZjwdQDAAJ
> >
> > Does that mean I'd need to build machinekit from source to be able to
> use it? Perhaps there is an optional debian package I could install to use
> it?
> >
> There is not. But you could probably create it. The Simplest solution will
> probably be to just compile into the Machinekit package or build from
> source as a RIP:
> http://www.machinekit.io/docs/developing/machinekit-developing/ and
> specify the WebTalk in ./configure step.
>
> Cern.
>
> >
> >
> >
> > --
> >  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/d5f697be-4028-4b40-8b7f-594e6e73e97a%40googlegroups.com
> <
> https://groups.google.com/d/msgid/machinekit/d5f697be-4028-4b40-8b7f-594e6e73e97a%40googlegroups.com?utm_medium=email_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/CAA9ERVr5ML8fSgbvmonVOomZhbPaPDtdn6sJRBnDmkFY%2B%3DPnVg%40mail.gmail.com.

[Machinekit] how to use webtalk

[John Allwine]

What steps are necessary to use webtalk? 

This thread seems to indicate that it's no longer compiled by default: 
https://groups.google.com/forum/#!searchin/machinekit/webtalk%7Csort:date/machinekit/rc7aSsjdU8k/FxeZjwdQDAAJ

Does that mean I'd need to build machinekit from source to be able to use 
it? Perhaps there is an optional debian package I could install to use 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/d5f697be-4028-4b40-8b7f-594e6e73e97a%40googlegroups.com.

[Machinekit] BeagleBone with Cramps X stepper vibrates but does not move

[John Hammond]

When the stepper is plugged into the Y-axis or Z-axis Polulu it rotates, when 
pluggedinto the X-axis Polulu, it just vibrates. The stepper is not driving 
anything. What needs to be changed in software to repair this? 

-- 
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/6df717cf-2d7b-430a-ac12-b525f1dac1ca%40googlegroups.com.

RE: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI

[John Dammeyer]

 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of Bas de Bruijn
Sent: March-13-20 6:47 AM
To: Jason Kridner
Cc: machinekit@googlegroups.com; beaglebo...@googlegroups.com
Subject: Re: [Machinekit] Seeed to design and build Machinekit focused Cape for 
BeagleBone Black/AI
 
I would use a cape who can drive DC and BLDC motors with encoder feedback. and 
has room for 24V I/O thru screw terminals.
 
And how many people would be interested in a cape like that?  The moment you 
put one type of driver on the cape you restrict the market.  For example the 
Replicape comes with stepper drivers sized for 3D printers.  Try using that on 
a mill with size 34 steppers or an AC Servo like I have for the 4th axis.
 
The days are past where there is a need or even a desire to close the motor 
control loop within the trajectory planner CNC control computer.  No offense 
meant to people who manufacture that sort of hardware but 15 years ago the 
processors to do that were few and far between.
 
Now there are kits like the STMBL which would still be available in its 
original form had not the motor driver chip been discontinued. A new version is 
in the works.  This drive can do AC servos and DC brushed or brushless.  
Step/Dir or Smart Serial.  And it's small and modular and can be replaced.  Yes 
it's expensive compared to a far east stepper motor driver.
 
 
A motor such as these types (just an example, maybe different capes for 
different power ratings) which would make creating tools for industrial 
situations much, much easier. No need to buy a €250 driver per motor.
 
https://en.nanotec.com/products/2265-internal-rotor-motors/
 
Such a cape would need to have enough oomph to drive 24V relays, and connect 
24V limit or proximity switches.
 
Maybe max out on motor+encoder and have a complimentary cape use the rest for 
the io’s.
 
The market for such as you describe exists with MESA and external drives using 
a standard PC.
 
Having hardware that drives these motors would help enormously in just creating 
a working machine (I’m not looking for 3D printing or CNC myself, but for 
custom machines) It would help me to focus on creating a machine, and not have 
me connect a bare BB to an industrial driver.
 
What you want will not be built.  The amount of work needed to create something 
like that for sales in the under 100 units just won't happen. 
 
For example in 2016 I created my Electronic Lead Screw project.  I included on 
that board two awesome driver chips that allowed control of a stepper motor up 
to 3A and 55V.  Therefore with a 48V supply one could run 300 oz-in stepper 
motors.  Just the two LMD18245 devices now cost more than an entire 
micro-stepping driver from the far east.  And if someone wants to control both 
Z and X on their lathe they would still need a second driver.  
 
The software inside the ELS has the full micro-stepping code including 
acceleration and deceleration that now is wasted but I have to maintain it on 
newer versions for those using the chips.
 
And if someone damages that high current driver I generally have to replace the 
entire board.   The ELS also requires a heat sink if the on board drivers are 
used resulting in a larger package and since it includes 35 key buttons, an MPG 
and a display it's not something buried deep in a box behind the machine.
 
So based on my experience I would never again build the motor drivers onto the 
cape.  
 
John Dammeyer
 
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 machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/0a8801d5f959%2427eac300%2477c04900%24%40autoartisans.com.

RE: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI

[John Dammeyer]

Although the subject talks about SeeedStudio let's leave that part alone for a 
moment and discuss what the Beagle's part is in all this.
 
I'd like to take everyone back to geometry learned in school.  SQRT(X^2+Y^2) = 
hypotenuse of a right angle triangle.   When we look at velocity we can use the 
same math.  If both X and Y axis are moved at 12 IPM then the movement along 
that path happens at 16.97 IPM.  SQRT(144+144).  
 
So when you set a G-Code value of F12 and execute a move with G1 set then X and 
Y will _not_ move at 12 IPM.  First the distance of each axis is determined.  
Assume for this example it's the same distance of 12".  That means the total 
distance moved along the hypotenuse is 16.97" and as we move along that path we 
want that to be done at 12 IPM because of the F12.
 
Well that's (144) = (X^2+Y^2) or in this case because we have a 45 degree angle 
with equal X and Y it's SQRT(144/2) = SQRT(72) = 8.48 IPM.  So both X and Y 
will be moved at 8.48 IPM.   (in really we use the cos and sin of the angle to 
proportion the speed to achieve the F speed value.
 
It's more complicated than that if the acceleration for each motor is 
different.  So the simple path planner will use the lowest acceleration and 
make both motors accelerate at that speed so they move at the same rate per 
second per second to reach the velocity.  Same with deceleration.  
 
Once this has been calculated the next question is how to translate a real 
world velocity (IPM) into steps per second.  Once again not really hard if the 
reduction drive on each axis is identical.  A bit harder if one uses 4:1 and 
the other uses 3:1.  
 
Now the software has to decide when to create each step pulse.  Assuming both 
axis require the same number of steps to move 1 inch (0.2" per rev and 10 
uSteps/Step = 2000 steps per rev = or 2000 steps to move 0.2")
 
We're asking for 12 IPM which is 0.2" per second so that's 2000 steps per 
second.  That's a step pulse every 500 uS.  Our DMA clock is set to run at 1MHz 
spitting out the 16 bits into the SPI device so we get a 1uS long step pulse.
 
Or in simple terms we get one 16 bit packet, with X and Y STEP pins both set 
high and another packet with X and Y STEP pins set low .  Then the next 498 
packets do not change the X and Y step pins.  So for one second of data we need 
at 1000 byte array with 500 values where only one of those has X and Y set 
high.  We need a second 1000 byte array with 500 values for the next 1 second 
worth of messages.  
 
The trajectory planner has one second to populate the array.  The DMA 
controller signals when it switches to the next array and we ping pong back and 
forth.  When there isn't any motion the array just has the DIR pins and the 
COOLANT pins set to their previous values.  The output doesn't appear to change 
even though the SPI hardware is loaded by the DMA hardware to spit out new data 
at a 10Mhz rate.
 
The question is…who and what populates the array and when and how.
 
John Dammeyer
 
 
 
 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of John Dammeyer
Sent: March-12-20 4:59 PM
To: 'Machinekit'
Cc: beaglebo...@googlegroups.com
Subject: RE: [Machinekit] Seeed to design and build Machinekit focused Cape for 
BeagleBone Black/AI
 
One has to be careful here not to spec in a 10 ton dump truck for that once a 
year 500 lb utility trailer load of peat moss for the garden.  For one thing 
they are hard to parallel park and really expensive for fuel.
 
There already exists, and will for some time, systems that can handle multiple 
spindles, closed loop control of the encoders back to the PC along with 
multiple FPGA controlled I/O and smart serial motor control for these 
retrofitted large commercial milling machines.  Those users will never ever 
install a BBB with a cape that has slow HMDI screen updates and limited I/O.
 
So forget them.
 
By the same token, the customers who are using Ardunio based duos or whatever 
the latest flavour is for their 3D printers are also of no interest.  If they 
were we'd have seen the Replicape on a BBB become the standard with Machinekit 
or Linux as the backbone.  Hasn't happened.  Won't happen.  Not sure why.  
Probably price.
 
So what is the target market for this type of product?  Well who is buying the 
ready to go $200 to $500 CNC boxes in China and for what machines? 
 
If I were to venture a guess I'd say the ones that are about this size:
https://www.grizzly.com/products/Grizzly-7-x-27-1-HP-Mill-Drill-with-Stand/G0704
 
They come in all sorts of flavours.  They are generally driven open loop with 
stepper motors and require only a spindle sensor for quadrature and maybe a 
second quadrature input for an MPG control although those can be had pretty 
inexpensively as USB devices.  And to tell you the truth I really like my 
ShuttleExpress over the USB MPG pendant. 
 
As along as the BoB has a FAULT input, which I forgot to put on m

RE: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI

[John Dammeyer]

One has to be careful here not to spec in a 10 ton dump truck for that once a 
year 500 lb utility trailer load of peat moss for the garden.  For one thing 
they are hard to parallel park and really expensive for fuel.
 
There already exists, and will for some time, systems that can handle multiple 
spindles, closed loop control of the encoders back to the PC along with 
multiple FPGA controlled I/O and smart serial motor control for these 
retrofitted large commercial milling machines.  Those users will never ever 
install a BBB with a cape that has slow HMDI screen updates and limited I/O.
 
So forget them.
 
By the same token, the customers who are using Ardunio based duos or whatever 
the latest flavour is for their 3D printers are also of no interest.  If they 
were we'd have seen the Replicape on a BBB become the standard with Machinekit 
or Linux as the backbone.  Hasn't happened.  Won't happen.  Not sure why.  
Probably price.
 
So what is the target market for this type of product?  Well who is buying the 
ready to go $200 to $500 CNC boxes in China and for what machines? 
 
If I were to venture a guess I'd say the ones that are about this size:
https://www.grizzly.com/products/Grizzly-7-x-27-1-HP-Mill-Drill-with-Stand/G0704
 
They come in all sorts of flavours.  They are generally driven open loop with 
stepper motors and require only a spindle sensor for quadrature and maybe a 
second quadrature input for an MPG control although those can be had pretty 
inexpensively as USB devices.  And to tell you the truth I really like my 
ShuttleExpress over the USB MPG pendant. 
 
As along as the BoB has a FAULT input, which I forgot to put on my previous 
list, you can even use intelligent drives like the step-servos that close the 
loop but provide a FAULT output when something goes wrong.  My STMBL, Bergerda 
and HP_UHU drives all have that.  I think the GECKO I have on the KNEE also 
does but I'm not using it at the moment.  All open collector outputs that pull 
the signal low when a fault occurs.
 
Anyway, that size of a machine and the price tag associated with it will set 
the price of the CNC conversion.  Most of the cost is in the mechanics and the 
electricals.  
 
So two PRU accessed quadrature inputs are more than enough to close the loop 
for power tapping as long as the spindle speed control is responsive.
 
About the only limitation I see in my list is that 500kHz stepping is really 
fast.  I used that number because that's the step rate for the Bergerda AC 
servos with the 2500 line encoder.That math works out to 10,000 edges per 
revolution and 3000 RPM is 50 RPS which means a 1:1 ratio is 500kHz.  The 
Bergerda can scale the step pulses in order to match the encoder with slower 
step rates.  I don't know if the STMBL AC Servo drive can do that.  Pretty sure 
the HP_UHU with the dsPIC can or almost can.
 
But for this target market, using standard stepper motors with micro-stepping 
drives we're back to 25kHz max before we see the motor torque drop off to a 
point where step speed doesn't matter.  And if you are using the step-servos 
the selection of the encoder will determine what's required.
 
So I'll agree with Chris that it's the I/O on the BBB that is the limiting 
factor.  But 10MHz SPI bus could take care of that. 
 
What I would do is use the PRU to load the DMA device to write two bytes to and 
read two bytes from the SPI port at a 1MHz rate.  It's the BBB's main 
processors responsibility to keep this filled or to stall it with step levels 
low and dir at last used value.  
 
The trajectory planner is responsible for setting the step pulses ON within the 
two byte packet to send out the SPI port.  The next two bytes hold the 
direction and drop the STEP.  Any other outputs on that buffer will also be 
left as is.  
 
Now you have hardware generating 6 pairs of step/dir as high as 500kHz.  The 
amount of time the 8th pair is ON and OFF is dependent on the PWM frequency and 
PWM pulse period within that frequency.   It's a simple matter of keeping the 
queues with this information full and default values when they aren't.
 
John Dammeyer
 
 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of Chris Albertson
Sent: March-12-20 3:33 PM
To: Jason Kridner
Cc: Machinekit
Subject: Re: [Machinekit] Seeed to design and build Machinekit focused Cape for 
BeagleBone Black/AI
 
 
 
Isn’t that something the Beagle is strong at with the eQEP and PRUs?
 
 
Strong only until you hit up against the limited number of I/O pins.  A PRU 
based solution is cheap and simple but can't scale.
 
In general TI's idea to place a small microcontroller on the same chip as their 
ARM Cortex-A was good and we see others doing this too but a big machine tool 
like a 5-axis mill with tool changer and cooling and saftey interconnects is 
going to need something bigger than a PRU.  FPGAs work well as wold an STM32 
tht had on order about 100 pins.
 
-- 

Chris Albertson

[Machinekit] BeagleBone with Cramps X stepper vibrates but does not move

[John Hammond]

The Y and Z steppers rotate but the X one does not. I have switched the Polulu 
driver from the X to Z and it works fine. Where is the pulse rate determined in 
Linux? Does Machinekit have linuxcnc files that I haven’t seen? 

-- 
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/79e919a9-d510-4176-8133-4d0336ec2d40%40googlegroups.com.

RE: [Machinekit] Re: PICnc with Machine Kit.

[John Dammeyer]

This is the only viable PIC32 is since it has the QEP module and PWM for motor 
control.  https://www.microchip.com/wwwproducts/en/PIC32MK1024MCF064
Unfortunately not Ethernet.
 
John
 
"ELS! Nothing else works as well for your Lathe"
Automation Artisans Inc.
http://www.autoartisans.com
 
 
 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of justin White
Sent: March-03-20 6:50 PM
To: Machinekit
Subject: Re: [Machinekit] Re: PICnc with Machine Kit.
 
Yep,
 
Actually I misspoke anyway, the PICnc never got an encoder module and the PWM 
stuff was "being worked on" so it's strictly a Stepgen/gpio project where it 
stalled. 

On Tuesday, March 3, 2020 at 9:22:44 PM UTC-5, John Dammeyer wrote:
Hi Justin,
Clearly we're on different pages.  
Thanks for your input.
John
 
 
From: machi...@googlegroups.com   
[mailto:machi...@googlegroups.com  ] On Behalf Of justin White
Sent: March-03-20 5:35 PM
To: Machinekit
Subject: Re: [Machinekit] Re: PICnc with Machine Kit.
 
I thought I was quite clear about this. 
Not at all, probably because you are misunderstanding the purpose of the 
hardware you are mentioning in this post.
 
This PICnc version requires Ethernet.  LinuxCNC through a MESA Ethernet 7i92H 
or MACH3-4 through an Ethernet Smooth Stepper control hardware.  I am going to 
guess that the MESA driver for the 7i92H also exists for MachineKit.
You want to run "mesa" ethernet from the 7i92H on the PICnc? Doesn't sound easy 
and I doubt there is anything specific about the 7i92 in the hm2_eth driver 
other than the fact that the board types are probably added to the driver as 
they are released. MK is well behind LCNC in Mesa drivers  so no idea if it 
worksyou should probably test it. Mesa cards don't run at all on windows 
with the hostmot2 firmware that the MK/LCNC projects interface with, and nobody 
around here can use a "smooth stepper" because of the architectural differences 
between Linux Preempt kernels and the Windows way of doing things. Windows 
devices tend to buffer things in hardware to avoid RT requirements, which is 
why USB hardware is a thing in Windows and not Linux. The "Linux way" is to run 
in a RT capable kernel and minimize the "load" by having the hardware do the 
heavy lifting, but it is still pegged in real-time. 
 
So you're hardware is not going to just be compatible with both, there is very 
little that is as it stands. This is probably not the place to discuss your 
Mach3/4 Windows needs (it's making me cringe just thinking about it). Mesa does 
however have a "SoftDMC" firmware that is meant for WIndows applications. An 
FPGA is far more versatile than a micro so there may be something you can do 
with that, but SoftDMC will not run under LinuxCNC and I seriously doubt anyone 
here knows much about it. 
 
The MESA board I have has the stepping-PWM  engines implemented in an FPGA. 
They all do, it's part of hostmot2 firmware, as are the encoder, Smart serial 
and a few other firmware modules.
 
What I´d like, but what may not be possible, is to replace the MESA 7i92H with 
the updated PICnc. 
 
They functionally do the same exact thing. The PICnc is doing the stepgen, 
encoder, PWM stuff as firmware modules in the micro as well. The difference is 
ethernet, support, and an FPGA vs SPI, a dead project, and a micro
 
If indeed the stepping engine is now within the PIC as well as the spindle 
quadrature etc.
 It is
 
and the board is in effect the Break Out Board for the machine then there is 
absolutely no reason you can´t have a single input serve as a local-remote 
switch.  In remote it behaves like, say a MESA 7i92H and the buttons and 
display appear to behave like a pendent on LinuxCNC.  In local it´s a DRO & 
PowerFeed machine controller with a bunch of useful buttons to simplify manual 
operation.
That's not going to happen like you want it to, unless you are capable of 
writing complex firmware. Your best bet is to abandon the PICnc thing for what 
you want to do and call Mesa. Hostmot2 is "host-based-motion-control" it only 
runs with a host i.e. LinuxCNC. SoftDMC is something completely different and 
like I said, it's never really discussed in the Linux world. The Mesa cards 
generally have 2 EPROMs and one can contain Hostmot2 firmware and the other 
SoftDMC. SoftDMC may possibly be able to run by itself and take care of your 
"local" thingI don't know.
 
Now maybe this won't be possible without also having an FPGA duplicate what is 
done with say the 792H.
 Maybe this won't be possible at all with MachineKit.
The PICnc already does functionally what the 7i92 does, just alot less of it 
and over spi.
 
The PICnc sounded interesting as I've never heard of it before. the board isn't 
very interesting and the micro is too small, but the fact that the original 
designer made firmware and drivers for it makes it something viable for 

RE: [Machinekit] Re: PICnc with Machine Kit.

[John Dammeyer]

Hi Justin,
Clearly we're on different pages.  
Thanks for your input.
John
 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of justin White
Sent: March-03-20 5:35 PM
To: Machinekit
Subject: Re: [Machinekit] Re: PICnc with Machine Kit.
 
I thought I was quite clear about this. 
Not at all, probably because you are misunderstanding the purpose of the 
hardware you are mentioning in this post.
 
This PICnc version requires Ethernet.  LinuxCNC through a MESA Ethernet 7i92H 
or MACH3-4 through an Ethernet Smooth Stepper control hardware.  I am going to 
guess that the MESA driver for the 7i92H also exists for MachineKit.
You want to run "mesa" ethernet from the 7i92H on the PICnc? Doesn't sound easy 
and I doubt there is anything specific about the 7i92 in the hm2_eth driver 
other than the fact that the board types are probably added to the driver as 
they are released. MK is well behind LCNC in Mesa drivers  so no idea if it 
worksyou should probably test it. Mesa cards don't run at all on windows 
with the hostmot2 firmware that the MK/LCNC projects interface with, and nobody 
around here can use a "smooth stepper" because of the architectural differences 
between Linux Preempt kernels and the Windows way of doing things. Windows 
devices tend to buffer things in hardware to avoid RT requirements, which is 
why USB hardware is a thing in Windows and not Linux. The "Linux way" is to run 
in a RT capable kernel and minimize the "load" by having the hardware do the 
heavy lifting, but it is still pegged in real-time. 
 
So you're hardware is not going to just be compatible with both, there is very 
little that is as it stands. This is probably not the place to discuss your 
Mach3/4 Windows needs (it's making me cringe just thinking about it). Mesa does 
however have a "SoftDMC" firmware that is meant for WIndows applications. An 
FPGA is far more versatile than a micro so there may be something you can do 
with that, but SoftDMC will not run under LinuxCNC and I seriously doubt anyone 
here knows much about it. 
 
The MESA board I have has the stepping-PWM  engines implemented in an FPGA. 
They all do, it's part of hostmot2 firmware, as are the encoder, Smart serial 
and a few other firmware modules.
 
What I´d like, but what may not be possible, is to replace the MESA 7i92H with 
the updated PICnc. 
 
They functionally do the same exact thing. The PICnc is doing the stepgen, 
encoder, PWM stuff as firmware modules in the micro as well. The difference is 
ethernet, support, and an FPGA vs SPI, a dead project, and a micro
 
If indeed the stepping engine is now within the PIC as well as the spindle 
quadrature etc.
 It is
 
and the board is in effect the Break Out Board for the machine then there is 
absolutely no reason you can´t have a single input serve as a local-remote 
switch.  In remote it behaves like, say a MESA 7i92H and the buttons and 
display appear to behave like a pendent on LinuxCNC.  In local it´s a DRO & 
PowerFeed machine controller with a bunch of useful buttons to simplify manual 
operation.
That's not going to happen like you want it to, unless you are capable of 
writing complex firmware. Your best bet is to abandon the PICnc thing for what 
you want to do and call Mesa. Hostmot2 is "host-based-motion-control" it only 
runs with a host i.e. LinuxCNC. SoftDMC is something completely different and 
like I said, it's never really discussed in the Linux world. The Mesa cards 
generally have 2 EPROMs and one can contain Hostmot2 firmware and the other 
SoftDMC. SoftDMC may possibly be able to run by itself and take care of your 
"local" thingI don't know.
 
Now maybe this won't be possible without also having an FPGA duplicate what is 
done with say the 792H.
 Maybe this won't be possible at all with MachineKit.
The PICnc already does functionally what the 7i92 does, just alot less of it 
and over spi.
 
The PICnc sounded interesting as I've never heard of it before. the board isn't 
very interesting and the micro is too small, but the fact that the original 
designer made firmware and drivers for it makes it something viable for 
resurrection, with SPI IMO.
 
Honestly your intended use doesn't sound very interesting at all because it 
requires way too much non-existent configuration and what you are actually 
trying to do is SUPER EASY just using an Rpi and a 7C80, 7C81, the original 
picnc...whatever. A DE10-Nano running MKSOCFPGA would do it all day.
 
I'm all in for a Rpi based SPI Resurrection of the original PICnc.
 
 
 
 
 
-- 
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

RE: [Machinekit] Re: PICnc with Machine Kit.

[John Dammeyer]

I thought I was quite clear about this.  This PICnc version requires Ethernet.  
LinuxCNC through a MESA Ethernet 7i92H or MACH3-4 through an Ethernet Smooth 
Stepper control hardware.  I am going to guess that the MESA driver for the 
7i92H also exists for MachineKit.
 
The MESA board I have has the stepping-PWM  engines implemented in an FPGA. 
What I´d like, but what may not be possible, is to replace the MESA 7i92H with 
the updated PICnc.  
 
If indeed the stepping engine is now within the PIC as well as the spindle 
quadrature etc. and the board is in effect the Break Out Board for the machine 
then there is absolutely no reason you can´t have a single input serve as a 
local-remote switch.  In remote it behaves like, say a MESA 7i92H and the 
buttons and display appear to behave like a pendent on LinuxCNC.  In local it´s 
a DRO & PowerFeed machine controller with a bunch of useful buttons to simplify 
manual operation.
 
And internally there's a remote config parameter that can be set to LinuxCNC or 
MACHx. Ie. MESA 7i92H or SmoothStepper.
 
Now maybe this won't be possible without also having an FPGA duplicate what is 
done with say the 792H.
 
Maybe this won't be possible at all with MachineKit.
 
Hope that clarifies things a bit.
 
John
 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of justin White
Sent: March-03-20 3:21 AM
To: Machinekit
Subject: Re: [Machinekit] Re: PICnc with Machine Kit.
 
I've seen the mention of these ideas but it's all over the place, there is 
mention of too many things that are in no way compatible with each other. The 
original post simply states that you want to resurrect the PICnc which the 
firmware and hal drivers already seem to be available for to run as the motion 
interface for a LinuxCNC/MK host, specifically the Rpi over SPI, and that 
doesn't work with Mach3  so now you're either writing another set of firmware 
or you're abandoning Mach3.
 
Then you seem to want to run this as a standalone electronic Lead screw thing 
that is going to require different firmware again, but it's supposed to drive a 
small LCD itself and be controlled by hardware buttons on a control panel I 
presume. But it is supposed to retain the functionality of being controlled by 
LCNC/MK? Is there a driver for that? what is the means of commanding it from 
LCNC/MK? If someone is going to plop a non purpose built laptop or PC in front 
of it to casually decide to do CNC today, that laptop needs to be running a RT 
kernel, I don't know that MK/LCNC will actually run a machine from a Live image.
 
All this when realistically, if the project is left with it's original 
intention of running as the motion interface for an rpi, the only thing that 
needs to happen you just create a simple GUI and config to do nothing more than 
be and electronic lead screw. The Rpi obviously can run a monitor out of the 
box and there will never be a need to reflash the firmware on the PICnc device. 
The Rpi itself already has an ethernet interface so if it's not being tied up 
by the PICnc thing as it's running on spi all someone has to do is plug the 
laptop into it and VNC to get a bigger monitor and keyboard going...or 
you can just plug a bigger monitor and keyboard in to the pie lol.
 
So what is the purpose of doing it any other way? to avoid the cost of a rpi?
 


On Monday, March 2, 2020 at 9:33:11 PM UTC-5, John Dammeyer wrote:
Let me go back one step and outline my idea.  First I have machinekit running 
on a BBB with a Xylotex Cape that has a DB-25. There are some problems with the 
high verses low for switches NC/NO so I ended up not using it.
 
I'm not directly thinking of the MachineKit, LinuxCNC or MACH3/4 group of 
users.  I'm thinking of the users who don't even sign onto the CNC groups and 
aren't interested in CNC.  Often because they don't know what they don't know.
 
What I'm thinking of is an ELS-MILL that has DROs, Step/Dir signals, Spindle 
Speed control, and ideally spindle speed feedback along with the usual group of 
inputs and outputs like limit switches and coolant etc.
 
Really just a DRO setup with power feed on each axis.  For someone using a 
manual mill the addition of power feed to an axis is such a tremendous 
improvements and there are all sorts of ways of doing this.  Model Engineer's 
Workshop magazine etc all have had articles along that theme.
 
Now grab that laptop or PC neither of those have SPI or IIC at least not 
without an add on card of some sort.  But they pretty well all have Ethernet.  
So BBB, Pi, PC, Laptop embedded PC box all with LCD Display or HDMI, USB for 
keyboard and mouse all running some form of CNC software with the motion 
commands out Ethernet to a target.  
 
And if that target is the ELS-MILL (which serves as a Break out Board too) then 
you can easily migrate a non-CNC user to the wonders of CNC.  And if you use a 
BBB or Raspberry Pi running machinekit in a way that appears to be an ELS-

RE: [Machinekit] Re: PICnc with Machine Kit.

[John Dammeyer]

Let me go back one step and outline my idea.  First I have machinekit running 
on a BBB with a Xylotex Cape that has a DB-25. There are some problems with the 
high verses low for switches NC/NO so I ended up not using it.
 
I'm not directly thinking of the MachineKit, LinuxCNC or MACH3/4 group of 
users.  I'm thinking of the users who don't even sign onto the CNC groups and 
aren't interested in CNC.  Often because they don't know what they don't know.
 
What I'm thinking of is an ELS-MILL that has DROs, Step/Dir signals, Spindle 
Speed control, and ideally spindle speed feedback along with the usual group of 
inputs and outputs like limit switches and coolant etc.
 
Really just a DRO setup with power feed on each axis.  For someone using a 
manual mill the addition of power feed to an axis is such a tremendous 
improvements and there are all sorts of ways of doing this.  Model Engineer's 
Workshop magazine etc all have had articles along that theme.
 
Now grab that laptop or PC neither of those have SPI or IIC at least not 
without an add on card of some sort.  But they pretty well all have Ethernet.  
So BBB, Pi, PC, Laptop embedded PC box all with LCD Display or HDMI, USB for 
keyboard and mouse all running some form of CNC software with the motion 
commands out Ethernet to a target.  
 
And if that target is the ELS-MILL (which serves as a Break out Board too) then 
you can easily migrate a non-CNC user to the wonders of CNC.  And if you use a 
BBB or Raspberry Pi running machinekit in a way that appears to be an ELS-MILL 
but with a local/remote switch changes personalities you now have it all 
bundled into one board.
 
But that might be asking too much hence the idea of using a PIC32 or something 
like that for the ELS-MILL.
 
John
 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of justin White
Sent: March-02-20 5:56 PM
To: John Dammeyer
Cc: Machinekit
Subject: Re: [Machinekit] Re: PICnc with Machine Kit.
 
Yeah, there is no reason to use ethernet when almost everything has a uart. SPI 
is a viable rt interface and there is no reason to tie up the processor boards 
ethernet port. Mesa is using spi with the raspberry pi boards, the 7c80 and the 
7c81, so you are pretty much guaranteed it works. Also being that spi comes off 
a gpio header there is no rj45 connector to add to the pic card.
 
I'm lost on the USB-c talk.an rt interface is about transferring small 
packets quickly. USB regardless of the generation isn't required, or even 
really suitable. Mesa doesn't even use gigabit on its ethernet cards, its 
10/100.
 
I've never heard of this PICnc before now but it seems like it could have been 
a good idea but that micro was too small, and imo too slow. Step rates were 
only mentioned at 40khz which is OK I suppose but mesa is doing them at 10mhz 
on a spartan 5/6. Stepgens and encoders only wind up running at a fraction of 
the speed of the controller and a 40mhz pic32 seems to get 40khz, while a 
500-600mhz fpga is getting them at 10mhz.
 
I realize cost is a thing here but what is the price difference really between 
the original pic32 used and a higher end micro?
 
On Mon, Mar 2, 2020, 7:16 PM John Dammeyer  wrote:
A bit of digging through my boxes after a double check of the data sheet shows 
I find that the PIC32 won't serve my needs.   I thought it had a quadrature 
encoder module but it doesn't.   I have PIC32MX boards and a bunch of dsPIC33F 
series boards.  
 
The problem is the PIC32MK which has motor control features and the quadrature 
encoder doesn't do Ethernet. However one could add the ENC28J60 to deal with 
Ethernet if it was wanted for connection to a MachineKit, LinuxCNC or MACH3 PC. 
 Or just use a Pi or Beagle running MachineKit or LinuxCNC and SPI and forget 
about Ethernet connectivity.
 
I have these modules.
http://www.autoartisans.com/PIC32/AutoBoard_CAN_EEROM.jpg
http://www.autoartisans.com/PIC32/PIC32_Sets.jpg
 
And a bunch of others with dsPIC33F series modules.
 
This will require some more research…
John Dammeyer
 
 
 
 
-- 
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/018d01d5f0f0%24fcb07e20%24f6117a60%24%40autoartisans.com
 
<https://groups.google.com/d/msgid/machinekit/018d01d5f0f0%24fcb07e20%24f6117a60%24%40autoartisans.com?utm_medium=email_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, se

RE: [Machinekit] Re: PICnc with Machine Kit.

[John Dammeyer]

A bit of digging through my boxes after a double check of the data sheet shows 
I find that the PIC32 won't serve my needs.   I thought it had a quadrature 
encoder module but it doesn't.   I have PIC32MX boards and a bunch of dsPIC33F 
series boards.  
 
The problem is the PIC32MK which has motor control features and the quadrature 
encoder doesn't do Ethernet. However one could add the ENC28J60 to deal with 
Ethernet if it was wanted for connection to a MachineKit, LinuxCNC or MACH3 PC. 
 Or just use a Pi or Beagle running MachineKit or LinuxCNC and SPI and forget 
about Ethernet connectivity.
 
I have these modules.
http://www.autoartisans.com/PIC32/AutoBoard_CAN_EEROM.jpg
http://www.autoartisans.com/PIC32/PIC32_Sets.jpg
 
And a bunch of others with dsPIC33F series modules.
 
This will require some more research…
John Dammeyer
 
 
 
 

-- 
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/018d01d5f0f0%24fcb07e20%24f6117a60%24%40autoartisans.com.

RE: [Machinekit] Re: PICnc with Machine Kit.

[John Dammeyer]

rocessor based.

So what's next in the METHOD section?
Well you want to create the code to accelerate and move the motors so you need 
a method of entering values and testing motion for each axis.  Take a close 
look at the method used n MACH 3 and given there's a 7" graphic display this is 
a good place to copy a concept.  The file created by this screen interaction 
may well be written out (and read back when the screen is displayed) to look 
like this:
[AXIS_0]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 3.3
MAX_ACCELERATION = 15.0
STEPGEN_MAXACCEL = 35.0
SCALE = 15000.0
FERROR = 0.05
MIN_FERROR = 0.01
MIN_LIMIT = -0.04
MAX_LIMIT = 13.5
BACKLASH = 0.0215
HOME_OFFSET = -0.1
HOME_SEARCH_VEL = -0.8
HOME_LATCH_VEL = 0.01
HOME_FINAL_VEL = 0.2
HOME_IGNORE_LIMITS = YES
HOME_VOLATILE = 1
HOME_SEQUENCE = 1

That would all be described in more detail in the DESCRIPTION section of this 
project.  An initial layout that describes what is wanted and how it should 
work.  Or just clone the tools that come with LinuxCNC/MachineKit.

Finally we get to the point where we write the code that accelerates and 
decelerates a motor and runs it a given speed.  Track the stepping pulses, 
convert to engineering units and show them on the display.It's not that 
much more work to then add another screen with BEGIN/END points for each axis 
and expand the software to now move from BEGIN to END using the accel and vel 
values.

So far we're really only talking about each axis operating independently.  
There's nothing in there, nor maybe should there be anything that says our feed 
rate is F30 and the distance from BEGIN to END is a tuple like BEGIN(X,Y and Z) 
and move to END(X,Y and Z).  That’s' so easily done with a single G code 
command that duplicating that means a user wants complex behaviour and so 
should invest in the time to learn a complex system.

But the reality is that the lowest acceleration value can be used for all axis 
and the max velocity of the slowest axis is also the limit.  So it's now simple 
linear algebra to calculate the motion of the tool bit from BEGIN to END at F30 
and supply an accel value, velocity value and distance value to the motion 
engine and move the motors so the tool bit travels at the expected rate from 
BEGIN to END.

The question is should it at this level of a tool.  That question needs to be 
answered before a single line of code is written.

This is all just me thinking out loud.  Perhaps the solution for a BeagleBone 
connected to a decent Cape is to run MachineKit but instead of the Axis 
Interface run the stand alone ELS-MILL user interface with the LCD screen and 
array of buttons.  But plug in a monitor, keyboard and mouse and press the 
local/remote switch on the LCD user interface and suddenly you are running 
MachineKit.

John Dammeyer.


> -Original Message-
> From: cern via Machinekit [mailto:machinekit@googlegroups.com]
> Sent: March-01-20 2:38 PM
> To: Mr Greg
> Cc: Machinekit
> Subject: Re: [Machinekit] Re: PICnc with Machine Kit.
> 
> Hi,
> I have been looking from afar (as I don't need another project at the time) at
> the Zephyr RTOS project. It gets me thinking, something like PICnc needs
> mainly access to encoder and PWM peripheral timers, right? And then
> receive and send messages over some time-deterministic line, right?
> 
> So, wouldn't it be possible to use some RTOS "middleware" (for lack of better
> terminus technicus) for this? That way the support for the hardware would
> be outsourced to somebody else.
> 
> (Sorry for my [maybe] naive idea.)
> 
> Cern.
> 
> Mar 1, 2020, 23:10 by mr84g...@gmail.com:
> 
> > Hello
> >
> > Yes, reasonably priced / cheap "off the shelf hardware", simplicity, docu -
> manuals - tutorials etc in line with Kinsa's original picnc project.
> >
> > I suggest it would be best to avoid using ethernet. wifi & BT want to be
> ruled out of the RT. This leaves ethernet as being the only practical option 
> to
> keep the machine networked. Somewhat necessary in the majority of use
> cases.
> > SPI is most likely available in the likely candidate MCUs. ARM, PIC
> whatever...
> >
> > The code is already for PIC. Developing the existing code for a current PIC
> Dev board does make sense. However..PIC developers seem to be a bit thin
> on the ground? The popularity of� and future availability PIC Dev boards is
> also open to question.
> >
> > The ARM Cortex M0 series and upwards� would perhaps be a good place
> to start if there is the skill and interest, not to mention quite a lot of 
> time to
> effect a Porting and development of existing code?
> > ARM Documentation states that (in theory at least) that code written for
> the M0 will run on any later Mx series. Eg STM32 series, Arduino Zero, Due,
> and any number of c

RE: [Machinekit] Re: PICnc with Machine Kit.

[John Dammeyer]

I do have a MESA 7i92H that works with LinuxCNC on a dual boot PC.  I have to 
switch to standard parallel port for MACH3 or use a USB Smooth Stepper (more 
expensive than the 7i92H).
I've also had my mill running with the BeagleBone Black, MachineKit and the 
Xylotex Cape.  There are issues with the cape, not with the BBB that had me 
change to a PC.
 
The BBB with Xylotex uses the PRUs for step/dir for up to 4 axis.  It can also 
take on Encoder input  Although there is a serial  port the CAN bus port is 
taken up by the Xylotex cape and I think SPI is too.  Partly, IIRC, because the 
HDMI also uses much of the I/O.
 
There are LCD displays for the BBB but once again they take up all the 
important I/O and support is minimal.  This screen was done in Python.
http://www.autoartisans.com/MachineKit/BB-W1-LCD4.jpg
 
Once you remove the HDMI and change which pins on the BBB can be used for 
step/dir and spindle encoder the potential of using SPI or I2C for keypad 
matrix and LCD display along with at least one Serial Port and one CAN port for 
CANopen you can address MODbus VFDs and CANopen based hardware for tool 
changers and other peripherals.
 
That means the basic Machinekit port to the BBB wouldn't have to be touched, 
the HAL and INI files would take care of remapping the step/dir pins but the 
AXIS user interface would have to go.  A new interface that handled say 48 
buttons, a graphical LCD display and an encoder knob like I have on my ELS 
could provide the basics.
 
In fact, to start with and to not have to build large amounts of hardware, I'd 
probably use my ELS with a 20x4 character screen (instead of the 20x2) and the 
35 buttons along with the MPG knob.  
For example:
http://www.autoartisans.com/ELS/photos/ELS110D.JPG
 
http://www.autoartisans.com/MachineKit/FourLines2.jpg
 
This photo shows the RS232 connection and if the Y axis step/dir pulses aren't 
used and the CAN driver chip is installed I've had it operating as a CANopen 
User Interface Device.
http://www.autoartisans.com/ELS/photos/ELSBottom.jpg
 
A prototype cape that has headers to plug in place of the PIC CPU on my ELS 
could be the starting point as in the past I've created companion boards that 
plug into jumper the header on the bottom of the ELS.  
http://www.autoartisans.com/MachineKit/IO_Interface-1.jpg
 
To expand a companion board with a ribbon cable to the 40 pin PIC IC socket 
then gives access to all the I/O and the header.  The BBB could plug into that.
 
And finally, since the BBB still has Ethernet it runs MachineKit but can 
perhaps talk MESA Ethernet protocol to a PC running LinuxCNC or MachineKit for 
the full blown AXIS display.  So you get the best of both worlds.  A small 
LCD/Keypad/MPG based module not much bigger than a DRO for pseudo manual 
operation of the mill but also attach a laptop or roll up a PC and you have 
full blown CNC.
 
This is all still kicking the tires.  Maybe a PIC32 would be an easier solution.
 
John Dammeyer
 
 
 
 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of mngr
Sent: February-29-20 2:46 AM
To: Machinekit
Subject: [Machinekit] Re: PICnc with Machine Kit.
 
Hi,
 
In my humble opinion it should have both SPI and Ethernet connection.
I do not see any difference in the real-time capabilities of these two 
protocols.
 
cost would go up a bit, but this project could receive more attention form 
already existing communities.
 
Maybe it could re-use the MESA protocol over ethernet, allowing for mutiple 
slaves to be connected, reusing work on the machinekit side, and attracting the 
attention of the LinuxCNC community. I am in europe, I cannot buy MESA because 
it came out way too expensive.
There already are some open source motor driver, like Odrive or VESC. Maybe we 
could reuse something from here (BLDC are not stepper, i know, but hey, stepper 
are way easyer!)
How hard do you think it is to move the MESA protocol from an FPGA, VHDL, to a 
microcontroller?
 
I would use something like an ATSAME54, which is a cortex m4. I feel that atmel 
start libraries are well made, but I am not a seasoned developer.
 
I can work on this, but I need the guide of a experienced one.
 
Regards,
 
mngr

Il giorno venerdì 28 febbraio 2020 16:11:23 UTC+1, Mr Greg ha scritto:
@ JohnD
 
Re your OP
The answer is yes.
I have been using a Picnc + RPi2 -Jessy OS combo with machinekit for several 
yrs. Looking to upgrade/resurect/or move on if necessary.
I'm personally not the chap to do the detail code, but am working with a dev 
who has an interest and can contribute some limited time and effort.
 
I am currently exploring Pi4 + Buster with a view to either Mesa or Picnc? TBD
 
@ Tomp
I understand you have had Picnc successfully running on a Pi3 ?
I can't seem to get it to behave on a Pi3. Not with Jessie + MK anyways. All 
motors just spiral out of control soon as MK is started :(
All the SPI and dma addressing looks compatible They are both 2837
Any ideas?
 
@ All

RE: [Machinekit] Re: PICnc with Machine Kit.

[John Dammeyer]

Hi Tomp,
I would have absolutely no problem doing a schematic and PCB layout in Altium.  
No problem in writing the software.  I have a bunch of PIC32 development 
systems and eval boards around here.  Just did a project about two years ago 
that captured CAN messages with a PIC32 and via very high speed SPI moved them 
into a Raspberry Pi with time/date and GPS stamps.
 
My web site home page shows one of my larger CAN based projects.  I also 
manufacture an Electronic Lead Screw kit.
 
What I've been mulling over is something like a Beaglebone Back with a larger 
LCD screen, perhaps even 48 buttons instead of 35, and more of a Break Out 
Board I/O interface.  The general idea is a DRO and Power Feed capability for 
all axis including spindle detection for power tapping.   Small box relative to 
PC, Keyboard, Mouse and Screen. 
 
But, with an Ethernet port and a MESA like interface so it becomes the hardware 
interface to LinuxCNC or maybe also MACH3/4.
 
John Dammeyer
 <http://www.autoartisans.com> http://www.autoartisans.com 
 
http://www.autoartisans.com/ELS/
 
 
 
 
 
 
From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On 
Behalf Of TJoseph Powderly
Sent: February-27-20 9:35 PM
To: Machinekit
Subject: [Machinekit] Re: PICnc with Machine Kit.
 
Ji Johm
please confirm that you can/cannot build it
and on what platform
I would not be the person to port to another chip or os
but i have built it , and used it before 2019
Thanks Tomp

On Thursday, February 27, 2020 at 1:42:41 PM UTC+7, John Dammeyer wrote:
This project seems to have lapsed 5 years ago.  
https://github.com/kinsamanka/PICnc-V2/wiki
 
Any interest in resurrecting it?
 
John Dammeyer
 
"ELS! Nothing else works as well for your Lathe"
Automation Artisans Inc.
www dot autoartisans dot com 
 
-- 
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/a9ab96ac-a2a4-4fec-8946-9aff305d17ac%40googlegroups.com
 
<https://groups.google.com/d/msgid/machinekit/a9ab96ac-a2a4-4fec-8946-9aff305d17ac%40googlegroups.com?utm_medium=email_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/166501d5edfb%2475a9bc90%2460fd35b0%24%40autoartisans.com.

RE: [Machinekit] PICnc with Machine Kit.

[John Dammeyer]

There's ARM and MIPS.  There was 8086 and M68000.  The 8086 won the war as 
Apple MACs now use Intel and Motorola is now part of NXP.  I do wonder whether 
the support for MIPS and the PIC32 has waned with Microchip purchasing ATMEL.

Perhaps it's better to go TI with their product line?

John


> -Original Message-
> From: machinekit@googlegroups.com
> [mailto:machinekit@googlegroups.com] On Behalf Of Charles Steinkuehler
> Sent: February-27-20 5:16 AM
> To: machinekit@googlegroups.com
> Subject: Re: [Machinekit] PICnc with Machine Kit.
> 
> I am allergic to PIC chips and 8051 derivatives.  ;-)
> 
> On 2/27/2020 12:42 AM, John Dammeyer wrote:
> > This project seems to have lapsed 5 years ago.
> > https://github.com/kinsamanka/PICnc-V2/wiki
> >
> > Any interest in resurrecting it?
> >
> > John Dammeyer
> >
> > "ELS! Nothing else works as well for your Lathe"
> > Automation Artisans Inc.
> > www dot autoartisans dot com
> >
> >
> 
> --
> Charles Steinkuehler
> char...@steinkuehler.net
> 
> --
> 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/ee24f2ef-890f-82eb-c667-
> 8f6290448ec3%40steinkuehler.net.

-- 
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/15a501d5ed98%24ec30a300%24c491e900%24%40autoartisans.com.

[Machinekit] PICnc with Machine Kit.

[John Dammeyer]

This project seems to have lapsed 5 years ago.  
https://github.com/kinsamanka/PICnc-V2/wiki
 
Any interest in resurrecting it?
 
John Dammeyer
 
"ELS! Nothing else works as well for your Lathe"
Automation Artisans Inc.
www dot autoartisans dot com 
 

-- 
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/150501d5ed39%24141d4900%243c57db00%24%40autoartisans.com.

Re: [Machinekit] Teknic motors and MachineKit

[John Allwine]

Thank you, Damien! This is really helpful. I’ll give something like this a shot.

> On Feb 24, 2020, at 3:10 AM, Damien Dando  wrote:
> 
> 
> And this is how I load my custom component in my HAL file:
> 
>> loadrt home_index_switch
>> newinst second_home_switch home-sw2 pincount=2
>> ## micrometric 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).
>> 
>> 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 and do_homing() in homing.c). 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 

Re: [Machinekit] Teknic motors and MachineKit

[John Allwine]

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  wrote:
> 
> 
> The google group fell off the reply.
> For completeness done manually :)
> 
>>> On 22 Feb 2020, at 17:44, Bas de Bruijn  wrote:
>>> 
>> 
>> 
>> 
>>>> On 22 Feb 2020, at 15:25, John Allwine  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  wrote:
>>>>> 
>>>> 
>>>> 
>>>> 
>>>>>> On 21 Feb 2020, at 23:30, John Allwine  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 

Re: [Machinekit] Teknic motors and MachineKit

[John Allwine]

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?

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  wrote:
> 
> 
> 
> 
>>> On 21 Feb 2020, at 23:30, John Allwine  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 machinek

[Machinekit] Teknic motors and MachineKit

[John Allwine]

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.

-- 
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/6b01a405-251f-4633-af72-abbcd6c78ab0%40googlegroups.com.

Re: [Machinekit] What happened to Machinekit's Jenkins?

[John Morris]

I'm not sure exactly what happened, except I know the server's owner needed to 
reclaim the resources Jenkins was using, and ISTR hearing Jenkins was a PITA to 
administer.

Travis CI is easy to set up, and the limitations that prompted the switch to 
Jenkins several years ago have since been solved (i.e. fast ARM cross-builds 
replaced the old emulated builds that exceeded the 50-minute time limit on 
Travis).  There are (likely out of date) Travis setup instructions in the 
mk-cross-builder repo.

https://github.com/dovetail-automata/mk-cross-builder/

John


From: 'Jan Svoboda' via Machinekit 
Sent: Tuesday, February 4, 2020 7:32 PM
To: Machinekit
Subject: [Machinekit] What happened to Machinekit's Jenkins?

Hello,
I wanted to loop up some older test on jenkins.machinekit.io - but the address 
is no longer active. Does anybody know what happened to the Jenkins server?

Thanks.
Cern.

--
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<mailto:machinekit+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/2b134daf-3411-4c32-9f2b-85072febfb21%40googlegroups.com<https://groups.google.com/d/msgid/machinekit/2b134daf-3411-4c32-9f2b-85072febfb21%40googlegroups.com?utm_medium=email_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/BYAPR12MB358961F5AFAE3EE2C8964778851D0%40BYAPR12MB3589.namprd12.prod.outlook.com.

[Machinekit] Re: Machinekit rtapi_app process symbol visibility

[John Morris]

On Friday, November 15, 2019 at 6:48:51 AM UTC+8, ce...@tuta.io wrote:
>
> Hello, 
> recently, in my play, I ran afoul of the Machinekit-HAL symbol visibility 
> mechanism, where the RTAPI symbols must be post-processed in the output ELF 
> by comparing sections and deleting symbols not defined as an EXPORT_SYMBOL 
> and also the explicit denial of rtapi_app being linked as a 
> -export-dynamic. 
>
> (Point: I presume that the userspace RT threads focus is design feature of 
> Machinekit. Not something which happened in the passing.) 
> I plus/minus do get why the symbol isolation is needed. But why was this 
> form used over own linker namespaces with run-time exported symbols to few 
> important functions? 
>

This is actually a relic of the days of kernel threads and integrating with 
Linux KBUILD.  Hopefully that's enough of a clue to track down your 
problem, since I've forgotten almost everything else about it.


And how to best "export" few symbols from rtapi_app to other modules given 
> that rtapi_app cannot export any symbols? The best thing I came up with is 
> to create shared library which will be linked both by rtapi_app and given 
> module, given the fact that all live in one linker namespace. 
>
>
 
Well, `rtapi_app` CAN export symbols, those marked with `EXPORT_SYMBOL`.  
To export a few symbols, that's the "best way" because it exists, it works, 
and other developers are familiar with it.  Why won't it work in your use 
case?

John

-- 
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/e288af89-f67b-40c7-b435-d30406959b15%40googlegroups.com.

Re: [Machinekit] Re: Machinekit on PocketBeagle

[John Morris]

On Tuesday, May 21, 2019 at 6:30:32 AM UTC+8, mlampert wrote:
>
> I created an issue, hope I got the description right: 
> https://github.com/machinekit/machinekit/issues/1481 
>

Thanks, Markus and Charles.  I put in a PR:

https://github.com/machinekit/machinekit/pull/1482

Sorry I didn't test the original patch more rigorously.  Seems my 
super-simple Goldibox HAL config didn't use any GPIO inputs!

John
 

>
> On Mon, 20 May 2019 14:39:49 -0700 
> markus > wrote: 
>
> > Yay - that does work, it is required to specify the board though: 
> > 
> > markus@pocketbeagle:~/machinekit/configs/infinity$ halrun 
> > msgd:0 stopped 
> > rtapi:0 stopped 
> > rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0 
> > --rtmsglevel=1 --usrmsglevel=1 --halsize=524288 rtapi_app 
> > command:  /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0 
> > halcmd: loadrt hal_bb_gpio  output_pins=201 :1: insmod failed, 
> > returned -1: rtapi_app_main(hal_bb_gpio): -1 Operation not permitted 
> > 
> > halcmd: loadrt hal_bb_gpio board=PocketBeagle output_pins=201 
> > halcmd: 
> > 
> > 
> > 
> > 
> > On Mon, 20 May 2019 16:24:59 -0500 
> > Charles Steinkuehler > wrote: 
> >   
> > > Hmm...looking at the code it appears the output pins have a 
> > > conditional for the pin numbering fixup: 
> > > 
> > > 
> https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L365-L370
>  
> > > 
> > > ...that's missing for the input pins: 
> > > 
> > > 
> https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L272-L275
>  
> > > 
> > > Combined with the legacy use of 1xx and 2xx for the BeagleBone pin 
> > > numbers (which is why the fixup exists in the first place) it looks 
> > > like that's breaking you pin numbering scheme. 
> > > 
> > > Can you try with just output pins and see if that works? 
> > > 
> > > 
> > > On 5/20/2019 4:06 PM, markus wrote:   
> > > > That actually is the problem - the driver takes the p1 and p2 pins 
> > > > and uses them as p8 and p9 pins, this is the excerpt from the hal 
> > > > file that I used: 
> > > > 
> > > > # load low-level drivers 
> > > > loadrt hal_bb_gpio board=PocketBeagle input_pins=201,202,203,204 
> > > > output_pins=217,227,228,229,230,231,232 loadrt [PRUCONF](DRIVER) 
> > > > prucode=$(HAL_RTMOD_DIR)/[PRUCONF](PRUBIN) [PRUCONF](CONFIG) 
> > > > 
> > > > Same thing happens if I do it manually with halrun - and it 
> > > > complains about the first pin in the command line, so if I remove 
> > > > 201 it complains about 902 not being valid. 
> > > > 
> > > > 
> > > > On Mon, 20 May 2019 15:55:37 -0500 
> > > > Charles Steinkuehler > wrote: 
> > > > 
> > > >> On 5/20/2019 3:36 PM, markus wrote: 
> > > >>> Thanks for the clarification - much appreciated. 
> > > >>> 
> > > >>> It seems the driver is ignoring the parameter though. And I get 
> > > >>> the same result. From linuxcnc.log:   
> > > >> 
> > > >> Look closer, it's not the same result. 
> > > >> 
> > > >>> May 20 00:07:37 pocketbeagle msgd:0: startup pid=1376 
> > > >>> flavor=rt-preempt rtlevel=1 usrlevel=1 halsize=524288 shm=Posix 
> > > >>> cc=gcc 6.3.0 20170516  version=v0.1~-~355496b May 20 
> > > >>> 00:07:37 pocketbeagle msgd:0: ØMQ=4.2.1 czmq=4.0.2 
> > > >>> protobuf=3.0.0 atomics=gcc intrinsicslibwebsockets=2.0.3 
> > > >>> May 20 00:07:37 pocketbeagle msgd:0: configured: sha=355496b 
> > > >>> May 20 00:07:37 pocketbeagle msgd:0: built:  Mar 14 2019 
> > > >>> 10:47:55 sha=355496b May 20 00:07:37 pocketbeagle msgd:0: 
> > > >>> register_stuff: actual hostname as announced by 
> > > >>> avahi='pocketbeagle.local' May 20 00:07:37 pocketbeagle msgd:0: 
> > > >>> zeroconf: registering: 'Log service on pocketbeagle.local pid 
> > > >>> 1376' May 20 00:07:38 pocketbeagle msgd:0: zeroconf: registered 
> > > >>> 'Log service on pocketbeagle.local pid 1376' _machinekit._tcp 
> > > >>> 49152 TXT "uuid=4e7e123c-1726-4351-bdfc-eba93047fb35" 
> > > >>> "instance=f2ce6258-7acd-11e9-aea4-6

Re: [Machinekit] Re: Machinekit on PocketBeagle

[John Morris]

On Monday, May 20, 2019 at 11:07:12 AM UTC+8, mlampert wrote:
>
> Am I correct that the support for the PB is a 'compile time' decision? 
>

Try`board=PocketBeagle`

https://github.com/machinekit/machinekit/blob/b58f6e83/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c#L83

John
 

> So if hal_bb_gpio is compiled for a BBB the driver does not support the 
> PB headers - right? 
>
> The MK image is from April 5 2019 - I made sure I updated to the latest 
> from deb.machinekit.io - the installed version is 0.1.155255826 which 
> has the commit sha1 355496b, which indeed seems to be HEAD of master. 
>
> If the driver is supposed to work on the PB although it was compiled 
> for the BBB then I'll file an issue for it. 
>
> Thanks, 
> Markus 
>
>
> On Sun, 19 May 2019 18:58:21 -0700 (PDT) 
> John Morris > wrote: 
>
> > On Monday, May 20, 2019 at 5:37:31 AM UTC+8, mlampert wrote: 
> > > 
> > > I've installed the stretch Machinekit image from elinux.org on a 
> > > PocketBeagle to play around with. As it turns out some of the 
> > > installed drivers are indeed specific to the BBB, hal_bb_gpio being 
> > > one of them (it insists on mapping pin 201 to 901 and then complain 
> > > that it cannot be configured). After looking at the source I 
> > > understand what's going on and why this is happening - however, I 
> > > don't know what else needs to get specifically built for the 
> > > pocketbeagle. 
> > > 
> > > So the question is: What's the best way to get Machinekit running 
> > > on a PocketBeagle? 
> > >   
> > 
> > I've had this running for a while on PB now.  The pin mapping issues 
> > should have been fixed for a couple of years now [1].  If the 
> > elinux.org image is too old to have this change, update Machinekit. 
> > If you confirm that the change is in place and you're still seeing 
> > this issue, file an issue on the tracker, and mention @zultron to 
> > ensure I see it (though I would anyway). 
> > 
> > John 
> > 
> > [1]: https://github.com/machinekit/machinekit/commit/b58f6e83 
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmachinekit%2Fcommit%2Fb58f6e83=D=1=AFQjCNEOgtKEQoXpQjGVxZtzxJ5Bt8A-HQ>
>  
> >   
> > 
> > > 
> > > Thanks a lot, 
> > > Markus 
> > > 
> > >   
> > 
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/214cc264-be5a-461e-8b9e-68ee23541608%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: Machinekit on PocketBeagle

[John Morris]

On Monday, May 20, 2019 at 5:37:31 AM UTC+8, mlampert wrote:
>
> I've installed the stretch Machinekit image from elinux.org on a 
> PocketBeagle to play around with. As it turns out some of the installed 
> drivers are indeed specific to the BBB, hal_bb_gpio being one of them (it 
> insists on mapping pin 201 to 901 and then complain that it cannot be 
> configured). After looking at the source I understand what's going on and 
> why this is happening - however, I don't know what else needs to get 
> specifically built for the pocketbeagle.
>
> So the question is: What's the best way to get Machinekit running on a 
> PocketBeagle?
>

I've had this running for a while on PB now.  The pin mapping issues should 
have been fixed for a couple of years now [1].  If the elinux.org image is 
too old to have this change, update Machinekit.  If you confirm that the 
change is in place and you're still seeing this issue, file an issue on the 
tracker, and mention @zultron to ensure I see it (though I would anyway).

John

[1]: https://github.com/machinekit/machinekit/commit/b58f6e83
 

>
> Thanks a lot,
> Markus
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/1aa5bd4b-ce13-4598-88c9-8f6747ae4a3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Successful cross-compiling with Debian Stretch

[John Morris]

James,

Very nice!  This is not an easy thing to do.  As Mick said, we do something 
very similar, all inside Docker containers, to speed up armhf builds on the 
amd64-arch CI systems the project uses to run  tests and builds.

Building packages is an additional challenge, and requires installing even more 
package dependencies alongside the build-arch tool chain to get 
`dpkg-buildpackage` even to *agree to  try* building your packages!

The basic trick we use to get around incomplete `MultiArch` support is to 
install conflicting packages in a multistrap root under `/sysroot`, and tell 
the compiler and linker to grab headers and libraries from there with the `gcc 
--sysroot=/sysroot` argument.  After that, the real fun begins!   Your 
`libboost-python-dev` hack is a good example of the many tricks we use to make 
this work, and the result is a big, stinky mess.

Happily, Docker neatly contains all this ugliness in an image that's easy to 
reproduce and easy to run, both in the project's CI systems and in our 
developer environments.  You can see what exactly goes into it in the below 
GitHub repository (PRs are very welcome if you can improve it).  Hopefully 
these kinks in `MultiArch` will be worked out some day and this will all be 
much simpler.

https://github.com/zultron/mk-cross-builder

John


From: machinekit@googlegroups.com  on behalf of 
schoone...@gmail.com 
Sent: Saturday, April 20, 2019 8:56 PM
To: machinekit@googlegroups.com
Subject: Re: [Machinekit] Successful cross-compiling with Debian Stretch

Hi James,

I went on a similar journey a few years ago, first using a chroot file system 
and qemu and then multiarch cross builds.
You learn a lot on the way and the latter is certainly faster.

We have been using John Morris's multiarch cross compiling docker containers 
for a while now.
They use the same approach as you did.

If you install docker-ce and checkout dovetailautomata/mk-cross-builder:armhf_9 
from dockerhub, you can build your packages with
`scripts/build_docker -t armhf_9 -c deb -j $(nproc)`
from the root dir of the machinekit repo.

That is how we produce all the machinekit packages now and it works well 
locally too.

regards




On 19/04/19 17:30, James Gao wrote:
Hi everyone,
Just wanted to report that I got Machinekit to successfully cross-compile 
through a Debian Stretch debootstrap. It seems that the latest multiarch 
support in stretch is good enough that (most) of the armhf libraries installed 
correctly. This doesn't require qemu, so it takes a fraction of the time to 
build. I was searching for more instructions on how to do a cross-compile 
build, and came across this thread: 
https://groups.google.com/forum/#!topic/machinekit/HWS807SS8ks<https://groups.google.com/forum/#%21topic/machinekit/HWS807SS8ks>
 which requested a PR -- let me know if that's still preferred.

This is partially for my own benefit, but here's a short summary of the 
commands I used to get it to work:
sudo debootstrap --components=main,contrib,non-free stretch {DEST_FOLDER} 
http://deb.debian.org/debian/

I configured schroot to launch the system:
cat < /etc/schroot/chroot.d/amd64-stretch
[amd64-stretch]
description=Debian Stretch (amd64)
directory={DEST_FOLDER}
root-users={USERNAME}
users={USERNAME}
type=directory
EOF
schroot -s amd64-stretch

Once inside, I configured multiarch and installed some basic packages:
sudo dpkg --add-architecture armhf
sudo apt update
sudo apt install gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf cython 
pkg-config autoconf git libczmq-dev:armhf
git pull https://github.com/machinekit/machinekit.git
cd machinekit/src/
./autogen.sh
PKG_CONFIG_PATH="/usr/lib/arm-linux-gnueabihf/pkgconfig/" ./configure 
--with-platform-beaglebone --host arm-linux-gnueabihf

Now the great dependency hunt begins -- basically just run the configure line, 
and install the :armhf version of whatever library it complains about. I can 
put together a more comprehensive list if requested.

The only library that requires special treatment is libboost-python-dev. If you 
try to install the :armhf version of that library, it tries to replace python 
with the armhf version, which will break the system. I went ahead and just 
directly extracted only the contents of /usr/lib/arm-linux-gnueabihf/ from 
http://ftp.us.debian.org/debian/pool/main/b/boost1.62/libboost-python1.62.0_1.62.0+dfsg-4_armhf.deb
 and 
http://ftp.us.debian.org/debian/pool/main/b/boost1.62/libboost-python1.62-dev_1.62.0+dfsg-4_armhf.deb

I'm pretty sure I have a working armhf build -- I haven't had a chance to run 
it on target yet because I need to figure out how to package it (currently 
still in the RIP environment).
--
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 a

Re: [Machinekit] Happy Birthday Machinekit!

[John Morris]

Happy Birthday Machinekit!  5 years old now.

This year, I'm very excited about the progress underway in the
`machinekit-hal` repository.  HAL is the crown jewel of the Machinekit
project, and splitting it off into its own repository brings it out
from under the shadow of the EMC application and at last into the
visibility of its own light.  There's a lot of polishing left to do,
but it's huge progress that it is already usable, with its own
independent code base and package stream.  Congratulations, and thanks
to everyone who helped make this happen!

John

On Wednesday, April 4, 2018 at 7:37:16 AM UTC+8, John Morris wrote:
>
> Happy Birthday #4 Machinekit! 
>
> While I've probably *contributed to* Machinekit *less* in the last year 
> than ever before, it turns out I've *used* Machinekit *more*, whether 
> for the EMC app on my 3D printer, or whether for straight HAL and 
> QtQuickVCP for Golibox, autoclave and robot controls.  Thanks to all the 
> devs and maintainers for the great work. 
>
> John 
>
>
> On 04/03/2017 12:19 AM, John Morris wrote: 
> > It's been three years.  Happy Birthday, Machinekit! 
> > 
> >  John 
> > 
> > 
> > On 04/03/2016 04:48 PM, John Morris wrote: 
> >> Happy two-year birthday, Machinekit!  Another great year and more great 
> >> leaps forward.  Keep it up! 
> >> 
> >> John 
> >> 
> >> 
> >> On 04/03/2015 03:59 AM, John Morris wrote: 
> >>> A year ago today on April 3, Michael posted the [Machinekit 
> >>> announcement] on the Emc-developers list.  IMO, that marks the 
> official 
> >>> birthday of Machinekit, so, 
> >>> 
> >>> Happy Birthday! 
> >>> 
> >>> I'm incredibly pleased (and surprised!) by the huge leaps the project 
> >>> has made in such a short time, and by the explosive growth of the 
> >>> project's community.  In the [ZeroMQ Guide Chap. 6], Pieter Hintjens 
> >>> writes that the two go hand-in-hand, and says "It's hard to 
> >>> overemphasize the power and persistence of a working open source 
> >>> community."  That's exactly what I see here, an amazing bunch of folks 
> >>> continually attracting new amazing folks, and the result is 
> brilliance. 
> >>>   Congratulations to everybody, both those participating in the 
> >>> Machinekit project today, and also those who contributed to the 15+ 
> year 
> >>> legacy of the code base.  I can't wait to see what the next year will 
> >>> bring. 
> >>> 
> >>> [Machinekit announcement]: 
> >>> http://sourceforge.net/p/emc/mailman/message/32182244/ 
> <http://www.google.com/url?q=http%3A%2F%2Fsourceforge.net%2Fp%2Femc%2Fmailman%2Fmessage%2F32182244%2F=D=1=AFQjCNEO4wlwp94BB-S3U8wscDMdmHmswA>
>  
> >>> 
> >>> [ZeroMQ Guide Chap. 6]:  http://zguide.zeromq.org/php:chapter6 
> >>> 
> >>>  John 
> >>> 
>

-- 
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] Border between Machinekit-HAL and Machinekit-CNC

[John Morris]

You're right, Machinekit has been more about HAL than the EMC application on 
top of it, although @machinekoder's `mkwrapper` and QtQuickVCP are major 
innovations in Machinekit that straddle that boundary.

For me the split is not a major architectural change, but rather to split out 
HAL to showcase it as an independent entity on which other applications can be 
built atop.  EMC is one such application, and I've worked on other 
applications, such as a ROS integration and an autoclave control.

The split conveys other advantages, as well.  For non-CNC applications, the 
separate mk-hal code base is lightweight:  faster to build, smaller, fewer 
dependencies.  I'm also hoping the split provides an opportunity to pull back 
in the many improvements made over the years on the EMC side in the LinuxCNC 
project, since Machinekit hasn't kept up with those changes.

Understand that my opinion doesn't necessarily reflect the general community 
consensus.  I'm jumping in to help out with this work because I think it's been 
sorely needed for a long time, and I'm super excited to see people stepping up 
to sort out this extremely tedious but IMO valuable change.

John



From: machinekit@googlegroups.com  on behalf of 
c...@tuta.io 
Sent: Sunday, March 31, 2019 8:45 AM
To: Machinekit
Subject: [Machinekit] Border between Machinekit-HAL and Machinekit-CNC

Been looking into the distinction of Machinekit-HAL and Machinekit-CNC 
repositories and so far what I can tell the Machinekit-HAL is perfectly happy 
to run on its own but the Machinekit-CNC needs as a prerequisite the 
Machinekit-HAL. I also see that the majority of work done in Machinekit as a 
fork of LinuxCNC was about the HAL layer, so it's possible to say that 
Machinekit is more Machinekit-HAL than Machinekit-CNC. What I would like to 
know is what's the end game of splitting?

If it is intended for Machinekit-CNC to forever require the Machinekit-HAL or 
if there is push for these two projects to be independent - i.e. if it's to be 
possible to install only Machinekit-CNC and talk to Machinekit-HAL on a 
different machine (or even the same machine) over the application bus? (As 
opposed by the RT-capable field bus, what I call application bus is the higher 
level messaging protocols and connected services like Machinetalk, HALtalk, and 
whatnot.) Application bus which does not care if it's interprocess or 
off-system.

I guess that the motion (and other) component would then need to be split into 
several parts (but then it is unyielding blob anyway), one RT HAL side and 
other not-RT. Would the current ring buffer FIFO be enough to facilitate the 
distinction? (Given one example is given as the streamer-hal_streamer 
component, it should.)

The question is not if somebody is going to develop it but what the authors of 
the split would like IT to be. (Something like these ZeroMQ RFCs which are so 
popular here.)

(For example, it could be possible to then develop and configure the system so 
the MACH3/4 would be the Machinekit-CNC and Machinekit-HAL would function as 
the SmoothStepper or CSMIO/IP-A real-time controller. Not that I am interested 
in it, just an example of how my thoughts go.)

--
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<mailto: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] Remap M6 in python

[John Morris]

Python functions may have `return` for regular functions or `yield` for 
generator functions, but not both.

John


From: machinekit@googlegroups.com  on behalf of 
Bob Bevins 
Sent: Wednesday, March 20, 2019 8:59 PM
To: Machinekit
Subject: [Machinekit] Remap M6 in python

Hi guys,

If I am out of line here with linuxcnc please let me know. I dont want to step 
on anyone's toes but I need to ask.

I have a machine with three spindles, only using one, and 33 drop drills on one 
motor and 9 horizontal drills. It is a big commercial Biesse 346 router.

I remapped M6 with pure python, and everything seems to work. A few issues that 
I had to work around:

The change epilog I cannot get to run unless it is in the remap body itself. So 
I just use  REMAP=M6 modalgroup=6 python=M^_Remap_BiesseRover346  in the ini.
I run the change_epilog1 as a funtion inside the remap. This works everytime 
without any issues as far as I can see.
The only way I can get epilog commands working re: emccanon_CHANGE_TOOL, 
set_tool_parameters() and toolchange_flag is to put them inside the remap body. 
If I try
to put them in a function in the remap file they wont run.

Everything is working now as I seem to have pacified the interpreter but, I 
cannot run any yield's. IT spits something about not being a generator.
I am a bit worried because I am not letting the ionterpreter catch up on a 
queuebuster.

Here is my code. https://github.com/bobbevins/Linuxcnc_python_remap_M6

What are your thoughts?

Thanks,

Bob


--
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<mailto: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] Mesa 6i25 & 7i76 - Operation not permitted with new Machinekit Version

[John Morris]

Dennis, I think I have a fix in the below branch.  If you could give it a test 
before I submit a PR, I'd be grateful.

https://github.com/zultron/machinekit/tree/pr-fix-hm2-pci

I'd also appreciate if you could paste the contents of your Mesa card's PCI 
resource file:

/sys/devices/pci:00/:00:1c.2/:02:00.0/:03:00.0/resource

Thanks again for doing all the legwork to track down this problem.  It was easy 
to fix with that hard part done for me.

John


From: schoone...@gmail.com 
Sent: Friday, March 8, 2019 7:23 PM
To: John Morris; machinekit@googlegroups.com; destra...@gmail.com
Subject: Re: [Machinekit] Mesa 6i25 & 7i76 - Operation not permitted with new 
Machinekit Version


On 08/03/19 09:28, John Morris wrote:
> If I'd double-checked e207745, it would've been clear what was wrong:  L3 
> should have stayed as ULL.  D'oh!
>
> Mick, I'd like to revert your commit 730837e, address all problems, and 
> submit a PR.  Of course e207745 caused the problem Dennis encountered, and I 
> have a fix for it.  However, it doesn't explain why it reverts b55b544 (or 
> more likely I'm missing something).  What's the problem there?
No specific problem, looked like that was the other bit of code which
threw a warning reading the same data
so I just reverted it back as was.

Since I had reverted to the old values in one, I expected it to error
looking for the new value in the other.

Was easier just to revert the associated commits, than find that whilst
it built (albeit with warnings)
haltalk could not make any sense of the data passed.
>
> No, I'm not looking forward to silencing warnings in gcc 8.  ;(
>
>  John
>
> 
> From: schoone...@gmail.com 
> Sent: Thursday, March 7, 2019 5:35 PM
> To: John Morris; machinekit@googlegroups.com
> Subject: Re: [Machinekit] Mesa 6i25 & 7i76 - Operation not permitted with new 
> Machinekit Version
>
>
> On 07/03/19 07:19, John Morris wrote:
>> Ugh, sorry for introducing this problem, and thanks for everyone's help 
>> figuring it out.
> One of those things John, if you don't do anything, you will never make
> a mistake :)
>> I think it's important to fix compiler warnings.  When fixing these 
>> warnings, I found a couple of instances where the warnings actually pointed 
>> out real bugs.  Warnings help me in my own development, and it's hard to see 
>> them in a haystack of other, unrelated warnings in the code (clean build log 
>> output was one of my motivations to fix the warnings in the first place).  I 
>> bet there are other good reasons for fixing them.  Am I alone on this one?
> The fixes are good, allows for a much cleaner build.  Also picks up on
> sloppy coding style etc. where real problems can lurk.
>> I'll fix this one properly so we can turn `-Werror` back on.  I'll also take 
>> a look at Buster builds down the road when I actually start using it, if 
>> others think fixing warnings is worthwhile; if not, I won't fight the 
>> current.
> Thanks, it will work perfectly well in the interim, don't worry until
> you have the time.
>
> Every increment of gcc seems to bring stricter standards adherence and
> hence more warnings.
>
> This has been beneficial in the past, where for instance we realised
> that a maths library appeared to have been written in C by a python
> programmer,
> because a whole group of conditional operations were indented but not
> within parenthesis, meaning only the first line was conditional and
> every other
> line was executed whatever the outcome of the conditional test.
> That situation appeared to have existed in linuxcnc also, for many years.
>
> I will wait for you to discover the wonders of gcc 8.xx for yourself and
> see if you can live with them :D
>
>>   John
>>
>> 
>> From: machinekit@googlegroups.com  on behalf of 
>> schoone...@gmail.com 
>> Sent: Wednesday, March 6, 2019 10:32 PM
>> To: machinekit@googlegroups.com
>> Subject: Re: [Machinekit] Mesa 6i25 & 7i76 - Operation not permitted with 
>> new Machinekit Version
>>
>> Yes, I read something very similar on stackoverflow Charles.
>> It is probably the way to go, certainly to test out.
>>
>> As I didn't have the ability right now to test on real hardware,
>> I just reverted to be safe.
>>
>> The warnings issue on Jessie and Stretch is as nothing to what is to come
>> in Buster with gcc 8.xx
>>
>> There are some pretty intractable warnings due to the coding style in our
>> legacy code, where buffers are allocated to a defined length
>> and then a subsequent strncpy() or whatever is fixed

Re: [Machinekit] Mesa 6i25 & 7i76 - Operation not permitted with new Machinekit Version

[John Morris]

If I'd double-checked e207745, it would've been clear what was wrong:  L3 
should have stayed as ULL.  D'oh!

Mick, I'd like to revert your commit 730837e, address all problems, and submit 
a PR.  Of course e207745 caused the problem Dennis encountered, and I have a 
fix for it.  However, it doesn't explain why it reverts b55b544 (or more likely 
I'm missing something).  What's the problem there?

No, I'm not looking forward to silencing warnings in gcc 8.  ;(

John


From: schoone...@gmail.com 
Sent: Thursday, March 7, 2019 5:35 PM
To: John Morris; machinekit@googlegroups.com
Subject: Re: [Machinekit] Mesa 6i25 & 7i76 - Operation not permitted with new 
Machinekit Version


On 07/03/19 07:19, John Morris wrote:
> Ugh, sorry for introducing this problem, and thanks for everyone's help 
> figuring it out.
One of those things John, if you don't do anything, you will never make
a mistake :)
>
> I think it's important to fix compiler warnings.  When fixing these warnings, 
> I found a couple of instances where the warnings actually pointed out real 
> bugs.  Warnings help me in my own development, and it's hard to see them in a 
> haystack of other, unrelated warnings in the code (clean build log output was 
> one of my motivations to fix the warnings in the first place).  I bet there 
> are other good reasons for fixing them.  Am I alone on this one?
The fixes are good, allows for a much cleaner build.  Also picks up on
sloppy coding style etc. where real problems can lurk.
>
> I'll fix this one properly so we can turn `-Werror` back on.  I'll also take 
> a look at Buster builds down the road when I actually start using it, if 
> others think fixing warnings is worthwhile; if not, I won't fight the current.
Thanks, it will work perfectly well in the interim, don't worry until
you have the time.

Every increment of gcc seems to bring stricter standards adherence and
hence more warnings.

This has been beneficial in the past, where for instance we realised
that a maths library appeared to have been written in C by a python
programmer,
because a whole group of conditional operations were indented but not
within parenthesis, meaning only the first line was conditional and
every other
line was executed whatever the outcome of the conditional test.
That situation appeared to have existed in linuxcnc also, for many years.

I will wait for you to discover the wonders of gcc 8.xx for yourself and
see if you can live with them :D

>
>  John
>
> 
> From: machinekit@googlegroups.com  on behalf of 
> schoone...@gmail.com 
> Sent: Wednesday, March 6, 2019 10:32 PM
> To: machinekit@googlegroups.com
> Subject: Re: [Machinekit] Mesa 6i25 & 7i76 - Operation not permitted with new 
> Machinekit Version
>
> Yes, I read something very similar on stackoverflow Charles.
> It is probably the way to go, certainly to test out.
>
> As I didn't have the ability right now to test on real hardware,
> I just reverted to be safe.
>
> The warnings issue on Jessie and Stretch is as nothing to what is to come
> in Buster with gcc 8.xx
>
> There are some pretty intractable warnings due to the coding style in our
> legacy code, where buffers are allocated to a defined length
> and then a subsequent strncpy() or whatever is fixed to that same
> defined length.
>
> The later version of gcc will both warn of potential buffer overflow and of
> potential data truncation, even if neither are possible in that instance.
>
> Removing those, if ever deemed worth spending time on, will mean re-writing
> a lot of code, possibly with some quite clunky stuff.
>
>
> On 06/03/19 14:08, Charles Steinkuehler wrote:
>> On 3/6/2019 5:30 AM, schoone...@gmail.com wrote:
>>> It essentially comes down to 32 bit and 64 bit differences in data type 
>>> size.
>>> If you then specify a format size in a printf operation, it will always 
>>> generate
>>> a warning under one architecture or another.
>>> Assigning with a (void*) cast, will do so too, hence the making of L1 and L2
>>> void * probably
>> I don't have time to test this in Machinekit, but I've solved these
>> sort of issues using the intptr_t data type (which changes size based
>> on the architecture), so something like:
>>
>> unsigned intptr_t L1, L2;
>> unsigned long L3;
>>
>> Another option (since intptr_t isn't guaranteed to be available and
>> I'm not 100% the pointer casts required for fscanf wouldn't throw a
>> warning) is to make a union and overlap a pointer with an integer
>> type, eg:
>>
>> union foo {
>>   unsigned long long foo_long;
>>   void *foo_ptr;
>> }
>>
>> ...t

Re: [Machinekit] Mesa 6i25 & 7i76 - Operation not permitted with new Machinekit Version

[John Morris]

Ugh, sorry for introducing this problem, and thanks for everyone's help 
figuring it out.

I think it's important to fix compiler warnings.  When fixing these warnings, I 
found a couple of instances where the warnings actually pointed out real bugs.  
Warnings help me in my own development, and it's hard to see them in a haystack 
of other, unrelated warnings in the code (clean build log output was one of my 
motivations to fix the warnings in the first place).  I bet there are other 
good reasons for fixing them.  Am I alone on this one?

I'll fix this one properly so we can turn `-Werror` back on.  I'll also take a 
look at Buster builds down the road when I actually start using it, if others 
think fixing warnings is worthwhile; if not, I won't fight the current.

John


From: machinekit@googlegroups.com  on behalf of 
schoone...@gmail.com 
Sent: Wednesday, March 6, 2019 10:32 PM
To: machinekit@googlegroups.com
Subject: Re: [Machinekit] Mesa 6i25 & 7i76 - Operation not permitted with new 
Machinekit Version

Yes, I read something very similar on stackoverflow Charles.
It is probably the way to go, certainly to test out.

As I didn't have the ability right now to test on real hardware,
I just reverted to be safe.

The warnings issue on Jessie and Stretch is as nothing to what is to come
in Buster with gcc 8.xx

There are some pretty intractable warnings due to the coding style in our
legacy code, where buffers are allocated to a defined length
and then a subsequent strncpy() or whatever is fixed to that same
defined length.

The later version of gcc will both warn of potential buffer overflow and of
potential data truncation, even if neither are possible in that instance.

Removing those, if ever deemed worth spending time on, will mean re-writing
a lot of code, possibly with some quite clunky stuff.


On 06/03/19 14:08, Charles Steinkuehler wrote:
> On 3/6/2019 5:30 AM, schoone...@gmail.com wrote:
>> It essentially comes down to 32 bit and 64 bit differences in data type size.
>> If you then specify a format size in a printf operation, it will always 
>> generate
>> a warning under one architecture or another.
>> Assigning with a (void*) cast, will do so too, hence the making of L1 and L2
>> void * probably
> I don't have time to test this in Machinekit, but I've solved these
> sort of issues using the intptr_t data type (which changes size based
> on the architecture), so something like:
>
>unsigned intptr_t L1, L2;
>unsigned long L3;
>
> Another option (since intptr_t isn't guaranteed to be available and
> I'm not 100% the pointer casts required for fscanf wouldn't throw a
> warning) is to make a union and overlap a pointer with an integer
> type, eg:
>
>union foo {
>  unsigned long long foo_long;
>  void *foo_ptr;
>}
>
> ...then use the appropriate type where needed.
>

--
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] I'm pulling my hair out over this, "Can't add linear move at line xxxx, error code -7"

[john]

Hi Rob,

Thanks for taking a look! Perhaps this information could help you get a 
predictable case set up. While testing, I'm able to always reproduce the 
error -7 when my [AXIS_0]HOME_OFFSET is set to 2.7499, [AXIS_0]HOME set to 
2.5 and a program that simply moves to 2.5 in X:

%
G0 X2.5
%

The error that is produced in /var/log/linuxcnc.log:
user line can't have zero length! xyz start = 
2.50007435e+00,2.4910e+00,-2.559125863375e-10, end = 
2.5000e+00,2.4910e+00,-2.559125863375e-10

-John


On Thursday, January 24, 2019 at 12:33:02 PM UTC-7, Robert Ellenberg wrote:
>
> Hi John,
>
> I'm taking another look at this now, and seeing some weird behavior with 
> the example NGC file in LinuxCNC 2.7.x too (hits an acceleration violation 
> in the A axis around line 1600). I suspect that there is an issue with the 
> floating point comparisons as well, in particular since LinuxCNC handles 
> the case of rotary + linear motion differently than a pure rotary motion. 
> As such, a motion that has some rotary motion and a pathologically small 
> linear motion could be triggering the problem. I don't currently have a 
> machinekit build on my dev PC, but I will set one up and do further testing 
> in simulation shortly.
>
> Best,
> Rob
>
> On Thu, Jan 24, 2019 at 10:26 AM > wrote:
>
>> Hey Robert,
>>
>> Have you had a chance to look at this any closer? We hit this error 100% 
>> of the time on the Pocket NC for specific values of various HOME_OFFSETs 
>> (our current solution is to tweak those values by .0001" until the error 
>> goes away). The error occurs immediately after pressing the run button on 
>> any program after homing the machine. Any jogging before running the 
>> program and it runs fine. I've done a little digging into the code base to 
>> see what could be causing the issue, but don't have a good enough sense of 
>> the overall flow of data. Any insights would be appreciated. I've located 
>> several floating point equality comparisons that would result in a more 
>> precise comparison than the 1e-20 the trajectory planner is comparing 
>> against, but haven't had any luck when changing from direct equality (or 
>> inequality) operations to a difference comparison (i.e. changing x == y to 
>> abs(x-y) < epsilon).
>>
>> Here are a few places I've tried adjusting:
>>
>> https://github.com/machinekit/machinekit/blob/1dfa0045ba95fd68e744826d684efa513cbffa97/src/emc/motion/control.c#L449
>>
>> https://github.com/machinekit/machinekit/blob/1dfa0045ba95fd68e744826d684efa513cbffa97/src/emc/rs274ngc/interp_convert.cc#L2465
>>  
>> (and several other similar instances in that same file)
>>
>> https://github.com/machinekit/machinekit/blob/1dfa0045ba95fd68e744826d684efa513cbffa97/src/emc/nml_intf/canon_position.cc#L73
>>  
>> (as well as !=)
>>
>> I don't know the best way to go about debugging this. Do you know how I 
>> could find where the zero length moves are being added to the trajectory 
>> planner and what normally prevents that from happening? 
>>
>> Yours and Schooner's insights have been helpful so far. Maybe we can work 
>> together to figure out what is going on.
>>
>> -John
>>
>> On Saturday, February 25, 2017 at 1:16:32 PM UTC-7, Robert Ellenberg 
>> wrote:
>>>
>>> Hi All,
>>>
>>> My guess is that this is a mismatch between canon and the TP in how a 
>>> zero length segment is defined. I recall running into a similar issue with 
>>> LinuxCNC. If we're lucky, it's been fixed already in another branch and 
>>> it's a matter of porting the fix over to Machinekit. I'll take a look this 
>>> weekend.
>>>
>>> Best,
>>> Rob
>>>
>>> On Sat, Feb 25, 2017 at 10:08 AM schoo...@btinternet.com <
>>> schoo...@btinternet.com> wrote:
>>>
>>>>
>>>> On 25/02/17 11:47, schoo...@btinternet.com wrote:
>>>>
>>>>
>>>> On 25/02/17 07:55, icecube45 wrote:
>>>>
>>>> It's seemingly a different line each time I run the file, this time it 
>>>> was line 20462, which is either the middle of 
>>>>
>>>>> G1 X-9.794 Y-69.769 A29.4549
>>>>>
>>>>> G1 X-10.971 Y-71.809 A29.5489
>>>>>
>>>>> G1 X-13.951 Y-71.809 A29.6678
>>>>>
>>>>> or the middle of 
>>>>
>>>>>  
>>>>
>>>> G1 X31.776 Y-64.609 A48.9986
>>>>
>>>> G1 X34.755 Y-64.609 A49.1175
>>>>
>>>> G1 X35.933 

Re: [Machinekit] I'm pulling my hair out over this, "Can't add linear move at line xxxx, error code -7"

[john]

Hi Rob,

Thanks for taking a look! Here's some information that hopefully will get 
you a predictable test case. I can reliably create the error -7 by setting 
my [AXIS_0]HOME_OFFSET to 2.7499, my [AXIS_0]HOME to 2.5 and running a 
program that simply moves to X 2.5:

%
G0 X2.5
%

-John

-- 
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] I'm pulling my hair out over this, "Can't add linear move at line xxxx, error code -7"

[john]

Hey Robert,

Have you had a chance to look at this any closer? We hit this error 100% of 
the time on the Pocket NC for specific values of various HOME_OFFSETs (our 
current solution is to tweak those values by .0001" until the error goes 
away). The error occurs immediately after pressing the run button on any 
program after homing the machine. Any jogging before running the program 
and it runs fine. I've done a little digging into the code base to see what 
could be causing the issue, but don't have a good enough sense of the 
overall flow of data. Any insights would be appreciated. I've located 
several floating point equality comparisons that would result in a more 
precise comparison than the 1e-20 the trajectory planner is comparing 
against, but haven't had any luck when changing from direct equality (or 
inequality) operations to a difference comparison (i.e. changing x == y to 
abs(x-y) < epsilon).

Here are a few places I've tried adjusting:
https://github.com/machinekit/machinekit/blob/1dfa0045ba95fd68e744826d684efa513cbffa97/src/emc/motion/control.c#L449
https://github.com/machinekit/machinekit/blob/1dfa0045ba95fd68e744826d684efa513cbffa97/src/emc/rs274ngc/interp_convert.cc#L2465
 
(and several other similar instances in that same file)
https://github.com/machinekit/machinekit/blob/1dfa0045ba95fd68e744826d684efa513cbffa97/src/emc/nml_intf/canon_position.cc#L73
 
(as well as !=)

I don't know the best way to go about debugging this. Do you know how I 
could find where the zero length moves are being added to the trajectory 
planner and what normally prevents that from happening? 

Yours and Schooner's insights have been helpful so far. Maybe we can work 
together to figure out what is going on.

-John

On Saturday, February 25, 2017 at 1:16:32 PM UTC-7, Robert Ellenberg wrote:
>
> Hi All,
>
> My guess is that this is a mismatch between canon and the TP in how a zero 
> length segment is defined. I recall running into a similar issue with 
> LinuxCNC. If we're lucky, it's been fixed already in another branch and 
> it's a matter of porting the fix over to Machinekit. I'll take a look this 
> weekend.
>
> Best,
> Rob
>
> On Sat, Feb 25, 2017 at 10:08 AM schoo...@btinternet.com  <
> schoo...@btinternet.com > wrote:
>
>>
>> On 25/02/17 11:47, schoo...@btinternet.com  wrote:
>>
>>
>> On 25/02/17 07:55, icecube45 wrote:
>>
>> It's seemingly a different line each time I run the file, this time it 
>> was line 20462, which is either the middle of 
>>
>>> G1 X-9.794 Y-69.769 A29.4549
>>>
>>> G1 X-10.971 Y-71.809 A29.5489
>>>
>>> G1 X-13.951 Y-71.809 A29.6678
>>>
>>> or the middle of 
>>
>>>  
>>
>> G1 X31.776 Y-64.609 A48.9986
>>
>> G1 X34.755 Y-64.609 A49.1175
>>
>> G1 X35.933 Y-62.569 A49.2115
>>
>>
>> defendant on if comments count as lines or not.. 
>> Nothing seems out of the ordinary here, which is why I'm so confused.
>>
>>
>> The error is defined as TP_ERR_ZERO_LENGTH
>>
>> https://github.com/machinekit/machinekit/blob/master/src/emc/tp/tp_types.h#L61
>>
>> The trajectory planner is dark magic with which I have no particular 
>> familiarity.
>> It was certainly not developed to squirt plastic in tens of thousands of 
>> extremely small moves.
>>
>> My only guess might be that depending upon what blending settings you 
>> have, it may not recognise  a commanded move(s) as
>> any sort of move at all.
>> But I could be completely wrong.
>>
>> Hopefully Robert or someone with more knowledge will chime in.
>>
>>
>> Just to flesh this out a bit
>>
>> This is the code which is throwing the error
>> https://github.com/machinekit/machinekit/blob/master/src/emc/tp/tp.c#L1937
>>
>> if (tc.target < TP_POS_EPSILON) {
>> rtapi_print_msg(RTAPI_MSG_DBG,"failed to create line id %d, 
>> zero-length segment\n",tp->nextId);
>> return TP_ERR_ZERO_LENGTH;
>> }
>>
>> If you switched on debugging, you should see this message in 
>> /var/log/linuxcnc.log
>>
>> This is why I am surmising that an extremely small move, with some 
>> rounding down from the tp settings, 
>> could be causing the error.
>>
>> TP_POS_EPSILON is defined here
>>
>> https://github.com/machinekit/machinekit/blob/master/src/emc/tp/tp_types.h#L44
>> as 1e-12 ( which is 10 to -12 or 0.000 000 000 001 !! )
>>
>> Why this is occurring I don't know, but you can switch on debugging and 
>> confirm that this is indeed the bit causing it.
>>
>> You can also switch off blending (G64 P0) or adjust the blend toler

[Machinekit] Help request for development PC to use Cetus

[fairbanks-john]

 

I’m a little confused on how to interface the Cetus gui with Machinekit on 
my new Linux based development PC on which I have already installed 
Machinekit as run in place.  I’m running on Linux Mint 18.3 with kernel 
4.9.98-RT. The Machinekit appears to be running fine and I have down loaded 
Cetus, MachinekitSDk, QTQuickvcp, Machinekit-Client and free version of QT5 
via web install.

 

I would like to get Cetus working and plan to use as a good starting and 
learning point to be able to develop in QT. Unfortunately I do not fully 
understand how to get all the pieces that I down loaded to function as a 
working system on in my Linux Mint PC right now. It appears to be a 
somewhat complicated process.

  

My Linux based development PC is attached via a dedicated network to an 
ACRA milling machine which uses a Mesa pre-programmed 7i80 FPGA interface 
card. Machinekit running on this PC is connecting to the mesa card and able 
to get status info from the card inputs via HalShow.

 

I will continue to try to get this PC configured on my own, but does anyone 
have available some rough information or guide on the best way to get the 
various pieces that I downloaded talking to each other on the PC?  I think 
that some information that I'm trying to use may not be meant to be used 
for configuring a PC.


After I get everything working on the Linux based PC then I plan to work on 
my Windows7  based development machine which is not ready to use yet. I 
plan to use for testing Cetus and other GUI's remotely and also for Qt5 
future GUI development work. I have on hand a Raspberry PI-3 and may also 
use it later for future work as time allows.

-- 
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] Machinekit logging on Linux Mint 18.3

[fairbanks-john]

I have been setting up a new development system using Mint 18.3 and also a 
Windows box using Win7 and have noticed that there is a problem getting 
Machinekit logging working properly on Mint every time 'sudo make setuid' 
is run. So  to help others here is my consolidated fix to overcome this.

To get Machinekit logging working in Linux Mint first edit system file as 
root: /etc/rsyslog.conf
You can open terminal as root and use text editer.
Comment out:
 
$PrivDropToUser syslog
$PrivDropToGroup syslog

Like this:
#$PrivDropToUser syslog
#$PrivDropToGroup syslog

Then save the file and send:
sudo service rsyslog restart

If you are receiving logging error messages while running the 'sudo make 
setuid' command the next commands may be needed.
To generate a missing '/var/log/linuxcnc.log' file send command:

sudo touch /var/log/linuxcnc.log

Linux Mint uses rsyslogd instead of the older syslogd. To route log data to 
the newly generated linuxcnc.log file we must first copy the machinekit 
rtapi/rsyslogd-linuxcnc.conf configuration file to the systems 
/etc/rsyslogd folder.

sudo cp rtapi/rsyslogd-linuxcnc.conf /etc/rsyslog.d/linuxcnc.conf
sudo service rsyslog restart

On rate limit error message 'No rate limit in rsyslogd is set':
Run this copy command.

sudo cp rtapi/shmdrv/limits.d-machinekit.conf 
/etc/security/limits.d/machinekit.conf

-- 
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] Output Pulse on Start Up

[John Dammeyer]

I think I'm just too quick for it.  Just because axis.ngc is gone off the 
screen apparently doesn't mean that MachineKit is done.  

So editing a .hal or .ini file, saving the file, closing axis and then 
clicking on the desktop icon to restart machine kit results in this error.  
If I wait 30 seconds or more then I don't get the issue.

Why it takes so long I don't know.

John
  

On Friday, May 18, 2018 at 10:55:07 PM UTC-7, Schooner wrote:

> The problem with this run is right at the beginning of the error print.
>
> rtapi/rtapi_msgd.cc:247 ERROR: found existing RT instance with the same 
> instance id (0)
>
>
> Your last run did not close down properly and when it tried to create a 
> new one found the instance number already in use
> Linuxcnc was never conceived as being able to run more than a single 
> instance, so the numbers tend to be the same every time which is how this 
> error shows.
>
> Why it isn't closing down properly is another matter. 
>
> On 5/19/2018 5:18 AM, John Dammeyer wrote:
>
> I'm running a BBB with Xylotex BBB-DB25/26.  Often when I start up 
> MachineKit I get the opening banner, it vanishes and then a minute or so 
> later pops up with an error window.  Attached is the dump.  I can restart 
> and MachineKit begins normally.  Or maybe it fails again and then runs 
> correctly the third time. 
>
> Also, the Xylotex uses the DB25-1 pin as IOPWR# which is an active low 
> signal coupled through the ESTOP switch to DB25-10.  I've added a pull up 
> resistor to DB25-1 and it's coupled to an active low Relay Driver circuit.  
> The relay connects the ESTOP DB25-10 input to ground.
>
> When MachineKit starts properly it blips the DB25-1 pin low for about one 
> second before it finishes starting up and then keeps that output off (at 
> +5V) until the ON button is clicked.  And if the ESTOP button or ESTOP or 
> LIMIT switches are activated the IOPWR# also returns high and the relay 
> goes off.  So everything works correctly except for the pulse on the IOPWR# 
> pin when MachineKit starts up.  
>
> This does not happen when the Beagle boots from power up.  Only when the 
> Icon for MachineKit with my G3616 ini and hal file configuration is clicked 
> and MachineKit starts rather than fails.  When it fails and throws up the 
> log window the output is not blipped.
>
> I've mentioned them both because I don't know if they are related.
>
> Here's the failure.
> Loading Real Time OS, RTAPI, and HAL_LIB modules
> rtapi_msgd startup failed - aborting
>
> Debug file information:
> rtapi/rtapi_msgd.cc:247 ERROR: found existing RT instance with the same 
> instance id (0)
> /usr/libexec/linuxcnc/rtapi_msgd: failed to create global segment
> /usr/bin/linuxcnc: line 750:  3503 Segmentation fault  $HALCMD -i 
> "$INIFILE" -f $CFGFILE
>
>
> Is this perhaps as simple as an older version that just needs to be 
> updated?  If it's an error in the HAL file why doesn't it show up every 
> time?
>
> Thanks
>
>
> -- 
> 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] Re: Help requested with Mesa custom 7i80HD-25 bit file compatibility

[fairbanks-john]

Schooner in reference to your comment:

"I am confused by your use of 'remote'.  Gmoccapy is not a remote GUI, but 
you were using it.  
Are you just referring to accessing the controller machine remotely from 
another computer?

Or are you intending to use an actual remote interface via a loader and 
machinetalk, like Alex's Machineface or Cetus?"

Yes.

I have been working on a gui for a while to replace gmoccapy on linuxcnc 
and to be able to run it remotely. But it turns out that I would have use 
what I consider to be obsolete methods to accomplish that. My goal has thus 
changed and drifted away from linuxcnc and towards Machinekit and run the 
gui I'm working on remotely like Cetus. It may end up running on a touch 
screen laptop.

I'm familiar with and have used Labview for programming remote control 
application for a good number of years and thus my gui is coded in Labview. 
Unfortunately there is not much information on how to code protobuf related 
items in Labview so I will need to work that out. Labview has a Zeromq 
library so that is not problem. As an aid in getting to understand protobuf 
coding a bit better I could use Cetus and perhaps do a little network 
snooping to look at the bi-directional data exchanges to help understand 
the communication process.

About gmocappy on being a remote gui.

I used gmocappy only as a starting point to get Machinekit installed and do 
some preliminary testing and do not intend to keep using it. I use gmocappy 
on my linxcnc controlled  milling machine and thus anticipated that using 
it for testing would be simplest. That turned out to be a mistake due to 
differences in available gmocappy versions and axis/joint difference 
requirements between linuxcnc and Machinekit.

Gmocappy buttons:

I also believe that picture buttons on anything that controls machinery is 
a very bad idea based on my own experience with working on past NASA 
related projects. Plainly marked buttons of a size suitable for a touch 
screen are fine. But finger tip size is not the same for everyone so touch 
screen buttons tend to grow larger and take up a large amount of screen 
area. To save screen area pull down menus excel but in general they do not 
use buttons and thus are not really suitable for touch screens. Touch 
screens however can use pop up button panels instead for selected items to 
save screen area and allow for added functionality.


-- 
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] Re: Guidance on 3 axis retrofit

[John Dammeyer]

>
>
> 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!
>

I'm doing something similar but with a Xylotex BBB-DB25/26 cape connected 
to a Probotix  PB-RF.  I have two of the axis running in this short clip.  

https://youtu.be/9GF709ZfLRQ

The X axis hardware is complete but I need to bundle everything together 
and wire up limit switches.  

 

-- 
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] Output Pulse on Start Up

[John Dammeyer]

I'm running a BBB with Xylotex BBB-DB25/26.  Often when I start up 
MachineKit I get the opening banner, it vanishes and then a minute or so 
later pops up with an error window.  Attached is the dump.  I can restart 
and MachineKit begins normally.  Or maybe it fails again and then runs 
correctly the third time. 

Also, the Xylotex uses the DB25-1 pin as IOPWR# which is an active low 
signal coupled through the ESTOP switch to DB25-10.  I've added a pull up 
resistor to DB25-1 and it's coupled to an active low Relay Driver circuit.  
The relay connects the ESTOP DB25-10 input to ground.

When MachineKit starts properly it blips the DB25-1 pin low for about one 
second before it finishes starting up and then keeps that output off (at 
+5V) until the ON button is clicked.  And if the ESTOP button or ESTOP or 
LIMIT switches are activated the IOPWR# also returns high and the relay 
goes off.  So everything works correctly except for the pulse on the IOPWR# 
pin when MachineKit starts up.  

This does not happen when the Beagle boots from power up.  Only when the 
Icon for MachineKit with my G3616 ini and hal file configuration is clicked 
and MachineKit starts rather than fails.  When it fails and throws up the 
log window the output is not blipped.

I've mentioned them both because I don't know if they are related.

Here's the failure.
Loading Real Time OS, RTAPI, and HAL_LIB modules
rtapi_msgd startup failed - aborting

Debug file information:
rtapi/rtapi_msgd.cc:247 ERROR: found existing RT instance with the same 
instance id (0)
/usr/libexec/linuxcnc/rtapi_msgd: failed to create global segment
/usr/bin/linuxcnc: line 750:  3503 Segmentation fault  $HALCMD -i 
"$INIFILE" -f $CFGFILE


Is this perhaps as simple as an older version that just needs to be 
updated?  If it's an error in the HAL file why doesn't it show up every 
time?

Thanks


-- 
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.
Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/share/linuxcnc/tcl/msgs
INIVAR=/usr/libexec/linuxcnc/inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
MACHINEKIT - 0.1
Machine configuration directory is 
'/home/machinekit/machinekit/configs/ARM.BeagleBone.Xylotex'
Machine configuration file is 'XylotexG3616.ini'
INIFILE=/home/machinekit/machinekit/configs/ARM.BeagleBone.Xylotex/XylotexG3616.ini
PARAMETER_FILE=pru-stepper.var
TASK=milltask
HALUI=halui
DISPLAY=axis
Starting Machinekit...
Starting Machinekit server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
rtapi_msgd startup failed - aborting
Starting Machinekit IO program: io
io started
halcmd loadusr io started
Starting HAL User Interface program: halui
Shutting down and cleaning up Machinekit...
Killing task linuxcncsvr, PID=3411
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments
Cleanup done

Debug file information:
rtapi/rtapi_msgd.cc:247 ERROR: found existing RT instance with the same 
instance id (0)
/usr/libexec/linuxcnc/rtapi_msgd: failed to create global segment
/usr/bin/linuxcnc: line 750:  3503 Segmentation fault  $HALCMD -i 
"$INIFILE" -f $CFGFILE
3411
  PID TTY  STAT   TIME COMMAND
Stopping realtime threads
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: the msgd:0 logger demon is not running - please investigate 
/var/log/linuxcnc.log
Unloading hal components
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: the msgd:0 logger demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: the msgd:0 logger demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: the msgd:0 logger demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: cant 

[Machinekit] Help requested with Mesa custom 7i80HD-25 bit file compatibility

[fairbanks-john]

I have Machinekit running now as a run in place with no error but having 
issues correctly addressing pins in my Mesa 7i80HD-25 board.

To help resolve this problem I have attached my custom  PIN_CNC1_V1_72.vhd 
file which is human readable. My install of Machinekit is a cloned install 
from git hub and to be used for development work on Debian 9.4 Stretch.

In searching for info I read this:

From: http://www.machinekit.io/docs/drivers/hostmot2/#pin-files
=
PIN Files

"The default pinout is described in a .PIN file (human-readable text). When 
you install a firmware package the .PIN files are installed in
/usr/share/doc/hostmot2-firmware-/"

Firmware

The selected firmware (.BIT file) and configuration is uploaded from the PC 
motherboard to the Mesa mothercard on Machinekit startup. If you are using 
Run In Place, you must still install a hostmot2-firmware- package. 
There is more information about firmware and configuration in the 
'Configurations' section.



I don't understand: 

"If you are using Run In Place, you must still install a 
hostmot2-firmware- package."  Not sure if this would also apply to 
Ethernet connected boards.

>From this it appears that I may need to satisfy the above requirement, but 
have no information on how to do that.

"My board package" is a Mesa 7i80HD which is installed in a milling 
machine, has been flashed with my custom .pin file, has IP address 
10.10.10.2, and works fine with LCNC. Machinekit connects to the board but 
does not address the boards pins correctly. I did notice that the hm2_eth.c 
and hm2_eth.h driver in Machinekit are different from the LCNC version so I 
assume that Machinekit may handle or reading the boards configuration 
differently, or that the drivers may just be different versions. I have a 
second development 7i80HD-25 board with IP 10.10.10.3 with three associated 
pin-out/protection boards.

I'm stuck on proceeding to develop on Machinekit until I'm able to fix this 
problem. I have searched for more info but have not run into anything 
useful yet

I have attached a copy of the .vhd file in case somebody can point me in 
the right direction.

-- 
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.


PIN_CNC1_V1_72.vhd
Description: Binary data

[Machinekit] Re: Problem with new install errors, warnings and notes

[fairbanks-john]

Yes, It looks like I'm getting closer to having a working configuration 
that is getting close to being suitable for further testing and development 
work.

I did purchase a second Mesa 7i80 card and flashed it with my custom bit 
file so that I would not have to use the actual card and milling machine 
for some preliminary testing.
The machine itself uses and linuxcnc and gmocappy right now but both are 
planned to be switched out for Machinekit and my Labview based custom gui 
that I have partially completed. My next step will be to get the gui to 
interface with Machinekit via the network and hopefully be able to get 
status info to verify that the interface between Machinekit and my gui is 
working properly.  I'm thinking that the simulation that you suggested will 
work well for that.

Before proceeding further I do need to verify that I can control the 
milling machine properly with Machinekit with the machines own Mesa 7i80hd 
Ethernet card.

-- 
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] Re: Problem with new install errors, warnings and notes

[fairbanks-john]

Schooner I think that I pushed a wrong buttons while posting and messed 
things up a bit. I got a new computer and build a new configuration since I 
think the old machine may have gotten corrupted while attempting to solve 
issues. I will rebuild it later. Machine kit loadsrand runs now but I'm 
confused on how machinekit handles Mesa bit files. I have read that they 
need to be placed in a folder somewhere as a txt file which confuses me 
more since a bit file that is loaded into a Mesa FPGA board is not a text 
file.

Here are the steps I used to install this new installation using Debian 
9.4.0 stretch.

# Desktop computer with run in place
$ installed Debian 9.4.0 amd64 stretch cd1 free only version
$ su usermod -a -G sudo "my user name"
$ sudo apt-key adv --keyserver hkp://pool.sks-keyservers.net --recv 43DDF224
$ sudo sh -c "echo 'deb http://deb.machinekit.io/debian stretch main' > 
/etc/apt/sources.list.d/machinekit.list
$ sudo apt-get update
$ sudo apt-get install linux-image-rt-amd64
$ reboot
$ cd /home
$ git clone https://github.com/machinekit/machinekit.git machinekit-dev
  
===
# in machinekit-dev folder
$ debian/configure -r
$ sudo mk-build-deps -ir
# say yes to install depends
$ sudo apt-get install dirmngr
$ sudo apt-get install git dpkg-dev 
$ sudo apt-get install devscripts
$ sudo apt-get install python-avahi 
$ sudo apt-get install python-dbus python-dbus-dev python-dbus-dbg
# some in the above line may not be required
$ sudo apt-get install python-glade2 python-gtkglext1 python-gtksourceview2
$ sudo apt-get install python-vte
$ sudo apt-get install --no-install-recommends devscripts equivs
$ sudo apt-get install memlockd  # may not be required
# the above line may not be required
$ cd src
$ ./autogen.sh
$ ./configure --with-rt-preempt --enable-build-documentation
$ make clean  (only if needed to completely make fresh version)
$ make
$ sudo make setuid
$ ../scripts/check-system-configuration.sh
$ sudo cp rtapi/rsyslogd-linuxcnc.conf /etc/rsyslog.d/linuxcnc.conf
$ sudo service rsyslog restart
$ sudo cp rtapi/shmdrv/limits.d-machinekit.conf 
/etc/security/limits.d/machinekit.conf
$ sudo touch /var/log/linuxcnc.log
$ sudo service rsyslog restart
$ cd ..
$ . ./scripts/rip-environment
$ export DEBUG=5
$ machinekit /home/cnc/machinekit-dev/configs/cnc1/cnc1.ini

# gmoccapy gui comes up ok but its  version is too old to be usefull


-- 
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] Re: Problem with new install errors, warnings and notes

[fairbanks-john]

On Monday, May 14, 2018 at 11:29:45 PM UTC-8, fairbanks-john wrote:
>
> I just made a fresh install from the git hub clone today and wondering if 
> I did something wrong since there are a lot of warnings and notes in the 
> installation log which I have attached..
>  The .hal file I have used before for testing fails to complete loading at 
> the below error message:
>
> Traceback (most recent call last):
>   File "/home/cnc/machinekit-dev/bin/gmoccapy", line 30, in 
> import hal_glib   # needed to make our own hal pins
>   File "/home/cnc/machinekit-dev/lib/python/hal_glib.py", line 20, in 
> 
> from machinetalk.protobuf.message_pb2 import Container
>   File "build/bdist.linux-x86_64/egg/machinetalk/protobuf/message_pb2.py", 
> line 16, in 
>   File "build/bdist.linux-x86_64/egg/machinetalk/protobuf/nanopb_pb2.py", 
> line 26, in 
> TypeError: __init__() got an unexpected keyword argument 'syntax'
> Shutting down and cleaning up Machinekit...
>
> Last time I installed Machinekit I was able to load my .hal file but got 
> stuck on communications to the Ethernet Mesa 7180 board which is till and 
> issue for me but I do now have a additional board to try to load the bit 
> file in a different way. This new Machinekit  install is to  to be used to 
> work on the interface requirements for the Labview coded gui that I have 
> partially completed for use with Machinekit. I expect that my biggest 
> problem with be with the Protocol Buffers encoding/decoding since I do not 
> have a clear understanding about those methods yet.
>

-- 
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

[john]

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

[john]

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

[john]

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

[john]

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

[john]

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.

[Machinekit] using comp on latest kernel 3.8 MachineKit image

[john]

It looks like comp isn't installed on the latest MachineKit image based on 
the 3.8 linux kernel. How can I get comp on it for compiling a kinematics 
module?

-- 
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] Re: Xylotex BBB-DB25/26 and Limit verses Home switches.

[John Dammeyer]

There's more to it than just the .hal file.  The .ini file needs tweaking 
too.  The Search Velocity can't be 0.  A negative value is used when the 
home switch is in the direction of the '-' key.  That's the speed the motor 
moves to find and activate the home switch.  The LATCH velocity is the 
speed it moves off it again in the other direction until it deactivates.  I 
use activate and deactivate to represent the switch changing state.  In my 
case the switches are closed and the activate opens them. 

My Home switch is also shared with the Negative motion limit switch but not 
the Positive motion limit switch but the HOME_IGNORE_LIMITS means that when 
it is activated it's not a limit switch error.  And there's one home switch 
for each axis so I believe HOME_IS_SHARED means the switch is not shared 
with any other axis.  Theoretically that would send Z home first and then 
do X and Y together.

I was able to get all but the Z axis working and then spent several hours 
searching the web, trying to understand the HAL and figure out why DB25-13 
wasn't working connected to the Z axis switch.  The pin stayed low 
regardless of the state of the switch.  It didn't look like there was 
anything else pulling the line low.  So out came the magnifying glass, then 
some solder flux and the touch of an iron to re-solder what appeared to be 
a solder joint on the pull up resistor which was not actually connected to 
the pad.  Now the meter reliably read 10K from the pin to the 3.3V rail and 
once re-installed and Machinekit running I had a working Z axis.  Such a 
simple solution .

Oh and 
NO_FORCE_HOMING =  0
must be set to zero to have the system actually want to home.  I had it set 
to 1 earlier when I was testing the HP-UHU Servo drive with the BBB-DB25/26 
since I didn't have home switches.

HOME =  0.000
HOME_OFFSET =   0.00
HOME_SEARCH_VEL =   -.1
HOME_LATCH_VEL =0.2
HOME_IGNORE_LIMITS =YES
HOME_IS_SHARED =0
#HOME_SEQUENCE =2


On Wednesday, April 18, 2018 at 6:35:34 PM UTC-7, John Dammeyer wrote:
>
> Answering one of own questions I think...
>>
> From the Wiki for standard parallel port modified for the BBB and Xylotex 
> BBB-DB25/26:
>  
>
>> # connect DB25-11 to X home and min limit
>> net home-x bb_gpio.p8.in-10 => axis.0.home-sw-in axis.0.neg-lim-sw-in 
>>
> # connect DB25-12 to Y home and min limit
>> net home-y bb_gpio.p8.in-14 => axis.1.home-sw-in axis.1.neg-lim-sw-in
>>
>> # connect DB25-13 to Z home and min limit
>> net home-z bb_gpio.p8.in-18 => axis.2.home-sw-in axis.2.neg-lim-sw-in
>>
>> # connect DB25-15 to all three max limits
>> net XYZ-max-lim bb_gpio.p9.in-41 => axis.0.pos-lim-sw-in 
>> axis.1.pos-lim-sw-in axis.2.pos-lim-sw-in
>>
>>  
>>
>
> Theoretically the above should work.  More when I try 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.

[Machinekit] Xylotex BBB-DB25/26 and Limit verses Home switches.

[John Dammeyer]

With respect to limit switches the README for the BBB-DB-25/26 states:






*"This configuration drives a standard 4-axis system using the PRU forhigh 
speed step/dir pulse generation and a Xylotex BBB interface board.  
Theinterface board sets up the STEP/DIR/Limit as:XS-2, XD-3, XL-11, 
YS-4,YD-5, YL-12, ZS-6, ZD-7, ZL-13, AS-8, AD-9, AL-15The STOP Input is Pin 
10 and the Enable Input is Pin 1"*

*But the HAL file has the inputs configured as Home Switches. For example:*

*#(JP) Add home switch input on DB25-11*
* net home-x bb_gpio.p8.in-10 => axis.0.home-sw-in *

I'd like to put all the axis limit switches in series and run them into 
DB25-15 since the rotary axis doesn't have a limit or home switch and then 
assign that to limit switches for al axis.

I would provide a mechanical switch to override the limits so it's possible 
to move off a limit switch.  Or maybe there's a configuration way to ignore 
the limit.

Or is the general approach more like putting all the limit switches in 
series with the DB25-1 to DB25-10 connection in series with the ESTOP?

Then the momentary button is pressed to override and a jog button used to 
move back off the activated limit switch? 

Am I missing something or is there some sort of net limit-x bb_gpio.p ... 
statement that can be used?

Thanks
John



-- 
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

[john]

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

[john]

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.

[Machinekit] switching between kinematics modes in G code

[john]

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.

[Machinekit] Re: Rotary Axis on BBB and Xylotex BBB_DB25/26

[John Dammeyer]

>
> I'll answer my own question. I was searching through the HAL docs rather 
> than the ini docs.
>
 
http://www.machinekit.io/docs/config/ini_config/#sub:AXIS-section
In that document I found ANGULAR_UNITS = degrees and has nothing to do with 
NC code.  
*"'ANGULAR_UNITS = ' - Specifies the 'machine units' for rotational 
axes. Possible choices are 'deg', 'degree' (360 per circle), 'rad', 
'radian' (2pi per circle), 'grad', or 'gon' (400 per circle). This does not 
affect the angular units of NC code. In RS274NGC, A-, B- and C- words are 
always expressed in degrees."*
It doesn't state if the SCALE is a floating point number like 75,000 pulses 
per 360 degrees = 208.3 per 1 degree or if it has to be 208.

-- 
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.