Re: [Machinekit] Re: Native Compilation and Cloudsmith Repos...

[cern via Machinekit]

Feb 28, 2021, 01:15 by machinekit@googlegroups.com:

> Feb 28, 2021, 01:08 by machinekit@googlegroups.com:
>
>> OK,
>>
>> let's get the high ground overview and get the EMCApplication installed 
>> first on AMD64 system. Only after this is done and working, we will attack 
>> these other issues.
>>
>> I will use a Docker container, as it is easy to spin up and clean after, but 
>> feel free to try it on a normal install (Debian) too:
>>
>> First start Docker container with passed X11 socket and DISPLAY environment 
>> and DBUS socket for announcement:
>>
>> docker run -it --rm -e DISPLAY=${DISPLAY} -v 
>> /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket -v 
>> /tmp/.X11-unix:/tmp/.X11-unix -v /dev/dri:/dev/dri debian:buster bash -i
>>
>> In it prepare basic setup and test it with firefox:
>>
>> apt-get update
>> apt-get -y upgrade
>> apt-get install -y sudo
>> echo "ALL ALL = (ALL) NOPASSWD: ALL" >> /etc/sudoers
>> adduser mk
>> sudo apt-get install -y firefox-esr
>>
>> test with 'firefox' and you should see a firefox window appear of 
>> application running in 
>>
And, of course, I forgot to mention you need to switch to that non-root user 
(otherwise you cannot connect to the DISPLAY):

su mk
firefox

and the rest of commands


>>
>> Docker. Then install the prerequisites for Machinekit-HAL and EMCApplication:
>>
>> sudo apt-get install -y curl
>> curl -1sLf \
>>   
>> 'https://dl.cloudsmith.io/public/machinekit/machinekit/cfg/setup/bash.deb.sh'
>>  \
>>   | sudo -E bash
>> curl -1sLf \
>>   
>> 'https://dl.cloudsmith.io/public/machinekit/machinekit-hal/cfg/setup/bash.deb.sh'
>>  \
>>   | sudo -E bash
>> curl -1sLf \
>>   
>> 'https://dl.cloudsmith.io/public/machinekit/emcapplication/cfg/setup/bash.deb.sh'
>>  \
>>   | sudo -E bash
>>
>> Now we need to install that special solver we were talking about as standard 
>> Debian APT cannot solve the dependencies:
>>
>> sudo apt-get install -y apt-cudf
>>
>> and install EMCApplication:
>>
>> sudo apt-cudf-get --solver aspcud -o APT::Get::Assume-Yes=1 -o 
>> Debug::pkgProblemResolver=0 -o APT::Install-Recommends=0 install 
>> emcapplication
>>
> Even simple:
>
> sudo apt-cudf-get --solver aspcud install emcapplication
> should be enough.
>
> Cern.
>
>>
>> and then run:
>>
>> linuxcnc
>>
>> You then should be able to see a configuration selection window, select AXIS 
>> sim and run. You should see a basic simulation.
>>
>> Please confirm you can get it running.
>>
>> Cern.
>>
>>
>> Feb 27, 2021, 00:54 by fun...@gmail.com:
>>
>>> Hello,
>>>
>>> I few, quick references here...
>>>
>>> Would it be easier to make emcapplication once LinuxCNC is installed?
>>>
>>> Oh and...
>>>
>>> Is there a cure all outside of building the binaries from scratch?
>>>
>>> Seth
>>> On Wednesday, February 24, 2021 at 7:36:28 PM UTC-6 Mala Dies wrote:
>>>
>>>> Hello,
>>>>
>>>> I have been trying to install machinekit-hal and emcapplication. I got 
>>>> some pointers here and there...
>>>>
>>>> The issue is that emcapplication does not work in my eyes yet. 
>>>>
>>>> I have been unable to install it, compile it, and/or compile plus install 
>>>> it from Cloudsmith repositories. 
>>>>
>>>> So, machinekit-hal is done. I can run halcmd and halrun. This is not an 
>>>> issue.
>>>>
>>>> Does emcapplication work yet or still? I am in the middle of a build right 
>>>> now.
>>>>
>>>> I am installing the python2 libs. right now to handle the emcapplication 
>>>> dependencies.
>>>>
>>>> ...
>>>>
>>>> Also, I have quickly gotten the Cloudsmith repo. items for machinekit-hal 
>>>> and emcapplication if this will help. I can easily install the .deb 
>>>> packages w/:
>>>>
>>>>     sudo apt install ./*.deb.
>>>>
>>>> But...
>>>>
>>>> Will it work? Have you seen anything online about it working? I started an 
>>>> issue or error source for the emcapplication online on the >> github.com 
>>>> <http://github.com>>>  repo. but deleted it (as I am too way 

Re: [Machinekit] Re: Native Compilation and Cloudsmith Repos...

[cern via Machinekit]

Feb 28, 2021, 01:08 by machinekit@googlegroups.com:

> OK,
>
> let's get the high ground overview and get the EMCApplication installed first 
> on AMD64 system. Only after this is done and working, we will attack these 
> other issues.
>
> I will use a Docker container, as it is easy to spin up and clean after, but 
> feel free to try it on a normal install (Debian) too:
>
> First start Docker container with passed X11 socket and DISPLAY environment 
> and DBUS socket for announcement:
>
> docker run -it --rm -e DISPLAY=${DISPLAY} -v 
> /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket -v 
> /tmp/.X11-unix:/tmp/.X11-unix -v /dev/dri:/dev/dri debian:buster bash -i
>
> In it prepare basic setup and test it with firefox:
>
> apt-get update
> apt-get -y upgrade
> apt-get install -y sudo
> echo "ALL ALL = (ALL) NOPASSWD: ALL" >> /etc/sudoers
> adduser mk
> sudo apt-get install -y firefox-esr
>
> test with 'firefox' and you should see a firefox window appear of application 
> running in Docker. Then install the prerequisites for Machinekit-HAL and 
> EMCApplication:
>
> sudo apt-get install -y curl
> curl -1sLf \
>   
> 'https://dl.cloudsmith.io/public/machinekit/machinekit/cfg/setup/bash.deb.sh' 
> \
>   | sudo -E bash
> curl -1sLf \
>   
> 'https://dl.cloudsmith.io/public/machinekit/machinekit-hal/cfg/setup/bash.deb.sh'
>  \
>   | sudo -E bash
> curl -1sLf \
>   
> 'https://dl.cloudsmith.io/public/machinekit/emcapplication/cfg/setup/bash.deb.sh'
>  \
>   | sudo -E bash
>
> Now we need to install that special solver we were talking about as standard 
> Debian APT cannot solve the dependencies:
>
> sudo apt-get install -y apt-cudf
>
> and install EMCApplication:
>
> sudo apt-cudf-get --solver aspcud -o APT::Get::Assume-Yes=1 -o 
> Debug::pkgProblemResolver=0 -o APT::Install-Recommends=0 install 
> emcapplication
>
Even simple:

sudo apt-cudf-get --solver aspcud install emcapplication
should be enough.

Cern.

>
> and then run:
>
> linuxcnc
>
> You then should be able to see a configuration selection window, select AXIS 
> sim and run. You should see a basic simulation.
>
> Please confirm you can get it running.
>
> Cern.
>
>
> Feb 27, 2021, 00:54 by fun...@gmail.com:
>
>> Hello,
>>
>> I few, quick references here...
>>
>> Would it be easier to make emcapplication once LinuxCNC is installed?
>>
>> Oh and...
>>
>> Is there a cure all outside of building the binaries from scratch?
>>
>> Seth
>> On Wednesday, February 24, 2021 at 7:36:28 PM UTC-6 Mala Dies wrote:
>>
>>> Hello,
>>>
>>> I have been trying to install machinekit-hal and emcapplication. I got some 
>>> pointers here and there...
>>>
>>> The issue is that emcapplication does not work in my eyes yet. 
>>>
>>> I have been unable to install it, compile it, and/or compile plus install 
>>> it from Cloudsmith repositories. 
>>>
>>> So, machinekit-hal is done. I can run halcmd and halrun. This is not an 
>>> issue.
>>>
>>> Does emcapplication work yet or still? I am in the middle of a build right 
>>> now.
>>>
>>> I am installing the python2 libs. right now to handle the emcapplication 
>>> dependencies.
>>>
>>> ...
>>>
>>> Also, I have quickly gotten the Cloudsmith repo. items for machinekit-hal 
>>> and emcapplication if this will help. I can easily install the .deb 
>>> packages w/:
>>>
>>>     sudo apt install ./*.deb.
>>>
>>> But...
>>>
>>> Will it work? Have you seen anything online about it working? I started an 
>>> issue or error source for the emcapplication online on the >> github.com 
>>> <http://github.com>>>  repo. but deleted it (as I am too way unfamiliar 
>>> with this process so far).
>>>
>>> If you have any pointers for this: 
>>> linuxcnc-build-deps_2.9.0~pre0.23585.git42bf973af~buster_all.deb 
>>>
>>> Please let me know. It seems I keep getting this repo. .deb and it is not 
>>> allowing me, the machine/internet/machinekit compilation, to access the 
>>> updated version of machinekit-hal that is current. 
>>>
>>> Also:
>>>
>>> Adding a new item to changelog:
>>> =
>>> linuxcnc (2.9.0~pre0.23585.git42bf973af~buster) Buster; urgency=low
>>>
>>>   * Machinekit EMCApplicatio

Re: [Machinekit] Re: Native Compilation and Cloudsmith Repos...

[cern via Machinekit]

OK,

let's get the high ground overview and get the EMCApplication installed first 
on AMD64 system. Only after this is done and working, we will attack these 
other issues.

I will use a Docker container, as it is easy to spin up and clean after, but 
feel free to try it on a normal install (Debian) too:

First start Docker container with passed X11 socket and DISPLAY environment and 
DBUS socket for announcement:

docker run -it --rm -e DISPLAY=${DISPLAY} -v 
/var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket -v 
/tmp/.X11-unix:/tmp/.X11-unix -v /dev/dri:/dev/dri debian:buster bash -i

In it prepare basic setup and test it with firefox:

apt-get update
apt-get -y upgrade
apt-get install -y sudo
echo "ALL ALL = (ALL) NOPASSWD: ALL" >> /etc/sudoers
adduser mk
sudo apt-get install -y firefox-esr

test with 'firefox' and you should see a firefox window appear of application 
running in Docker. Then install the prerequisites for Machinekit-HAL and 
EMCApplication:

sudo apt-get install -y curl
curl -1sLf \
  'https://dl.cloudsmith.io/public/machinekit/machinekit/cfg/setup/bash.deb.sh' 
\
  | sudo -E bash
curl -1sLf \
  
'https://dl.cloudsmith.io/public/machinekit/machinekit-hal/cfg/setup/bash.deb.sh'
 \
  | sudo -E bash
curl -1sLf \
  
'https://dl.cloudsmith.io/public/machinekit/emcapplication/cfg/setup/bash.deb.sh'
 \
  | sudo -E bash

Now we need to install that special solver we were talking about as standard 
Debian APT cannot solve the dependencies:

sudo apt-get install -y apt-cudf

and install EMCApplication:

sudo apt-cudf-get --solver aspcud -o APT::Get::Assume-Yes=1 -o 
Debug::pkgProblemResolver=0 -o APT::Install-Recommends=0 install emcapplication

and then run:

linuxcnc

You then should be able to see a configuration selection window, select AXIS 
sim and run. You should see a basic simulation.

Please confirm you can get it running.

Cern.


Feb 27, 2021, 00:54 by fun...@gmail.com:

> Hello,
>
> I few, quick references here...
>
> Would it be easier to make emcapplication once LinuxCNC is installed?
>
> Oh and...
>
> Is there a cure all outside of building the binaries from scratch?
>
> Seth
> On Wednesday, February 24, 2021 at 7:36:28 PM UTC-6 Mala Dies wrote:
>
>> Hello,
>>
>> I have been trying to install machinekit-hal and emcapplication. I got some 
>> pointers here and there...
>>
>> The issue is that emcapplication does not work in my eyes yet. 
>>
>> I have been unable to install it, compile it, and/or compile plus install it 
>> from Cloudsmith repositories. 
>>
>> So, machinekit-hal is done. I can run halcmd and halrun. This is not an 
>> issue.
>>
>> Does emcapplication work yet or still? I am in the middle of a build right 
>> now.
>>
>> I am installing the python2 libs. right now to handle the emcapplication 
>> dependencies.
>>
>> ...
>>
>> Also, I have quickly gotten the Cloudsmith repo. items for machinekit-hal 
>> and emcapplication if this will help. I can easily install the .deb packages 
>> w/:
>>
>>     sudo apt install ./*.deb.
>>
>> But...
>>
>> Will it work? Have you seen anything online about it working? I started an 
>> issue or error source for the emcapplication online on the >> github.com 
>> <http://github.com>>>  repo. but deleted it (as I am too way unfamiliar with 
>> this process so far).
>>
>> If you have any pointers for this: 
>> linuxcnc-build-deps_2.9.0~pre0.23585.git42bf973af~buster_all.deb 
>>
>> Please let me know. It seems I keep getting this repo. .deb and it is not 
>> allowing me, the machine/internet/machinekit compilation, to access the 
>> updated version of machinekit-hal that is current. 
>>
>> Also:
>>
>> Adding a new item to changelog:
>> =
>> linuxcnc (2.9.0~pre0.23585.git42bf973af~buster) Buster; urgency=low
>>
>>   * Machinekit EMCApplication is build from LinuxCNC code, but is not part of
>>     LinuxCNC and as such the lower entries are NOT accurate
>>   * Commit: 42bf973af68d1ee4f18a3c43af15d49c0ea4bf54
>>   * Merge pull request #7 from cerna/merge-21-october-2020
>>   * Build as an 23585th rebuild for Debian Buster armhf
>>
>>  --  xxx <>> xx...@xxx.com <>>> >  Thu, 25 Feb 2021 01:04:49 
>> +
>> New package version number added to changelog
>> successfully configured for 'ext-hal-Debian-10'-'machinekit-hal'..
>>
>> The above pops up when I have a 'valid' install of this command:
>>
>> debian/configure machinekit-h

Re: [Machinekit] Re: any info on the spiPRU mentioned

[cern via Machinekit]

Feb 18, 2021, 23:44 by joonas.fors...@gmail.com:

> Realtime isn't about latency but determinism and the standard usb driver 
> stack is non-deterministic. I believe there are realtime capable stacks for 
> usb devices but it needs to be supported by both devices. And I don't think 
> most mcus support it.
>
Latency is an integral part of determinism. The larger the uncertain latency 
part will be, the bigger the limit until when the information is valid will 
need to be. And real-time in how Machinekit-HAL understands it and uses it is 
all about the top maximum when the information has to be processed, not the 
minimum or absolute gradual, sequential time of each step. (You can look at how 
the HAL modules, both drivers and components, are conceptually programmed and 
compiled, there are no time constant execution path, the same amount of jumps 
or other similar real-time concepts.)

Pretty much all it cares about is to start the linked list of functions 
comprising the HAL thread at a given monotonic clock tick.

>
> If you don't care about the smoothness of tour motion or use a buffered 
> approach, usb works fine.
>
Yes, buffered approach is one way to use USB. It really depends on for what you 
want to use it, if your application can live with the latency of - let's say - 
5 ms, because your monotonic clock is ticking at 20 ms, well, then you are 
going to be fine.

Cern.

>
> On Fri 19. Feb 2021 at 0.36, justin White <> blazin...@gmail.com> > wrote:
>
>>> It's not that simple. USB2 has higher latencies, true, but if you are OK 
>>> with them, then the USB2 interface is as capable of real-time communication 
>>> as any other interface. There have been attempts to mitigate these 
>>> latencies with various results. (Search research papers online.) USB3 
>>> should be much better in this regard.
>>>
>>
>> I dont see how that's true when the default USB2 polling rate is 8ms. You 
>> can change the mouse driver to get 1ms but I don't know that the RT patches 
>> touch USB. So whats the secret sauce to getting RT USB if the polling 
>> interval remains at 8ms on a shared bus?
>>
>> USB3 isn't really even worth talking about yes its peer to peer with much 
>> better latency but an rpi4 having a USB3 port doesn't do any good when MCUs 
>> really do not. Most MCUs bake usb2 hardware right onto the chip while usb3 
>> is generally a PCIE lane attached to a PHY which I have yet to see on any 
>> dev boards.
>>
>> So what's the secret sauce to RT USBx? And ...why, when any MCU contains 
>> fast UARTs, spi and sometimes ethernet.
>>
>> On Thu, Feb 18, 2021 at 11:23 AM cern via Machinekit <>> 
>> machinekit@googlegroups.com>> > wrote:
>>
>>> Hello,
>>>  
>>>  Feb 18, 2021, 14:32 by >>> joonas.fors...@gmail.com>>> :
>>>  
>>>  > USB itself isn’t realtime capable so it can’t be used for any realtime 
>>> tasks.
>>>  >
>>>  It's not that simple. USB2 has higher latencies, true, but if you are OK 
>>> with them, then the USB2 interface is as capable of real-time communication 
>>> as any other interface. There have been attempts to mitigate these 
>>> latencies with various results. (Search research papers online.) USB3 
>>> should be much better in this regard.
>>>  
>>>  Cern.
>>>  
>>>  >
>>>  > On Thu 18. Feb 2021 at 11.18, > >>> ozzy...@gmail.com>>> >  <> >>> 
>>> ozzyro...@gmail.com>>> > > wrote:
>>>  >
>>>  >> Be interesting to see more details on the Linuxcnc\USB\MESA setup.
>>>  >> As far as I was aware there was no RT support for USB.
>>>  >> I'm not even sure if MESA themselves recommend their USB boards for use 
>>> with Linuxcnc.
>>>  >>
>>>  >> On Thursday, February 18, 2021 at 7:32:57 AM UTC+11 >> >>> 
>>> doug@gmail.com>>> >>  wrote:
>>>  >>
>>>  >>> Great, thanks for finding it!
>>>  >>>
>>>  >>> I've seen lots of people purchasing 3DP controller boards to upgrade 
>>> 3DP/Lasers/CNC's(consumer stuff) and many of them also use an rPi with 
>>> OctoPrint or CNCjs, GridBot etc.
>>>  >>> I like this approach in that all of my macines(4 3DPs, 2 laser cutters 
>>> and 1 CNC) all have consumer grade controllers in them running on different 
>>> uCPUs. Some AVR328, STM32, LPC17xx and one a BBB/CRAMPS.
>>

Re: [Machinekit] Re: any info on the spiPRU mentioned

[cern via Machinekit]

Feb 18, 2021, 23:36 by blazin...@gmail.com:

>> It's not that simple. USB2 has higher latencies, true, but if you are OK 
>> with them, then the USB2 interface is as capable of real-time communication 
>> as any other interface. There have been attempts to mitigate these latencies 
>> with various results. (Search research papers online.) USB3 should be much 
>> better in this regard.
>>
>
> I dont see how that's true when the default USB2 polling rate is 8ms. You can 
> change the mouse driver to get 1ms but I don't know that the RT patches touch 
> USB. So whats the secret sauce to getting RT USB if the polling interval 
> remains at 8ms on a shared bus?
>
> USB3 isn't really even worth talking about yes its peer to peer with much 
> better latency but an rpi4 having a USB3 port doesn't do any good when MCUs 
> really do not. Most MCUs bake usb2 hardware right onto the chip while usb3 is 
> generally a PCIE lane attached to a PHY which I have yet to see on any dev 
> boards.
>
> So what's the secret sauce to RT USBx? And ...why, when any MCU contains 
> fast UARTs, spi and sometimes ethernet.
>
There is no secret sauce. Or better said the sauce is not secret. You may have 
an application which requires 10 ms polling of maximum reaction time, in that 
case you are golden as then you will have 8 ms rate (simplified).

You can read this thesis: http://caxapa.ru/thumbs/833386/pomarlan.pdf about 
what one can do about RT on USB2.

And why? Well, because people are people, and they will always try to do things 
which seem superfluous. If somebody wants to use USB, great, let's see what he 
will be able to come up with...

Cern

>
> On Thu, Feb 18, 2021 at 11:23 AM cern via Machinekit <> 
> machinekit@googlegroups.com> > wrote:
>
>> Hello,
>>  
>>  Feb 18, 2021, 14:32 by >> joonas.fors...@gmail.com>> :
>>  
>>  > USB itself isn’t realtime capable so it can’t be used for any realtime 
>> tasks.
>>  >
>>  It's not that simple. USB2 has higher latencies, true, but if you are OK 
>> with them, then the USB2 interface is as capable of real-time communication 
>> as any other interface. There have been attempts to mitigate these latencies 
>> with various results. (Search research papers online.) USB3 should be much 
>> better in this regard.
>>  
>>  Cern.
>>  
>>  >
>>  > On Thu 18. Feb 2021 at 11.18, > >> ozzy...@gmail.com>> >  <> >> 
>> ozzyro...@gmail.com>> > > wrote:
>>  >
>>  >> Be interesting to see more details on the Linuxcnc\USB\MESA setup.
>>  >> As far as I was aware there was no RT support for USB.
>>  >> I'm not even sure if MESA themselves recommend their USB boards for use 
>> with Linuxcnc.
>>  >>
>>  >> On Thursday, February 18, 2021 at 7:32:57 AM UTC+11 >> >> 
>> doug@gmail.com>> >>  wrote:
>>  >>
>>  >>> Great, thanks for finding it!
>>  >>>
>>  >>> I've seen lots of people purchasing 3DP controller boards to upgrade 
>> 3DP/Lasers/CNC's(consumer stuff) and many of them also use an rPi with 
>> OctoPrint or CNCjs, GridBot etc.
>>  >>> I like this approach in that all of my macines(4 3DPs, 2 laser cutters 
>> and 1 CNC) all have consumer grade controllers in them running on different 
>> uCPUs. Some AVR328, STM32, LPC17xx and one a BBB/CRAMPS.
>>  >>> But would love to be able to have LinuxCNC/Machinekit on an rPi doing 
>> the control, UI, setup. 
>>  >>> On Wednesday, February 17, 2021 at 11:02:18 AM UTC-8 >>> >> 
>> ce...@tuta.io>>  <>>>>  wrote:
>>  >>>
>>  >>>> Hi,
>>  >>>> the code is available in >>>> >> 
>> https://github.com/scottalford75/Remora>> >>>>  - looks like he though that 
>> spiPRU is not a great name and changed it to something more flashy.
>>  >>>>
>>  >>>> Looks interesting from programming point of view, but I wonder how 
>> many people would buy Smoothieboard and RPi both to run 3D printer with 
>> LinuxCNC on it? Most will stay with Smoothie, I think.
>>  >>>>
>>  >>>> Cern.
>>  >>>>
>>  >>>> Dne úterý 16. února 2021 v 19:18:20 UTC+1 uživatel >>>> >> 
>> doug@gmail.com>>  <>>>>>  napsal:
>>  >>>>
>>  >>>>> I was about to start on setting up a Xylotex

Re: [Machinekit] Re: any info on the spiPRU mentioned

[cern via Machinekit]

Hello,

Feb 18, 2021, 14:32 by joonas.fors...@gmail.com:

> USB itself isn’t realtime capable so it can’t be used for any realtime tasks.
>
It's not that simple. USB2 has higher latencies, true, but if you are OK with 
them, then the USB2 interface is as capable of real-time communication as any 
other interface. There have been attempts to mitigate these latencies with 
various results. (Search research papers online.) USB3 should be much better in 
this regard.

Cern.

>
> On Thu 18. Feb 2021 at 11.18, > ozzy...@gmail.com>  <> ozzyro...@gmail.com> > 
> wrote:
>
>> Be interesting to see more details on the Linuxcnc\USB\MESA setup.
>> As far as I was aware there was no RT support for USB.
>> I'm not even sure if MESA themselves recommend their USB boards for use with 
>> Linuxcnc.
>>
>> On Thursday, February 18, 2021 at 7:32:57 AM UTC+11 >> doug@gmail.com>>  
>> wrote:
>>
>>> Great, thanks for finding it!
>>>
>>> I've seen lots of people purchasing 3DP controller boards to upgrade 
>>> 3DP/Lasers/CNC's(consumer stuff) and many of them also use an rPi with 
>>> OctoPrint or CNCjs, GridBot etc.
>>> I like this approach in that all of my macines(4 3DPs, 2 laser cutters and 
>>> 1 CNC) all have consumer grade controllers in them running on different 
>>> uCPUs. Some AVR328, STM32, LPC17xx and one a BBB/CRAMPS.
>>> But would love to be able to have LinuxCNC/Machinekit on an rPi doing the 
>>> control, UI, setup. 
>>> On Wednesday, February 17, 2021 at 11:02:18 AM UTC-8 >>> ce...@tuta.io 
>>> <>>>>  wrote:
>>>
>>>> Hi,
>>>> the code is available in >>>> https://github.com/scottalford75/Remora>>>>  
>>>> - looks like he though that spiPRU is not a great name and changed it to 
>>>> something more flashy.
>>>>
>>>> Looks interesting from programming point of view, but I wonder how many 
>>>> people would buy Smoothieboard and RPi both to run 3D printer with 
>>>> LinuxCNC on it? Most will stay with Smoothie, I think.
>>>>
>>>> Cern.
>>>>
>>>> Dne úterý 16. února 2021 v 19:18:20 UTC+1 uživatel >>>> doug@gmail.com 
>>>> <>>>>>  napsal:
>>>>
>>>>> I was about to start on setting up a Xylotex BareBoneCNC with a 
>>>>> BBB/Machinekit and thought I'd look at what's going on with Raspberry Pi 
>>>>> in CNC world. I found a video of a guy driving a Mesa board over USB with 
>>>>> LinuxCNC and it looked impressive(doesn't take much).
>>>>>
>>>>> Got to wondering if a standard 3DP controller like SKR, Smoothieboard, 
>>>>> etc couldn't run firmware similar to the MESA board and only found 
>>>>> mention of this spiPRU but no details, code, anything.
>>>>>
>>>>> https://github.com/scottalford75/LinuxCNC-on-RPi
>>>>>
>>>>> I searched for spiPRU here and in general inter-web lands and found 
>>>>> nothing but the mention of it in the above git repo.  If anyone knew 
>>>>> about it I figured they would be here.
>>>>> Thx
>>>>>
>>
>>
>>
>> --
>>  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/cc241b97-47bb-48d0-b3b4-e595dc809b55n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/machinekit/cc241b97-47bb-48d0-b3b4-e595dc809b55n%40googlegroups.com?utm_medium=email&utm_source=footer>>>
>>  .
>>
> -- 
> Terv,
> Joonas Forsell
>
>
>
> --
>  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/CA%2B%2BSnhq%3D-rmGD2z8ewbQ9ryBoyWgwymJTbmWp6NKnGPyhmsrbw%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/machinekit/CA%2B%2BSnhq%3D-rmGD2z8ewbQ9ryBoyWgwymJTbmWp6NKnGPyhmsrbw%40mail.gmail.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/MTpwssk--3-2%40tuta.io.

Re: [Machinekit] Re: Cold storage or dead?

[cern via Machinekit]

Hi,
Feb 6, 2021, 03:16 by fun...@gmail.com:

> Hello...
>
> Okay. So, the PSU will be here soon. It seems this has put a damper in my 
> handling of the MachineKit source and usage. Anyway, I will be posting soon 
> to show and tell soon.
>
> Seth
>
> P.S. If you all are still interested in me making things works for beginners 
> like me w/ Machinekit, okay. Good...I will wait for the PSU to arrive and 
> then cracking. 
>
Of course, I am still interested in your write-ups and HOWTOs. It's the best 
way how to learn to just look somebody else over his shoulders.

Cern.

> On Monday, January 25, 2021 at 10:46:04 PM UTC-6 Mala Dies wrote:
>
>> Hello,
>>
>> I know what I said and I know I have failed so far. Excuse me, I will keep 
>> attempting ideas. My power source is on another planet or something. I am 
>> still waiting for it. 
>>
>> ...
>>
>> So, Jekyll is out. Okay. If the site cannot be done via stretch any longer 
>> and has to be rebuilt on another machine, from what I understand, Docker is 
>> "precarious." I started some "fancy" coding in html5 and w/out using 
>> JavaScript. 
>>
>> ...
>>
>> I  host my sites for controlling some bots via a server, some html5, css, 
>> and a BBB. I used bind9, virtual hosts, a soon to enable cgi-script(s), and 
>> I have a long time to go. New year, new issues!
>>
>> What is the current standing so far w/ Machinekit.io and "whatever" source 
>> needs to be used to duplicate the site. I do not use DBs much. So, 
>> replication is still copy and paste over here.
>>
>> I am not sure I know exactly my part so far, i.e. outside of promoting 
>> findings w/ a BBB/BBAI and other board(s). 
>>
>> Has anyone used the replicape for handling Machinekit.io ideas? So, here is 
>> a screenshot of my page online for now. Not fancy, one or two lines only, 
>> and no machinekit stuff yet. I am still waiting of the power supply stuff.
>>
>> I will test the >> machinekit.io <http://machinekit.io>>>  source w/ the 
>> replicape and a BBB. I will also stop transmissions w/out production on my 
>> part. 
>>
>> I know I am getting repetitive. Anyway, I hope everyone is doing well in the 
>> new year (as well as things can be).
>>
>>
>>
>>
>> Seth
>>
>> P.S. The above snapshot is just a site w/ HTML5. If anyone is working w/ DBs 
>> and wants to, from what I am understanding, control the >> machinekit.io 
>> <http://machinekit.io>>>  pages w/ a change or two (many), jump in. Blah! I 
>> will get more productive soon. 
>>
>> On Wednesday, December 30, 2020 at 12:14:07 PM UTC-6 >> ce...@tuta.io <>>>  
>> wrote:
>>
>>> Hello, 
>>>  
>>> Dec 29, 2020, 03:04 by >>> fun...@gmail.com <>>>> : 
>>>  
>>> > Sir, 
>>> > 
>>> > Also...are you (we) trying to move away from Jekll and markdown? If so, I 
>>> > should not waste my time in markdown for now. 
>>> > 
>>> I think the Hugo looks nice, but I wouldn't say that move away from Jekyll 
>>> is a must. I have been looking more at what has nice free templates I could 
>>> use with minimal changes and that was funnelling my search, not the backend 
>>> engine. 
>>>  
>>> (For example I have been looking at >>> 
>>> https://github.com/nekocode/codelabs-hugo-theme>>>  and >>> 
>>> https://github.com/nekocode/codelabs-hugo-theme>>>  or >>> 
>>> https://github.com/samuelhorn/jamdocs>>>  or >>> 
>>> https://github.com/jeblister/kube>>>  .) 
>>>  
>>> And I think Markdown and ASCIIDoc are nice, but don't have any particular 
>>> attachment to any of them. Do you think there is something better what 
>>> could be used? 
>>>  
>>> > 
>>> > ... 
>>> > 
>>> > Seth 
>>> > 
>>> > P.S. I have found that there are some other items out there like what you 
>>> > described, the CodeLabs and some others, that can help me help you help 
>>> > me help others. Phew. That was difficult to type out.  
>>> > 
>>> It was just something I found a little while ago when I was investigating 
>>> how to make the documentation better. I am not married to this idea, just 
>>> seemed interesting at the time. 
>>>  
>>> Any help welcome! 
>>>  
>>> Cern

Re: [Machinekit] Re: Cold storage or dead?

[cern via Machinekit]

Hi,

Jan 26, 2021, 05:46 by fun...@gmail.com:

> Hello,
>
> I know what I said and I know I have failed so far. Excuse me, I will keep 
> attempting ideas. My power source is on another planet or something. I am 
> still waiting for it. 
>
> ...
>
> So, Jekyll is out. Okay. If the site cannot be done via stretch any longer 
> and has to be rebuilt on another machine, from what I understand, Docker is 
> "precarious." I started some "fancy" coding in html5 and w/out using 
> JavaScript. 
>
The current Docker image which contains the main build logic is only precarious 
because it is based on Debian Jessie or Wheezy, both of which are currently 
obsolete, and as such cannot be just build again. To make it buildable again 
(and more robust at the same time), one would need to do the maintenance work 
and update all to current versions.

Moreover, the building process was originally happening on private hardware 
behind closed doors. And not all the logic could be simply ported to the public 
cloud as it is now. (It is bit convoluted.)

>
> ...
>
> I  host my sites for controlling some bots via a server, some html5, css, and 
> a BBB. I used bind9, virtual hosts, a soon to enable cgi-script(s), and I 
> have a long time to go. New year, new issues!
>
> What is the current standing so far w/ Machinekit.io and "whatever" source 
> needs to be used to duplicate the site. I do not use DBs much. So, 
> replication is still copy and paste over here.
>
The current state is that the Machinekit site is hosted on Github Pages - it is 
redirect to machinekit.github.io, so everything is stored in the 
github.com/machinekit/machinekit.github.io 
<http://github.com/machinekit/machinekit.github.io> repository. But it is a bit 
more complicated, the site itself is stored in 
github.com/machinekit/machinekit-docs 
<http://github.com/machinekit/machinekit.github.io> or at least the recipe for 
it is. From this repository on each merge the Jekyll pipeline runs and builds 
the output which is then stored in machinekit.github.io.

The relevant commands are in:
https://github.com/machinekit/machinekit.github.io/blob/master/.github/workflows/build-on-ping.yaml

and

https://github.com/machinekit/machinekit-docs/blob/master/.github/workflows/ping-remote-repository.yaml

My personal opinion is that the site should stay on public and reproducible 
hosting solution and should use public and reproducible tools - that way if the 
author leaves or looses interest, the code and logic is all there and can 
maintained by somebody else intereted.

Cern.

>
> I am not sure I know exactly my part so far, i.e. outside of promoting 
> findings w/ a BBB/BBAI and other board(s). 
>
> Has anyone used the replicape for handling Machinekit.io ideas? So, here is a 
> screenshot of my page online for now. Not fancy, one or two lines only, and 
> no machinekit stuff yet. I am still waiting of the power supply stuff.
>
> I will test the machinekit.io source w/ the replicape and a BBB. I will also 
> stop transmissions w/out production on my part. 
>
> I know I am getting repetitive. Anyway, I hope everyone is doing well in the 
> new year (as well as things can be).
>
>
>
>
> Seth
>
> P.S. The above snapshot is just a site w/ HTML5. If anyone is working w/ DBs 
> and wants to, from what I am understanding, control the machinekit.io pages 
> w/ a change or two (many), jump in. Blah! I will get more productive soon. 
>
> On Wednesday, December 30, 2020 at 12:14:07 PM UTC-6 ce...@tuta.io wrote:
>
>> Hello, 
>>  
>> Dec 29, 2020, 03:04 by >> fun...@gmail.com <>>> : 
>>  
>> > Sir, 
>> > 
>> > Also...are you (we) trying to move away from Jekll and markdown? If so, I 
>> > should not waste my time in markdown for now. 
>> > 
>> I think the Hugo looks nice, but I wouldn't say that move away from Jekyll 
>> is a must. I have been looking more at what has nice free templates I could 
>> use with minimal changes and that was funnelling my search, not the backend 
>> engine. 
>>  
>> (For example I have been looking at >> 
>> https://github.com/nekocode/codelabs-hugo-theme>>  and >> 
>> https://github.com/nekocode/codelabs-hugo-theme>>  or >> 
>> https://github.com/samuelhorn/jamdocs>>  or >> 
>> https://github.com/jeblister/kube>>  .) 
>>  
>> And I think Markdown and ASCIIDoc are nice, but don't have any particular 
>> attachment to any of them. Do you think there is something better what could 
>> be used? 
>>  
>> > 
>> > ... 
>> > 
>> > Seth 
>> > 
>> > P.S. I have found that there are s

Re: [Machinekit] Re: linuxcnc-ethercat / ethercatlab and lcnc/machinekit

[cern via Machinekit]

Hi,

Jan 9, 2021, 22:09 by moronicsm...@gmail.com:

> Sadly no, i havent seen that one. And that comes back to my previous points 
> on that the current work on machinekit is a bit obscured.
> The fact you have a cloudsmith repository going is news to me and not 
> something ive seen in any of the documentation.
>
Well, it is part of the documentation. But it's quite hidden. It's in page: 
http://www.machinekit.io/docs/developing/machinekit-developing/ in:

>If you don’t have build package installed, install it by following the 
>official Debian wiki <https://wiki.debian.org/BuildingTutorial#Requirements>. 
>You may also need to have installed the official 
>https://cloudsmith.io/~machinekit/repos/machinekit/packages/][Machinekit 
>dependencies repository], install it by following the instructions 
><https://cloudsmith.io/~machinekit/repos/machinekit/setup/#formats-deb>.

(It is messy, I know.)

>
> Looking at those actions tho ithey seem pretty stable. Once again i dont 
> reeeally see the point of docker for the common user, but its the devops in 
> me i guess.
>
Well, you can have a bigger control over updates and the whole environment. You 
can have "multiple" system wide installations from packages and not use the 
in-tree build.

For cross-building, you have the multi-arch binaries only in container and not 
in your system.

> Docker is a great tool, but sometimes as devops i need to think of who is 
> gonna use this.. And most likely that is not experienced developers and 
> devops people.
>
> Gitub actions is a great use for these things tho. And also docker helps if 
> one wanna regularly create release packages for the common user.
>
Tend to agree on the GA. Hopefully it will not go the way of Travis any day 
soon.

Cern.

>
> // The Smurf.
>
> lördag 9 januari 2021 kl. 17:03:08 UTC+1 skrev ce...@tuta.io:
>
>> Hello,
>>
>> thank you for the writeup! Have you seen this: >> 
>> https://github.com/zultron/linuxcnc-ethercat>>  ? It is able to produce 
>> packages in Github Actions CI workflow.
>>
>> Cern.
>> Dne pondělí 4. ledna 2021 v 23:26:22 UTC+1 uživatel Moronic Smurf napsal:
>>
>>> These are some of my notes from building the packages of 
>>> Machinekit/linuxcnc and getting linuxcnc-ethercat packages built in 
>>> conjunction with the ethercatlabmaster packages.
>>>
>>> Hopefully this wil help some other poor schmuck trying to get ethercat  
>>> servos running.
>>> But at this point in time i'm giving up. Mainly cuz machinekit build 
>>> process is seemingly terribly broken and/or confusing.
>>>
>>> Link.
>>> https://gist.github.com/NeoTech/434c6f93e6c5e2471f8b2505b9d2f56c>>>   
>>>
>
>
>
> --
>  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/-PusZo7E64w/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/c2b6eeb8-9b84-44e0-a4b1-6febc7efd605n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/c2b6eeb8-9b84-44e0-a4b1-6febc7efd605n%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/MQh09z_--3-2%40tuta.io.

Re: [Machinekit] Is machinekit broken?

[cern via Machinekit]

Hi,
Jan 9, 2021, 22:05 by moronicsm...@gmail.com:

> https://cloudsmith.io/~machinekit/repos/machinekit/packages/?q=python3-avahi  
> << This i dodnt even knew that it existed by reading the documentation. :)
>
> I was talking about the machinekit-hal repository. :)
>
> Regarding documentation, is there a way to get hold of you for a call? A zoom 
> or similar where i can pick you brain or start dumping parts of it to stick 
> into documentation.
> Or we could even do something like setup a Discord for contributors just to 
> be able to sync whats going on, what people are working on what needs to be 
> tested and documented.
>
Well, there is the Matrix room #machinekit:matrix.org connected to the Gitter 
room Machinekit/Machinekit and few IRC channels.

> As far as ive seen by reading thru all the code base.. the painpoints atm, is 
> outdated website, outdated documentation and lack of communication.. And this 
> is prob true for every opensource project i have been part of.
>
Yes, the site is outdated and given that the documentation is the site, then 
that's connected. I am trying to keep the communication part, I don't think it 
is that bad.

Cern.

>
> If interest, please email me at moronicsm...@gmail.com and i will get back to 
> you on my private email.
>
> lördag 9 januari 2021 kl. 03:49:45 UTC+1 skrev ce...@tuta.io:
>
>> Hello, 
>>  
>> I will try to give an honest answer, however I am sure that as a Machinekit 
>> organization maintainer, I am liable to a tinted viewpoint. 
>>  
>> Firstly, from your post I am not sure if you are talking mainly about the 
>> monorepo at >> github.com/machinekit/machinekit 
>> <http://github.com/machinekit/machinekit>>>  <>> 
>> http://github.com/machinekit/machinekit>> > or the separated repositories 
>> mainly in >> github.com/machinekit/machinekit-hal 
>> <http://github.com/machinekit/machinekit-hal>>> , <>> 
>> http://github.com/machinekit/machinekit>> > >> 
>> github.com/machinekit/machinekit-cnc 
>> <http://github.com/machinekit/machinekit-cnc>>>  <>> 
>> http://github.com/machinekit/machinekit>> > and >> 
>> github.com/machinekit/emcapplication 
>> <http://github.com/machinekit/emcapplication>>> . <>> 
>> http://github.com/machinekit/machinekit>> > But the fact is that the 
>> monorepo was deprecated and is no longer maintained or developed on. The 
>> core of development will be in Machinekit-HAL plus few connected 
>> repositories based on the momentary need and community contribution. 
>>  
>> The Achilles' heel is the documentation. The documentation is terrible. 
>> Everybody can see it. It would be great to get it to a better shape. But 
>> that would actually mean to completely rewrite it. Because I don't think 
>> there is a chance for salvaging it. I also think that there is a more 
>> pressing task in need of completion. That is the CMAKE port I am currently 
>> working on - it is going a lot slower than I would like because it is 
>> connected with restructuralizing of the codebase tree (which is completely 
>> insane at the moment), but it will - I think - allow to shed the dependency 
>> on Debian based distribution for bigger pool of GNU Linux ones. 
>>  
>> You may think that it is counterproductive to focus on development when the 
>> documentation is in the state in which it is - but one has to remember that 
>> Machinekit (all of its repositories) is mostly used in companies and company 
>> specific products. 
>>  
>>  
>> Jan 4, 2021, 23:24 by >> moroni...@gmail.com <>>> : 
>>  
>> > I have spent the better part of a couple of evenings trying to get it to 
>> > run from sourcecode. 
>> > 
>> > And i can tell you, its only because i really know my way around linuxcnc 
>> > as a devops i actually managed to get anything done. 
>> > 
>> > But here is some notes. 
>> > Repository / prebuilt packages 
>> > - They work. 
>> > 
>> There currently are multiple repositories. The old ones are the >> 
>> deb.machinekit.io <http://deb.machinekit.io>>>  are in process of 
>> deprecation (as they are hosted on private server of long gone Machinekit 
>> member with no change of getting access). The new ones are hosted on 
>> Cloudsmith service: >> https://cloudsmith.io/~machinekit/repos/>>  
>>  
>> Specifically: 
>> https://cloudsmith.io/~machinekit/repos/machinekit/packages/>>  - for common 

Re: [Machinekit] Is machinekit broken?

[cern via Machinekit]

Debian packaging leaves a lot to be desired and currently on 
its own cannot solve a dependency tree of multiple projects going at different 
vectors. So you need for EMCApplication to install older version of 
Machinekit-HAL and such.) 

>
> In the end i got all the packages built with no fuss, and was gonna runt the 
> ol' dpkg -i machinekit-hal - and well.. what do you know.. it requires more 
> package dependcies.. on packages that doesnt even exist anymore .. like 
> "python3-avahi" .. That now makes the whole effort useless..
>
Python3-avahi is available. I know because I spend multiple hours building it 
and other packages.

https://cloudsmith.io/~machinekit/repos/machinekit/packages/?q=python3-avahi

>
> And final thought.. the prebuilt packages on archive is version 0.2, when 
> building my own packages i made a jump to 0.4.. when going to git and looking 
> in the branches.. well what do you know.. no 0.2 to be found or any other 
> branch...
>
The 0.2 is in the old deb.machinekit.io repository. I cannot do anything about 
it, I don't have the keys. That's the reason why the Cloudsmith repo was 
created, here I can give access to all active Machinekit organization's members.

>
> Please at least follow some.. "rules".. make sure the compatibility packages 
> can be built, like if its gonna be a split of source code.. make sure there 
> is coherent documentation on how to compile it.. When compiling i get the 
> machinekit-dev package btw, why isnt that on archive?!
>
Again, you are probably compiling the monorepo. Or some older version of 
Machinekit-HAL. There should be no machinekit-dev package anymore.

>
> I'm working as a senior devops / project manager in my day to day.. I will 
> happily pitch in with some organizationl chops and hand pointing if it would 
> help the project.. Also happy writing documentation. I basically already have 
> for my experiments with this.
>
Of course, any and all help is appreciated. The best space for discussing this 
is the Github issue tracker. Based on the area either in Machinekit-HAL, 
EMCApplication, Machinekit-CNC, Machinekit-docs or any other.

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/b83674b1-a8fc-4c28-bb06-62cb0d754e53n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/b83674b1-a8fc-4c28-bb06-62cb0d754e53n%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/MQ_29M4--3-2%40tuta.io.

Re: [Machinekit] Re: Cold storage or dead?

[cern via Machinekit]

Hello,

Dec 29, 2020, 03:04 by fun...@gmail.com:

> Sir,
>
> Also...are you (we) trying to move away from Jekll and markdown? If so, I 
> should not waste my time in markdown for now.
>
I think the Hugo looks nice, but I wouldn't say that move away from Jekyll is a 
must. I have been looking more at what has nice free templates I could use with 
minimal changes and that was funnelling my search, not the backend engine.

(For example I have been looking at 
https://github.com/nekocode/codelabs-hugo-theme and 
https://github.com/nekocode/codelabs-hugo-theme or 
https://github.com/samuelhorn/jamdocs or https://github.com/jeblister/kube .)

And I think Markdown and ASCIIDoc are nice, but don't have any particular 
attachment to any of them. Do you think there is something better what could be 
used?

>
> ...
>
> Seth
>
> P.S. I have found that there are some other items out there like what you 
> described, the CodeLabs and some others, that can help me help you help me 
> help others. Phew. That was difficult to type out. 
>
It was just something I found a little while ago when I was investigating how 
to make the documentation better. I am not married to this idea, just seemed 
interesting at the time.

Any help welcome!

Cern.

> On Sunday, December 27, 2020 at 6:02:03 PM UTC-6 ce...@tuta.io wrote:
>
>> Hello, 
>> Dec 18, 2020, 03:50 by >> fun...@gmail.com <>>> : 
>>  
>> > Hello, 
>> > 
>> > You got it. Do not solely rely on me but if you want me to start sharing 
>> > ideas, I can keep it up to date constantly. If learning this source will 
>> > help me w/ my machines, learning is preferable for me and I can document 
>> > things well enough to have others understand it easily (outside of some 
>> > reasoning behind C/C++). 
>> > 
>> I think that different people have different ways of how to approach this 
>> endeavour. Things which were important for me to understand, so I can boast 
>> understanding of the whole system are not necessarily  things somebody else 
>> will need to understand for the same level of feelings. I am and was 
>> approaching this from a software engineering point of view, not a machinist 
>> or machine integrator angle. So I am interested in how and with what exactly 
>> people are struggling with. 
>>  
>> > 
>> > Seth 
>> > 
>> > P.S. So, even though I have not started yet, starting w/ machines is 
>> > something I find neat. So, I am starting now at an older age b/c "why 
>> > not?" Why would I just sit still doing nothing all day? Oh and sir, I 
>> > understand about the gearing towards the BBB for me. I brought it up b/c 
>> > they have an image w/ it specifically motioned towards the machinekit 
>> > ideas. I understand now that other boards hold machinekit too. Now, if I 
>> > can only add in machinekit jargon while creating these messages. Sheesh. 
>> > 
>> Nobody is too old to learn something new! And on a side note, I have always 
>> found that I am able to learn when I want to, not when I should or somebody 
>> else thinks that I should. Or when I have a problem in need of solution. So 
>> I am fully supporting this approach. 
>>  
>> Cern. 
>>  
>> > 
>> > On Monday, December 14, 2020 at 9:14:59 PM UTC-6 >> ce...@tuta.io <>>>  
>> > wrote: 
>> > 
>> >> 
>> >> Hi, 
>> >> sure. I meant that it would be part of the Machinekit.io website and 
>> >> served as a part of it. But you are right that there currently is no 
>> >> provision for it and that would need to be scripted in. 
>> >> 
>> >> So, for now just try to do what you think is best. 
>> >> 
>> >> I am not against the BBB. It is a good system. If you want to zero on 
>> >> BBB, then by all means. I was just mentioning, that Machinekit is not 
>> >> geared only towards BBB and that there are groups using other platforms. 
>> >> 
>> >> Cern. 
>> >> 
>> >> Dec 14, 2020, 03:49 by >> >> fun...@gmail.com <>>>  <>>> : 
>> >> 
>> >> > 
>> >> > Hello, 
>> >> > 
>> >> > I can try. I looked over the idea of making the googlecodelab/tools. I 
>> >> > would not want to hold the server on my end but I may find another 
>> >> > resource. I will keep learning and like you said, I will try to not 
>> >> > gear it towards the BBB.  
>> >> > 
>> >> > ... 
>>

Re: [Machinekit] Re: Cold storage or dead?

[cern via Machinekit]

Hi,

Dec 28, 2020, 04:36 by fun...@gmail.com:

> Hello,
>
> I found markdown.org. It seems, newly born again software "expert" here, 
> there are many avenues to take on this venture. CodeLabs does not like me or 
> Ubuntu for some reason. 
>
> ...
>
> I can try CodeLabs again under Debian if necessary but it seems that there 
> are many avenues available with markdown. I have been reading and I have used 
> the markdown briefly before reading into it more recently.
>
> If necessary, I can start to transfer specific pages out of your 
> machinekit.io pages or make new ones for people like me who are new to 
> machinekit. 
>
I think making new ones would be the right thing in this, because trying to 
bend something to own needs is always mildly frustrating and could potentially 
lead to loss of stamina or interest. When one starts on a green field, 
everything looks more promising.

This way one can also create something based on his best intentions and 
knowledge without the need to constantly double-guess what somebody else was 
thinking.

> I am not sure what is needed right now. I know what I would do but it may not 
> be as professional as some people would like.
>
Professionals are just amateurs who get paid. This is part of what I wanted to 
say by pointing out that everyone has different vector how to learn this tool. 
I probably messed my reasoning up.

For me, the most important part was to understand that it is not about CNC or 
path planning or kernelspace and userspace modules or any of that parts most 
frequently talked about, but it is about shared memory based IPC, and its 
functional API. But for somebody else, somebody interested in other areas, it 
will be different.

So I do think that user description, understanding and on this based tutorials 
are important. Sure, for somebody it will not be "professional" enough, for 
somebody else it will be exactly what he was looking for. That's life.

> I would just use markdown to create some simple examples to test. For 
> example, I can try w/ the BBB and learn the commands and publish what I am 
> learning. I have not been around long enough to know every in and out but...
>
Sounds great. Usually people who just recently gained some knowledge are the 
ones best poised to spread it to others.

> I have a motor
> I have a BBB
> I have some nice source to test the motor
> I can get an image of Machinekit ready to prevail with the BBB image
> Easy to read or black and white text? See me, I am not a popular person nor 
> do I stay accustomed to seizures from lucid colors while reading. I like it 
> plain and simple (one reason google groups is nice). No frills. 
>
Sure, that is the advantage of using Markdow or AsciiDoc. These are targeted 
toward the content and the form can be modified afterwards.

So, you are against the change to something modern, like Discourse?

>
> ...
>
> So, in retrospect, I would say markdown and in an easy-to-read format, i.e. 
> bullet points, some code from testing, some command usage, and outcomes w/ 
> all of that combined into a video for "leverage." People love the final 
> product.
>
Great, videos are nice! Especially from someone who has a pleasant voice.

>
> I have a couple more items to get so I can alter the state of this motor but 
> I will look to machinekit for usage. I am learning currently about machinekit 
> slowly along w/ commands and .ini files for usage on the commands. 
>
> Seth
>
> P.S. If you need me to promote my findings on "popular" links about 
> machinekit.io and the ideas involved, let me know. I will do it. Places like 
> Hackster.io, Hackady.io, Instructables, and places of that nature might bring 
> in some fascination since I cannot really provide high levels of C/C++ source 
> right now. If it works, it works. People who use 32-bit machines should know 
> and I think people should use it based on this info. about it being dedicated 
> to 32-bit machines. Just for the record, I will be posting some files in here 
> regarding my markdown findings on the subject of machinekit.io and my 
> personal usage. Sorry for the long explanation. Over and out...tutorials on 
> the way!
>
Do what you think is best. I have found that it is the best approach.

Cern.

> On Sunday, December 27, 2020 at 6:02:03 PM UTC-6 ce...@tuta.io wrote:
>
>> Hello, 
>> Dec 18, 2020, 03:50 by >> fun...@gmail.com <>>> : 
>>  
>> > Hello, 
>> > 
>> > You got it. Do not solely rely on me but if you want me to start sharing 
>> > ideas, I can keep it up to date constantly. If learning this source will 
>> > help me w/ my machines, learning is preferable for me and I can document 
>> > things well enough to have ot

Re: [Machinekit] Re: Cold storage or dead?

[cern via Machinekit]

Hello,
Dec 18, 2020, 03:50 by fun...@gmail.com:

> Hello, 
>
> You got it. Do not solely rely on me but if you want me to start sharing 
> ideas, I can keep it up to date constantly. If learning this source will help 
> me w/ my machines, learning is preferable for me and I can document things 
> well enough to have others understand it easily (outside of some reasoning 
> behind C/C++).
>
I think that different people have different ways of how to approach this 
endeavour. Things which were important for me to understand, so I can boast 
understanding of the whole system are not necessarily  things somebody else 
will need to understand for the same level of feelings. I am and was 
approaching this from a software engineering point of view, not a machinist or 
machine integrator angle. So I am interested in how and with what exactly 
people are struggling with.

>
> Seth
>
> P.S. So, even though I have not started yet, starting w/ machines is 
> something I find neat. So, I am starting now at an older age b/c "why not?" 
> Why would I just sit still doing nothing all day? Oh and sir, I understand 
> about the gearing towards the BBB for me. I brought it up b/c they have an 
> image w/ it specifically motioned towards the machinekit ideas. I understand 
> now that other boards hold machinekit too. Now, if I can only add in 
> machinekit jargon while creating these messages. Sheesh. 
>
Nobody is too old to learn something new! And on a side note, I have always 
found that I am able to learn when I want to, not when I should or somebody 
else thinks that I should. Or when I have a problem in need of solution. So I 
am fully supporting this approach.

Cern.

>
> On Monday, December 14, 2020 at 9:14:59 PM UTC-6 ce...@tuta.io wrote:
>
>>
>> Hi, 
>> sure. I meant that it would be part of the Machinekit.io website and served 
>> as a part of it. But you are right that there currently is no provision for 
>> it and that would need to be scripted in. 
>>  
>> So, for now just try to do what you think is best. 
>>  
>> I am not against the BBB. It is a good system. If you want to zero on BBB, 
>> then by all means. I was just mentioning, that Machinekit is not geared only 
>> towards BBB and that there are groups using other platforms. 
>>  
>> Cern. 
>>  
>> Dec 14, 2020, 03:49 by >> fun...@gmail.com <>>> : 
>>  
>> > 
>> > Hello, 
>> > 
>> > I can try. I looked over the idea of making the googlecodelab/tools. I 
>> > would not want to hold the server on my end but I may find another 
>> > resource. I will keep learning and like you said, I will try to not gear 
>> > it towards the BBB.  
>> > 
>> > ... 
>> > 
>> > I just know that those boards are my boards of choice. So, I am a bit 
>> > hesitant to try to make it for another type of board or for a 32-bit OS w/ 
>> > parport. But, like I say, I can try and I will keep learning while 
>> > promoting the effort.  
>> > 
>> > Seth 
>> > On Friday, December 11, 2020 at 8:07:17 PM UTC-6 >> ce...@tuta.io <>>>  
>> > wrote: 
>> > 
>> >> Hi, 
>> >> of course, this is a voluntary project, you can take as much time as you 
>> >> need. I heard that people who just learned something are the best 
>> >> teachers. I don't know if I agree completely, but for sure it is a good 
>> >> way how to sort out newly acquired knowledge even better! 
>> >> 
>> >> I was thinking of creating few hands-on tutorial for specific problems 
>> >> with use of Codelabs: >> >> https://github.com/googlecodelabs/tools>> >>  
>> >> (It looks quite easy, has OK-ish template and the flow looks very similar 
>> >> to instructables.) 
>> >> 
>> >> Cern. 
>> >> 
>> >> 
>> >> Dec 9, 2020, 07:12 by >> >> fun...@gmail.com <>>>  <>>> : 
>> >> 
>> >> > Hello, 
>> >> > 
>> >> > If you guys have patience, I would be willing to write up ideas 
>> >> > revolving around MachineKit. It would be a side project but a much 
>> >> > needed one for me. To tell you the truth, I learn a lot of things 
>> >> > constantly. I am always picking up new books, reading articles, and 
>> >> > practicing Linux based initiatives. I use motors for fun for now but I 
>> >> > have been learning more about C/C++ and Python as time persists.  
>> >> > 
>> >> > ... 

Re: [Machinekit] Re: Cold storage or dead?

[cern via Machinekit]

Hello,

Dec 21, 2020, 05:22 by fun...@gmail.com:

> Hello,
>
> Okay. I am trying CodeLabs now. Not fun!
>
Sorry to hear that!

>
> Although I am willing to spend more time on this endeavor, publishing via 
> wiki might not be an answer. You are right. So, w/ codelabs, I can publish a 
> small routine, test it, and see the outcome. Nice but there is one awful 
> pitch I forgot to mention. My codelabs codelab from their instructions does 
> not work (for now).
>
> So, I will attempt it later.
>
Just do what you think is for the best! If you think there is a better 
solution, I am open to all.

Cern.

>
> Seth
>
> P.S. BBL w/ more support for the findings and workings. 
>
> On Monday, December 14, 2020 at 9:14:59 PM UTC-6 ce...@tuta.io wrote:
>
>>
>> Hi, 
>> sure. I meant that it would be part of the Machinekit.io website and served 
>> as a part of it. But you are right that there currently is no provision for 
>> it and that would need to be scripted in. 
>>  
>> So, for now just try to do what you think is best. 
>>  
>> I am not against the BBB. It is a good system. If you want to zero on BBB, 
>> then by all means. I was just mentioning, that Machinekit is not geared only 
>> towards BBB and that there are groups using other platforms. 
>>  
>> Cern. 
>>  
>> Dec 14, 2020, 03:49 by >> fun...@gmail.com <>>> : 
>>  
>> > 
>> > Hello, 
>> > 
>> > I can try. I looked over the idea of making the googlecodelab/tools. I 
>> > would not want to hold the server on my end but I may find another 
>> > resource. I will keep learning and like you said, I will try to not gear 
>> > it towards the BBB.  
>> > 
>> > ... 
>> > 
>> > I just know that those boards are my boards of choice. So, I am a bit 
>> > hesitant to try to make it for another type of board or for a 32-bit OS w/ 
>> > parport. But, like I say, I can try and I will keep learning while 
>> > promoting the effort.  
>> > 
>> > Seth 
>> > On Friday, December 11, 2020 at 8:07:17 PM UTC-6 >> ce...@tuta.io <>>>  
>> > wrote: 
>> > 
>> >> Hi, 
>> >> of course, this is a voluntary project, you can take as much time as you 
>> >> need. I heard that people who just learned something are the best 
>> >> teachers. I don't know if I agree completely, but for sure it is a good 
>> >> way how to sort out newly acquired knowledge even better! 
>> >> 
>> >> I was thinking of creating few hands-on tutorial for specific problems 
>> >> with use of Codelabs: >> >> https://github.com/googlecodelabs/tools>> >>  
>> >> (It looks quite easy, has OK-ish template and the flow looks very similar 
>> >> to instructables.) 
>> >> 
>> >> Cern. 
>> >> 
>> >> 
>> >> Dec 9, 2020, 07:12 by >> >> fun...@gmail.com <>>>  <>>> : 
>> >> 
>> >> > Hello, 
>> >> > 
>> >> > If you guys have patience, I would be willing to write up ideas 
>> >> > revolving around MachineKit. It would be a side project but a much 
>> >> > needed one for me. To tell you the truth, I learn a lot of things 
>> >> > constantly. I am always picking up new books, reading articles, and 
>> >> > practicing Linux based initiatives. I use motors for fun for now but I 
>> >> > have been learning more about C/C++ and Python as time persists.  
>> >> > 
>> >> > ... 
>> >> > 
>> >> > I said the site was fine and I think it is...it is in a list format. 
>> >> > Far from a tree structure but the site is needed if people are to want 
>> >> > to adjust to the way machinekit is set up. 
>> >> > 
>> >> > Seth 
>> >> > On Tuesday, December 8, 2020 at 1:47:43 PM UTC-6 >> >> ce...@tuta.io 
>> >> > <>>>  <>>>  wrote: 
>> >> > 
>> >> >> Thank you for the input! 
>> >> >> 
>> >> >> Dec 7, 2020, 07:04 by >> >> >> fun...@gmail.com <>>>  <>>>  <>>> : 
>> >> >> 
>> >> >> > Hello, 
>> >> >> > 
>> >> >> > I say start small w/ the site. Add a few hyperlinks to start. Make 
>> >> >> > something official geared tow

Re: [Machinekit] Re: Cold storage or dead?

[cern via Machinekit]

Hi, 
sure. I meant that it would be part of the Machinekit.io website and served as 
a part of it. But you are right that there currently is no provision for it and 
that would need to be scripted in.

So, for now just try to do what you think is best.

I am not against the BBB. It is a good system. If you want to zero on BBB, then 
by all means. I was just mentioning, that Machinekit is not geared only towards 
BBB and that there are groups using other platforms.

Cern.

Dec 14, 2020, 03:49 by fun...@gmail.com:

>
> Hello,
>
> I can try. I looked over the idea of making the googlecodelab/tools. I would 
> not want to hold the server on my end but I may find another resource. I will 
> keep learning and like you said, I will try to not gear it towards the BBB. 
>
> ...
>
> I just know that those boards are my boards of choice. So, I am a bit 
> hesitant to try to make it for another type of board or for a 32-bit OS w/ 
> parport. But, like I say, I can try and I will keep learning while promoting 
> the effort. 
>
> Seth
> On Friday, December 11, 2020 at 8:07:17 PM UTC-6 ce...@tuta.io wrote:
>
>> Hi, 
>> of course, this is a voluntary project, you can take as much time as you 
>> need. I heard that people who just learned something are the best teachers. 
>> I don't know if I agree completely, but for sure it is a good way how to 
>> sort out newly acquired knowledge even better! 
>>  
>> I was thinking of creating few hands-on tutorial for specific problems with 
>> use of Codelabs: >> https://github.com/googlecodelabs/tools>>  (It looks 
>> quite easy, has OK-ish template and the flow looks very similar to 
>> instructables.) 
>>  
>> Cern. 
>>  
>>  
>> Dec 9, 2020, 07:12 by >> fun...@gmail.com <>>> : 
>>  
>> > Hello, 
>> > 
>> > If you guys have patience, I would be willing to write up ideas revolving 
>> > around MachineKit. It would be a side project but a much needed one for 
>> > me. To tell you the truth, I learn a lot of things constantly. I am always 
>> > picking up new books, reading articles, and practicing Linux based 
>> > initiatives. I use motors for fun for now but I have been learning more 
>> > about C/C++ and Python as time persists.  
>> > 
>> > ... 
>> > 
>> > I said the site was fine and I think it is...it is in a list format. Far 
>> > from a tree structure but the site is needed if people are to want to 
>> > adjust to the way machinekit is set up. 
>> > 
>> > Seth 
>> > On Tuesday, December 8, 2020 at 1:47:43 PM UTC-6 >> ce...@tuta.io <>>>  
>> > wrote: 
>> > 
>> >> Thank you for the input! 
>> >> 
>> >> Dec 7, 2020, 07:04 by >> >> fun...@gmail.com <>>>  <>>> : 
>> >> 
>> >> > Hello, 
>> >> > 
>> >> > I say start small w/ the site. Add a few hyperlinks to start. Make 
>> >> > something official geared towards people like me who are newcomers and 
>> >> > willing to spend time dedicated to application. I am a starter in this 
>> >> > field but I am getting older and older. 
>> >> > 
>> >> Yes, small is something which I had in mind. I don't think there is 
>> >> enough power or willingness to do full in-depth rewrite. 
>> >> 
>> >> > 
>> >> > ... 
>> >> > 
>> >> > Small site and a full representation of a working order would be nice 
>> >> > for people staring blindly at the famous pages that seem to multiply 
>> >> > quickly when viewing. 
>> >> > 
>> >> > I posted a small section from github in the form of a hyperlink. It 
>> >> > basically just goes to an incomplete but dedicated piece of text on 
>> >> > github that supports machinekit ideas w/ gcode, .ini files, and basics 
>> >> > on ideas for setting up commands. 
>> >> > 
>> >> > I think this is a good starter for people. I am sure that most of you 
>> >> > are very educated in this dept. and do not need to bother w/ newcomers 
>> >> > and nonsensical questions. I understand. I have been behind the helm 
>> >> > asking silly questions for five years in the BBB.io world. The books 
>> >> > were nice at first, the starter scripts were nice too, and in the end, 
>> >> > it seems that people stopped their futuristic approach to the entire 
>> >> > comm

Re: [Machinekit] Re: Cold storage or dead?

[cern via Machinekit]

Hi,
of course, this is a voluntary project, you can take as much time as you need. 
I heard that people who just learned something are the best teachers. I don't 
know if I agree completely, but for sure it is a good way how to sort out newly 
acquired knowledge even better!

I was thinking of creating few hands-on tutorial for specific problems with use 
of Codelabs: https://github.com/googlecodelabs/tools (It looks quite easy, has 
OK-ish template and the flow looks very similar to instructables.)

Cern.


Dec 9, 2020, 07:12 by fun...@gmail.com:

> Hello,
>
> If you guys have patience, I would be willing to write up ideas revolving 
> around MachineKit. It would be a side project but a much needed one for me. 
> To tell you the truth, I learn a lot of things constantly. I am always 
> picking up new books, reading articles, and practicing Linux based 
> initiatives. I use motors for fun for now but I have been learning more about 
> C/C++ and Python as time persists. 
>
> ...
>
> I said the site was fine and I think it is...it is in a list format. Far from 
> a tree structure but the site is needed if people are to want to adjust to 
> the way machinekit is set up.
>
> Seth
> On Tuesday, December 8, 2020 at 1:47:43 PM UTC-6 ce...@tuta.io wrote:
>
>> Thank you for the input! 
>>  
>> Dec 7, 2020, 07:04 by >> fun...@gmail.com <>>> : 
>>  
>> > Hello, 
>> > 
>> > I say start small w/ the site. Add a few hyperlinks to start. Make 
>> > something official geared towards people like me who are newcomers and 
>> > willing to spend time dedicated to application. I am a starter in this 
>> > field but I am getting older and older. 
>> > 
>> Yes, small is something which I had in mind. I don't think there is enough 
>> power or willingness to do full in-depth rewrite. 
>>  
>> > 
>> > ... 
>> > 
>> > Small site and a full representation of a working order would be nice for 
>> > people staring blindly at the famous pages that seem to multiply quickly 
>> > when viewing. 
>> > 
>> > I posted a small section from github in the form of a hyperlink. It 
>> > basically just goes to an incomplete but dedicated piece of text on github 
>> > that supports machinekit ideas w/ gcode, .ini files, and basics on ideas 
>> > for setting up commands. 
>> > 
>> > I think this is a good starter for people. I am sure that most of you are 
>> > very educated in this dept. and do not need to bother w/ newcomers and 
>> > nonsensical questions. I understand. I have been behind the helm asking 
>> > silly questions for five years in the BBB.io world. The books were nice at 
>> > first, the starter scripts were nice too, and in the end, it seems that 
>> > people stopped their futuristic approach to the entire community of 
>> > newcomers, their ideas, and bringing old to new. 
>> > 
>> > There is no pressure from me. I can learn from the >> machinekit.io 
>> > <http://machinekit.io>>>  site like I have been doing. But after a bit of 
>> > spending time on the site, it is an actually large database. It is easy to 
>> > use and dedicated to instruction. This is nice. 
>> > 
>> Most people who I talked about the site said to me that it is chaotic, the 
>> tree structure doesn't make sense and finding anything even with a search 
>> engine is Herculean task. It is interesting that you find the site fine and 
>> definitely something which needs to be taken into consideration. 
>>  
>> > 
>> > I say keep it or are you guys going to rearrange things a bit? I ask b/c 
>> > some of the ideas are not BBB.io related. I am not affiliated w/ the >> 
>> > beagleboard.org <http://beagleboard.org>>>  people but I enjoy using their 
>> > boards for learning Linux based initiatives.  
>> > 
>> I would say the biggest problem is the fact that the site still presumes 
>> (and gives the impression) that Machinekit is monorepo. It does not 
>> differentiate between Machinekit-HAL, MKSoCFPGA, EMCApplication, 
>> HAL_ROS_control (when I include the Zultron's project) and other parts. 
>>  
>> And I hope many ideas are not BBB related. I would hate if people thought 
>> that Machinekit is BeagleBone only endeavour. 
>>  
>> > 
>> > I just like motor work, the use of motors, and to mfg. new machines when I 
>> > can to promote the ideas behind it all. Finding open minds is not easy. 
>> > People would rather pay for a Arduino w/ a cheap daughter

Re: [Machinekit] Re: Cold storage or dead?

[cern via Machinekit]

Thank you for the input!

Dec 7, 2020, 07:04 by fun...@gmail.com:

> Hello,
>
> I say start small w/ the site. Add a few hyperlinks to start. Make something 
> official geared towards people like me who are newcomers and willing to spend 
> time dedicated to application. I am a starter in this field but I am getting 
> older and older.
>
Yes, small is something which I had in mind. I don't think there is enough 
power or willingness to do full in-depth rewrite.

>
> ...
>
> Small site and a full representation of a working order would be nice for 
> people staring blindly at the famous pages that seem to multiply quickly when 
> viewing.
>
> I posted a small section from github in the form of a hyperlink. It basically 
> just goes to an incomplete but dedicated piece of text on github that 
> supports machinekit ideas w/ gcode, .ini files, and basics on ideas for 
> setting up commands.
>
> I think this is a good starter for people. I am sure that most of you are 
> very educated in this dept. and do not need to bother w/ newcomers and 
> nonsensical questions. I understand. I have been behind the helm asking silly 
> questions for five years in the BBB.io world. The books were nice at first, 
> the starter scripts were nice too, and in the end, it seems that people 
> stopped their futuristic approach to the entire community of newcomers, their 
> ideas, and bringing old to new.
>
> There is no pressure from me. I can learn from the machinekit.io site like I 
> have been doing. But after a bit of spending time on the site, it is an 
> actually large database. It is easy to use and dedicated to instruction. This 
> is nice.
>
Most people who I talked about the site said to me that it is chaotic, the tree 
structure doesn't make sense and finding anything even with a search engine is 
Herculean task. It is interesting that you find the site fine and definitely 
something which needs to be taken into consideration.

>
> I say keep it or are you guys going to rearrange things a bit? I ask b/c some 
> of the ideas are not BBB.io related. I am not affiliated w/ the 
> beagleboard.org people but I enjoy using their boards for learning Linux 
> based initiatives. 
>
I would say the biggest problem is the fact that the site still presumes (and 
gives the impression) that Machinekit is monorepo. It does not differentiate 
between Machinekit-HAL, MKSoCFPGA, EMCApplication, HAL_ROS_control (when I 
include the Zultron's project) and other parts.

And I hope many ideas are not BBB related. I would hate if people thought that 
Machinekit is BeagleBone only endeavour.

>
> I just like motor work, the use of motors, and to mfg. new machines when I 
> can to promote the ideas behind it all. Finding open minds is not easy. 
> People would rather pay for a Arduino w/ a cheap daughter card so that they 
> can put GRBL or Marlin on it. Machinekit is not the same and is highly 
> configurable. This is what I think is nice about the entire set up you guys 
> have in the CNC world.
>
Well, to be fair, there is a tonnage of interesting ideas in the Arduino world. 
If it all can be somehow interconnected or reused, the better. In terms of 
better documentation, getting up some page comparing Arduino products to 
Machinekit et al. is source of tension than a helpful tool in the long run.

Cern.

>
> But, like my old posts in the field, I say a Cape for the BBB or BBAI would 
> be neat. 
>
> Well, it is late and I have not tested much recently. I just got trying to 
> handle interrupts on some Python3 source via the Motor Bridge Cape, the BBGG, 
> and some other source. Testing will ensue!
>
> Seth
>
> P.S. Nothing is final. Things evolve, people take specific routes, and stuff 
> stays the same. MachineKit!
> On Monday, November 30, 2020 at 12:54:09 PM UTC-6 ce...@tuta.io wrote:
>
>> The was discussion about this problem in the Machinekit chat room. The truth 
>> is that the community support in Machinekit is and was not good (being 
>> tactful) and with changes in development it only got worse.
>>
>> The documentation is bad and obsolete, the site itself is pretty chaotic and 
>> finding information is almost Sisyphean task. Everybody recognises this.
>>
>> The changes happening in development on Github were not manually propagated 
>> here to Google groups. Moreover, the links at top are again long obsolete in 
>> its step-by-step tutorial value (but the overall explanation and goals are 
>> still more or less valid). This is a lot more murky than to say "The site 
>> needs replacement" - because Machinekit always recognised the need for the 
>> user to be proactive and keep a finger on the pulse of development (and 
>> encouraged to do

Re: [Machinekit] Re: Problems building machinekit-cnc from source

[cern via Machinekit]

Hi,
the latest Machinekit-HAL should run on arm64 architecture - there is even 
testing of this: 
https://travis-ci.com/github/machinekit/machinekit-hal/jobs/371433497 (example 
of the latest push). I am not completely sure about the commit 
e81023b8b9ae49a9e971d9da6d424297061772bc, what kind of issue are you 
experiencing?

Cern.

Aug 13, 2020, 10:14 by xuchunmiaom...@gmail.com:

> Hi，Michael 
>    I followed your advice to use the commit id 
> e81023b8b9ae49a9e971d9da6d424297061772bc  and use the  
> ./script/build_with_cnc 
>    but I forgotted that I was running on a ARM64 board，there are many 
> problems occured。
>    Is there a available version on arm64 architecture ？
> 在2020年8月11日星期二 UTC+8 下午10:16:15 写道：
>
>> Yes, the Machinekit-CNC@master cannot be currently built on top of 
>> Machinekit-HAL@master. This was done because the original build flow was 
>> extremely inflexible and the precedence was given to option to build 
>> Enhanced Machine Controller (which is developed as part of LinuxCNC and the 
>> development is much more active than Machinekit's own CNC portions). This is 
>> now possible - >> https://github.com/machinekit/emcapplication>>  and can be 
>> previewed by following instructions here: >> 
>> https://github.com/machinekit/EMCApplication/issues/1#issue-60311>>  . 
>>  
>> I am hoping that Machinekit-CNC will be again buildable on Machinekit-HAL 
>> after CMake build system switch, which should filter out problems stemming 
>> out from kernel-space module past and streamline the whole operation. 
>>  
>> Cern. 
>>  
>>  
>> Aug 11, 2020, 11:23 by >> xuchunm...@gmail.com <>>> : 
>>  
>> > I also encountered  the same problem 。I‘ll try this check out later。 
>> > You just solved this problem by check out commit id？ 
>> > 
>> > 在 2020年6月21日星期日 UTC+8上午1:14:17，Michael Labuda写道： 
>> > 
>> >> Hello, 
>> >> 
>> >> I am setting up a development environment and trying to build machine-kit 
>> >> from source, I was able to build machinekit-hal without any problems, but 
>> >> machinekit-cnc is a different story. Following instructions given on >> 
>> >> >> https://www.machinekit.io/>> >> docs/developing/machinekit->> 
>> >> developing/#get-source-and->> build>>  I encountered problems immediately 
>> >> as there is no build_with_cnc script included in the machinekit git. I 
>> >> found this script in someone else's repo and copied it over. It started 
>> >> to compile but then failed after it couldn't find 
>> >> /machinekit-cnc/src/libnml/>> nml/inifile.XX. These appear to be symlinks 
>> >> to some fakeinclude directory. I put in some dummy empty inifile.XX files 
>> >> which got me a bit further but other source files are actually attempting 
>> >> to use an Inifile class that doesn't exist. What's going on here? Did I 
>> >> clone the wrong repo or something? 
>> >> 
>> >> 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+...@googlegroups.com <>>> > . 
>> >  To view this discussion on the web visit > >> 
>> > https://groups.google.com/d/msgid/machinekit/2846e9a6-95ea-486f-abcf-44e958b00798o%40googlegroups.com>>
>> >   <>> 
>> > https://groups.google.com/d/msgid/machinekit/2846e9a6-95ea-486f-abcf-44e958b00798o%40googlegroups.com?utm_medium=email&utm_source=footer>>
>> >  >> . 
>> > 
>>  
>>
>
>
>
> --
>  website: > http://www.machinekit.io>  blog: > http://blog.machinekit.io>  
> github: > https://github.com/machinekit
>  --- 
>  You received this message because you are subscribed to the Google Groups 
> "Machinekit" group.
>  To unsubscribe from this group and stop receiving emails from it, send an 
> email to > machinekit+unsubscr...@googlegroups.com> .
>  To view this discussion on the web visit > 
> https://groups.google.com/d/msgid/machinekit/a74db377-e255-49ac-9545-29180951fa14n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/a74db377-e255-49ac-9545-29180951fa14n%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/MEbj8ZJ--3-2%40tuta.io.

Re: [Machinekit] Re: Problems building machinekit-cnc from source

[cern via Machinekit]

Yes, the Machinekit-CNC@master cannot be currently built on top of 
Machinekit-HAL@master. This was done because the original build flow was 
extremely inflexible and the precedence was given to option to build Enhanced 
Machine Controller (which is developed as part of LinuxCNC and the development 
is much more active than Machinekit's own CNC portions). This is now possible - 
https://github.com/machinekit/emcapplication and can be previewed by following 
instructions here: 
https://github.com/machinekit/EMCApplication/issues/1#issue-60311 .

I am hoping that Machinekit-CNC will be again buildable on Machinekit-HAL after 
CMake build system switch, which should filter out problems stemming out from 
kernel-space module past and streamline the whole operation.

Cern.


Aug 11, 2020, 11:23 by xuchunmiaom...@gmail.com:

> I also encountered  the same problem 。I‘ll try this check out later。
> You just solved this problem by check out commit id？
>
> 在 2020年6月21日星期日 UTC+8上午1:14:17，Michael Labuda写道：
>
>> Hello,
>>
>> I am setting up a development environment and trying to build machine-kit 
>> from source, I was able to build machinekit-hal without any problems, but 
>> machinekit-cnc is a different story. Following instructions given on >> 
>> https://www.machinekit.io/>> docs/developing/machinekit->> 
>> developing/#get-source-and->> build>>  I encountered problems immediately as 
>> there is no build_with_cnc script included in the machinekit git. I found 
>> this script in someone else's repo and copied it over. It started to compile 
>> but then failed after it couldn't find /machinekit-cnc/src/libnml/>> 
>> nml/inifile.XX. These appear to be symlinks to some fakeinclude directory. I 
>> put in some dummy empty inifile.XX files which got me a bit further but 
>> other source files are actually attempting to use an Inifile class that 
>> doesn't exist. What's going on here? Did I clone the wrong repo or something?
>>
>> 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> .
>  To view this discussion on the web visit > 
> https://groups.google.com/d/msgid/machinekit/2846e9a6-95ea-486f-abcf-44e958b00798o%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/2846e9a6-95ea-486f-abcf-44e958b00798o%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/MESsDiT--Z-2%40tuta.io.

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

[cern via Machinekit]

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 
>> <http://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 

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

[cern via Machinekit]

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

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

[cern via Machinekit]

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://g

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

[cern via Machinekit]

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&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/MD23CoJ--3-2%40tuta.io.

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

[cern via Machinekit]

Jun 25, 2020, 01:53 by blazin...@gmail.com:

> Linuxcnc has a hal driver for ethercat master as it doesn't require any 
> special hardware. 
>
There was support for quite some time now, that's not the problem.

>
> Ethercat slaves AFAIK require an ASIC and it's pretty expensive.
>
Ethercat slave requires a licence - whatever that is ASIC or code is not that 
important. And the license is relatively cheap, the LAN9252 costs around 8 Euro 
in 1-piece quantity.

>
>  I hear alot of talk of ethercat but rarely see it actually used in industry. 
> I don't know the status of the hal ethercat driver in MK but if it's not 
> there why can't it be added (meaning what does it have to do with Beaglebone 
> specifically). As for the slave, Not really sure I see why you would use a BB 
> as a slave but it sounds like it's not practical. 
>
BeagleBone AI uses AM5729, which in contrast to the one used in BBB should have 
a Ethercat slave support. You can then use the PRU for exchange of Ethercat 
messages and create distributed, multi-node system (multi Machinekit instances).

>
> If this was something I were gonna use I'd be glad to have a smart serial 
> channel or 2
>
This seems like an asymmetry to me. You say that nobody use Ethercat based 
systems, but then want a support for solution that really nobody use and is not 
that good in first place.

Why not use something which is developed and backed by a quite big group 
instead of one-man-show?

But that's probably off-topic to this discussion, as it is going to be a 
CRAMPS-like board. That's why I am interested in what it will mean for the 
software side.

Cern.

> On Wednesday, June 24, 2020 at 6:09:06 PM UTC-4, ce...@tuta.io wrote:
>
>> Hi, 
>> Jun 23, 2020, 20:45 by >> jkri...@beagleboard.org <>>> : 
>>  
>> > On Thu, Mar 12, 2020 at 7:14 PM justin White <> >> blaz...@gmail.com <>>> 
>> > > > wrote: 
>> > 
>> >>> On Thursday, March 12, 2020 at 6:32:52 PM UTC-4, Chris Albertson wrote: 
>> >>> 
>> >>>> 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 
>> >>> Redondo Beach, California 
>> >>> 
>> >> 
>> >> But that's not what they are going for "Help assemble and provide 
>> >> software images configured for an open source 3D printer and CNC machine 
>> >> (with BeagleBoard.org and community guidance and support)"..Pretty 
>> >> much sums up the mission statement. If they're looking to showcase the 
>> >> Beaglebone hardware as part of an official beaglebone supported piece, I 
>> >> seriously doubt they're looking to offload IO to a microcontroller and 
>> >> develop the firmware for it when: 
>> >>   
>> >> 
>> >>> * Manufacture the design under the BeagleBoard.org name to support the 
>> >>> BeagleBoard.org Foundation and community 
>> >>> 
>> >> 
>> >> Everytime someone mentions something like this people get all starry eyed 
>> >> about it.It's going to be Seeed's version of Cramps. The most helpful 
>> >> suggestions would probably be along those lines. Jason will have to 
>> >> clarify but I'm pretty sure this is a maker focused thing, Ethercat and 
>> >> analog outputs for each axis are not going to happen.  
>> >> 
>> > 
>> > Your statement is mostly accurate. I've gotten a bit distracted and 
>> > overwhelmed by the input as "Seeed's version of Cramps" was indeed the 
>> > intended scope. We all need something like CRAMPS and we need it readily 
>> > available. It isn't that we aren't willing to put in some more effort 
>> > here, but I want to right-

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

[cern via Machinekit]

Hi,
Jun 23, 2020, 20:45 by jkrid...@beagleboard.org:

> On Thu, Mar 12, 2020 at 7:14 PM justin White <> blazin...@gmail.com> > wrote:
>
>>> On Thursday, March 12, 2020 at 6:32:52 PM UTC-4, Chris Albertson wrote:
>>>
>>>> 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
>>> Redondo Beach, California
>>>
>>
>> But that's not what they are going for "Help assemble and provide software 
>> images configured for an open source 3D printer and CNC machine (with 
>> BeagleBoard.org and community guidance and support)"..Pretty much sums 
>> up the mission statement. If they're looking to showcase the Beaglebone 
>> hardware as part of an official beaglebone supported piece, I seriously 
>> doubt they're looking to offload IO to a microcontroller and develop the 
>> firmware for it when:
>>  
>>
>>> * Manufacture the design under the BeagleBoard.org name to support the 
>>> BeagleBoard.org Foundation and community
>>>
>>
>> Everytime someone mentions something like this people get all starry eyed 
>> about it.It's going to be Seeed's version of Cramps. The most helpful 
>> suggestions would probably be along those lines. Jason will have to clarify 
>> but I'm pretty sure this is a maker focused thing, Ethercat and analog 
>> outputs for each axis are not going to happen. 
>>
>
> Your statement is mostly accurate. I've gotten a bit distracted and 
> overwhelmed by the input as "Seeed's version of Cramps" was indeed the 
> intended scope. We all need something like CRAMPS and we need it readily 
> available. It isn't that we aren't willing to put in some more effort here, 
> but I want to right-size this based on what will be most broadly used.
>
isn't that market already pretty filled with various MCU based boards and such? 
Don't get me wrong, I am all for new hardware, but I am wondering what the edge 
in this case would be. Because though it pains me to say this - even 
Open-Source project (hardware and software) needs marketing. Machinekit wasn't 
really that successful on that front in the past and it can be seen on the 
socFPGA work (in diplomatic speak).

Maybe some kind of combination of Centroid Acorn and CRAMPS, I can see people 
wanting it. (But then people always want all-in-one solution which somebody 
else already thought of.)

Let's talk about what it would mean from software side (as this is the side 
which I am most interested in) - I presume you want to run Machinekit on it, 
right? So how do you envision this? There already is some effort to support BB 
AI from the PocketNC company.

>
> Sorry I got distracted from this thread for a while. I'm going to re-engage 
> over the next few days to get this kicked-off.
>
> Ethercat is somewhat of an option. We could support Ethercat on BeagleBone AI 
> with some software investment.
>
I have always considered distributed multi-node system the holy grail, so I 
would be very much interested in solution, which could function both as master 
and as slave on some kind of industrial bus network.

Cern

>  
>
>>
>> Realistically that is the Machinekit audience anyway, otherwise mksocfpga 
>> would have quite a bit more interest than Beaglebone projects, Try running 
>> out of IO on a DE10-Nano, you could probably run a Haas with all that IO.
>>
>
>
> We can get more I/O out of BeagleBone, but I don't want to quickly get to the 
> situation where we add a bunch of hardware that is useless for 90% of people.
>
>
>>
>>
>>
>> --
>>  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 >

Re: [Machinekit] Problems building machinekit-cnc from source

[cern via Machinekit]

Hi,

Jun 20, 2020, 19:14 by michael.labud...@gmail.com:

> Hello,
>
> I am setting up a development environment and trying to build machine-kit 
> from source, I was able to build machinekit-hal without any problems, but 
> machinekit-cnc is a different story. Following instructions given on > 
> https://www.machinekit.io/docs/developing/machinekit-developing/#get-source-and-build>
>   I encountered problems immediately as there is no build_with_cnc script 
> included in the machinekit git. 
>
Yeah, the building of Machinekit-CNC is currently broken with work on 
supporting the EMCApplication work from Zultron. You can read more about it in 
https://github.com/machinekit/machinekit-hal/issues/267 . I am currently 
working on it but is it going slower that I would have liked. I am also 
changing the workflow of the building to be simpler and saner (actually read: 
So I like it better), so it is pretty unstable at the moment. The 
Machinekit-CNC will need to be updated to the same style as EMCApplication to 
actually function.

>
> I found this script in someone else's repo and copied it over. It started to 
> compile but then failed after it couldn't find 
> /machinekit-cnc/src/libnml/nml/inifile.XX. These appear to be symlinks to 
> some fakeinclude directory. I put in some dummy empty inifile.XX files which 
> got me a bit further but other source files are actually attempting to use an 
> Inifile class that doesn't exist. What's going on here? Did I clone the wrong 
> repo or something?
>
No, you cloned the right one. Probably. Checkout the 
e81023b8b9ae49a9e971d9da6d424297061772bc to use the scripts/build_with_cnc 
script.

Cern.

>
> 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> .
>  To view this discussion on the web visit > 
> https://groups.google.com/d/msgid/machinekit/85ea14a0-48a5-4b27-b4d0-ebf1fd2d7575o%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/85ea14a0-48a5-4b27-b4d0-ebf1fd2d7575o%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/MAI7W1N--3-2%40tuta.io.

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

[cern via Machinekit]

Hi,
Jun 9, 2020, 22:25 by juha.hei...@gmail.com:

> Hmm out of curiosity why would you require 2 separate EtherCat ports or is it 
> just for a ring topology?
>
> If you can settle for just one, you could run the igh EtherCat master stack 
> on the BBB and use available LAN port. So if one is enough, no need to mixup 
> the cape with the EtherCat stuff.
>
> ”Ideally” for an industrial approach you could do ”minimal” setup on the cape 
> and then (I think someone suggested this in the past) make a bunch of 
> EtherCat slaves. Using a microchip LAN9252 coupled with a microcontoller is 
> relatively simple to make and somewhat cheap. From the top of my head ill say 
> the 9252 requires some 50 components around it and most just resistors and 
> capacitors. The EtherCat slave license ”comes with” the LAN9252 so no issues 
>
> If you pair the slave controller with a popular mcu I think the community 
> could do a lot in the EtherCat slave world.
>
There actually already is a similar project: 
https://github.com/DieBieEngineering/DieBieSlave - problem is, it's not exactly 
community DIY friendly, it has 6 layers PCB.

Then there is the XMC4800 MCU from Infineon which has Ethercat integrated.

Cern.

>
> Just my 2 cents.
>
> tiistai 9. kesäkuuta 2020 Stephen Bell <> bell.stephe...@gmail.com> > 
> kirjoitti:
>
>> Agreed on the massive requirements disparity. In my view, given how 
>> saturated the market is for stepper-motor based control boards (particularly 
>> the Duet 3, which can be controlled by a BBB/RPi) I'd prefer a more 
>> Break-out-Board style cape to make industrial-level control more accessible. 
>>
>> My ideal cape would have dual etherCAT RJ45 ports, an RS422 or 485 header 
>> with voltage selection for PLC/spindle vfd control, UART headers, dual CAN 
>> headers and a small array of optoisloators for the other GPIO. Biggest 
>> problem for this is the ethercat license, which is somewhat of a pain...
>>
>> I also prefer the web-based GUIs locally hosted on the device, which can be 
>> accessed across the network and use less resources than a driven display and 
>> a native GUI, so I'd prefer a cape NOT be limited by a desire to have a 
>> screen/monitor from the BBB. 
>>
>> just my 2C
>>
>> On Sunday, June 7, 2020 at 12:46:01 AM UTC-4, Malte Schmidt wrote:
>>
>>> I think the issue is always that the requirements with these machines are 
>>> very different and that you never quite get what is needed.
>>>
>>>
>>> When I build the cape I use on my lathe I sort of used a modular design. I 
>>> based this on a prototype cape and used those small optocoupler and level 
>>> shift modules that you get from China for the maker scene. It looks quite 
>>> like a hack but you might see the three opto modules in the back and the 
>>> two level shifters here:
>>> https://forum.zerspanungsbude.>>> net/download/file.php?id=18836>>> 
>>> 6&mode=view
>>> There is an external pwm-> 0-10V module as well (not shown) for spindle 
>>> control
>>>
>>>
>>>
>>>
>>> I always thought about making this nicer. I would have done it this way:
>>> A cape that:
>>> - Make PRU and GPIO Pins available in sets of 4? pins on standardized PIN 
>>> headers + power.
>>> - Makes the terminals for connecting the cables available
>>>
>>>
>>>
>>> PLUS
>>>
>>>
>>>
>>> Small modules for level shift, opto isolation , spindle control (as 
>>> desired). These would use the standardized connectors on the cape.
>>> For this I would actually rely on stuff that is already available (if so).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>>  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+unsubscribe@googleg>> roups.com>> .
>>  To view this discussion on the web visit >> 
>> https://groups.google.com/d/ms>> gid/machinekit/4e75a7ba-b13f-4>> 
>> 579-a7f1-09211ff4cbd7o%40googl>> egroups.com 
>> <https://groups.google.com/d/msgid/machinekit/4e75a7ba-b13f-4579-

Re: [Machinekit] Re: halcmd setp equivalent in python

[cern via Machinekit]

May 19, 2020, 18:14 by mib.holotro...@gmail.com:

> Well seems like my brain started working again and I found out that this 
> construction fits that task:
>
>     os.system("halcmd setp hm2_5i25.0.pwmgen.00.scale %s "%(c.find('SPINDLE', 
> 'MAXRPM')))
>
> On a side note according to this post:
> https://www.mail-archive.com/search?l=machinekit@googlegroups.com&q=subject:%22%5C%5BMachinekit%5C%5D+Machinekit+Advanced+HAL+Tutorial%22&o=newest&f=1
> Parameters are depreciated in machinekit-hal so,
> It could seem like a great idea to convert all the Params in hm2 to pins ?
> Unless there are worries about breaking too many existing Machinekit mesa hm2 
> configs ?
>
Look at https://github.com/machinekit/machinekit-hal/issues/260 - the idea to 
delete lower functions and make the Parameters C API simply call Pin API 
probably has the best chance at being passable.

Cern.

>
> Best wishes
> Michael Brown
>
>
>
>
> On Tuesday, May 19, 2020 at 5:47:05 PM UTC+2, Michael Brown wrote:
>
>> Perhaps I will clarify if I point directly to the exact file I'm attempting 
>> to rectify:
>> https://github.com/the->> snowwhite/Hm2-soc_FDM/blob/>> 
>> work/Cramps/PY/OX/cramps.py#>> L91
>>
>> I'm trying to replace the hard coded 12000 below with the parameter 
>> MAXRPM from the .ini file 
>> <https://github.com/the-snowwhite/Hm2-soc_FDM/blob/work/Cramps/PY/OX/ox.ini#L382>
>> os.system('halcmd setp hm2_5i25.0.pwmgen.00.scale 12000')
>>
>> I cannot see how to make this work:
>>
>> os.system('halcmd setp hm2_5i25.0.pwmgen.00.scale >> c>> .>> f>> ind>> (>> 
>> 'SPINDLE'>> , >> 'MAXRPM'>> )>> ')
>>
>>
>> On Tuesday, May 19, 2020 at 5:05:42 PM UTC+2, Bas de Bruijn wrote:
>>
>>>
>>>  
>>>
>>>
>>>  
>>>
>>>
>>> From:>>>  >>> machi...@googlegroups.com <>>>>  <>>> 
>>> machi...@googlegroups.com <>>>> > >>> On Behalf Of >>> justin White
>>> Sent:>>>  Tuesday, 19 May 2020 17:01
>>> To:>>>  Machinekit <>>> machi...@googlegroups.com <>>>> >
>>> Subject:>>>  Re: [Machinekit] Re: halcmd setp equivalent in python
>>>
>>>  
>>>
>>>
>>>  
>>>
>>>
>>> Yeah, I forgot Machinekit is in a perpetual state of "this might work the 
>>> way it used to".or "maybe not". I've recompiled components to swap 
>>> parameters for pins but I don't think I'd try with a hm2 driver.
>>>
>>>
>>>  
>>>
>>>
>>> If all you want to do is set a parameter from an .ini line you don't have 
>>> to do anything with Python whatsoever (unless there's some reason you 
>>> really want to). All you need to do is:
>>>
>>>
>>>  
>>>
>>>
>>> In the .ini
>>>
>>>
>>>  
>>>
>>>
>>> [SPINDLE]
>>>
>>>
>>> MAXRPM = 12000
>>>
>>>
>>>  
>>>
>>>
>>> In the hal file:
>>>
>>>
>>> setp hm2_5i25.0.pwmgen.00.scale [SPINDLE]MAXRPM
>>>
>>>
>>>  
>>>
>>>
>>> That's the pretty standard usage, or am I missing something?
>>>
>>>
>>>  
>>>
>>>
>>>  
>>>
>>>
>>>  
>>>
>>>
>>> Yes, we were talking of doing this from python (see subject)
>>>
>>>
>
>
>
> --
>  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/05d8021e-c605-4c46-90ba-8eaddc03fee8%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/05d8021e-c605-4c46-90ba-8eaddc03fee8%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/M7ia3J6--3-2%40tuta.io.

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

[cern via Machinekit]

Hi,
May 14, 2020, 15:46 by jkrid...@beagleboard.org:

> 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 don't have the answers. If you/we can make something that works 
> for an interesting and engaged set of the Machinekit population, that'd be 
> good with me. Ultimately, what I want to make is a pick-and-place machine for 
> myself so that I can bootstrap Beagles making Beagles. Still, I'd be happy as 
> a first step if I can just replace the 3D printer controllers with something 
> Beagle-based that I can understand and hack.
>
> I should check in with the PocketNC folks to see what their cape requirements 
> are. I'm sure I've checked in the past, but I slept since then.
>
have you seen this: https://github.com/machinekit/machinekit-hal/issues/284 ?

Cern.

>
> On Sun, Apr 5, 2020 at 4:11 PM Peter RCNC Newbery <> rcn...@gmail.com> > 
> wrote:
>
>>
>> Hi John,
>>
>>
>> I am aware of the Replicape hardware but they’re no longerproducing this 
>> cape and its being phased out for their new up and coming hardware,so again 
>> there is little to no cape support available for the BBB. I startingto think 
>> the BBB might not be the best solution… 
>>
>>
>>
>>
>>
>> What are other people using?
>>
>>
>>
>>
>>
>> However, I don’t think I was clear with my first post. I’mnot building this 
>> for a 3D printer. This it for a CNC router.
>>
>>
>>
>>
>>
>> I might hold of a little longer with this cape and re-accessmy options. I 
>> might stay with Marlin (known and working solution for me but notreal time) 
>> or look more into some other options on the market that don’t breakthe bank. 
>>
>>
>>
>>
>>
>>
>>
>> On Saturday, April 4, 2020 at 11:58:55 PM UTC+1, John Dammeyer wrote:
>>
>>>
>>> Hi Peter,
>>>
>>>
>>> Much of what you are providing is already there with the >>> Replicape>>>  
>>> which by the looks of it is out of stock.
>>>
>>>
>>> https://www.thing-printer.com/product/replicape/
>>>
>>>
>>> I've got one but haven't yet connected it to my Delta 3D printer.>>>   >>> 
>>> I had problems with the Manga Screen touch sensitivity.>>>   >>> I sent it 
>>> back and it was confirmed to be working.>>>   >>> Came back here and didn't 
>>> work any better.>>>   >>> I then bought a Manga 2 screen but haven't 
>>> progressed with the project.
>>>
>>>
>>>  
>>>
>>>
>>> Looking at the Root CNC web site it seems like you have a pretty impressive 
>>> little project there.>>>   >>>  >>> And I believe the BBB software to 
>>> support such a printer is already in place with the >>> replicape>>> .>>>   
>>> >>> So I'd suggest from a software perspective that is a good starting 
>>> point.>>>   >>> Granted it's targeted at 3D printing but the infrastructure 
>>> for motor control is there.
>>>
>>>
>>>  
>>>
>>>
>>> I have a CNC router running with MACH3 and more than happy with it. >>>  
>>> >>> Haven't seen a reason to change over to anything else that has 3A 55V 
>>> drivers.>>>   >>> And a CNC router is definitely a project that requires a 
>>> CNC program.>>>   >>> It's not something you use with hand wheels like a 
>>> milling machine.
>>>
>>>
>>>  
>>>
>>>
>>> OTOH, a milling machine that

Re: [Machinekit] vfdb_vfd missing from latest machinekit-hal

[cern via Machinekit]

Hi,
May 13, 2020, 18:57 by j...@pocketnc.com:

> It looks like the vfdb_vfd HAL module was removed when machinekit-hal 
> separated from the main machinekit repository (> this commit 
> <https://github.com/machinekit/machinekit-hal/commit/f2d740fd31e74353eed84c318fb0ba0fa24365fd>>
>  ). 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?
>
I think that it was probably left out by omission and not intentionally. The 
same way MB2HAL was. (Since already integrated back to Machinekit-HAL.) I don't 
see any reason why it should not be integrated back into the source-tree. You 
may want to try the more universal Modbus modules like the MB2HAL or the new 
https://github.com/aekhv/vfdmod

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/7ec7127d-1349-4533-bb2e-f172836defc9%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/7ec7127d-1349-4533-bb2e-f172836defc9%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/M7IZLIX--3-2%40tuta.io.

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

[cern via Machinekit]

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&offset=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&utm_source=footer>>>
>>  .
>>
>
>
>
> --
>  website: > http://www.machinekit.io>  blog: > http://blog.machinekit.io>  
> github: > https://github.com/machinekit
>  --- 
>  You received this message because you are subscribed to the Google Groups 
> "Machinekit" group.
>  To unsubscribe from this group and stop receiving emails from it, send an 
> email to > machinekit+unsubscr...@googlegroups.com> .
>  To view this discussion on the web visit > 
> https://groups.google.com/d/msgid/machinekit/CAPEK9qbEdq5hL4p5yNsWa6DSTthhed-vM7CBdSBX%3DFPHMZ0BBg%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/machinekit/CAPEK9qbEdq5hL4p5yNsWa6DSTthhed-vM7CBdSBX%3DFPHMZ0BBg%40mail.gmail.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/M6Ht6hJ--3-2%40tuta.io.

Re: [Machinekit] Travis CI builds of machinekit-cnc

[cern via Machinekit]

Hi,
I was somewhat successful in solving this issue. Description on Github: 
https://github.com/machinekit/machinekit-hal/issues/271

Cern.


Apr 11, 2020, 01:38 by machinekit@googlegroups.com:

> Hmmm,
> it looks like package installation should be included in CI test run.
>
> I am no expert at packaging, either. Debian or otherwise. (This is Zultron's 
> area and I hope he will pop in.) What I discovered so far is that there was 
> some discussion about functionality which would allow excluding files 
> previously included by wildcard resolution in .install files: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436240 , but I don't think 
> it is currently available. (Debian developers are probably not big on set 
> operations.)
>
> The only thing I can come with up now, is to create script which would cure 
> the .install files at runtime and be placed here: 
> https://github.com/machinekit/machinekit-hal/blob/98a93c227ac2fa4e81aca40887d08b717eb926ad/debian/rules#L149
>  . Trying to just list all files manually fails because not all platforms 
> create all files. (On the same note: usr/share/linuxcnc/Makefile.*) (First 
> thing I tried: https://github.com/cerna/machinekit-hal/actions/runs/75572559 )
>
> I think this is serious bug and should be solved (somewhat) properly. 
> Zultron, what so you think?
>
> BTW, didn't you want to create the build pipeline on Travis? Maybe I gave the 
> wrong impression: The reason why I chose the Github Actions is that it can 
> (at least I think it can) provide turn-key solution for everybody with just 
> forking the repo on Github without the need for setting up tokens and 
> whatnots. However, by the motto of "more stripes, more adidas" I fully 
> support and plan to multiple CD/CI services - so when one goes under or stops 
> the free plan, nothing really happens.
>
> BTW, building Docker images with this logic: 
> https://github.com/cmcquinn/machinekit-hal/blob/master/.github/workflows/docker-containers.yaml
>  won't work because in Github Actions workflows cannot wait on each other. So 
> the one building Docker images will run on the same time as the one building 
> the Machinekit application. So the one building the Machinekit application 
> will pull the older images and very probably fail. It all has to be 
> integrated into one workflow.
>
> Cern.
>
>
> Apr 10, 2020, 03:18 by cameron.mcqu...@gmail.com:
>
>> Alright so I've been working on getting automated Docker container builds 
>> going, and I've run into a hiccup. As you mentioned, machinekit-cnc needs 
>> files from machinekit-hal to build, and the approach that I am taking to 
>> solve the problem is to build Docker containers for machinekit-cnc using the 
>> ones for machinekit-hal as a base, and installing the Debian packages 
>> generated from the mk-hal build into the mk-cnc containers. Here is where I 
>> run into a problem. The build needs header files that are provided by the 
>> machinekit-hal-dev package, which depends on machinekit-hal, but both 
>> packages provide /usr/bin/comp. When installing via apt-get install, apt 
>> detects that machinekit-hal-dev tries to overwrite /usr/bin/comp from 
>> machinekit-hal and aborts the install. This behavior can be mitigated for 
>> non sys_root environments by passing -o Dpkg::Options::="--force-overwrite" 
>> to apt. However, when those two packages are specified in a multistrap 
>> config, multistrap fails silently and does not install any of the machinekit 
>> packages.
>>
>> I am not very familiar with Debian packaging, but noticed that the file 
>> debian/machinekit-hal.install in the mk-hal repo contains the line usr/bin/* 
>> which I assume sweeps up everything produced by the build under /usr/bin and 
>> puts it into the Debian package. Is there a way to exclude /usr/bin/comp 
>> from the machinekit-hal package so that we can install the 
>> machinekit-hal-dev package in multistrap systems?
>>
>> You can follow along with what I have been doing at > 
>> cmcquinn/machinekit-hal <https://github.com/cmcquinn/machinekit-hal>>  and > 
>> cmcquinn/machinekit-cnc <https://github.com/cmcquinn/machinekit-cnc>> .
>>
>> Regards,
>> Cameron McQuinn
>>
>> On Sunday, March 22, 2020 at 8:00:20 AM UTC-6, ce...@tuta.io wrote:
>>
>>> Hi, 
>>> Mar 22, 2020, 03:09 by >> cameron...@gmail.com <>>> : 
>>>  
>>> > What is the status of Travis CI builds for machinekit-cnc? I would love 
>>> > to help get this going if needed. Let me know how I can help :) 
>>> > 
>>> The current status is 

Re: [Machinekit] Travis CI builds of machinekit-cnc

[cern via Machinekit]

Hmmm,
it looks like package installation should be included in CI test run.

I am no expert at packaging, either. Debian or otherwise. (This is Zultron's 
area and I hope he will pop in.) What I discovered so far is that there was 
some discussion about functionality which would allow excluding files 
previously included by wildcard resolution in .install files: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436240 , but I don't think it 
is currently available. (Debian developers are probably not big on set 
operations.)

The only thing I can come with up now, is to create script which would cure the 
.install files at runtime and be placed here: 
https://github.com/machinekit/machinekit-hal/blob/98a93c227ac2fa4e81aca40887d08b717eb926ad/debian/rules#L149
 . Trying to just list all files manually fails because not all platforms 
create all files. (On the same note: usr/share/linuxcnc/Makefile.*) (First 
thing I tried: https://github.com/cerna/machinekit-hal/actions/runs/75572559 )

I think this is serious bug and should be solved (somewhat) properly. Zultron, 
what so you think?

BTW, didn't you want to create the build pipeline on Travis? Maybe I gave the 
wrong impression: The reason why I chose the Github Actions is that it can (at 
least I think it can) provide turn-key solution for everybody with just forking 
the repo on Github without the need for setting up tokens and whatnots. 
However, by the motto of "more stripes, more adidas" I fully support and plan 
to multiple CD/CI services - so when one goes under or stops the free plan, 
nothing really happens.

BTW, building Docker images with this logic: 
https://github.com/cmcquinn/machinekit-hal/blob/master/.github/workflows/docker-containers.yaml
 won't work because in Github Actions workflows cannot wait on each other. So 
the one building Docker images will run on the same time as the one building 
the Machinekit application. So the one building the Machinekit application will 
pull the older images and very probably fail. It all has to be integrated into 
one workflow.

Cern.


Apr 10, 2020, 03:18 by cameron.mcqu...@gmail.com:

> Alright so I've been working on getting automated Docker container builds 
> going, and I've run into a hiccup. As you mentioned, machinekit-cnc needs 
> files from machinekit-hal to build, and the approach that I am taking to 
> solve the problem is to build Docker containers for machinekit-cnc using the 
> ones for machinekit-hal as a base, and installing the Debian packages 
> generated from the mk-hal build into the mk-cnc containers. Here is where I 
> run into a problem. The build needs header files that are provided by the 
> machinekit-hal-dev package, which depends on machinekit-hal, but both 
> packages provide /usr/bin/comp. When installing via apt-get install, apt 
> detects that machinekit-hal-dev tries to overwrite /usr/bin/comp from 
> machinekit-hal and aborts the install. This behavior can be mitigated for non 
> sys_root environments by passing -o Dpkg::Options::="--force-overwrite" to 
> apt. However, when those two packages are specified in a multistrap config, 
> multistrap fails silently and does not install any of the machinekit packages.
>
> I am not very familiar with Debian packaging, but noticed that the file 
> debian/machinekit-hal.install in the mk-hal repo contains the line usr/bin/* 
> which I assume sweeps up everything produced by the build under /usr/bin and 
> puts it into the Debian package. Is there a way to exclude /usr/bin/comp from 
> the machinekit-hal package so that we can install the machinekit-hal-dev 
> package in multistrap systems?
>
> You can follow along with what I have been doing at > cmcquinn/machinekit-hal 
> <https://github.com/cmcquinn/machinekit-hal>>  and > cmcquinn/machinekit-cnc 
> <https://github.com/cmcquinn/machinekit-cnc>> .
>
> Regards,
> Cameron McQuinn
>
> On Sunday, March 22, 2020 at 8:00:20 AM UTC-6, ce...@tuta.io wrote:
>
>> Hi, 
>> Mar 22, 2020, 03:09 by >> cameron...@gmail.com <>>> : 
>>  
>> > What is the status of Travis CI builds for machinekit-cnc? I would love to 
>> > help get this going if needed. Let me know how I can help :) 
>> > 
>> The current status is that it is not working. And frankly have no idea if it 
>> ever worked or was just left as a something from the original split into 
>> separate repositories. I am currently trying to implement the CI/CD flow 
>> based on Github Actions. (You can read about it here: >> 
>> https://github.com/machinekit/>> machinekit-hal/issues/268>>  .) Main reason 
>> for this is the higher limits for Open-Source project, it is simply in the 
>> Github repository, so every fork will have it by default and Github 

Re: [Machinekit] Machinekit Buster missing dependency (Debian)?

[cern via Machinekit]

No, just installing python-yapps is not enough.

The whole Machinekit/machinekit branch of development with its repository 
https://github.com/machinekit/machinekit is no longer developed and so new 
versions of packages are not going to happen. So the needed change is not going 
to be done there.

But given that you already have dpkg .deb package of Machinekit (probably from 
deb.machinekit.io), you can manually alter that dpkg package to use 
python-yapps. Tutorial is (for example) here: 
http://www.lucademarini.com/thedarkmaster/2008/05/24/how-to-create-manipulate-a-deb-file-of-a-compiled-application/
 You will trash the original PGP signature, but that's no concern for your 
needs.

Cern.

Apr 5, 2020, 14:08 by jiriprochazka...@gmail.com:

> Sorry, maybe it is a silly question, but how do I update the machinekit 
> package?
> I guess that installing python-yapps is not enough.
>
> Thank you 
> Jiri
>
> Dne neděle 5. dubna 2020 13:14:56 UTC+2 ce...@tuta.io napsal(a):
>
>> Hi, 
>> Apr 5, 2020, 08:40 by >> jiripro...@gmail.com <>>> : 
>>  
>> > Any update on this issue now? 
>> > 
>> yes, this issue was solved by ORing python-yapps (which is in buster: >> 
>> https://packages.debian.org/>> buster/python-yapps>>  ) in place of 
>> yapps2-runtime (which is only for jessie and stretch: >> 
>> https://packages.debian.org/>> stretch/yapps2-runtime>>  ). 
>>  
>> However, machinekit package is obsolete. So it was probably not fixed there. 
>> You can just update the package to use another dependency. 
>>  
>> Cern. 
>>  
>> > Because I am having the same problem. 
>> > 
>> > The following packages have unmet dependencies: 
>> >  machinekit-rt-preempt : Depends: machinekit (= 
>> > 0.1.1570528621.git9239acb-1~>> buster) but it is not going to be installed 
>> >                          Depends: yapps2-runtime but it is not installable 
>> > E: Unable to correct problems, you have held broken packages. 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > Dne neděle 16. února 2020 18:06:37 UTC Mr Greg napsal(a): 
>> > 
>> >> 
>> >> 
>> >> On Sunday, 16 February 2020 17:13:15 UTC, >> >> ce...@tuta.io <>>>  <>>>  
>> >> wrote: 
>> >> 
>> >>> Hello, 
>> >>> Feb 16, 2020, 16:59 by >>> >> mr84...@gmail.com <>>>  <>>>> : 
>> >>>   
>> >>> > 
>> >>> > 
>> >>> > On Sunday, 16 February 2020 14:42:33 UTC, >>> >> ce...@tuta.io <>>>  
>> >>> > <>>>>   wrote: 
>> >>> > 
>> >>> >> Hello, 
>> >>> >> Feb 15, 2020, 22:06 by >> >>> >> mr84...@gmail.com <>>>  <>>>>  <>>> 
>> >>> >> : 
>> >>> >> 
>> >>> >> > 
>> >>> >> > 
>> >>> >> > On Saturday, 15 February 2020 20:26:24 UTC, Bas de Bruijn  wrote: 
>> >>> >> > 
>> >>> >> >> 
>> >>> >> >> > Any known workaround for this problem? 
>> >>> >> >>   
>> >>> >> >> Try installing the package manually first. `sudo apt install 
>> >>> >> >> ` 
>> >>> >> >> 
>> >>> >> > 
>> >>> >> > 
>> >>> >> > 
>> >>> >> > My problem is the package   no longer exists in 
>> >>> >> > Buster. It has been removed. 
>> >>> >> > See 
>> >>> >> > >> >>> >> https://reposcope.com/package/>> >>> >> yapps2-runtime>>  
>> >>> >> > >> >>> >>  
>> >>> >> > 
>> >>> >> > Machinelit Buster does not recognise the replacement  
>> >>> >> > ( installed manually first ) 
>> >>> >> > 
>> >>> >> this is odd. The problems should have been solved a year ago with 
>> >>> >> ORing the python-yapps package for Debian Buster, i.e. this line: >> 
>> >>> >> >>> >> https://github.com/machinekit/>> >>> >> machinekit-hal/blob/>> 
>> >>> >>

Re: [Machinekit] Machinekit Buster missing dependency (Debian)?

[cern via Machinekit]

Hi,
Apr 5, 2020, 08:40 by jiriprochazka...@gmail.com:

> Any update on this issue now?
>
yes, this issue was solved by ORing python-yapps (which is in buster: 
https://packages.debian.org/buster/python-yapps ) in place of yapps2-runtime 
(which is only for jessie and stretch: 
https://packages.debian.org/stretch/yapps2-runtime ).

However, machinekit package is obsolete. So it was probably not fixed there. 
You can just update the package to use another dependency.

Cern.

> Because I am having the same problem.
>
> The following packages have unmet dependencies:
>  machinekit-rt-preempt : Depends: machinekit (= 
> 0.1.1570528621.git9239acb-1~buster) but it is not going to be installed
>                          Depends: yapps2-runtime but it is not installable
> E: Unable to correct problems, you have held broken packages.
>
>
>
>
>
>
> Dne neděle 16. února 2020 18:06:37 UTC Mr Greg napsal(a):
>
>>
>>
>> On Sunday, 16 February 2020 17:13:15 UTC, >> ce...@tuta.io <>>>  wrote:
>>
>>> Hello, 
>>> Feb 16, 2020, 16:59 by >>> mr84...@gmail.com <>>>> : 
>>>  
>>> > 
>>> > 
>>> > On Sunday, 16 February 2020 14:42:33 UTC, >>> ce...@tuta.io <>>>>   
>>> > wrote: 
>>> > 
>>> >> Hello, 
>>> >> Feb 15, 2020, 22:06 by >> >>> mr84...@gmail.com <>>>>  <>>> : 
>>> >> 
>>> >> > 
>>> >> > 
>>> >> > On Saturday, 15 February 2020 20:26:24 UTC, Bas de Bruijn  wrote: 
>>> >> > 
>>> >> >> 
>>> >> >> > Any known workaround for this problem? 
>>> >> >>   
>>> >> >> Try installing the package manually first. `sudo apt install 
>>> >> >> ` 
>>> >> >> 
>>> >> > 
>>> >> > 
>>> >> > 
>>> >> > My problem is the package   no longer exists in 
>>> >> > Buster. It has been removed. 
>>> >> > See 
>>> >> > >> >>> https://reposcope.com/package/>>> >> yapps2-runtime>>   
>>> >> > 
>>> >> > Machinelit Buster does not recognise the replacement  ( 
>>> >> > installed manually first ) 
>>> >> > 
>>> >> this is odd. The problems should have been solved a year ago with ORing 
>>> >> the python-yapps package for Debian Buster, i.e. this line: >> >>> 
>>> >> https://github.com/machinekit/>>> >> machinekit-hal/blob/>> 
>>> >> 120c9f765cf12bcd337b66308b64b3>>> >> 146a26ec8d/debian/control.d/>> >>> 
>>> >> control.in#L20 <http://control.in#L20>>>> >>  and the >> >>> 
>>> >> https://github.com/machinekit/>>> >> machinekit-hal/commit/>> 
>>> >> d25ca64184660a44fcd6b3162b6e75>>> >> 84d781ee16>>  commit. 
>>> >> 
>>> >> I can install Machinekit-HAL  Buster on my amd64 computer without 
>>> >> problem. 
>>> >> 
>>> >> Could you post the command sequence what you are trying to do? 
>>> >> 
>>> >> Thanks, 
>>> >> Cern. 
>>> >> 
>>> >> > 
>>> >> > Cheers 
>>> >> > MrGreg 
>>> >> > 
>>> >> > 
>>> >> > 
>>> >> > 
>>> >> > -- 
>>> >> >  website: > >> >>> http://www.machinekit.io>>> >> >  blog: > >> >>> 
>>> >> > http://blog.machinekit.io>>> >> >  github: > >> >>> 
>>> >> > https://github.com/machinekit>>> >>>> >   
>>> >> >  --- 
>>> >> >  You received this message because you are subscribed to the Google 
>>> >> > Groups "Machinekit" group. 
>>> >> >  To unsubscribe from this group and stop receiving emails from it, 
>>> >> > send an email to > >> machi...@>> >>> googlegroups.com 
>>> >> > <http://googlegroups.com>>>>  <>>> > . 
>>> >> >  To view this discussion on the web visit > >> >>> 
>>> >> > https://groups.google

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

[cern via Machinekit]

Hi,
Apr 4, 2020, 04:04 by ozzyro...@gmail.com:

>
>
> 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. 
>
the great thing about open-source is that you don't have to care about 
preferences of some arbitrary "dev". You can do whatever you want as long as it 
is fun for you (or you get something else out of it).

(I just hate for interested users to lose their enthusiasm.)

Cern.

>
> 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&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/M44Rfow--7-2%40tuta.io.

Re: [Machinekit] Travis CI builds of machinekit-cnc

[cern via Machinekit]

Hi,
Mar 22, 2020, 03:09 by cameron.mcqu...@gmail.com:

> What is the status of Travis CI builds for machinekit-cnc? I would love to 
> help get this going if needed. Let me know how I can help :)
>
The current status is that it is not working. And frankly have no idea if it 
ever worked or was just left as a something from the original split into 
separate repositories. I am currently trying to implement the CI/CD flow based 
on Github Actions. (You can read about it here: 
https://github.com/machinekit/machinekit-hal/issues/268 .) Main reason for this 
is the higher limits for Open-Source project, it is simply in the Github 
repository, so every fork will have it by default and Github will store the 
artifacts for later download.

Of course, if somebody will implement Travis CI jobs, then that's good for 
redundancy.

How I imagine it to work is following: The mk-cross-builder code was integrated 
into Machinekit-HAL repository, so in given time some job will build from it 
Debian images and store them in some repository (I am thinking about Github 
Packages as it is directly connected to Github Git repository and it is on one 
network with Github Actions workers). On this will be constructed the 
Machinekit-HAL building and packaging.

Given that Machinekit-CNC needs for its build the Machinekit-HAL (some info can 
be glanced from https://github.com/machinekit/machinekit-cnc/pull/93 ), I was 
thinking that Machinekit-CNC will add another onion layer to the Machinekit-HAL 
created builder images with its own build dependencies and from this get its 
own builder (or builder which will be capable of building both Machinekit-HAL 
and Machinekit-CNC).

So what needs to be done is to rework the Debian packaging in Machinekit-CNC 
("debian" folder in root of the repository), build of the specific 
Machinekit-CNC builder (so far it can just take the Machinekit-HAL builder 
images from DockerHub) and the CI job.

If you have specific question, just ask. Here or on the Matrix chat.
Cern.

>
> Thanks,
> Cameron McQuinn
>
> -- 
> 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/0bca17f7-2840-483a-9fc1-63b5a3e642fb%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/M31XpMU--3-2%40tuta.io.

Re: [Machinekit] how to use webtalk

[cern via Machinekit]

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&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/M2ZkNUJ--3-2%40tuta.io.

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

[cern via Machinekit]

Hi,

Mar 13, 2020, 20:17 by hammond.jo...@gmail.com:

> 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? 
>
Frankly, I have no idea. But I take it that you tried the problematic driver in 
other socket? And there it was working? How many drives do you need, CRAMPS has 
6 sockets, so can you live with (six-one not working)?

I think what needs to be determined is if the problem with socket/driver is 
hardware one or software one. (It could be that the BBB pin is dead.)

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/6df717cf-2d7b-430a-ac12-b525f1dac1ca%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/M2KaERa--3-2%40tuta.io.

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

[cern via Machinekit]

Hi,

since we are having extensive talk about this kind of hardware - did anybody 
spare any thought to EtherCAT slave device which would be useful for home 
machine integrator/retrofiter? (Some basic IO, encoder counters, analog signal 
output generation and step/dir signals output [in one or two devices] - 
basically what MESA sells mostly to LinuxCNC crowd.)

My fancy taken me to XMC4800 from Infineon or LAN9252 from Microchip, there is 
even OpenSource project: https://github.com/DieBieEngineering/DieBieSlave - 
however the author overdid it with layers and it would still need another board.

Cern.

Mar 4, 2020, 07:21 by jo...@autoartisans.com:

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

Re: [Machinekit] Q: Regarding the diff between repos.

[cern via Machinekit]

Hello,
the main development is happening in the Machinekit-HAL repository, but that is 
only because active developers are more interested in that kind of work. The 
Machinekit-CNC branch is little bit stale as no one is really interested in it 
at the moment. There was discussion about creating kind of LinuxCNC jail, where 
most of the LinuxCNC application (the non-realtime part which consists of the 
majority of code) would live independent and only the most-trusted prisoners 
(read RT components) would be allowed into Machinekit-HAL proper.

Cern.

Mar 2, 2020, 09:52 by moronicsm...@gmail.com:

> Thanks alot for clearing that up.
> So the old linuxcnc fork is not maintained at all. Does that mean machinekit 
> is fully drifting from lcnc stuff, like the motion planner and so on or are 
> this moved in bit by bit as needed?
>
> Kindly // Andreas
>
> Den söndag 1 mars 2020 kl. 22:06:34 UTC+1 skrev ce...@tuta.io:
>
>> Hello, 
>> Mar 1, 2020, 17:44 by >> moroni...@gmail.com <>>> : 
>>  
>> > So new to Machinekit. Been looking at it coming from LinuxCNC. 
>> > 
>> > And been going thru the documentation and it seems like machinekit is alot 
>> > more focused on useability than LinuxCNC. 
>> > 
>> > One thing i couldnt really differentiate in either repo readme's or 
>> > documentation would be. 
>> > 
>> > machinekit/machinekit -> What makes this repo different from 
>> > 
>> I would like to update the README to specify that the repository is no 
>> longer maintained and then archive it on Github. 
>>  
>> > 
>> > machinekit/machinekit-hal 
>> > and 
>> > machinekit/machinekit-cnc 
>> > 
>> These are only repositories where development happens (including buxfixes). 
>>  
>> > 
>> > As i understand - the machinekit-hal would be just the machine control 
>> > parts and the machinekit-cnc would be just the UI parts. 
>> > But that doesnt seem to be the case. 
>> > 
>> Yeah, the split wasn't so easy because of historical reasons. 
>>  
>> > 
>> > I also read about running machinekit as "rip" - couldnt find any info 
>> > regarding this in the documentation tho, what it would mean for the user 
>> > for one. 
>> > 
>> Does this help? >> http://www.machinekit.io/docs/>> developing/machinekit->> 
>> developing/>>  RIP means just running from specific directory without 
>> installing on the system. 
>>  
>> Cern. 
>>  
>> > 
>> > Sorry bout noob questions. 
>> > 
>> > Kindly // Andreas 
>> > 
>> > 
>> > 
>> > -- 
>> >  website: > >> http://www.machinekit.io>> >  blog: > >> 
>> > http://blog.machinekit.io>> >  github: > >> 
>> > https://github.com/machinekit>>  
>> >  --- 
>> >  You received this message because you are subscribed to the Google Groups 
>> > "Machinekit" group. 
>> >  To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to > >> machi...@>> googlegroups.com <>>> > . 
>> >  To view this discussion on the web visit > >> 
>> > https://groups.google.com/d/>> msgid/machinekit/1e3fd7b1->> 
>> > 3a50-4115-b784-faaf3c6a6312%>> 40googlegroups.com>>  <>> 
>> > https://groups.google.com/d/>> msgid/machinekit/1e3fd7b1->> 
>> > 3a50-4115-b784-faaf3c6a6312%>> 40googlegroups.com?utm_medium=>> 
>> > email&utm_source=footer>> >> . 
>> > 
>>  
>>
>
>
>
> --
>  website: > http://www.machinekit.io>  blog: > http://blog.machinekit.io>  
> github: > https://github.com/machinekit
>  --- 
>  You received this message because you are subscribed to the Google Groups 
> "Machinekit" group.
>  To unsubscribe from this group and stop receiving emails from it, send an 
> email to > machinekit+unsubscr...@googlegroups.com> .
>  To view this discussion on the web visit > 
> https://groups.google.com/d/msgid/machinekit/a6deef35-2c48-4bb1-b938-e72f6ce54ce9%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/a6deef35-2c48-4bb1-b938-e72f6ce54ce9%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/M1QiPin--B-2%40tuta.io.

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

[cern via Machinekit]

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 clones and similar ARM M0, M3 M(whatever boards) that are quite 
> ubiquitous, cheap and a probable assured future as far as can be seen. 
> The previously mentioned developer (and myself)  started this project a year+ 
> ago.
>
> https://gitlab.com/samdcnc/samdcnc
>
> It was only a start, with limited headway made. External pressures and the 
> enormity of the task brought about a halt. He may well be interested in 
> contributing further TBD.
> Guess you will hear from him if he is.
>
> Just a basic rework and update of the existing Picnc driver and firmware on 
> the existing pic32MX150 that works with current hardware and OSs + Machinekit 
> and Lcnc would be a most excellent solution in itself without porting it to 
> anything else. It works well and is cheap. Gerber files for existing PCBs are 
> available. It is already is capable of fulfilling the use cases of many 
> potential users. Perhaps nobody has taken much notice of it.
>
> For those readers here who haven't
>
> https://github.com/kinsamanka/PICnc-V2/wiki
>
> I am prepared to do test & verification on PIs 2, 3 and 4. I have ARM M0 and 
> M3 boards. Bench test cnc and 3/4 axis cnc machine(s) currently running Picnc.
> I am happy to write docu, at least for the Pi stuff that I have tested. 
> possibly more TBA.
>
> So, yes I am interested in a resurrection, or perhaps rebirth sounds a bit 
> more positive? of Picnc.
>
> Food for thought and possible collaboration,
>
> Cheers
> MrGreg
>
>
>
> On Sunday, 1 March 2020 00:27:38 UTC, ce...@tuta.io  wrote:
>
>> Hi, 
>>  
>> I am all in for cheap, low entry hardware. Don't care if it is PIC or ARM. I 
>> think that for most cases it would be enough to have just serial connection 
>> between PC/SBC and this board. But some simple  Ethernet based communication 
>> (maybe lower in the OSI model) would be nice too. 
>>  
>> I have a feeling that to get traction, it has to be simple, it has to be 
>> documented and it has to have tutorials and pre-compiled usecases which are 
>> near the real-word wants and needs of machine builders. (Like the BBB and 
>> CRAMPS, simple one use device.) 
>>  
>> Some type of free-cool-in social networking with Youtube videos would also 
>> help. 
>>  
>> Then, I think, you have change to get involvement from general community. 
>>  
>> And I think that the interest is there: Look for example on the YAPSC:10v 
>> project. 
>>  
>> BTW, there are implementations for the smartserial protocol which could be 
>> used for mining operation. The STMBL guy have implementation and there are 
>> guys around the world who reverse-engineered it. 
>>  
>> Cern. 
>>  
>>  
>> Feb 29, 2020, 19:27 by >> jo...@autoartisans.com <>>> : 
>>  
>> > 
>> > I do have a MESA 7i92H that works with > LinuxCNC>  on a dual boot PC.>   
>> > > I have to switch to 

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

[cern via Machinekit]

Guys, please, make sure that you click "Reply to all" and that you include the 
machinekit@googlegroups.com address in the "To" form.

Thanks,
Cern.


Mar 1, 2020, 22:53 by jo...@autoartisans.com:

> Personally I think that's a load of crap.  One only has to look at the 
> various microprocessor products out there to see that USB 2.0 as an interface 
> will be with us for a very long time.  One of my clients switched from using 
> Panasonic Tough Books for their PC interface in their product to the 
> dedicated industrial PC boxes.   And their products are designed to have at 
> least a 10 year life.   And those boxes will have USB 2.0 for a long time 
> along with Ethernet. 
>
> Take a look out at the industry where suppliers and manufacturers are 
> attempting to alleviate their clients fears about buying a specific 
> technology so they promise at least a 10 year life span.  I'm still using a 
> 9S12 series in a product that as yet has not been issued an end of life buy 
> request.
>
> Of course newer PCs will come out with USB-C.  Of course over the years we 
> will see products that are sold with that.  And we'll probably also see a ton 
> of products that are the USB-C connection to the laptop and have 4 to 8 USB 
> 2.0 connectors to attach to all the real hardware that's out there.
>
> So yes we will see new embedded processors with USB-C.  Of course.  But to 
> say that the only design choice is that is ignoring what is already there.
>
> John
>
>
>> -Original Message-
>> From: cern via Machinekit [mailto:machinekit@googlegroups.com]
>> Sent: March-01-20 1:26 PM
>> To: Chris Albertson; Machinekit
>> Subject: Re: [Machinekit] Re: PICnc with Machine Kit.
>>
>> Hi,
>> the original author didn't include the  email
>> in his reply, so I am posting this as an all-in-one answer.
>>
>> Mar 1, 2020, 06:20 by albertson.ch...@gmail.com:
>>
>> >
>> >
>> > On Sat, Feb 29, 2020 at 4:27 PM cern via Machinekit <>
>> machinekit@googlegroups.com> > wrote:
>> >
>> >> Hi,
>> >>
>> >>  I am all in for cheap, low entry hardware. Don't care if it is PIC or 
>> >> ARM. I
>> think that for most cases it would be enough to have just serial connection
>> between PC/SBC and this board. But some simple� Ethernet based
>> communication�
>> >>
>> >
>> > In today"s world and tomorrow's world, the only serial interface that makes
>> sense in a new design is USB-C.� This goes duble if it has to connect to a 
>> PC. �
>> Soon this will be the only data connector PCs have. � � What is quickly
>> becomming�universal is USB 3.1 protocol�over a USB-C connector. � � It can
>> do 10 Gigabits persecond. � But just as importantly�it can be VERY low
>> latency with�> isochronous transfers and there are specs for buffer times on
>> hubs. � ��> Anything designs not using USB-C will be > obsolete> �in a few
>> years. � A limitation ss that USB-C cables can only be 3M long. � �Ethernet
>> can go for a few kiliometers if you use fiber but is slower and few computers
>> will have Ethernet in the future.
>> >
>> I have one USB-C connector with ThunderBolt capability on my notebook,
>> but I have no idea if it even works as so far I had no device to connect to 
>> it. To
>> me it sounds little bit like the predictions that we will travel to Moon 
>> bases
>> for our holidays.
>>
>> But, to allow deterministic (up to a point) communication over USB-C sounds
>> interesting. Do you have some link for papers (or other documents) on this
>> subject? (For when the time allows or the strike of fancy happens.)
>>
>> Cern.
>>
>> > �
>> > --
>> >
>> > Chris Albertson
>> > Redondo Beach, California
>> >
>>
>> --
>> 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/M1MzPd---3-2%40tuta.io.
>>

-- 
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/M1N8TT7--3-2%40tuta.io.

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

[cern via Machinekit]

Hi,
the original author didn't include the  email in 
his reply, so I am posting this as an all-in-one answer.

Mar 1, 2020, 06:20 by albertson.ch...@gmail.com:

>
>
> On Sat, Feb 29, 2020 at 4:27 PM cern via Machinekit <> 
> machinekit@googlegroups.com> > wrote:
>
>> Hi,
>>  
>>  I am all in for cheap, low entry hardware. Don't care if it is PIC or ARM. 
>> I think that for most cases it would be enough to have just serial 
>> connection between PC/SBC and this board. But some simple  Ethernet based 
>> communication 
>>
>
> In today"s world and tomorrow's world, the only serial interface that makes 
> sense in a new design is USB-C.  This goes duble if it has to connect to a 
> PC.   Soon this will be the only data connector PCs have.     What is quickly 
> becomming universal is USB 3.1 protocol over a USB-C connector.     It can do 
> 10 Gigabits persecond.   But just as importantly it can be VERY low latency 
> with > isochronous transfers and there are specs for buffer times on hubs.    
>  > Anything designs not using USB-C will be > obsolete>  in a few years.   A 
> limitation ss that USB-C cables can only be 3M long.    Ethernet can go for a 
> few kiliometers if you use fiber but is slower and few computers will have 
> Ethernet in the future.
>
I have one USB-C connector with ThunderBolt capability on my notebook, but I 
have no idea if it even works as so far I had no device to connect to it. To me 
it sounds little bit like the predictions that we will travel to Moon bases for 
our holidays.

But, to allow deterministic (up to a point) communication over USB-C sounds 
interesting. Do you have some link for papers (or other documents) on this 
subject? (For when the time allows or the strike of fancy happens.)

Cern.

>  
> -- 
>
> Chris Albertson
> Redondo Beach, California
>

-- 
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/M1MzPd---3-2%40tuta.io.

Re: [Machinekit] mb2hal?

[cern via Machinekit]

Hi,

I have just posted pull request merging MB2HAL from LinuxCNC/linuxcnc@master 
into Machinekit/machinekit-hal@master: 
https://github.com/machinekit/machinekit-hal/pull/258

Cern.


Dec 27, 2019, 16:46 by blazin...@gmail.com:

> Bump...not alotta interest in modbus in my eh?
>
> -- 
> 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/cb5c867b-ccbe-4491-b75d-d3cba9698232%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/M1MvjXk--3-2%40tuta.io.

Re: [Machinekit] Q: Regarding the diff between repos.

[cern via Machinekit]

Hello,
Mar 1, 2020, 17:44 by moronicsm...@gmail.com:

> So new to Machinekit. Been looking at it coming from LinuxCNC.
>
> And been going thru the documentation and it seems like machinekit is alot 
> more focused on useability than LinuxCNC.
>
> One thing i couldnt really differentiate in either repo readme's or 
> documentation would be.
>
> machinekit/machinekit -> What makes this repo different from
>
I would like to update the README to specify that the repository is no longer 
maintained and then archive it on Github.

>
> machinekit/machinekit-hal
> and
> machinekit/machinekit-cnc
>
These are only repositories where development happens (including buxfixes).

>
> As i understand - the machinekit-hal would be just the machine control parts 
> and the machinekit-cnc would be just the UI parts.
> But that doesnt seem to be the case.
>
Yeah, the split wasn't so easy because of historical reasons.

>
> I also read about running machinekit as "rip" - couldnt find any info 
> regarding this in the documentation tho, what it would mean for the user for 
> one.
>
Does this help? http://www.machinekit.io/docs/developing/machinekit-developing/ 
RIP means just running from specific directory without installing on the system.

Cern.

>
> Sorry bout noob questions.
>
> Kindly // Andreas
>
>
>
> --
>  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/1e3fd7b1-3a50-4115-b784-faaf3c6a6312%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/1e3fd7b1-3a50-4115-b784-faaf3c6a6312%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/M1Mv-2r--7-2%40tuta.io.

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

[cern via Machinekit]

Hi,

I am all in for cheap, low entry hardware. Don't care if it is PIC or ARM. I 
think that for most cases it would be enough to have just serial connection 
between PC/SBC and this board. But some simple  Ethernet based communication 
(maybe lower in the OSI model) would be nice too.

I have a feeling that to get traction, it has to be simple, it has to be 
documented and it has to have tutorials and pre-compiled usecases which are 
near the real-word wants and needs of machine builders. (Like the BBB and 
CRAMPS, simple one use device.)

Some type of free-cool-in social networking with Youtube videos would also help.

Then, I think, you have change to get involvement from general community.

And I think that the interest is there: Look for example on the YAPSC:10v 
project.

BTW, there are implementations for the smartserial protocol which could be used 
for mining operation. The STMBL guy have implementation and there are guys 
around the world who reverse-engineered it.

Cern.


Feb 29, 2020, 19:27 by jo...@autoartisans.com:

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

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[cern via Machinekit]

Hi,

Feb 26, 2020, 16:02 by blazin...@gmail.com:

> Yes the mesa firmware has been around for quite some time but only in this 
> project has it been this configurable. 
>
> Putting an fpga on a pcb isn't super easy for novices, while Mesa is 
> fantastic you are buying a board with the fpga's i/o hardware is set in 
> stone. You can reconfigure stepgens for PWM and such only because the 
> external hardware is the same. If I want to use a 7i76e but I need 6 
> stepgens,  well now I need to add a card. None of that is a major issue it's 
> good stuff but that's how it is.
>
> Couple that with the fact that there is a low end cpu attached directly to 
> that fpga and you have an all in one hmi type device that's completely 
> reconfigurable. The daughter card I made was built with the intention of 
> cramming as much stuff as possible, I now use it for prototyping everything 
> because it is literally as simple as writing a hal file and possibly making a 
> simple GUI.
>
> I can run just about any machine from my board, albeit a mill lathe, 
> whatever. My biggest issue is actually MK itself, it's too far behind 
> linuxcnc in key areas like joints+axis and since you mentioned mesa, well 
> that's rather far behind too. I wouldn't have a problem deploying mksocfpga 
> if I didn't have a problem deploying MK itself.
>
Currently, the machinekit/machinekit-cnc@master cannot be build on top of 
machnekit/machinekit-hal@master due to merge in of the so-called 
"single-module-dir" branch. I am planning to have a look at it in due time, but 
it would be helpful if someone else wanted to take a look at this.

Or do the LinuxCNC port. I, too, have been thinking about some kind of LinuxCNC 
jail where only the most trusted prisoners would be allowed access to the 
Machinekit-HAL. However, I didn't spend any significant time on this. I think 
Zultron or ArcEye did something, so maybe have a peek in theirs repositories.

Cern.

>
> On Wed, Feb 26, 2020, 4:41 AM Bas de Bruijn <> b...@basdebruijn.com> > wrote:
>
>>
>>
>> > On 26 Feb 2020, at 01:34, justin White <>> blazin...@gmail.com>> > wrote:
>>  > 
>>  > Its amazing that mksocfpga doesn't get more interest/support, I dont 
>> think people realize how powerful the idea is.
>>  
>>  Do you mean the reconfigurability? If not, the Mesa FPGA is around already 
>> for a long time, and it is great that the FPGA runs on such a small platform 
>> too.
>>  
>>  The reason I think it is not used very much is that for real use, in a 
>> production/manufacturing  environment, there is no hardware that one can 
>> “just buy and works”.
>>  
>>  If I want to use this in a customer project, from an integrator point of 
>> view, my concerns are about longtime availability of the hardware. I do not 
>> want to buy components, solder etc. I just want to open the box, attach 
>> wires to terminals and configure the machine.
>>  
>>  If something breaks or need to make another machine then I want to order 
>> the _exact_ same hardware, use the same code/version of the original and it 
>> should just work.
>>  
>>  This holds for BBB’s too btw. For customers I only use pc’s with the Mesa 
>> cards. There are other considerations than just the cost price of the board. 
>> Development time, hardware availability and support far outweigh the cost of 
>> the board.
>>  
>>  Just my 2 ct.
>>  
>>  
>>  
>>
>
>
>
> --
>  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/CA%2BQ02MN0Uiof8LE7m%2BWxx%2BPLKonQfug3GbixdXd6ZqzN3bDFTg%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/machinekit/CA%2BQ02MN0Uiof8LE7m%2BWxx%2BPLKonQfug3GbixdXd6ZqzN3bDFTg%40mail.gmail.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/M1IRL95--3-2%40tuta.io.

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

[cern via Machinekit]

Hello,
Feb 6, 2020, 05:16 by j...@dovetail-automata.com:

> 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.
>
problem is - at least it looks like it from where I stand - killing the Jenkins 
server also killed the Machinekit build system. And no packages are generated.

>
> 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/
>
Yes, thank you. I am using it on Travis. 

There is currently no auto-build for Machinekit-CNC, right?

Cern.

>
>  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&utm_source=footer>.
>
> -- 
> website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
> https://github.com/machinekit
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to machinekit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/machinekit/BYAPR12MB358961F5AFAE3EE2C8964778851D0%40BYAPR12MB3589.namprd12.prod.outlook.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/M0EN8X7--3-2%40tuta.io.

Re: [Machinekit] Machinekit Buster missing dependency (Debian)?

[cern via Machinekit]

Hello,
Feb 16, 2020, 16:59 by mr84g...@gmail.com:

>
>
> On Sunday, 16 February 2020 14:42:33 UTC, ce...@tuta.io  wrote:
>
>> Hello, 
>> Feb 15, 2020, 22:06 by >> mr84...@gmail.com <>>> : 
>>
>> > 
>> > 
>> > On Saturday, 15 February 2020 20:26:24 UTC, Bas de Bruijn  wrote: 
>> > 
>> >> 
>> >> > Any known workaround for this problem? 
>> >>   
>> >> Try installing the package manually first. `sudo apt install 
>> >> ` 
>> >> 
>> > 
>> > 
>> > 
>> > My problem is the package   no longer exists in Buster. It 
>> > has been removed. 
>> > See 
>> > >> https://reposcope.com/package/>> yapps2-runtime>>  
>> > 
>> > Machinelit Buster does not recognise the replacement  ( 
>> > installed manually first ) 
>> > 
>> this is odd. The problems should have been solved a year ago with ORing the 
>> python-yapps package for Debian Buster, i.e. this line: >> 
>> https://github.com/machinekit/>> machinekit-hal/blob/>> 
>> 120c9f765cf12bcd337b66308b64b3>> 146a26ec8d/debian/control.d/>> 
>> control.in#L20>>  and the >> https://github.com/machinekit/>> 
>> machinekit-hal/commit/>> d25ca64184660a44fcd6b3162b6e75>> 84d781ee16>>  
>> commit. 
>>
>> I can install Machinekit-HAL  Buster on my amd64 computer without problem. 
>>
>> Could you post the command sequence what you are trying to do? 
>>
>> Thanks, 
>> Cern. 
>>
>> > 
>> > Cheers 
>> > MrGreg 
>> > 
>> > 
>> > 
>> > 
>> > -- 
>> >  website: > >> http://www.machinekit.io>> >  blog: > >> 
>> > http://blog.machinekit.io>> >  github: > >> 
>> > https://github.com/machinekit>>  
>> >  --- 
>> >  You received this message because you are subscribed to the Google Groups 
>> > "Machinekit" group. 
>> >  To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to > >> machi...@>> googlegroups.com <>>> > . 
>> >  To view this discussion on the web visit > >> 
>> > https://groups.google.com/d/>> msgid/machinekit/40e69652->> 
>> > 5e83-4285-9055-6dcae4c2852d%>> 40googlegroups.com>>  <>> 
>> > https://groups.google.com/d/>> msgid/machinekit/40e69652->> 
>> > 5e83-4285-9055-6dcae4c2852d%>> 40googlegroups.com?utm_medium=>> 
>> > email&utm_source=footer>> >> . 
>> > 
>>
>>
>
>
> OK to expand on my OP
>
> Trying to install machinekit Buster on an Rpi3B
> Starting here
> http://www.machinekit.io/docs/getting-started/installing-packages/
> Following section9 : 
> 9. Debian Buster on armhf
>
> Apt  successful
> RT from here
> https://github.com/guysoft/RealtimePi
>
> Install runtime packages : Fail
>
> Missing dependency
> yapps2-runtime ( non existent package in Debian)
>
> I'm guessing that the arm machinekit package has not been built with the 
> necessary updates to  
>
> ???
>
oh, yeah, I can see it now. You are trying to install the deprecated Machinekit 
package, which require the yapps2-runtime.

Well, that's an error in documentation. (Which I am going to repair.) The one 
Machinekit package was superseded by two packages - Machinekit-HAL and 
Machinekit-CNC. But the Machinekit-CNC cannot be installed because of pulled 
python-gnome2 from Buster. You can use the-snowwhite's hack from 
https://github.com/machinekit/machinekit/issues/1323#issuecomment-536042893 . 
However, from LinuxCNC discussion 
https://github.com/LinuxCNC/linuxcnc/issues/341 it looks like the package is 
useless and can be removed. I will try it.

Cern.

T

>
>
>
> --
> 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/b2ab0a59-0dee-4d4c-bea6-2538f8e416c3%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/b2ab0a59-0dee-4d4c-bea6-2538f8e416c3%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/M0DwtMp--7-2%40tuta.io.

Re: [Machinekit] Machinekit Buster missing dependency (Debian)?

[cern via Machinekit]

Hello,
Feb 15, 2020, 22:06 by mr84g...@gmail.com:

>
>
> On Saturday, 15 February 2020 20:26:24 UTC, Bas de Bruijn  wrote:
>
>>
>> > Any known workaround for this problem? 
>>  
>> Try installing the package manually first. `sudo apt install 
>> ` 
>>
>
>
>
> My problem is the package   no longer exists in Buster. It 
> has been removed.
> See
> https://reposcope.com/package/yapps2-runtime
>
> Machinelit Buster does not recognise the replacement  ( 
> installed manually first )
>
this is odd. The problems should have been solved a year ago with ORing the 
python-yapps package for Debian Buster, i.e. this line: 
https://github.com/machinekit/machinekit-hal/blob/120c9f765cf12bcd337b66308b64b3146a26ec8d/debian/control.d/control.in#L20
 and the 
https://github.com/machinekit/machinekit-hal/commit/d25ca64184660a44fcd6b3162b6e7584d781ee16
 commit.

I can install Machinekit-HAL  Buster on my amd64 computer without problem.

Could you post the command sequence what you are trying to do?

Thanks,
Cern.

>
> Cheers
> MrGreg
>
>
>
>
> --
>  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/40e69652-5e83-4285-9055-6dcae4c2852d%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/40e69652-5e83-4285-9055-6dcae4c2852d%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/M0DRqSH--3-2%40tuta.io.

Re: [Machinekit] Re: mb2hal?

[cern]

Hi,

Jan 3, 2020, 11:56 by mib.holotro...@gmail.com:

> The current relation between feeling of accomplishment and feedback.
>
You just need to learn praise yourself for work accomplished. Nobody else will 
do it for you. Just tap yourself on the back and say Well Done. Depending on 
others is the highway to hell.

In my situation it translated into periods of high interests and lazy pauses.

>
> On Monday, December 30, 2019 at 8:54:59 PM UTC+1, ce...@tuta.io wrote:
>
>> Dec 30, 2019, 18:30 by >> mib.ho...@gmail.com <>>> : 
>>  
>> > 
>> > 
>> > On Monday, December 30, 2019 at 12:27:05 AM UTC+1, >> ce...@tuta.io <>>>  
>> > wrote: 
>> > 
>> >> Dec 29, 2019, 23:51 by >> >> blaz...@gmail.com <>>>  <>>> : 
>> >>   
>> >> > That's good, thanks for taking the time to test it. Did you use the 
>> >> > lcnc version or the old mk version? 
>> >> > 
>> >> I used the current LinuxCNC version. 
>> >>   
>> >> > 
>> >> > it'll be a bit before my setup is ready to try it. I suppose by then it 
>> >> > will be pulled into the mk-hal repo and a simple update will will 
>> >> > install it? 
>> >> > 
>> >> Don't know. If it was stricken for specific reason, it would probably not 
>> >> be good to introduce it again. 
>> >>   
>> >> Cern. 
>> >> 
>> > 
>> > Correct  the maintainers exceeded the "use" limit due to: 
>> > assumptions 
>> > expectations. 
>> > between "user" and Developer "space" 
>> > call it a communication breakdown due to educational systems in general 
>> > between the earth and gaian "philosofies" 
>> > Thanx 
>> > From an energetic(suble energies) viewpoint of a Systemverilog rt 
>> > constructor. 
>> > 
>> I think I will ask for a hint. Because I don't understand. 
>>  
>> Do you mean the RTAPI/ULAPI and RT/"userspace" nomenclature the Machinekit 
>> inherited from LinuxCNC (making everything overly complicated) or something 
>> else? 
>>  
>>
>
> If its related to "serial" protocols ,,probably. yes :-)
>
RT communication needs RT-capable drivers. For RT_PREEMPT there probably is no 
actual work which needs to be done. (For Xenomai/EVL there is, I think.)

Simple test would be to create HAL module where the polling of/sending to 
remote device is exported as a HAL function which would be then added into the 
thread. (So put the functionality into the rtapi_app process, don't create new 
process which would be IPCed by shared memory into HAL segment.) And then look 
for errors on RT side (context switches or time violations).

In connection to Modbus, I think it depends on number and types of SYCALLs 
causing context switch in the implementation of current libmodbus library.

Cern.

>  
>
>> Cern. 
>>  
>> > 
>> >   
>> > 
>> >> 
>> >> > 
>> >> > On Sunday, December 29, 2019 at 11:17:14 AM UTC-5, >> >> ce...@tuta.io 
>> >> > <>>>  <>>>  wrote: 
>> >> > 
>> >> >> OK, 
>> >> >> an arduino found, packaged example code tested and it looks like it is 
>> >> >> working. So simple copy&paste solution. 
>> >> >>   
>> >> >> Still have no idea why it was deleted from machinekit-hal package. 
>> >> >>   
>> >> >> Cern. 
>> >> >>   
>> >> >>   
>> >> >> Dec 28, 2019, 21:11 by >> >> >> ce...@tuta.io <>>>  <>>>  <>>> : 
>> >> >>   
>> >> >> > Hmmm..., 
>> >> >> > 
>> >> >> > simple Ctrl+C, Ctrl+V from LinuxCNC repository to Machinekit-HAL 
>> >> >> > repository seems to work (at least it compiles and so something, I 
>> >> >> > have nothing for extra quick test [would have to find my arduino]) - 
>> >> >> > >> >> >> https://github.com/cerna/>> >> >> 
>> >> >> > machinekit-hal/tree/import->> mb2hal-from-linuxcnc>>  . Even the 
>> >> >> > include command in src/Makefile was still there. 
>> >> >> > 
>> >> >> > Cern. 
>> >> 

Re: [Machinekit] Re: mb2hal?

[cern]

Dec 30, 2019, 18:30 by mib.holotro...@gmail.com:

>
>
> On Monday, December 30, 2019 at 12:27:05 AM UTC+1, ce...@tuta.io wrote:
>
>> Dec 29, 2019, 23:51 by >> blaz...@gmail.com <>>> : 
>>  
>> > That's good, thanks for taking the time to test it. Did you use the lcnc 
>> > version or the old mk version? 
>> > 
>> I used the current LinuxCNC version. 
>>  
>> > 
>> > it'll be a bit before my setup is ready to try it. I suppose by then it 
>> > will be pulled into the mk-hal repo and a simple update will will install 
>> > it? 
>> > 
>> Don't know. If it was stricken for specific reason, it would probably not be 
>> good to introduce it again. 
>>  
>> Cern. 
>>
>
> Correct  the maintainers exceeded the "use" limit due to:
> assumptions
> expectations.
> between "user" and Developer "space"
> call it a communication breakdown due to educational systems in general 
> between the earth and gaian "philosofies"
> Thanx
> From an energetic(suble energies) viewpoint of a Systemverilog rt constructor.
>
I think I will ask for a hint. Because I don't understand. 

Do you mean the RTAPI/ULAPI and RT/"userspace" nomenclature the Machinekit 
inherited from LinuxCNC (making everything overly complicated) or something 
else?

Cern.

>
>  
>
>>
>> > 
>> > On Sunday, December 29, 2019 at 11:17:14 AM UTC-5, >> ce...@tuta.io <>>>  
>> > wrote: 
>> > 
>> >> OK, 
>> >> an arduino found, packaged example code tested and it looks like it is 
>> >> working. So simple copy&paste solution. 
>> >>   
>> >> Still have no idea why it was deleted from machinekit-hal package. 
>> >>   
>> >> Cern. 
>> >>   
>> >>   
>> >> Dec 28, 2019, 21:11 by >> >> ce...@tuta.io <>>>  <>>> : 
>> >>   
>> >> > Hmmm..., 
>> >> > 
>> >> > simple Ctrl+C, Ctrl+V from LinuxCNC repository to Machinekit-HAL 
>> >> > repository seems to work (at least it compiles and so something, I have 
>> >> > nothing for extra quick test [would have to find my arduino]) - >> >> 
>> >> > https://github.com/cerna/>> >> machinekit-hal/tree/import->> 
>> >> > mb2hal-from-linuxcnc>>  . Even the include command in src/Makefile was 
>> >> > still there. 
>> >> > 
>> >> > Cern. 
>> >> > 
>> >> > 
>> >> > Dec 28, 2019, 18:22 by >> >> blaz...@gmail.com <>>>  <>>> : 
>> >> > 
>> >> >> A commit a year ago in MK legacy addresses something with libmodbus. 
>> >> >> >> >> https://github.com/machinekit/>> >> 
>> >> >> >> >> machinekit/tree/master/src/>> hal/user_comps/mb2hal>>   
>> >> >> 
>> >> >> I don't know that I was asking specifically about LinuxCNC's version 
>> >> >> unless there is a more recent change that matters. The version that 
>> >> >> was in MK is probably fine if it's useable. 
>> >> >> 
>> >> >> On Saturday, December 28, 2019 at 12:10:25 PM UTC-5, >> >> 
>> >> >> ce...@tuta.io <>>>  <>>>  wrote: 
>> >> >> 
>> >> >>> Well, looking at the mb2hal in LinuxCNC repository, I - at first 
>> >> >>> glance - don't see any reason why it should not work in the 
>> >> >>> Machinekit (maybe with some simple and generally automatic code 
>> >> >>> changes). 
>> >> >>>   
>> >> >>> So I would really like to know the reason behind removing it. I think 
>> >> >>> (trying to remember) that there was some issue with the libmodbus 
>> >> >>> library and Debian package which mb2hal is wrapper around. 
>> >> >>>   
>> >> >>> Cern. 
>> >> >>>   
>> >> >>>   
>> >> >>> Dec 28, 2019, 16:40 by >> >> >> blaz...@gmail.com <>>>  <>>>  <>>> : 
>> >> >>>   
>> >> >>> > Just navigating the split repo directories, "user" comps still 
>> >&

Re: [Machinekit] Re: mb2hal?

[cern]

Dec 29, 2019, 23:51 by blazin...@gmail.com:

> That's good, thanks for taking the time to test it. Did you use the lcnc 
> version or the old mk version?
>
I used the current LinuxCNC version.

>
> it'll be a bit before my setup is ready to try it. I suppose by then it will 
> be pulled into the mk-hal repo and a simple update will will install it?
>
Don't know. If it was stricken for specific reason, it would probably not be 
good to introduce it again.

Cern.

>
> On Sunday, December 29, 2019 at 11:17:14 AM UTC-5, ce...@tuta.io wrote:
>
>> OK, 
>> an arduino found, packaged example code tested and it looks like it is 
>> working. So simple copy&paste solution. 
>>  
>> Still have no idea why it was deleted from machinekit-hal package. 
>>  
>> Cern. 
>>  
>>  
>> Dec 28, 2019, 21:11 by >> ce...@tuta.io <>>> : 
>>  
>> > Hmmm..., 
>> > 
>> > simple Ctrl+C, Ctrl+V from LinuxCNC repository to Machinekit-HAL 
>> > repository seems to work (at least it compiles and so something, I have 
>> > nothing for extra quick test [would have to find my arduino]) - >> 
>> > https://github.com/cerna/>> machinekit-hal/tree/import->> 
>> > mb2hal-from-linuxcnc>>  . Even the include command in src/Makefile was 
>> > still there. 
>> > 
>> > Cern. 
>> > 
>> > 
>> > Dec 28, 2019, 18:22 by >> blaz...@gmail.com <>>> : 
>> > 
>> >> A commit a year ago in MK legacy addresses something with libmodbus. 
>> >> >> https://github.com/machinekit/>> machinekit/tree/master/src/>> 
>> >> >> hal/user_comps/mb2hal>>  
>> >> 
>> >> I don't know that I was asking specifically about LinuxCNC's version 
>> >> unless there is a more recent change that matters. The version that was 
>> >> in MK is probably fine if it's useable. 
>> >> 
>> >> On Saturday, December 28, 2019 at 12:10:25 PM UTC-5, >> ce...@tuta.io 
>> >> <>>>  wrote: 
>> >> 
>> >>> Well, looking at the mb2hal in LinuxCNC repository, I - at first glance 
>> >>> - don't see any reason why it should not work in the Machinekit (maybe 
>> >>> with some simple and generally automatic code changes). 
>> >>>   
>> >>> So I would really like to know the reason behind removing it. I think 
>> >>> (trying to remember) that there was some issue with the libmodbus 
>> >>> library and Debian package which mb2hal is wrapper around. 
>> >>>   
>> >>> Cern. 
>> >>>   
>> >>>   
>> >>> Dec 28, 2019, 16:40 by >> >> blaz...@gmail.com <>>>  <>>> : 
>> >>>   
>> >>> > Just navigating the split repo directories, "user" comps still exist 
>> >>> > in the typical directory of MK-hal, tho mb2hal is missing. Nothing 
>> >>> > like that seems to exist in MK-CNC so I assumed the MO was to keep the 
>> >>> > user comps in MK-HAL as is. mb2hal also works over serial which aside 
>> >>> > from Mesa smartserial I don't think has ever been considered "RT" in 
>> >>> > linuxCNC likely because of baud rates. While I'm sure RT modbus is 
>> >>> > probably quite useful I don't think the main use for it is usually RT 
>> >>> > critical. Generally it would take the place of other serial protocols 
>> >>> > with the convenience of TCP as well for interfacing with something 
>> >>> > else that is running faster at a hardware level, like talking to a VFD 
>> >>> > or commanding a servo drive. I think getting it in there in it's 
>> >>> > current form if possible is probably more important than addressing RT 
>> >>> > changes, which could always be added later I suppose.  
>> >>> > 
>> >>> > On Saturday, December 28, 2019 at 9:50:53 AM UTC-5, >> >> 
>> >>> > ce...@tuta.io <>>>  <>>>  wrote: 
>> >>> > 
>> >>> >> I remember that there was some problem with Modbus module which I 
>> >>> >> thought was solved by ArcEye. (Maybe he will chime in.) But given 
>> >>> >> that it was the so called "userspace" component, it would be in 
>> >>> >> m

Re: [Machinekit] Re: mb2hal?

[cern]

OK,
an arduino found, packaged example code tested and it looks like it is working. 
So simple copy&paste solution.

Still have no idea why it was deleted from machinekit-hal package.

Cern.


Dec 28, 2019, 21:11 by c...@tuta.io:

> Hmmm...,
>
> simple Ctrl+C, Ctrl+V from LinuxCNC repository to Machinekit-HAL repository 
> seems to work (at least it compiles and so something, I have nothing for 
> extra quick test [would have to find my arduino]) - 
> https://github.com/cerna/machinekit-hal/tree/import-mb2hal-from-linuxcnc . 
> Even the include command in src/Makefile was still there.
>
> Cern.
>
>
> Dec 28, 2019, 18:22 by blazin...@gmail.com:
>
>> A commit a year ago in MK legacy addresses something with libmodbus.
>> https://github.com/machinekit/machinekit/tree/master/src/hal/user_comps/mb2hal
>>
>> I don't know that I was asking specifically about LinuxCNC's version unless 
>> there is a more recent change that matters. The version that was in MK is 
>> probably fine if it's useable.
>>
>> On Saturday, December 28, 2019 at 12:10:25 PM UTC-5, ce...@tuta.io wrote:
>>
>>> Well, looking at the mb2hal in LinuxCNC repository, I - at first glance - 
>>> don't see any reason why it should not work in the Machinekit (maybe with 
>>> some simple and generally automatic code changes). 
>>>  
>>> So I would really like to know the reason behind removing it. I think 
>>> (trying to remember) that there was some issue with the libmodbus library 
>>> and Debian package which mb2hal is wrapper around. 
>>>  
>>> Cern. 
>>>  
>>>  
>>> Dec 28, 2019, 16:40 by >> blaz...@gmail.com <>>> : 
>>>  
>>> > Just navigating the split repo directories, "user" comps still exist in 
>>> > the typical directory of MK-hal, tho mb2hal is missing. Nothing like that 
>>> > seems to exist in MK-CNC so I assumed the MO was to keep the user comps 
>>> > in MK-HAL as is. mb2hal also works over serial which aside from Mesa 
>>> > smartserial I don't think has ever been considered "RT" in linuxCNC 
>>> > likely because of baud rates. While I'm sure RT modbus is probably quite 
>>> > useful I don't think the main use for it is usually RT critical. 
>>> > Generally it would take the place of other serial protocols with the 
>>> > convenience of TCP as well for interfacing with something else that is 
>>> > running faster at a hardware level, like talking to a VFD or commanding a 
>>> > servo drive. I think getting it in there in it's current form if possible 
>>> > is probably more important than addressing RT changes, which could always 
>>> > be added later I suppose.  
>>> > 
>>> > On Saturday, December 28, 2019 at 9:50:53 AM UTC-5, >> ce...@tuta.io <>>> 
>>> >  wrote: 
>>> > 
>>> >> I remember that there was some problem with Modbus module which I 
>>> >> thought was solved by ArcEye. (Maybe he will chime in.) But given that 
>>> >> it was the so called "userspace" component, it would be in 
>>> >> machinekit-cnc, not machinekit-hal. But it doesn't look like it is 
>>> >> there. 
>>> >>   
>>> >> The problem with mb2hal is that it presents itself as a non-real-time 
>>> >> component (Modbus is generally considered as a non-RT), but as far as I 
>>> >> know the Modbus RTU can be used in RT, the TCP because of inner working 
>>> >> of TCP communication cannot. 
>>> >>   
>>> >> Given the "RT" and "userspace" components definition in Machinekit is a 
>>> >> prehistoric vintage from LinuxCNC which outlived it's usefuness, maybe 
>>> >> it is time to have something capable both of RT and non-RT functioning. 
>>> >>   
>>> >> I am planning something for which I will need the modbus communication, 
>>> >> problem is, I plan in years. 
>>> >>   
>>> >> Cern. 
>>> >>   
>>> >>   
>>> >> Dec 28, 2019, 02:36 by >> >> blaz...@gmail.com <>>>  <>>> : 
>>> >>   
>>> >> > Maybe a slight misunderstanding as I just realized mb2hal does exist 
>>> >> > in the (legacy?) MK repo but is missing from the mk-hal split repo as 
>>> >> > is a couple other user comps. 
>>> >> > 

Re: [Machinekit] Re: mb2hal?

[cern]

Hmmm...,

simple Ctrl+C, Ctrl+V from LinuxCNC repository to Machinekit-HAL repository 
seems to work (at least it compiles and so something, I have nothing for extra 
quick test [would have to find my arduino]) - 
https://github.com/cerna/machinekit-hal/tree/import-mb2hal-from-linuxcnc . Even 
the include command in src/Makefile was still there.

Cern.


Dec 28, 2019, 18:22 by blazin...@gmail.com:

> A commit a year ago in MK legacy addresses something with libmodbus.
> https://github.com/machinekit/machinekit/tree/master/src/hal/user_comps/mb2hal
>
> I don't know that I was asking specifically about LinuxCNC's version unless 
> there is a more recent change that matters. The version that was in MK is 
> probably fine if it's useable.
>
> On Saturday, December 28, 2019 at 12:10:25 PM UTC-5, ce...@tuta.io wrote:
>
>> Well, looking at the mb2hal in LinuxCNC repository, I - at first glance - 
>> don't see any reason why it should not work in the Machinekit (maybe with 
>> some simple and generally automatic code changes). 
>>  
>> So I would really like to know the reason behind removing it. I think 
>> (trying to remember) that there was some issue with the libmodbus library 
>> and Debian package which mb2hal is wrapper around. 
>>  
>> Cern. 
>>  
>>  
>> Dec 28, 2019, 16:40 by >> blaz...@gmail.com <>>> : 
>>  
>> > Just navigating the split repo directories, "user" comps still exist in 
>> > the typical directory of MK-hal, tho mb2hal is missing. Nothing like that 
>> > seems to exist in MK-CNC so I assumed the MO was to keep the user comps in 
>> > MK-HAL as is. mb2hal also works over serial which aside from Mesa 
>> > smartserial I don't think has ever been considered "RT" in linuxCNC likely 
>> > because of baud rates. While I'm sure RT modbus is probably quite useful I 
>> > don't think the main use for it is usually RT critical. Generally it would 
>> > take the place of other serial protocols with the convenience of TCP as 
>> > well for interfacing with something else that is running faster at a 
>> > hardware level, like talking to a VFD or commanding a servo drive. I think 
>> > getting it in there in it's current form if possible is probably more 
>> > important than addressing RT changes, which could always be added later I 
>> > suppose.  
>> > 
>> > On Saturday, December 28, 2019 at 9:50:53 AM UTC-5, >> ce...@tuta.io <>>>  
>> > wrote: 
>> > 
>> >> I remember that there was some problem with Modbus module which I thought 
>> >> was solved by ArcEye. (Maybe he will chime in.) But given that it was the 
>> >> so called "userspace" component, it would be in machinekit-cnc, not 
>> >> machinekit-hal. But it doesn't look like it is there. 
>> >>   
>> >> The problem with mb2hal is that it presents itself as a non-real-time 
>> >> component (Modbus is generally considered as a non-RT), but as far as I 
>> >> know the Modbus RTU can be used in RT, the TCP because of inner working 
>> >> of TCP communication cannot. 
>> >>   
>> >> Given the "RT" and "userspace" components definition in Machinekit is a 
>> >> prehistoric vintage from LinuxCNC which outlived it's usefuness, maybe it 
>> >> is time to have something capable both of RT and non-RT functioning. 
>> >>   
>> >> I am planning something for which I will need the modbus communication, 
>> >> problem is, I plan in years. 
>> >>   
>> >> Cern. 
>> >>   
>> >>   
>> >> Dec 28, 2019, 02:36 by >> >> blaz...@gmail.com <>>>  <>>> : 
>> >>   
>> >> > Maybe a slight misunderstanding as I just realized mb2hal does exist in 
>> >> > the (legacy?) MK repo but is missing from the mk-hal split repo as is a 
>> >> > couple other user comps. 
>> >> > 
>> >> > I'm not requesting a special lcnc flavored mb2hal, As modbus is a 
>> >> > protocol I would expect a working modbus component to work generically. 
>> >> > What I'm asking is is there a particular reason it's not in the split 
>> >> > repo? If it fails to build for whatever reason I'm sure I'm not the 
>> >> > person anyone wants modifying the code and PR'ing it. I could however 
>> >> > help test it. 
>> >> > 
>

Re: [Machinekit] Re: mb2hal?

[cern]

Well, looking at the mb2hal in LinuxCNC repository, I - at first glance - don't 
see any reason why it should not work in the Machinekit (maybe with some simple 
and generally automatic code changes).

So I would really like to know the reason behind removing it. I think (trying 
to remember) that there was some issue with the libmodbus library and Debian 
package which mb2hal is wrapper around.

Cern.


Dec 28, 2019, 16:40 by blazin...@gmail.com:

> Just navigating the split repo directories, "user" comps still exist in the 
> typical directory of MK-hal, tho mb2hal is missing. Nothing like that seems 
> to exist in MK-CNC so I assumed the MO was to keep the user comps in MK-HAL 
> as is. mb2hal also works over serial which aside from Mesa smartserial I 
> don't think has ever been considered "RT" in linuxCNC likely because of baud 
> rates. While I'm sure RT modbus is probably quite useful I don't think the 
> main use for it is usually RT critical. Generally it would take the place of 
> other serial protocols with the convenience of TCP as well for interfacing 
> with something else that is running faster at a hardware level, like talking 
> to a VFD or commanding a servo drive. I think getting it in there in it's 
> current form if possible is probably more important than addressing RT 
> changes, which could always be added later I suppose. 
>
> On Saturday, December 28, 2019 at 9:50:53 AM UTC-5, ce...@tuta.io wrote:
>
>> I remember that there was some problem with Modbus module which I thought 
>> was solved by ArcEye. (Maybe he will chime in.) But given that it was the so 
>> called "userspace" component, it would be in machinekit-cnc, not 
>> machinekit-hal. But it doesn't look like it is there. 
>>  
>> The problem with mb2hal is that it presents itself as a non-real-time 
>> component (Modbus is generally considered as a non-RT), but as far as I know 
>> the Modbus RTU can be used in RT, the TCP because of inner working of TCP 
>> communication cannot. 
>>  
>> Given the "RT" and "userspace" components definition in Machinekit is a 
>> prehistoric vintage from LinuxCNC which outlived it's usefuness, maybe it is 
>> time to have something capable both of RT and non-RT functioning. 
>>  
>> I am planning something for which I will need the modbus communication, 
>> problem is, I plan in years. 
>>  
>> Cern. 
>>  
>>  
>> Dec 28, 2019, 02:36 by >> blaz...@gmail.com <>>> : 
>>  
>> > Maybe a slight misunderstanding as I just realized mb2hal does exist in 
>> > the (legacy?) MK repo but is missing from the mk-hal split repo as is a 
>> > couple other user comps. 
>> > 
>> > I'm not requesting a special lcnc flavored mb2hal, As modbus is a protocol 
>> > I would expect a working modbus component to work generically. What I'm 
>> > asking is is there a particular reason it's not in the split repo? If it 
>> > fails to build for whatever reason I'm sure I'm not the person anyone 
>> > wants modifying the code and PR'ing it. I could however help test it. 
>> > 
>> > On Friday, December 27, 2019 at 6:50:45 PM UTC-5, Michael Brown wrote: 
>> > 
>> >> As things are currently I'm certain that if you convert any "simple" 
>> >> existing mk userspace component and replace the functional code with 
>> >> that lcnc modbus component you are requesting, test it, get it to 
>> >> function as expected and lastly create a PR.. 
>> >> Someone eventually will forward the pr request into the repo ... :-) 
>> >> 
>> >> Best wishes 
>> >> Michael Brown 
>> >> 
>> >> On Friday, December 27, 2019 at 4:46:09 PM UTC+1, justin White wrote: 
>> >> 
>> >>> Bump...not alotta interest in modbus in my eh? 
>> >>> 
>> > 
>> > 
>> > 
>> > -- 
>> >  website: > >> http://www.machinekit.io>> >  blog: > >> 
>> > http://blog.machinekit.io>> >  github: > >> 
>> > https://github.com/machinekit>>  
>> >  --- 
>> >  You received this message because you are subscribed to the Google Groups 
>> > "Machinekit" group. 
>> >  To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to > >> machi...@>> googlegroups.com <>>> > . 
>> >  To view this discussion on the web visit > >> 
>> > https://groups.google.com

Re: [Machinekit] Re: mb2hal?

[cern]

I remember that there was some problem with Modbus module which I thought was 
solved by ArcEye. (Maybe he will chime in.) But given that it was the so called 
"userspace" component, it would be in machinekit-cnc, not machinekit-hal. But 
it doesn't look like it is there.

The problem with mb2hal is that it presents itself as a non-real-time component 
(Modbus is generally considered as a non-RT), but as far as I know the Modbus 
RTU can be used in RT, the TCP because of inner working of TCP communication 
cannot.

Given the "RT" and "userspace" components definition in Machinekit is a 
prehistoric vintage from LinuxCNC which outlived it's usefuness, maybe it is 
time to have something capable both of RT and non-RT functioning.

I am planning something for which I will need the modbus communication, problem 
is, I plan in years.

Cern.


Dec 28, 2019, 02:36 by blazin...@gmail.com:

> Maybe a slight misunderstanding as I just realized mb2hal does exist in the 
> (legacy?) MK repo but is missing from the mk-hal split repo as is a couple 
> other user comps.
>
> I'm not requesting a special lcnc flavored mb2hal, As modbus is a protocol I 
> would expect a working modbus component to work generically. What I'm asking 
> is is there a particular reason it's not in the split repo? If it fails to 
> build for whatever reason I'm sure I'm not the person anyone wants modifying 
> the code and PR'ing it. I could however help test it.
>
> On Friday, December 27, 2019 at 6:50:45 PM UTC-5, Michael Brown wrote:
>
>> As things are currently I'm certain that if you convert any "simple" 
>> existing mk userspace component and replace the functional code with
>> that lcnc modbus component you are requesting, test it, get it to function 
>> as expected and lastly create a PR..
>> Someone eventually will forward the pr request into the repo ... :-)
>>
>> Best wishes
>> Michael Brown
>>
>> On Friday, December 27, 2019 at 4:46:09 PM UTC+1, justin White wrote:
>>
>>> Bump...not alotta interest in modbus in my eh?
>>>
>
>
>
> --
>  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/acc411f1-36e1-49c5-9c5b-22bc7b47e2b6%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/acc411f1-36e1-49c5-9c5b-22bc7b47e2b6%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/LxBzG2_--3-2%40tuta.io.

Re: [Machinekit] Re: Machinekit rtapi_app process symbol visibility

[cern]

Nov 18, 2019, 08:27 by j...@dovetail-automata.com:

>
>
> 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.
>
Yes, thank you. I know how it works. I was just thinking if the linker 
namespaces would not be a better solution. But the problem with GLibC is that 
nothing younger than 15 years is considered for primetime and so there is (I 
think) only 16 possible namespaces with no ability to reuse or to insert into.

>
>
>
>> 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?
>
Because there is an executive order not to do it. Look at 
https://github.com/machinekit/machinekit-hal/blob/120c9f765cf12bcd337b66308b64b3146a26ec8d/src/rtapi/Submakefile#L165-#L180
 . So I don't want to do something which goes against basic architectural 
design of the application.

Cern.

>
>     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
>  
> <https://groups.google.com/d/msgid/machinekit/e288af89-f67b-40c7-b435-d30406959b15%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/LuLC3wf--3-1%40tuta.io.

Re: [Machinekit] Announcement : new fork "OpenCN"

[cern]

Nov 21, 2019, 22:22 by raoul1.herz...@gmail.com:

> I'm pleased to announce a new fork of LinuxCNC, in the spirit of Machinekit :
>
>
> OpenCNis an open source numerical control (CNC) for high endmachining 
> applications (high dynamics, high precision).
>  OpenCN is originally based on LinuxCNC, but with strongenhancements :
>
> -)completely reworked trajectory planning (TP) including jerk control based 
> onembedded optimization
>  -) Xenomai asymmetric multiprocessing (AMP) for hard realtime, low latency
>  -) up to date Linux kernel
>  -) EtherCat with 10 kHz frame rate and distributed clock(DC), mode B
>  -) Qt based GUI
>  
>  The HW platforms are x86 (available) and ARM (inpreparation).
>
>
>  
>
>
> Software : > https://gitlab.com/mecatronyx/opencnc/opencn
>
>
> Doc : > https://mecatronyx.gitlab.io/opencnc/doc/
>
>
> Youtube : > https://www.youtube.com/channel/UC8FQCu_fKYfK7QRDN0j_dBw
>
>
> best regards,
>
> Raoul
>
Hello,
nice, at first glance the code looks lot simpler and cleaner. Are you that guy 
who was talking at a Xenomai list about inter-processor communication and 
complete separation of cores?

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/a08724f8-983b-48bd-933c-b297123626e8%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/a08724f8-983b-48bd-933c-b297123626e8%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/LuF-iWj--3-1%40tuta.io.

[Machinekit] Machinekit rtapi_app process symbol visibility

[cern]

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?

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.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/Ltg5hHg--3-1%40tuta.io.

Re: [Machinekit] Re: What potential hal implementation change could a low cost soc-fpga bring to the table ?

[cern]

BTW,
on Xenomai mail-list, there is a new announcement - 
https://xenomai.org/pipermail/xenomai/2019-October/041719.html 
<https://xenomai.org/pipermail/xenomai/2019-October/041719.html> - about 
machine control project based on ideas from LinuxCNC (per say). By the looks of 
their blog: http://blog.reds.ch/ <http://blog.reds.ch/> - it looks like they 
are into SOCFPGA.

So maybe they will have something reusable for this project in the works.

Cern.


Oct 2, 2019, 00:52 by mib.holotro...@gmail.com:

> On Tuesday, 1 October 2019 22:48:05 UTC+2, ce...@tuta.io  wrote:
>
>> Oct 1, 2019, 22:11 by >> mib.ho...@gmail.com <>>> : 
>>  
>> > On Tuesday, 1 October 2019 21:25:07 UTC+2, >> ce...@tuta.io <>>>   wrote: 
>> > 
>> >> Oct 1, 2019, 01:35 by >> >> mib.ho...@gmail.com <>>>  <>>> : 
>> >>   
>> >> > 
>> >> > 
>> >> > On Monday, 30 September 2019 23:53:36 UTC+2, >> >> ce...@tuta.io <>>>  
>> >> > <>>>   wrote: 
>> >> > 
>> >> >> There is a kernel module driver - src/rtapi/shmdrv folder and shmdrv.h 
>> >> >> and shmdrv.c specifically - which I understand was initially meant for 
>> >> >> RTAI support (maybe) but then as everything moved into userspace it 
>> >> >> was phased out. But given this use-case, it wouldn't be too hard to 
>> >> >> dust it off and use it for kernel-space connection with AXI DMA 
>> >> >> driver. Looking at the >> >> >> https://xilinx-wiki.atlassian 
>> >> >> <https://xilinx-wiki.atlassian>>>  <>> https://xilinx-wiki.atlassian 
>> >> >> <https://xilinx-wiki.atlassian>>> >>> .>> >> 
>> >> >> net/wiki/spaces/A/pages/>> 18842337/DMA+Drivers+-+Soft+>> IPs <>> >> 
>> >> >> https://xilinx-wiki <https://xilinx-wiki>>> .>> >> 
>> >> >> atlassian.net/wiki/spaces/A/ <http://atlassian.net/wiki/spaces/A/>>> 
>> >> >> >> pages/18842337/DMA+Drivers+-+>>> > Soft+IPs <>> 
>> >> >> https://xilinx-wiki.>> atlassian.net/wiki/spaces/A/>> 
>> >> >> pages/18842337/DMA+Drivers+-+>> Soft+IPs 
>> >> >> <https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842337/DMA+Drivers+-+Soft+IPs>>>
>> >> >>  >>> >>>  <>> >> >> https://xilinx-wiki <https://xilinx-wiki>>>  <>> 
>> >> >> https://xilinx-wiki <https://xilinx-wiki>>> >>> .>> >> >> 
>> >> >> atlassian.net/wiki/spaces/A/ <http://atlassian.net/wiki/spaces/A/>>>  
>> >> >> <>> http://atlassian.net/wiki/>> spaces/A/ 
>> >> >> <http://atlassian.net/wiki/spaces/A/>>> >>> >> 
>> >> >> pages/18842337/DMA+Drivers+-+>>> >> > Soft+IPs <>> >> 
>> >> >> https://xilinx-wiki <https://xilinx-wiki>>> .>> >> 
>> >> >> atlassian.net/wiki/spaces/A/ <http://atlassian.net/wiki/spaces/A/>>> 
>> >> >> >> pages/18842337/DMA+Drivers+-+>>> > Soft+IPs <>> 
>> >> >> https://xilinx-wiki.>> atlassian.net/wiki/spaces/A/>> 
>> >> >> pages/18842337/DMA+Drivers+-+>> Soft+IPs 
>> >> >> <https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842337/DMA+Drivers+-+Soft+IPs>>>
>> >> >>  >>> >>> > page from Xilinx and the Linux port at >> >> >> 
>> >> >> https://github.com/Xilinx/ <https://github.com/Xilinx/>>>  <>> 
>> >> >> https://github.com/Xilinx/ <https://github.com/Xilinx/>>> >>> >> 
>> >> >> linux-xlnx/tree/master/>> drivers/dma/xilinx <>> >> 
>> >> >> https://github.com/Xilinx/ <https://github.com/Xilinx/>>> >> 
>> >> >> linux-xlnx/tree/master/>> drivers/dma/xilinx <>> 
>> >> >> https://github.com/Xilinx/>> linux-xlnx/tree/master/>> 
>> >> >> drivers/dma/xilinx 
>> >> >> <https://github.com/Xilinx/linux-xlnx/tree/master/drivers/dma/xilinx>>>
>> >> >&g

Re: [Machinekit] Re: What potential hal implementation change could a low cost soc-fpga bring to the table ?

[cern]

ining when to wake them (flag, call on pin 
change etc). And only this mechanism could be reused for AXI DMA module, not 
the whole file access thingy. The DMA-to-signalling should be as zero-copy and 
small as possible. (You know, the whole idea is "Once it is there, lets use it 
for as many things as possible".)

IOCTL I was thinking to use only for configuration (non-realtime) purpose. 
("Create new instance of a HAL component named...").

>
>  
>
>> In the Linux-side, there will also need to be an object in the HAL 
>> representing the PL-side component. However, it would need some careful 
>> planning and thinking though. Not just adding new component type beside the 
>> TYPE_REMOTE, TYPE_USER, TYPE_RT. (Because, I don't feel fine with TYPE_user 
>> and TYPE_RT component differentiation. Being real-time or non-realtime is 
>> not distinction on component level, but actually on flavour level and thread 
>> level - when you run the POSIX-NONREALTIME flavour, you are running the 
>> TYPE_RT as a TYPE_USER. So nowadays, the only distinction is that TYPE_USER 
>> components are running with external thread/scheduling. Which with this 
>> state machine idea could TYPE_RT too. [It's crutch from LinuxCNC time.]) So 
>> part of the work is to figure out how to make it generic enough and not fuck 
>> everyone else up. 
>>  
>> >   
>> > 
>> >> 
>> >> 
>> >> However, would it be possible to use some of these premade AXI DMA IP 
>> >> cores for this idea? 
>> >> 
>> > Yes 
>> >   
>> > 
>> >> Given it is Open-Source and probably should encompass both Intel and 
>> >> Xilinx? 
>> >> 
>> > 
>> > 
>> > Oh I wouldn't worry right now about being Intel compatible it seems like 
>> > Altera is destined to survive Intel(who has brought no visible innovation 
>> > to the sub $500 socfpga market in their time), 
>> > right now Xilinx is holding the lead (the soft spot), so let's focus on 
>> > what we currently have available to play with 
>> > 
>> Oh, OK. But just for the "maybe" in the distant future, I don't think it 
>> should be completely vendor locked and some "generic" API should be 
>> prepared. 
>>
>
> What I meant was Xilinx seem to be in the zone right now If we create 
> something generic based on some ot their "stuff" I'm sure other vendors will 
> follow suit.
>  
>
>>
>> BTW, should the partial reconfiguration part be "real-time"? Without the 
>> shutdown of the parts which are not being reconfigured? 
>>
> There can be several (many) PR regions:
>  I/O's to a PR region are "frozen" (only) while it is reconfigured.
> When you reconfigure a pr region all other parts (including other PR regions) 
> act like static regions (keep running). 
>
Thought so and makes sense. I am just thinking about the netting (connections 
of pins) and which issues would that raise.

Cern.

>>
>> Cern. 
>>  
>> >   
>> > 
>> >> 
>> >> Cern. 
>> >>   
>> >>   
>> >> 
>> > 
>> > Michael B.  
>> > 
>> >> 
>> >> Sep 27, 2019, 23:03 by >> >> ce...@tuta.io <>>>  <>>> : 
>> >>   
>> >> > Been doing some (extremely light) reading into AXI/CHI and besides 
>> >> > discovering that it will need many 180° world-view changes before even 
>> >> > basic understanding sets in it looks like the possibility of memory 
>> >> > access/sharing is real. Differently than I thought but still good 
>> >> > enough. 
>> >> > 
>> >> > Comes to mind how much of needed work is already done by vendor and 
>> >> > community and how much it would need to be done (programmed) by 
>> >> > Machinekit? 
>> >> > 
>> >> > Also took high altitude look into C/C++ HLS and discovered that it 
>> >> > looks like something even I could do. That's cool. 
>> >> > 
>> >> > Cern. 
>> >> > 
>> >> > 
>> >> > Sep 26, 2019, 23:04 by >> >> mib.ho...@gmail.com <>>>  <>>> : 
>> >> > 
>> >> >> 
>> >> >> 
>> >> >> On Thursday, 26 September 2019 21:19:04 UTC+2, >> >> ce...@tuta.io 
>> >> >> <>&g

Re: [Machinekit] Re: What potential hal implementation change could a low cost soc-fpga bring to the table ?

[cern]

Oct 1, 2019, 21:25 by c...@tuta.io:

> Oct 1, 2019, 01:35 by mib.holotro...@gmail.com:
>
>>
>>
>> On Monday, 30 September 2019 23:53:36 UTC+2, ce...@tuta.io  wrote:
>>
>>> There is a kernel module driver - src/rtapi/shmdrv folder and shmdrv.h and 
>>> shmdrv.c specifically - which I understand was initially meant for RTAI 
>>> support (maybe) but then as everything moved into userspace it was phased 
>>> out. But given this use-case, it wouldn't be too hard to dust it off and 
>>> use it for kernel-space connection with AXI DMA driver. Looking at the >> 
>>> https://xilinx-wiki.atlassian.>> net/wiki/spaces/A/pages/>> 
>>> 18842337/DMA+Drivers+-+Soft+>> IPs 
>>> <https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842337/DMA+Drivers+-+Soft+IPs>>>
>>>   <>> https://xilinx-wiki.>> atlassian.net/wiki/spaces/A/>> 
>>> pages/18842337/DMA+Drivers+-+>> Soft+IPs 
>>> <https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842337/DMA+Drivers+-+Soft+IPs>>>
>>>  > page from Xilinx and the Linux port at >> https://github.com/Xilinx/>> 
>>> linux-xlnx/tree/master/>> drivers/dma/xilinx 
>>> <https://github.com/Xilinx/linux-xlnx/tree/master/drivers/dma/xilinx>>>  
>>> <>> https://github.com/Xilinx/>> linux-xlnx/tree/master/>> 
>>> drivers/dma/xilinx 
>>> <https://github.com/Xilinx/linux-xlnx/tree/master/drivers/dma/xilinx>>> > 
>>> it should be possible to connect the HAL memory with DMA driver. 
>>>  
>>>
>> seems highly probable
>>
>>  
>>
>>> My initial idea to synchronize (or have one) memory is probably not that 
>>> great. Linux side Hal memory and FPGA side HAL memory would be better off 
>>> synchronized only on pins (data) which transcend the barrier. (HAL 
>>> component which runs in Linux RT thread with pin connected to HAL component 
>>> in FPGA fabric.) That way the number of signal changes from fast FPGA side 
>>> to "slow" ARM side would be minimal.
>>>
>>
>> In the fpga some sort of state machine(s) logic would be implemented to act 
>> like a (small os)(protocol governing the rules for behaviour and triggering 
>> dma communication.
>>
> Something like this will need to be implemented in PS-side HAL/RTAPI too. To 
> trigger the DMA communication back to PL-side. (I would like to use this 
> mechanism with the MachinekitFS idea. BTW, looking through the EMC-dev 
> channel, I discovered that Haberler had this idea long before me in 
> prehistoric era. So it should be fairly generic.)
>
> In the Linux-side, there will also need to be an object in the HAL 
> representing the PL-side component. However, it would need some careful 
> planning and thinking though. Not just adding new component type beside the 
> TYPE_REMOTE, TYPE_USER, TYPE_RT. (Because, I don't feel fine with TYPE_user 
> and TYPE_RT component differentiation. Being real-time or non-realtime is not 
> distinction on component level, but actually on flavour level and thread 
> level - when you run the POSIX-NONREALTIME flavour, you are running the 
> TYPE_RT as a TYPE_USER. So nowadays, the only distinction is that TYPE_USER 
> components are running with external thread/scheduling. Which with this state 
> machine idea could TYPE_RT too. [It's crutch from LinuxCNC time.]) So part of 
> the work is to figure out how to make it generic enough and not fuck everyone 
> else up.
>
BTW, I am moaning about it in this thread because this functionality could 
terminate the need of some projects for RT capable Linux KERNEL.

Cern.

>>  
>>
>>>
>>>
>>> However, would it be possible to use some of these premade AXI DMA IP cores 
>>> for this idea?
>>>
>> Yes
>>  
>>
>>> Given it is Open-Source and probably should encompass both Intel and 
>>> Xilinx? 
>>>
>>
>>
>> Oh I wouldn't worry right now about being Intel compatible it seems like 
>> Altera is destined to survive Intel(who has brought no visible innovation to 
>> the sub $500 socfpga market in their time),
>> right now Xilinx is holding the lead (the soft spot), so let's focus on what 
>> we currently have available to play with
>>
> Oh, OK. But just for the "maybe" in the distant future, I don't think it 
> should be completely vendor locked and some "generic" API should be prepared.
>
> BTW, should the partial reconfiguration part be "rea

Re: [Machinekit] Re: What potential hal implementation change could a low cost soc-fpga bring to the table ?

[cern]

Oct 1, 2019, 01:35 by mib.holotro...@gmail.com:

>
>
> On Monday, 30 September 2019 23:53:36 UTC+2, ce...@tuta.io  wrote:
>
>> There is a kernel module driver - src/rtapi/shmdrv folder and shmdrv.h and 
>> shmdrv.c specifically - which I understand was initially meant for RTAI 
>> support (maybe) but then as everything moved into userspace it was phased 
>> out. But given this use-case, it wouldn't be too hard to dust it off and use 
>> it for kernel-space connection with AXI DMA driver. Looking at the >> 
>> https://xilinx-wiki.atlassian.>> net/wiki/spaces/A/pages/>> 
>> 18842337/DMA+Drivers+-+Soft+>> IPs 
>> <https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842337/DMA+Drivers+-+Soft+IPs>>>
>>   <>> https://xilinx-wiki.>> atlassian.net/wiki/spaces/A/>> 
>> pages/18842337/DMA+Drivers+-+>> Soft+IPs 
>> <https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842337/DMA+Drivers+-+Soft+IPs>>>
>>  > page from Xilinx and the Linux port at >> https://github.com/Xilinx/>> 
>> linux-xlnx/tree/master/>> drivers/dma/xilinx 
>> <https://github.com/Xilinx/linux-xlnx/tree/master/drivers/dma/xilinx>>>  <>> 
>> https://github.com/Xilinx/>> linux-xlnx/tree/master/>> drivers/dma/xilinx 
>> <https://github.com/Xilinx/linux-xlnx/tree/master/drivers/dma/xilinx>>> > it 
>> should be possible to connect the HAL memory with DMA driver. 
>>  
>>
> seems highly probable
>
>  
>
>> My initial idea to synchronize (or have one) memory is probably not that 
>> great. Linux side Hal memory and FPGA side HAL memory would be better off 
>> synchronized only on pins (data) which transcend the barrier. (HAL component 
>> which runs in Linux RT thread with pin connected to HAL component in FPGA 
>> fabric.) That way the number of signal changes from fast FPGA side to "slow" 
>> ARM side would be minimal.
>>
>
> In the fpga some sort of state machine(s) logic would be implemented to act 
> like a (small os)(protocol governing the rules for behaviour and triggering 
> dma communication.
>
Something like this will need to be implemented in PS-side HAL/RTAPI too. To 
trigger the DMA communication back to PL-side. (I would like to use this 
mechanism with the MachinekitFS idea. BTW, looking through the EMC-dev channel, 
I discovered that Haberler had this idea long before me in prehistoric era. So 
it should be fairly generic.)

In the Linux-side, there will also need to be an object in the HAL representing 
the PL-side component. However, it would need some careful planning and 
thinking though. Not just adding new component type beside the TYPE_REMOTE, 
TYPE_USER, TYPE_RT. (Because, I don't feel fine with TYPE_user and TYPE_RT 
component differentiation. Being real-time or non-realtime is not distinction 
on component level, but actually on flavour level and thread level - when you 
run the POSIX-NONREALTIME flavour, you are running the TYPE_RT as a TYPE_USER. 
So nowadays, the only distinction is that TYPE_USER components are running with 
external thread/scheduling. Which with this state machine idea could TYPE_RT 
too. [It's crutch from LinuxCNC time.]) So part of the work is to figure out 
how to make it generic enough and not fuck everyone else up.

>  
>
>>
>>
>> However, would it be possible to use some of these premade AXI DMA IP cores 
>> for this idea?
>>
> Yes
>  
>
>> Given it is Open-Source and probably should encompass both Intel and Xilinx? 
>>
>
>
> Oh I wouldn't worry right now about being Intel compatible it seems like 
> Altera is destined to survive Intel(who has brought no visible innovation to 
> the sub $500 socfpga market in their time),
> right now Xilinx is holding the lead (the soft spot), so let's focus on what 
> we currently have available to play with
>
Oh, OK. But just for the "maybe" in the distant future, I don't think it should 
be completely vendor locked and some "generic" API should be prepared.

BTW, should the partial reconfiguration part be "real-time"? Without the 
shutdown of the parts which are not being reconfigured?

Cern.

>  
>
>>
>> Cern. 
>>   
>>  
>>
>
> Michael B. 
>
>>
>> Sep 27, 2019, 23:03 by >> ce...@tuta.io <>>> : 
>>  
>> > Been doing some (extremely light) reading into AXI/CHI and besides 
>> > discovering that it will need many 180° world-view changes before even 
>> > basic understanding sets in it looks like the possibility of memory 
>> > access/sharing is real. Differently

Re: [Machinekit] Re: What potential hal implementation change could a low cost soc-fpga bring to the table ?

[cern]

There is a kernel module driver - src/rtapi/shmdrv folder and shmdrv.h and 
shmdrv.c specifically - which I understand was initially meant for RTAI support 
(maybe) but then as everything moved into userspace it was phased out. But 
given this use-case, it wouldn't be too hard to dust it off and use it for 
kernel-space connection with AXI DMA driver. Looking at the 
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842337/DMA+Drivers+-+Soft+IPs
 
<https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842337/DMA+Drivers+-+Soft+IPs>
 page from Xilinx and the Linux port at 
https://github.com/Xilinx/linux-xlnx/tree/master/drivers/dma/xilinx 
<https://github.com/Xilinx/linux-xlnx/tree/master/drivers/dma/xilinx> it should 
be possible to connect the HAL memory with DMA driver.

My initial idea to synchronize (or have one) memory is probably not that great. 
Linux side Hal memory and FPGA side HAL memory would be better off synchronized 
only on pins (data) which transcend the barrier. (HAL component which runs in 
Linux RT thread with pin connected to HAL component in FPGA fabric.) That way 
the number of signal changes from fast FPGA side to "slow" ARM side would be 
minimal.

However, would it be possible to use some of these premade AXI DMA IP cores for 
this idea? Given it is Open-Source and probably should encompass both Intel and 
Xilinx?

Cern.
 


Sep 27, 2019, 23:03 by c...@tuta.io:

> Been doing some (extremely light) reading into AXI/CHI and besides 
> discovering that it will need many 180° world-view changes before even basic 
> understanding sets in it looks like the possibility of memory access/sharing 
> is real. Differently than I thought but still good enough.
>
> Comes to mind how much of needed work is already done by vendor and community 
> and how much it would need to be done (programmed) by Machinekit?
>
> Also took high altitude look into C/C++ HLS and discovered that it looks like 
> something even I could do. That's cool.
>
> Cern.
>
>
> Sep 26, 2019, 23:04 by mib.holotro...@gmail.com:
>
>>
>>
>> On Thursday, 26 September 2019 21:19:04 UTC+2, ce...@tuta.io  wrote:
>>
>>> Sep 26, 2019, 17:53 by >> mib.ho...@gmail.com <>>> : 
>>>
>>> > I'm probably the wrong guy to answer this question as I'm a noob into how 
>>> > sw os's work, but regarding linux memory access from the fpga: 
>>> > 
>>> Thanks. Sorry for probably idiotic questions, I am noob about FPGA 
>>> development. 
>>>
>>>
>>
>> Ok :-)
>>  
>>
>>> > 
>>> > A (hw) function in  fpga (also with dma channels), can address any linux 
>>> > memory location (even sw restricted ones). 
>>> > 
>>> > If needed it is also possible to setup say like a 64KB dual port shared 
>>> > memory block inside the fpga fabric and have both fpga and linux access 
>>> > to that.  
>>> > 
>>> Are both solutions useful for this scenario? I imagine that the frequency 
>>> of change will be lot higher on FPGA side than on Linux side. For example 
>>> the encoder counter will be updated almost constantly. 
>>>
>>> Cern. 
>>>
>>>
>>
>> Well on the fpga side you don't have any cpu-like structure that governs 
>> every thing,
>> only clock signals, and flags
>> and every function you implement runs on it's own simultaneously (in 
>> parallel) (think 1 sw core for every function)
>> on every clock cycle.
>>
>>  
>>
>>> > 
>>> > 
>>> > On Thursday, 26 September 2019 15:48:35 UTC+2, >> ce...@tuta.io <>>>   
>>> > wrote: 
>>> > 
>>> >> Sep 26, 2019, 01:29 by >> >> mib.ho...@gmail.com <>>>  <>>> : 
>>> >>   
>>> >> > Well current state is that PR (Partial Reconfiguration) is brand new 
>>> >> > to the OS (Open Source) world,  
>>> >> > as > IntelfPGA (former Altera) "just" have promised it for their 19.1 
>>> >> > release (no lite version out yet), <>> >> https://github.com/ 
>>> >> > <https://github.com/>>> >> machinekit/mksocfpga/issues/>> 100 <>> 
>>> >> > https://github.com/>> machinekit/mksocfpga/issues/>> 100 
>>> >> > <https://github.com/machinekit/mksocfpga/issues/100>>> >>> > 
>>> >> > on the contrary Xilinx have sneaked it out very quietly with their 
>>> >> > Vivado 2019.1 releas

Re: [Machinekit] Re: Rpi3, Beagleboard X15, And Avnet Ultra96

[cern]

What about the ultracheap ZYNQ boards coming from China like this one: 
https://www.aliexpress.com/item/442572307.html?spm=a2g0o.productlist.0.0.ffa06f58V00L7M&algo_pvid=1673d04d-c50f-4962-9448-92686905272a&algo_expid=1673d04d-c50f-4962-9448-92686905272a-0&btsid=24d1b06e-03fd-466c-a7b1-dd52368fa2ad&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_53
 
<https://www.aliexpress.com/item/442572307.html?spm=a2g0o.productlist.0.0.ffa06f58V00L7M&algo_pvid=1673d04d-c50f-4962-9448-92686905272a&algo_expid=1673d04d-c50f-4962-9448-92686905272a-0&btsid=24d1b06e-03fd-466c-a7b1-dd52368fa2ad&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_53>
 ?

Specifications are low, but the price is very interesting. And for 
Machinekit-HAL it could be enough.

Cern.


Sep 20, 2019, 15:08 by mib.holotro...@gmail.com:

> Initial Pinfile 
> <https://github.com/the-snowwhite/mksocfpga/blob/ultra96-raw/HW/VivadoProjects/ultra96/ultra96_v1/const/PIN_ULTR_36.vhd>
> I/O routing 
> <https://github.com/the-snowwhite/mksocfpga/blob/ultra96-raw/HW/VivadoProjects/ultra96/ultra96_v1/const/u96_v1_pinmap.xdc>
>
>
> On Friday, 20 September 2019 04:34:41 UTC+2, justin White  wrote:
>
>> What's the I/O on this thing look like in hm2?
>>
>> On Thursday, September 19, 2019 at 8:19:55 PM UTC-4, Michael Brown wrote:
>>
>>> I have released a >>> Ultra96 beta sd Image including (a) mksocfpga bitfile 
>>> <https://github.com/the-snowwhite/soc-image-buildscripts/releases/tag/mk-ultra96_pre>
>>> For those ready to testrun mksocfpga amr64
>>>
>>> https://github.com/the->>> snowwhite/soc-image->>> 
>>> buildscripts/releases/tag/mk->>> ultra96_pre 
>>> <https://github.com/the-snowwhite/soc-image-buildscripts/releases/tag/mk-ultra96_pre>
>>>
>>> Time to begin warming up for release party :-)
>>>
>>> On Friday, 13 September 2019 17:56:38 UTC+2, Michael Brown  wrote:
>>>
>>>> Just to clarify a mistake in the top post:
>>>>
>>>> Beaglebone x15 + the new AI model are fully 32-bit --> armhf
>>>>
>>>> Rpi3 HW is fully 64 bit capable (cortex A53),
>>>> Rpi3 SW (os) is still 32-bit ATM --> armhf
>>>>
>>>> Leaving the Ultra96 as sole contender with FULL 64-bit HW & SW support --> 
>>>> aarch64
>>>>
>>>> Sorry for the earlier confusion...
>>>>
>>>> On Monday, 6 August 2018 16:38:20 UTC+2, Michael Brown  wrote:
>>>>
>>>>> I would like to present an interresting mksoc candidate I have, been able 
>>>>> to
>>>>> do some prelimonary evasstigations on:
>>>>>
>>>>> http://zedboard.org/product/>>>>> ultra96 
>>>>> <http://zedboard.org/product/ultra96>
>>>>>
>>>>> Cpu wise in same club as the Rpi3 and Beagleboard X15
>>>>>
>>>>> Same price as the x15 if you import from usa:
>>>>> my import clause for consideration(>>>>> https://drive.>>>>> 
>>>>> google.com/open?id=16r6Bn->>>>> AeZ5RZyROAEXuPaOLFylihsUVm 
>>>>> <https://drive.google.com/open?id=16r6Bn-AeZ5RZyROAEXuPaOLFylihsUVm>>>>>> 
>>>>> ):
>>>>>
>>>>> Fpga fabric ~4x DE10 Nano roughly.
>>>>> I/O wise 16 1.8v I/O out of the box + High speed mezaine + ??
>>>>>
>>>>> A 3.3v/5v adaptor (audio mezz..) is still available for $5 incl freight 
>>>>> (ask).
>>>>>
>>>>> Mali 400 Gpu.
>>>>>
>>>>> Unique for its price class 
>>>>>
>>>>> First it finally gave me the opportunity to get started with Vivado 
>>>>> (2018.2), and
>>>>> this has been a very pleasant experience as I find it much more mature, 
>>>>> comprehensive and informative
>>>>> than the Altera based tools sill available.
>>>>>
>>>>> The ultra96 comes with petalinux based upon yocto/ openembedded.
>>>>>
>>>>> Via my build script(s) I have also been able to get it running Debian 
>>>>> stretch and Ubuntu bionic,
>>>>> with 14xx kernel however only with software framebuffer as the Mali 400 
>>>>> gpu drivers are wierd. 
>>>>>
>>>>> On the interesting node I have initiated a request at the danish Xilinx 
>>>>> distributors seeking a lic

Re: [Machinekit] Re: What potential hal implementation change could a low cost soc-fpga bring to the table ?

[cern]

Sep 26, 2019, 23:48 by blazin...@gmail.com:

> So what is special about socfpga that makes this specific to socfpga chips 
> rather than just an FPGA  communicating to the CPU in another form? 
>
As I see it, it is quick communication bus between PS and PL units where you 
can share memory effectively.

>
> If I'm following the idea right we're basically talking about running hal 
> components individually as FPGA soft cores. I follow that idea but what is 
> the main benefit? Is it to mitigate the latency issues of the lower 
> performance ARM cores of the SOC? 
>
I don't think it's about lowering latency, however latency in itself should be 
considerably lower in FPGA fabric than in Linux OS. It's more in the way tasks 
are executed now in HAL and how they could be in FPGA. Basically it is about 
concurrency. Now you have some thread running on CPU core (in best case 
scenario isolated one) periodically scheduled for execution. Everything is 
sequential. What you can do with the dawn of multicore is to have multiple 
threads each isolated to own core each performing some specific (but connected) 
subset of tasks. (So to not have everything hooked up on one 1ms thread as is 
typical from LinuxCNC world). That is stumbling onto the problem that you have 
the memory synchronization by message from the thread itself to and from Mesa 
FPGA (example for simplicity, nobody is using anything else). You cannot do 
that effectively from multiple threads.

> Seems like alot of work, compatibility, portability, and maintainability 
> issues. If I had to guess, I would say that a headless socfpga on mk-hal and 
> mk-cnc running on a more competent cpu/gpu would make for a well performing, 
> low cost system. The socfpga CPU would already be independent of the 
> constraints caused by running a display and higher level languages right?
>
Display yes, higher lever languages maybe, but probably not. (And there is no 
reason for it. It would still need Linux.)

Cern.

> I know there is work to be done in that area but that seems like a solution 
> to alot of problems in and of itself.
>
> On Thu, Sep 26, 2019 at 5:04 PM Michael Brown <> mib.holotro...@gmail.com 
> <mailto:mib.holotro...@gmail.com>> > wrote:
>
>>
>>
>> On Thursday, 26 September 2019 21:19:04 UTC+2, >> ce...@tuta.io 
>> <mailto:ce...@tuta.io>>>  wrote:
>>
>>> Sep 26, 2019, 17:53 by >>> mib.ho...@gmail.com <>>>> : 
>>>  
>>> > I'm probably the wrong guy to answer this question as I'm a noob into how 
>>> > sw os's work, but regarding linux memory access from the fpga: 
>>> > 
>>> Thanks. Sorry for probably idiotic questions, I am noob about FPGA 
>>> development. 
>>>  
>>>
>>
>> Ok :-)
>>  
>>
>>> > 
>>> > A (hw) function in  fpga (also with dma channels), can address any linux 
>>> > memory location (even sw restricted ones). 
>>> > 
>>> > If needed it is also possible to setup say like a 64KB dual port shared 
>>> > memory block inside the fpga fabric and have both fpga and linux access 
>>> > to that.  
>>> > 
>>> Are both solutions useful for this scenario? I imagine that the frequency 
>>> of change will be lot higher on FPGA side than on Linux side. For example 
>>> the encoder counter will be updated almost constantly. 
>>>  
>>> Cern. 
>>>  
>>>
>>
>> Well on the fpga side you don't have any cpu-like structure that governs 
>> every thing,
>> only clock signals, and flags
>> and every function you implement runs on it's own simultaneously (in 
>> parallel) (think 1 sw core for every function)
>> on every clock cycle.
>>
>>  
>>
>>> > 
>>> > 
>>> > On Thursday, 26 September 2019 15:48:35 UTC+2, >>> ce...@tuta.io <>>>>   
>>> > wrote: 
>>> > 
>>> >> Sep 26, 2019, 01:29 by >> >>> mib.ho...@gmail.com <>>>>  <>>> : 
>>> >>   
>>> >> > Well current state is that PR (Partial Reconfiguration) is brand new 
>>> >> > to the OS (Open Source) world,  
>>> >> > as > IntelfPGA (former Altera) "just" have promised it for their 19.1 
>>> >> > release (no lite version out yet), <>> >>> https://github.com/ 
>>> >> > <https://github.com/>>>> >> machinekit/mksocfpga/issues/>> 100 <>>> 
>>> >> > https://github

Re: [Machinekit] Re: What potential hal implementation change could a low cost soc-fpga bring to the table ?

[cern]

Been doing some (extremely light) reading into AXI/CHI and besides discovering 
that it will need many 180° world-view changes before even basic understanding 
sets in it looks like the possibility of memory access/sharing is real. 
Differently than I thought but still good enough.

Comes to mind how much of needed work is already done by vendor and community 
and how much it would need to be done (programmed) by Machinekit?

Also took high altitude look into C/C++ HLS and discovered that it looks like 
something even I could do. That's cool.

Cern.


Sep 26, 2019, 23:04 by mib.holotro...@gmail.com:

>
>
> On Thursday, 26 September 2019 21:19:04 UTC+2, ce...@tuta.io  wrote:
>
>> Sep 26, 2019, 17:53 by >> mib.ho...@gmail.com <>>> : 
>>  
>> > I'm probably the wrong guy to answer this question as I'm a noob into how 
>> > sw os's work, but regarding linux memory access from the fpga: 
>> > 
>> Thanks. Sorry for probably idiotic questions, I am noob about FPGA 
>> development. 
>>  
>>
>
> Ok :-)
>  
>
>> > 
>> > A (hw) function in  fpga (also with dma channels), can address any linux 
>> > memory location (even sw restricted ones). 
>> > 
>> > If needed it is also possible to setup say like a 64KB dual port shared 
>> > memory block inside the fpga fabric and have both fpga and linux access to 
>> > that.  
>> > 
>> Are both solutions useful for this scenario? I imagine that the frequency of 
>> change will be lot higher on FPGA side than on Linux side. For example the 
>> encoder counter will be updated almost constantly. 
>>  
>> Cern. 
>>  
>>
>
> Well on the fpga side you don't have any cpu-like structure that governs 
> every thing,
> only clock signals, and flags
> and every function you implement runs on it's own simultaneously (in 
> parallel) (think 1 sw core for every function)
> on every clock cycle.
>
>  
>
>> > 
>> > 
>> > On Thursday, 26 September 2019 15:48:35 UTC+2, >> ce...@tuta.io <>>>   
>> > wrote: 
>> > 
>> >> Sep 26, 2019, 01:29 by >> >> mib.ho...@gmail.com <>>>  <>>> : 
>> >>   
>> >> > Well current state is that PR (Partial Reconfiguration) is brand new to 
>> >> > the OS (Open Source) world,  
>> >> > as > IntelfPGA (former Altera) "just" have promised it for their 19.1 
>> >> > release (no lite version out yet), <>> >> https://github.com/ 
>> >> > <https://github.com/>>> >> machinekit/mksocfpga/issues/>> 100 <>> 
>> >> > https://github.com/>> machinekit/mksocfpga/issues/>> 100 
>> >> > <https://github.com/machinekit/mksocfpga/issues/100>>> >>> > 
>> >> > on the contrary Xilinx have sneaked it out very quietly with their 
>> >> > Vivado 2019.1 release this summer <>> >> https://github.com/ 
>> >> > <https://github.com/>>> >> machinekit/mksocfpga/issues/>> 100 <>> 
>> >> > https://github.com/>> machinekit/mksocfpga/issues/>> 100 
>> >> > <https://github.com/machinekit/mksocfpga/issues/100>>> >>> > 
>> >> > 
>> >> > So while the idea has had time to settle in this old thread, the 
>> >> > possibility of implementation here in Machinekit is brand new :-) 
>> >> > Michael B 
>> >> > 
>> >> Well, 
>> >> and how it is with the memory? And with the bus connection between hard 
>> >> ARM processor and FPGA fabric? Because now we have the HAL memory block 
>> >> locked into RAM with HAL library enabled allocating and memory 
>> >> (alignment) management from Linux side. But I presume that for FPGA-side 
>> >> components, that would not be good enough and this memory block will have 
>> >> to be directly in FPGA fabric so the components can use this space as a 
>> >> "register", right? Will then be possible to atimically access this memory 
>> >> (or variables there stored) both from Linux running on an ARM core and 
>> >> component in FPGA fabric? (I mean as a direct memory access, zero-copy, 
>> >> not some memory synchronization.) 
>> >>   
>> >> Cern. 
>> >>   
>> >> > 
>> >> > On Wednesday, 25 September 2019 20:49:04 UTC+2, >> >> c

Re: [Machinekit] Re: What potential hal implementation change could a low cost soc-fpga bring to the table ?

[cern]

Sep 26, 2019, 17:53 by mib.holotro...@gmail.com:

> I'm probably the wrong guy to answer this question as I'm a noob into how sw 
> os's work, but regarding linux memory access from the fpga:
>
Thanks. Sorry for probably idiotic questions, I am noob about FPGA development.

>
> A (hw) function in  fpga (also with dma channels), can address any linux 
> memory location (even sw restricted ones).
>
> If needed it is also possible to setup say like a 64KB dual port shared 
> memory block inside the fpga fabric and have both fpga and linux access to 
> that. 
>
Are both solutions useful for this scenario? I imagine that the frequency of 
change will be lot higher on FPGA side than on Linux side. For example the 
encoder counter will be updated almost constantly.

Cern.

>
>
> On Thursday, 26 September 2019 15:48:35 UTC+2, ce...@tuta.io  wrote:
>
>> Sep 26, 2019, 01:29 by >> mib.ho...@gmail.com <>>> : 
>>  
>> > Well current state is that PR (Partial Reconfiguration) is brand new to 
>> > the OS (Open Source) world,  
>> > as > IntelfPGA (former Altera) "just" have promised it for their 19.1 
>> > release (no lite version out yet), <>> https://github.com/>> 
>> > machinekit/mksocfpga/issues/>> 100 
>> > <https://github.com/machinekit/mksocfpga/issues/100>>> > 
>> > on the contrary Xilinx have sneaked it out very quietly with their Vivado 
>> > 2019.1 release this summer <>> https://github.com/>> 
>> > machinekit/mksocfpga/issues/>> 100 
>> > <https://github.com/machinekit/mksocfpga/issues/100>>> > 
>> > 
>> > So while the idea has had time to settle in this old thread, the 
>> > possibility of implementation here in Machinekit is brand new :-) 
>> > Michael B 
>> > 
>> Well, 
>> and how it is with the memory? And with the bus connection between hard ARM 
>> processor and FPGA fabric? Because now we have the HAL memory block locked 
>> into RAM with HAL library enabled allocating and memory (alignment) 
>> management from Linux side. But I presume that for FPGA-side components, 
>> that would not be good enough and this memory block will have to be directly 
>> in FPGA fabric so the components can use this space as a "register", right? 
>> Will then be possible to atimically access this memory (or variables there 
>> stored) both from Linux running on an ARM core and component in FPGA fabric? 
>> (I mean as a direct memory access, zero-copy, not some memory 
>> synchronization.) 
>>  
>> Cern. 
>>  
>> > 
>> > On Wednesday, 25 September 2019 20:49:04 UTC+2, >> ce...@tuta.io <>>>   
>> > wrote: 
>> > 
>> >> I am late to the party, I know, sorry, but this idea is very interesting 
>> >> to me. As I know that perspectives and opinions change, I would like to 
>> >> inquire about the current state. If all in this thread is still valid or 
>> >> if it was redacted in some way? 
>> >>   
>> >> I need to wrap my head around this concept, but fundamentally speaking, I 
>> >> see no reason why it should not be possible and even how it is that much 
>> >> different from the current state. Because, currently the operation on HAL 
>> >> is discrete and sequential. But only up to the point. As I see it, the 
>> >> basic structure of HAL is the input and output of each block (component). 
>> >> What is happening inside the component is a black box and of no 
>> >> particular interest to the user or a system. That "happening" is enabled 
>> >> by so called threads or tasks (on the Linux OS side), but actually from 
>> >> theoretical point of view are also of no importance. 
>> >>   
>> >> Given the dawn of multicore, we can have multiple threads running 
>> >> independent on each other on different isolated CPU/cores all reaching 
>> >> the same memory. There is still the limit that threads on one instance 
>> >> has to be run in increments of the first one, but I am not sure if that 
>> >> is real limit or just something nobody changed from LinuxCNC days. 
>> >> (Because really, it is nonsense.) 
>> >>   
>> >> If you can somehow pass-through the memory (I/O) from FPGA-side HAL to 
>> >> Linux-side HAL, I think you are pretty much done and you have HAL in 
>> >> FPGA. (HostMot2 FPGA firmware is also a HAL type, but you have the ugly 
>> >> read/write funct

Re: [Machinekit] Re: What potential hal implementation change could a low cost soc-fpga bring to the table ?

[cern]

Sep 26, 2019, 01:29 by mib.holotro...@gmail.com:

> Well current state is that PR (Partial Reconfiguration) is brand new to the 
> OS (Open Source) world, 
> as > IntelfPGA (former Altera) "just" have promised it for their 19.1 release 
> (no lite version out yet), 
> <https://github.com/machinekit/mksocfpga/issues/100>
> on the contrary Xilinx have sneaked it out very quietly with their Vivado 
> 2019.1 release this summer 
> <https://github.com/machinekit/mksocfpga/issues/100>
>
> So while the idea has had time to settle in this old thread, the possibility 
> of implementation here in Machinekit is brand new :-)
> Michael B
>
Well,
and how it is with the memory? And with the bus connection between hard ARM 
processor and FPGA fabric? Because now we have the HAL memory block locked into 
RAM with HAL library enabled allocating and memory (alignment) management from 
Linux side. But I presume that for FPGA-side components, that would not be good 
enough and this memory block will have to be directly in FPGA fabric so the 
components can use this space as a "register", right? Will then be possible to 
atimically access this memory (or variables there stored) both from Linux 
running on an ARM core and component in FPGA fabric? (I mean as a direct memory 
access, zero-copy, not some memory synchronization.)

Cern.

>
> On Wednesday, 25 September 2019 20:49:04 UTC+2, ce...@tuta.io  wrote:
>
>> I am late to the party, I know, sorry, but this idea is very interesting to 
>> me. As I know that perspectives and opinions change, I would like to inquire 
>> about the current state. If all in this thread is still valid or if it was 
>> redacted in some way? 
>>  
>> I need to wrap my head around this concept, but fundamentally speaking, I 
>> see no reason why it should not be possible and even how it is that much 
>> different from the current state. Because, currently the operation on HAL is 
>> discrete and sequential. But only up to the point. As I see it, the basic 
>> structure of HAL is the input and output of each block (component). What is 
>> happening inside the component is a black box and of no particular interest 
>> to the user or a system. That "happening" is enabled by so called threads or 
>> tasks (on the Linux OS side), but actually from theoretical point of view 
>> are also of no importance. 
>>  
>> Given the dawn of multicore, we can have multiple threads running 
>> independent on each other on different isolated CPU/cores all reaching the 
>> same memory. There is still the limit that threads on one instance has to be 
>> run in increments of the first one, but I am not sure if that is real limit 
>> or just something nobody changed from LinuxCNC days. (Because really, it is 
>> nonsense.) 
>>  
>> If you can somehow pass-through the memory (I/O) from FPGA-side HAL to 
>> Linux-side HAL, I think you are pretty much done and you have HAL in FPGA. 
>> (HostMot2 FPGA firmware is also a HAL type, but you have the ugly read/write 
>> functions. I call it the LinuxCNC way of thinking about it.) 
>>  
>> Because then it will be the same old, same old. 
>>  
>> And that opens up some very interesting possibilities. 
>>  
>> BTW, I have only very rough understanding about FPGA development. But that 
>> SystemC looks extremely promising. 
>>  
>> Cern. 
>>
>
>
>
> --
>  website: > http://www.machinekit.io <http://www.machinekit.io>>  blog: > 
> http://blog.machinekit.io <http://blog.machinekit.io>>  github: > 
> https://github.com/machinekit <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/a9420e6d-4f39-46e2-97c1-d4f7af69c89e%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/a9420e6d-4f39-46e2-97c1-d4f7af69c89e%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/Lphp8TW--3-1%40tuta.io.

Re: [Machinekit] Re: What potential hal implementation change could a low cost soc-fpga bring to the table ?

[cern]

I am late to the party, I know, sorry, but this idea is very interesting to me. 
As I know that perspectives and opinions change, I would like to inquire about 
the current state. If all in this thread is still valid or if it was redacted 
in some way?

I need to wrap my head around this concept, but fundamentally speaking, I see 
no reason why it should not be possible and even how it is that much different 
from the current state. Because, currently the operation on HAL is discrete and 
sequential. But only up to the point. As I see it, the basic structure of HAL 
is the input and output of each block (component). What is happening inside the 
component is a black box and of no particular interest to the user or a system. 
That "happening" is enabled by so called threads or tasks (on the Linux OS 
side), but actually from theoretical point of view are also of no importance.

Given the dawn of multicore, we can have multiple threads running independent 
on each other on different isolated CPU/cores all reaching the same memory. 
There is still the limit that threads on one instance has to be run in 
increments of the first one, but I am not sure if that is real limit or just 
something nobody changed from LinuxCNC days. (Because really, it is nonsense.)

If you can somehow pass-through the memory (I/O) from FPGA-side HAL to 
Linux-side HAL, I think you are pretty much done and you have HAL in FPGA. 
(HostMot2 FPGA firmware is also a HAL type, but you have the ugly read/write 
functions. I call it the LinuxCNC way of thinking about it.)

Because then it will be the same old, same old. 

And that opens up some very interesting possibilities.

BTW, I have only very rough understanding about FPGA development. But that 
SystemC looks extremely promising.

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/LpdkKZV--3-1%40tuta.io.

Re: [Machinekit] OSHW release DE10-Nano Daughtercard

[cern]

Sep 23, 2019, 05:34 by blazin...@gmail.com:

> I've decided to release the board I've been working on pretty much as is, 
> just with some open source considerations. It was intended for a specific 
> machine, but I rung out all of the I/O possibillities I could, no DE10 GPIO 
> pin went unused. There is an onboard 5v regulator that will power the nano 
> from GPIO and has a PTC fused connector to power about 3A worth of external 
> whatever. Specs:
>
> 9-25v VIN, 
> 5v regulator powers Nano from GPIO
> 6 differential stepgen interfaces with 5v enable (for external drivers)
> 6 differential encoder inputs (single ended encoders pull down encoders work 
> fine as well with no extra wiring)
> 16 sourcing outputs at supplied field voltage Outputs are done at whatever 
> field voltage supplies the board (recommend 24v)
> 2 high current opto-mosfet outputs
> 16 inputs arranged with single 3-pin connectors each to simplify NPN or PNP 
> type switch wiring. Inputs upto 30v
> 1 RS422 connector interface for SmartSerial. (not well tested, may be issues 
> with MK SS)
> On PCB terminal blocks for ground and field V+ that simplify wiring in 
> smaller machines
> a 3A PTC fused connector for powering external devices from the overkill 
> 5V/5A regulator (Nano+onboard components probably don't use more than 2.5A @ 
> 5v)
> 2 scaled analog input interfaces (4 channels each). 5v interface for using 
> potentiometers and such at 5v_ref, and one 4 channel interface that is 
> hardware scaled to accept 0-10v external input. (ADC hal component in repo) 
>
> The stepgens or outputs could probably be configured in hm2 firmware to 
> support PWM. Stepgens would provide differential PWM @ 5v, outputs would be 
> single ended PWM @ supplied field voltage haven't tested PWM yet but there's 
> not much to it.
>
> There are hal files, a gladevcp GUI, and display python file that will set 
> the DE10-FB image up as a test platform for the board. The hal files are 
> examples of pin masking and pin inversion that is done in hal to make the i/o 
> intuitive. It could use some sort of hm2 overlay type thing but that is 
> beyond me. There is also 2 versions of an ADC hal component that will convert 
> the 12bit data from the onboard ADC into a usable scaled voltage input in hal.
>
> The board isn't super cheap, that wasn't the intention but compared  to the 
> BBB hardware it's probably not too bad. It's a fairly large board (200x155), 
> but that's because I prefer Phoenix connectors and overall wiring cleanliness 
> over small form factor stuff. Still working on the git, but it's up.
>
> https://github.com/ShadeTechnik/socfpga-developement-OSHW 
> <https://github.com/ShadeTechnik/socfpga-developement-OSHW>
>
> Testing a stepgen and encoder:
> https://www.dropbox.com/s/qa4ro9r0io0dlvf/Video%20Sep%2022%2C%209%2054%2040%20PM.mov?dl=0
>  
> <https://www.dropbox.com/s/qa4ro9r0io0dlvf/Video%20Sep%2022%2C%209%2054%2040%20PM.mov?dl=0>
>
Looks nice. This and the version with an analogue industrial output (instead of 
stepgens) would probably satisfy majority of traditional home-grown CNC mill 
machine projects.

Bet the connectors are the most expensive part of the BOM.

BTW, I did install the Kicad. True, only in VM, but still...

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/Lp_KVT6--3-1%40tuta.io.

Re: [Machinekit] service discovery from different subnet ?

[cern]

24. 9. 2019 1:16 od c...@tuta.io:

> 24. 9. 2019 0:45 od mar...@bibi.ca:
>
>> I have linux running in a VM and want to connect to MK, which is connected 
>> to the same subnet as the host. Virtualbox seems to assign an IP of 
>> 10.0.2.15 to the guest (and 10.0.2.2 to the host) and my local network is on 
>> 192.168.1.0.
>>
>> I understand that mDNS (zeroconf) only works within the same subnet - so I'm 
>> wondering what's the best way of discovering the services from a different 
>> subnet
>>
>> Thanks a lot,
>> Markus
>>
> Hi,
> I believe that you need Avahi reflector on machine with access to both 
> networks. (Or similar software).
>
> Cern.
>
Or you can set-up your hypervisor to pass-through the networking so you are on 
same subnet. (But that is cheating and don't answer the question.)

Cern.

>>
>>
>>
>> --
>>  website: > http://www.machinekit.io <http://www.machinekit.io>>  blog: > 
>> http://blog.machinekit.io <http://blog.machinekit.io>>  github: > 
>> https://github.com/machinekit <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/4b7981f1-4490-426c-891b-4107e41ed3ea%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/machinekit/4b7981f1-4490-426c-891b-4107e41ed3ea%40googlegroups.com?utm_medium=email&utm_source=footer>>
>>  .
>>
>
> -- 
> website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
> https://github.com/machinekit
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to machinekit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/machinekit/LpVPKm8--3-1%40tuta.io.
>

-- 
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/LpVQ_Kb--3-1%40tuta.io.

Re: [Machinekit] service discovery from different subnet ?

[cern]

24. 9. 2019 0:45 od mar...@bibi.ca:

> I have linux running in a VM and want to connect to MK, which is connected to 
> the same subnet as the host. Virtualbox seems to assign an IP of 10.0.2.15 to 
> the guest (and 10.0.2.2 to the host) and my local network is on 192.168.1.0.
>
> I understand that mDNS (zeroconf) only works within the same subnet - so I'm 
> wondering what's the best way of discovering the services from a different 
> subnet
>
> Thanks a lot,
> Markus
>
Hi,
I believe that you need Avahi reflector on machine with access to both 
networks. (Or similar software).

Cern.

>
>
>
> --
>  website: > http://www.machinekit.io <http://www.machinekit.io>>  blog: > 
> http://blog.machinekit.io <http://blog.machinekit.io>>  github: > 
> https://github.com/machinekit <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/4b7981f1-4490-426c-891b-4107e41ed3ea%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/4b7981f1-4490-426c-891b-4107e41ed3ea%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/LpVPKm8--3-1%40tuta.io.

Re: [Machinekit] Re: Acorn CNC Controller

[cern]

Sep 23, 2019, 06:32 by cliffpo...@gmail.com:

> Cern, i recently became interested in MachineKit, after seeing the Centroid 
> Acorn system, BBG with remote windows based GUI. My research into MachineKit 
> indicated that it can be setup the same as the Acorn. I guess it is possible 
> that all the code in the BBG is their own, but likely heavily influenced by 
> MachineKit. How is it that you know for sure that it is not?
>
> Steve Carlisle 
>
Steve,
I think for sure based on making of my own conclusions, net know for sure based 
on the fact, that somebody high in Centroid who has direct knowledge told me so.

I looked at an output of decompilation of Acorn software and what I have seen 
is bunch of .NET CIL code and WIN32 API. Also, what is flashed on the BBG 
looked pretty small. Machinekit-HAL uses Linux userspace real-time 
threads/tasks. I did not think it would fit. The Windows side didn't look like 
anything Machinekit-like I have seen.

Then, by their website, the Centroid started in 1979, before the Enhanced 
Machine Controller project. So I again assumed, that the Centroid Acorn is 
direct evolvement of their own work.

Of course, I can be wrong.

Cern.

>
> On Monday, February 18, 2019 at 6:44:46 AM UTC-8, ce...@tuta.io wrote:
>
>> No, they are not. If the software looks great, use it. You will spare 
>> yourself the headache of developing port.
>>
>> Cern.
>>
>> Dne pondělí 18. února 2019 10:58:44 UTC+1 Mathias Giacomuzzi napsal(a):
>>
>>> Hi,
>>>
>>> Dose someone knew if they are using Machinekit ant QtQuickVcp?
>>> ? Because the hardware seems to be a very nice alternative to the CRAMPS. 
>>> Also the Software looks great.
>>>
>>> http://www.centroidcnc.com/>>> centroid_diy/acorn_cnc_>>> controller.html 
>>> <http://www.centroidcnc.com/centroid_diy/acorn_cnc_controller.html>
>>>
>>> many thanks
>>>
>
>
>
> --
>  website: > http://www.machinekit.io <http://www.machinekit.io>>  blog: > 
> http://blog.machinekit.io <http://blog.machinekit.io>>  github: > 
> https://github.com/machinekit <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/dc329782-1319-4141-8273-533a5c986152%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/dc329782-1319-4141-8273-533a5c986152%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/LpT-MDF--3-1%40tuta.io.

Re: [Machinekit] Weird idea?

[cern]

Sep 20, 2019, 16:16 by b...@basdebruijn.com:

>
>
>> On 19 Sep 2019, at 17:50,   wrote:
>>
>> Sep 18, 2019, 20:19 by blazin...@gmail.com:
>>
>>> @cern
>>>
>>> Curious, what is the state of machinetalk? 
>>>
>>> I am at some point planning on running a remote GUI, pretty much as you 
>>> described with a de10 nano as the RT pc/FPGA and some ARM or small X86 
>>> running the interface. I didn’t get too far in depth of what I need to do 
>>> with remotely controlling it, too busy with hardware but I thought the 
>>> remote concept of machinekit was solid.
>>>
>> This is only my view at the situation and as such there is going to be a 
>> difference of opinions. Mainly what Machinetalk is and what it should do.
>>
>> The Machinetalk and HALtalk is a joint baby of Michael Haberler and 
>> Alexander Rössler (for whom I think it was a diploma work). By post-mortem 
>> investigation, there were a quite big plans for what Machinetalk should be 
>> able to do. It was intended as a replacement of the NML and also shift from 
>> current position, when NML sits on top of (for example) motion component, 
>> nearer the HALayer core. That way it would enable node structure of machine 
>> system setup. (As a example, imagine two RTAPI instances (msgd and rtapi_app 
>> daemons) running infinite real-time loop tasks like now, but getting the 
>> instruction from one separate planner, which it itself is controlled from 
>> numerous terminals [GUIs].) Instances of Machinekit should be also able to 
>> communicate with each other, not only with current clien-server. As there 
>> was intention for direct control of rtapi_app created HAL.
>>
>> But then Michael Haberler performed his exit stage left without finishing 
>> his work (he even wanted to write documentation) and Alexander Rössler was 
>> always (and by his online activity still is) interested more in GUI and HMI 
>> work and replacing AXIS with something remote/running on Android/written in 
>> modern language.
>>
>> So, the current situation is that the Machinetalk (and affiliated 
>> technologies) is deeply ingrained into Machinekit, but not deeply enough as 
>> too much LinuxCNC ways is still visible. And then it's development stalled. 
>> And that is the root of my frustration.
>>
>> So, to @Bas, if you want to use only the UI components, you are fine as it 
>> works. (But is still only a clutch, as the messages are translated to NML to 
>> communicate with Machinekit-CNC side.)
>>
>
> I’m afraid you misunderstand. I do not use the CNC stuff. Just the HAL layer. 
> Pins, No NML.
>
Ah yes, I did. HALtalk works. But then I always thought that HALtalk is only a 
subset of Machinetalk. 

BTW, given that you use it in - probably - professional manner, do you think 
that the HAL_REMOTE_COMPONENT idea would be usable for creating orphaned pins 
inside HAL for real-time components if my realtime character device 
communication idea was possible?

>
> The entire “let’s replace nml” has halted because 1: this is hard work and 2: 
> it is a lot of work and 3: there’s nobody who wants to do that.
>
I can relate to that. It's just that it seems  that replacing the NML was the 
main motivation behind Machinetalk. Given the fact, that NML is layered upon 
the CNC side, it is not that interesting to me at the moment.

Cern.

>> However, look for example at the NOTYET portion of code in rtapi_app and 
>> then how HALCMD communicates with  rtapi_app. It uses the Machinetalk. But 
>> then not. It uses the ZeroMQ layer and Protobuf serialization. And then it 
>> registers itself as a HAL module, which I consider a braindead move (OK, I 
>> get it why it does that, but it's bad architectural design and means that 
>> the process needs to run on the same system as a rtapi_app). Saner approach 
>> would be to enforce the rtapi_app only place where access to the HAL shared 
>> memory space happen. CMDLINE would message rtapi_app socket with command, 
>> rtapi_app would execute it and send back a status. That way you can milk the 
>> great feature of ZeroMQ and use HALCMD from everywhere, even Windows 
>> Machines. (Typical machine programmer monkey cannot use Linux.)
>>
>> I think the best approach would be to implement what I described here: 
>> https://github.com/machinekit/machinekit-hal/issues/230 
>> <https://github.com/machinekit/machinekit-hal/issues/230> with Linux based 
>> permissions on file access, onto this connect new process which would do the 
>> Machitalk access (machinetalk_app), which would do all what is done now plus 
>

Re: [Machinekit] Weird idea?

[cern]

Sep 19, 2019, 19:41 by berk...@gmail.com:

> Hi Cern,
>
> You are the guy. You helped me a lot.
>
> And,
>
> Isn't the following veeery long and also great explanation about what I (kind 
> of) have asked for in the first place?
>
I don't know about great, but in a way it is. And you can use it today if you 
are able to meet the limitations (AXIS like GUI, remote HAL components, 
MKWrapper, Launcher and so on). The problem with the latency and what is one 
capable with reaching is the video Frame Buffer. You are never going to get the 
best when you run the graphics on the same system. (Plus you should always use 
processor isolation, you can even let different tasks (threads) run on 
different wholly isolated cores.)

BTW, in many cases you don't even need FPGA. It became a kind of magic bullet 
in LinuxCNC community, because the solution around HostMot2 works, it has 
support from Peter Wallace, is universal and people like repetition. There are 
many (commercial) solutions based on microcontrollers which work as good.

But if you want something like CS-LAB CSMIO (real-time tasks with additional 
hardware for encoder counting, PWM and step/dir generation and some real-time 
processed GPIO commanded by some higher system), then you are out of luck with 
current system. Even if @SnowWhite's SoC solutions could be excellent for this, 
you would still need to slash the Motion component.

(That's another legacy from LinuxCNC, they historically had a problem with 
letting go of the all-in-one system.)

Cern.

>
> Berkdan
>
>> @cern
>>
>> Curious, what is the state of machinetalk?
>>
>> I am at some point planning on running a remote GUI, pretty much as you 
>> described with a de10 nano as the RT pc/FPGA and some ARM or small X86 
>> running the interface. I didn’t get too far in depth of what I need to do 
>> with remotely controlling it, too busy with hardware but I thought the 
>> remote concept of machinekit was solid.
>>
> This is only my view at the situation and as such there is going to be a 
> difference of opinions. Mainly what Machinetalk is and what it should do.
>
> The Machinetalk and HALtalk is a joint baby of Michael Haberler and Alexander 
> Rössler (for whom I think it was a diploma work). By post-mortem 
> investigation, there were a quite big plans for what Machinetalk should be 
> able to do. It was intended as a replacement of the NML and also shift from 
> current position, when NML sits on top of (for example) motion component, 
> nearer the HALayer core. That way it would enable node structure of machine 
> system setup. (As a example, imagine two RTAPI instances (msgd and rtapi_app 
> daemons) running infinite real-time loop tasks like now, but getting the 
> instruction from one separate planner, which it itself is controlled from 
> numerous terminals [GUIs].) Instances of Machinekit should be also able to 
> communicate with each other, not only with current clien-server. As there was 
> intention for direct control of rtapi_app created HAL.
>
> But then Michael Haberler performed his exit stage left without finishing his 
> work (he even wanted to write documentation) and Alexander Rössler was always 
> (and by his online activity still is) interested more in GUI and HMI work and 
> replacing AXIS with something remote/running on Android/written in modern 
> language.
>
> So, the current situation is that the Machinetalk (and affiliated 
> technologies) is deeply ingrained into Machinekit, but not deeply enough as 
> too much LinuxCNC ways is still visible. And then it's development stalled. 
> And that is the root of my frustration.
>
> So, to @Bas, if you want to use only the UI components, you are fine as it 
> works. (But is still only a clutch, as the messages are translated to NML to 
> communicate with Machinekit-CNC side.) However, look for example at the 
> NOTYET portion of code in rtapi_app and then how HALCMD communicates with  
> rtapi_app. It uses the Machinetalk. But then not. It uses the ZeroMQ layer 
> and Protobuf serialization. And then it registers itself as a HAL module, 
> which I consider a braindead move (OK, I get it why it does that, but it's 
> bad architectural design and means that the process needs to run on the same 
> system as a rtapi_app). Saner approach would be to enforce the rtapi_app only 
> place where access to the HAL shared memory space happen. CMDLINE would 
> message rtapi_app socket with command, rtapi_app would execute it and send 
> back a status. That way you can milk the great feature of ZeroMQ and use 
> HALCMD from everywhere, even Windows Machines. (Typical machine programmer 
> monkey cannot use Linux.)
>
> I think the best approach would be to implement what I described

Re: [Machinekit] Weird idea?

[cern]

Sep 18, 2019, 21:05 by berk...@gmail.com:

> Cern, thank you very much for the infos. I have had lots of informations from 
> your message.
>
> After writing on the forum I took a look at picnc project on GitHub. It was 
> promising for me to see it's possible to make a board that can generate step 
> pulses and communicate over spi with pi. There is even a pull up which uses 
> more powerful CPU but unfortunately I cannot get these CPU's in Turkey.
>
You may find interesting to follow local auctions/bazaars with lookout for 
Ethercat Beckhoff hardware. I was able to score some off (German) Ebay in an 
interesting price range.

>
> So I have checked what else I can reach easily in my country and found out 
> that stm32f4 discovery and STM nucleo are cheap and available here. I may go 
> in that way if your suggestions does not work for me. But I am surely going 
> to check beaglebone out.
>
It would be great to get some new OSH in the Machinekit community. But I 
imagine it is a lot of work. I had some hopes for the DieBie Slave ( 
https://github.com/DieBieEngineering/DieBieSlave ), 
<https://github.com/DieBieEngineering/DieBieSlave> but he had to use a 6 layer 
board, which is death sentence for any DYI/OSH project.

Hope the BBB will work out for you.

>
> And Justin, unfortunately own output does not work for me. 
>
> I am going to use step to analog converter to control the servos. Thus I will 
> control motors with a stepgen card.
>
> Thanks again. I am going to check the other possibilities that Cern suggested.
>
> -- 
> 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/52dfc271-98c4-4ba0-8df7-54956e570451%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/Lp9FEQC--3-1%40tuta.io.

Re: [Machinekit] Weird idea?

[cern]

Sep 18, 2019, 20:19 by blazin...@gmail.com:

> @cern
>
> Curious, what is the state of machinetalk? 
>
> I am at some point planning on running a remote GUI, pretty much as you 
> described with a de10 nano as the RT pc/FPGA and some ARM or small X86 
> running the interface. I didn’t get too far in depth of what I need to do 
> with remotely controlling it, too busy with hardware but I thought the remote 
> concept of machinekit was solid.
>
This is only my view at the situation and as such there is going to be a 
difference of opinions. Mainly what Machinetalk is and what it should do.

The Machinetalk and HALtalk is a joint baby of Michael Haberler and Alexander 
Rössler (for whom I think it was a diploma work). By post-mortem investigation, 
there were a quite big plans for what Machinetalk should be able to do. It was 
intended as a replacement of the NML and also shift from current position, when 
NML sits on top of (for example) motion component, nearer the HALayer core. 
That way it would enable node structure of machine system setup. (As a example, 
imagine two RTAPI instances (msgd and rtapi_app daemons) running infinite 
real-time loop tasks like now, but getting the instruction from one separate 
planner, which it itself is controlled from numerous terminals [GUIs].) 
Instances of Machinekit should be also able to communicate with each other, not 
only with current clien-server. As there was intention for direct control of 
rtapi_app created HAL.

But then Michael Haberler performed his exit stage left without finishing his 
work (he even wanted to write documentation) and Alexander Rössler was always 
(and by his online activity still is) interested more in GUI and HMI work and 
replacing AXIS with something remote/running on Android/written in modern 
language.

So, the current situation is that the Machinetalk (and affiliated technologies) 
is deeply ingrained into Machinekit, but not deeply enough as too much LinuxCNC 
ways is still visible. And then it's development stalled. And that is the root 
of my frustration.

So, to @Bas, if you want to use only the UI components, you are fine as it 
works. (But is still only a clutch, as the messages are translated to NML to 
communicate with Machinekit-CNC side.) However, look for example at the NOTYET 
portion of code in rtapi_app and then how HALCMD communicates with  rtapi_app. 
It uses the Machinetalk. But then not. It uses the ZeroMQ layer and Protobuf 
serialization. And then it registers itself as a HAL module, which I consider a 
braindead move (OK, I get it why it does that, but it's bad architectural 
design and means that the process needs to run on the same system as a 
rtapi_app). Saner approach would be to enforce the rtapi_app only place where 
access to the HAL shared memory space happen. CMDLINE would message rtapi_app 
socket with command, rtapi_app would execute it and send back a status. That 
way you can milk the great feature of ZeroMQ and use HALCMD from everywhere, 
even Windows Machines. (Typical machine programmer monkey cannot use Linux.)

I think the best approach would be to implement what I described here: 
https://github.com/machinekit/machinekit-hal/issues/230 
<https://github.com/machinekit/machinekit-hal/issues/230> with Linux based 
permissions on file access, onto this connect new process which would do the 
Machitalk access (machinetalk_app), which would do all what is done now plus 
manage permissions (which current implementation of Machinetalk does not even 
take into account) based on certificates, protocols and interfaces (you can 
have an interface you consider implicitly safe which is direct connection to 
other parts of the machine and then another which is LAN) onto which would be 
connected the HALCMD and other similar applications or remote/nonRT connected 
rtapi_app (Machinekit-HAL) instances. But, as I said, it is only my opinion.

Also, part of Machinekit is the router message pipe (currently not used, I 
think) which is intended for direct messaging between two HAL modules. Imagine 
module which has a ring buffer. This ring buffer is filled from one side by 
(for example) RT HAL module, then on other end emptied  by this router, send 
over ZeroMQ to other machine and there the dealer puts this message back into 
receiving ring buffer of some local HAL module. Problem with this is that the 
HAL module works with structures, but the router has to serialize this to 
Protobuf format and remote router has to deserialize it. For this, something 
with same-on-wire-same-in-memory format would be better. Like Flat buffers 
(pending consideration on memory alignment).

Machinetalk is also big on multipart messaging concept. Which is considered by 
parental ZeroMQ community as an obsolete (or starting to be obsolete) and is no 
longer supported with new messaging patterns and sockets - like the UDP, which 
for direct communication between two Machinekit/M

Re: [Machinekit] Weird idea?

[cern]

Sep 18, 2019, 16:26 by berk...@gmail.com:

> Thank you Justin and Bas for quick response.
>
> I know about Mesa cards, but it takes too long to have it in my country. 
> Legal procedures etc. or I need to spend a lot for quick cargo and custom 
> taxes.. Besides I have two analog and one digital servo motor and drive thus 
> I need at least two Mesa daughter card and one anything card like the one for 
> pi or pcie etc. Which is very confusing for me.  So I am trying to find a 
> solution for that. I am good at python programming and I know that using NML 
> with machinekit is possible to control motors. I already have a pi3b+ and a 
> pc :) so I just wanted to know if it's a good idea to spend some time on it 
> or not.
>
> I have no idea about pic programming nor electronics so I wanted to do 
> something with what I already have.
>
> About step frequency I have tested linuxcnc with parallel port and I have got 
> 1500 mm/min speed rate if just two axis runs at the same time. I do relief 
> machining a lot and when z axis runs with X and y, speed drastically reduce 
> to 600 mm/min. This is because of the latency issues. Not to have latency 
> issues I thought it would be good idea if I seperate the GUI and the step 
> generator.
>
> Since forums is here for brainstorming I just got the idea and shared with 
> you to learn if it's a good idea or not.
>
> Thank you again for your interest.
>
> Berkdan
>
Hello,
I can feel your pain. The distribution part of Mesa business is very bad. It is 
a little bit better that it was but still they could learn a lot from Chinese 
sellers.

However, Raspberry Pi with default GPIO configuration for step-gen is not good 
solution. I have heard some interesting news about the GPIO toggling on 
Raspberry Pi: https://evlproject.org/pipermail/evl/2019-May/19.html 
<https://evlproject.org/pipermail/evl/2019-May/19.html> but fo far I didn't 
play with it.

About distributed system, to have proper distinction between RT tasks specific 
hardware and non-RT tasks specific hardware is the way forward, I think. It is 
clutch from LinuxCNC days to have everything on one PC, from times when 
electronics, PCs and whatnots were very expensive. Today, there is no need to 
not have one physical system running the RT kernel and tasks and other taking 
care of the planning and another taking care of UI. Video frame buffer will 
always cause unnecessary latencies on RT systems.

However, Machinetalk in the current form is not going to take us there. 
Unfortunately.

If you want Raspberry Pi with something like Mesa FPGA firmware, try the 
BeagleBone Black.

And, if you are up to challenge, you can try to implement simple core on some 
$10 FPGA developer board from Alibaba. The HostMot2 is nice, but it is 
universal and so overcomplicated. Look for example at the Pluto code or 
internet tutorials. Or the LAN9252 + ARM or XMC4800 for Mesa card DYI 
alternatives.

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/Lp4RDSK--3-1%40tuta.io.

Re: [Machinekit] mksocfpga DE10-Nano encoder index issue (latency?)

[cern]

Sep 14, 2019, 23:40 by blazin...@gmail.com:

> Actually this is a better example because I do the exact same thing on this 
> gizmo but in real use. The encoder is driven by a 2" diameter roller and the 
> web driving it is running at 900fpm. That means the roller is spinning at 
> ~1700 RPMs. That machine is using a much more complicated hal file, it counts 
> index pulses (using updown) then triggers the an output on the comparator 
> component. It's the same encoder, a 7i96 and a LinuxCNC PC @ ~2ghz with not 
> great latencies, but it never really misses an index count. That machine runs 
> a fairly huge Python file but all the logic is done in hal.
>
> Point is that all things being equal I probably shouldn't have an issue 
> seeing an index pulse in the same manner at 1/100th the speed at 900MHz. But 
> like I said, I do alot of monkeying around, maybe I damaged this encoder in 
> some way.
>
>
Actually, without seeing the code you are using to set-up your system, it is 
just abstract talking.

What I had in mind is to determine if the problem is in Machinekit-HAL proper, 
HostMot2 driver or the MESA FPGA firmware. The actual counting of encoder's 
signals (A/B/Z) happens inside the FPGA firmware core and outside the scope of 
Machinekit. Machinekit-HAL only with periodicity of read function loop inside a 
real-time task (for example the 1ms long so called base-period) asks about 
update and receive state of registers inside the FPGA at some time.

What is needed is to investigate if the SoC FPGA firmware is functioning 
properly and you are - for example - only counting something improperly in 
Machinekit-HAL (can be - as I said - the problem with non-RT access to HAL from 
GUI), or if the whole FPGA firmware is shot.

So, please, tell me exactly what you are doing inside the HAL.

Cern.


>
> On Saturday, September 14, 2019 at 5:21:32 PM UTC-4, justin White wrote:
>
>> The "GUI" isn't counting the pulses. As I said/ I'm using the hal component 
>> "updown" which is a RT component as any other. That component outputs an 
>> unsigned integer that I just push to a gladevcp hal label. So it's being 
>> "counted" at the servo thread rate of 1ms or the .5ms that I briefly tried. 
>> I don't do any python coding or anything like that other than a very simple 
>> Python file to load the GUI as you typically would. The whole GUI is Hal 
>> files with a gladevcp interface, all it's doing is printing the number on 
>> the updown count pin.
>>
>> The 900MHz CPU in and of itself can't possibly be the issue. The HM2 encoder 
>> core runs at the same speed as it does on any of my Mesa ETH cards, and 
>> being ETH cards it means I use a Preempt-RT kernel on those PCs as well. An 
>> encoder spinning at 3000rpms and not missing a single pulse has that index 
>> pulse state in several orders of magnitude less FPGA cycles than me sitting 
>> here spinning an encoder by hand. A 2GHz x86 CPU with almost equal latency 
>> has far less opportunity to recognize that hm2 pin state than the Nano does 
>> at 900mhz with me spinning it by hand.  
>>
>> On Saturday, September 14, 2019 at 5:01:39 PM UTC-4, >> ce...@tuta.io <>>>  
>> wrote:
>>
>>> Sep 14, 2019, 20:04 by >>> blaz...@gmail.com <>>>> : 
>>>  
>>> > Doing a little testing on my hardware I noticed there is an issue with 
>>> > encoder indexes being missed while trying to count them. It's difficult 
>>> > in hal to see the index pin change state on an encoder with reasonable 
>>> > resolution because the change in state is very short. So I added the 
>>> > function in my GUI to count up the encoder index pulses  because it's 
>>> > obviously more visible when a number increments up vs trying to catch a 
>>> > small blip in halshow or halcmd. I noticed the index pulses are missed 
>>> > spinning the encoder at anything other than a very slow speed. I'm not 
>>> > really sure what communication method mksocfpga uses between the fpga and 
>>> > the cpu but I figured I'd try running a few non-fp components in a 0.2ms 
>>> > base thread to see if it helped. Didn't really seem to help at all 
>>> > 
>>> > I first tried this by routing the hm2index-input hal pin into the 
>>> > updown component and sending the counts to a hal label in my gui. My 
>>> > first thought is that the state change is too short for the servo-thread 
>>> > to catch at 1ms, so I added the "edge" component to extend the length of 
>>> > the index-inpu

Re: [Machinekit] Odroid N2 RT kernel readiness?

[cern]

Sep 18, 2019, 01:48 by blazin...@gmail.com:

> As I mentioned in another post, I'm a big fan of this SBC, It's got the most 
> powerful consumer ARM chip I've used and there seems to be a major interest 
> in bringing the board into the mainline kernel, which may be well on it's way 
> by now. I haven't had the time to try building an RT-preempt kernel for it 
> and I honestly have never had much lick with patching ARM kernels anyway. I 
> inquired on the Odroid forums about a RT kernel prior to the 5.1 release and 
> I believe someone said that once RT kernel patches caught up to 5.2 it would 
> be possible. Patches are at 5.2.14 now. I was thinking that this board runnng 
> hm2 over SPI would be pretty major. I'd assume with Mesa's recent support for 
> the RaspberryPI over SPI this may be a little more realistic now. I'm not the 
> guy to be digging into software and kernel developement, I'm just curious if 
> any of the Machinekit wizards think this is worth looking into.
>
> Odroid N2 
>
> Mainline Kernel discussion. 
> 
>
Isn't that that Android TV stick chipset? If so, there are going to be many 
different boards. True, they will be targeted to other uses and so will 
probably not have the broken GPIOs, but still. Maybe it will create bigger 
traction for RT capable kernel development.

C.

-- 
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/Lp11JEp--3-1%40tuta.io.

Re: [Machinekit] ROCKPro64 + Mesa 6i24 or 6i25 What are your thoughts on this low cost mini combo

[cern]

Sep 17, 2019, 16:02 by mib.holotro...@gmail.com:

> Just an Idea
> While debugging on the new Machinekit aarch64 port, my thoughts went to 
> wondering if it would be possible for someone to combine a low cost Arm64 Soc 
> with a mesa card: (and yes...)
>
> ROCKPro64 2/4GB 60$ -80$ <https://www.pine64.org/rockpro64/>
>
> Mesa 6i25-6i24 110$-$140 <http://www.mesanet.com/>
>
> The ROCKPro64 has 64MB of pcie mappable address space, more than enough for 
> the 64KB hostmot2 memory map and this combo is much smaller than any pc .
>
I have seen discussions about Rockpro64 in LinuxCNC annals. So, there are 
people using it for this purpose. But I didn't follow it further as I don't 
consider it a viable option.

However, you may find it interesting.

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/LozjzA1--B-1%40tuta.io.

Re: [Machinekit] mksocfpga DE10-Nano encoder index issue (latency?)

[cern]

Sep 14, 2019, 20:04 by blazin...@gmail.com:

> Doing a little testing on my hardware I noticed there is an issue with 
> encoder indexes being missed while trying to count them. It's difficult in 
> hal to see the index pin change state on an encoder with reasonable 
> resolution because the change in state is very short. So I added the function 
> in my GUI to count up the encoder index pulses  because it's obviously more 
> visible when a number increments up vs trying to catch a small blip in 
> halshow or halcmd. I noticed the index pulses are missed spinning the encoder 
> at anything other than a very slow speed. I'm not really sure what 
> communication method mksocfpga uses between the fpga and the cpu but I 
> figured I'd try running a few non-fp components in a 0.2ms base thread to see 
> if it helped. Didn't really seem to help at all
>
> I first tried this by routing the hm2index-input hal pin into the 
> updown component and sending the counts to a hal label in my gui. My first 
> thought is that the state change is too short for the servo-thread to catch 
> at 1ms, so I added the "edge" component to extend the length of the 
> index-input on it's output but that didn't really help. The output of edge 
> obviously only get's extended if it catches the input state change which it 
> does no better than updown.
>
> The conclusion I'm drawing is that the RT behavior of the CPU or the 
> communication between the FPGA and CPU cores is too slow for whatever reason, 
> that or there's some issue with the encoder module in mksocfpga's hm2. I'm 
> using 3 channels of a quad differential receiver chip for each encoder input. 
> There is no difference between the index channel and A-B channels hardware 
> wise, and this is the same on 6 identical instances of encoder inputs. The 
> only difference is that hm2 counts the A-B channels in the FPGA while the 
> index is not. I haven't seen any indication of missed counts on the A-B 
> channels counting 4000 edges in quadrature. I've messed with the hm2 encoder 
> sample-frequency too which also did not help. The only thing that helped 
> somewhat is running a 0.5ms servo-thread but it still missed quite a few 
> index's, and this is with me spinning the encoder by hand.
>
> I use this same model of encoder on a LinuxCNC machine with a Mesa 7i96 and 
> again on a 7i76e and I've never really seen an index missed on those spindle 
> motors at ~3000rpms. If this isn't an issue with the hm2 encoder module 
> itself I'd expect to see the same issue with a normal GPIO input missing 
> short/fast pulses but I would think that someone else would have noticed that 
> issue by now?
>
> Thoughts?
>
Stupid question, but how exactly are you counting the Z pulses in your GUI? Are 
taking into account the non-RT nature of the GUI?

I don't remember how exactly is the communication done in HostMot2, but I 
remember that you have to "compute" the index signal from A/B registers if you 
were to catch the sampling message (request and response from FPGA layer) 
outside the index occurrence.

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/Lol_BfY--3-1%40tuta.io.

Re: [Machinekit] Re: Rpi3, Beagleboard X15, And Avnet Ultra96

[cern]

Aug 25, 2019, 20:52 by mib.holotro...@gmail.com:

> OK decided to attempt the RIP method and after a dependency nightmare (and 
> enabling a swap file) got a full compilation,
> with the scripts/build_with_cnc method.
> 
> Ready to run full machinekit RIP
> 
>
> real    18m56,876s
> user    60m38,652s
> sys     4m32,197s
>
> Later I was able to run machinekit command and the setup GUI pops up very 
> satisfying however
> I was not able to run the simulator (havn't tried the sim before :-) )
>
> following messages appear in the console;
> linaro@ultra96:~$ machinekit
> MACHINEKIT - 0.2
> Machine configuration directory is '/home/linaro/machinekit-hal/configs/sim'
> Machine configuration file is 'axis-iocontrolv2-demo-ubuntu8.04.ini'
> Starting Machinekit...
> rtapi_msgd command:  /home/linaro/machinekit-hal/libexec/rtapi_msgd 
> --instance=0 --rtmsglevel=1 --usrmsglevel=1 --halsize=524288
> rtapi_app command:  /home/linaro/machinekit-hal/libexec/rtapi_app_posix 
> --instance=0
> iov2 -support-start-change started
> halcmd loadusr iov2 -support-start-change started
> task pid=4400
> emcTaskInit: using builtin interpreter
> Traceback (most recent call last):
>   File "/home/linaro/machinekit-hal/bin/axis", line 122, in 
>     nf.start(root_window)
>   File "/home/linaro/machinekit-hal/lib/python/nf.py", line 119, in start
>     source_lib_tcl(r, "support.tcl")
>   File "/home/linaro/machinekit-hal/lib/python/nf.py", line 111, in 
> source_lib_tcl
>     r.tk.call("source", os.path.join(tcl_libdir, f))
> _tkinter.TclError: can't find package Img
> Shutting down and cleaning up Machinekit...
>
You seem to be still in hell, this time in run-time section. Try installing 
libtk-img or whatever else which seems appropriate. (It is a shotgun approach, 
but it worked for me in the past.)

Cern

>
>
>
>
> On Sunday, 25 August 2019 17:54:32 UTC+2, c.gl...@cox.net  wrote:
>
>> The Ultra96 is simply the most powerful embedded processor I've ever used! 
>>
>> When loaded with PYNQ, a Python environment that runs in Jupyter it turns 
>> into a powerful platform for FPGA development. Using a Ultra96 is akin to 
>> taking an A10 Warthog to a gunfight.
>>
>
>
>
> --
>  website: > http://www.machinekit.io <http://www.machinekit.io>>  blog: > 
> http://blog.machinekit.io <http://blog.machinekit.io>>  github: > 
> https://github.com/machinekit <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/bfaef999-7a55-4c03-b485-d083e75e7ff3%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/bfaef999-7a55-4c03-b485-d083e75e7ff3%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/Ln9ak1n--3-1%40tuta.io.

Re: [Machinekit] Building MK from source for beaglebone black

[cern]

Aug 19, 2019, 22:09 by klemenzivko...@gmail.com:

> I follow instruction from official documentation of machinekit building fom 
> source:
> http://www.machinekit.io/docs/developing/machinekit-developing/ 
> <http://www.machinekit.io/docs/developing/machinekit-developing/>
>
> and I get:
> ...
> ./configure --with-platform-beaglebone
> returns:
> ...
> configure: error: Package requirements (libczmq > 4.0) were not met:
>
> I am on:
> machinekit@beaglebone:~/git/machinekitOff/src$ cat /proc/version
> Linux version 3.8.13-xenomai-r79 (root@a3-imx6q-wandboard-2gb) (gcc version 
> 4.9.2 (Debian 4.9.2-10) ) #1 Wed Jun 15 22:12:09 UTC 2016
>
> what is fast track to upgrade to latest machinekit on beaglebone black?
>
The fastest track to upgrade to Latest Machinekit is to use packages install 
and not the Run-in-Place build. More: 
http://www.machinekit.io/docs/getting-started/installing-packages/ 
<http://www.machinekit.io/docs/getting-started/installing-packages/>

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/LmfWGPs--3-1%40tuta.io.

Re: [Machinekit] anyone know of any Machinekit kinematics for hangbots?

[cern]

Aug 10, 2019, 02:09 by doug.la...@gmail.com:

> I've got a MaslowCNC and there's discussions on moving off of the 8bit 
> Arduino and PC software to an integrated system.  
>
> Since the Maslow CNC is a CNC machine, but not your typical one, my thoughts 
> went directly to Machinekit. So I thought I'd ask if anyone
> knows of any previous work on Machinekit for a hangbot. The Maslow CNC uses 2 
> geared DC motors with encoders with chains hanging down
> and connected together at the router motor.
>
> M1         M2
> --\         /--
>    \       /
>      \   /
>        V
>      router
>
> knowing there's some code to work with already might help.
> Two main features of interest: hangbot kinematics and DC motor encoders.
>
I have no idea if somebody is using Machinekit for Hangbot. But there are (is) 
transformation module for CoreXY (which I tested), this - I think - could work 
on similar principle.  In goes XYZ cartesian, then it is transformed by magic 
of linear algebra to another space and then you feed it to hardware.

DC motors and encoders should not be problem. With MKSOCFPGA it should be 
possible to directly feed PWM to H-bridges.

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/Llt1ZEr--3-1%40tuta.io.

Re: [Machinekit] Disable RTAPI Logging

[cern]

Aug 8, 2019, 12:19 by a...@machinekoder.com:

> We have a problem with our BeagleBone setup. The RTAPI logging is causing 
> systemd-journal to use a big chunk of the CPU resources, in particular right 
> after program start.
>
> The log messages are visible by running journalctl, something along the lines 
> of CMD 1036, code 29 and SET_LINE (sorry, I'm on a different computer). So it 
> looks like RTAPI is printing out messages when reading the file.
>
> Anyway, is there a way to disable or reduce the RTAPI logging?
>
Hi,
what exactly do you mean by disabling? When the RTAPI message level will be set 
to NONE - 
https://github.com/machinekit/machinekit-hal/blob/master/src/rtapi/rtapi_support.c#L98-L99
 
<https://github.com/machinekit/machinekit-hal/blob/master/src/rtapi/rtapi_support.c#L98-L99>
 - it should not log the messages from RTAPI_PRINT_* function. You can then 
decouple the default system logger in, I think, syslog-async.c. However, maybe 
you mean something else.

Could you post what messages make the bulk of load?

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/LlnWf5e--3-1%40tuta.io.

Re: [Machinekit] Which kernel is the fastest running Machinekit on BBB?

[cern]

Aug 6, 2019, 8:05 PM by fishpep...@gmail.com:

> Hi!
>
> Sorry about beeing unclear. I know that I switched the underlaying RT os.
>
> The jessie box runs: 
> Linux beaglebone 3.8.13-xenomai-r83 #1 Thu Jan 5 01:32:32 UTC 2017 armv7l 
> GNU/Linux
>
> And on stretch:
> Linux beaglebone 4.19.37-bone-rt-r33 > #1stretch <>>  PREEMPT RT Wed Jun 5 
> 11:22:07 UTC 2019 armv7l GNU/Linux
>
> I switched all driver/config stuff to use the preempt rt stuff.
>
> The jessie box is perfectly fine. The stretch based one is unusable. 
> I am wondering how others use a stretch based image and if I am doing 
> something wrong
> and there is a "magic" kernel version that is fast enough to be used.
>
> I did a simple benchmark opening a text engraving gcode file from fusion360.
> On the Jessie box it takes ~20s from clicking load to display.
> On the stretch base box takes around 4 minutes...
>
> Or could it have something to do with the fact that the stretch image runs 
> from SD and the jessie from internal flash?
> Is there so much disk I/O involved?
>
Well, it pretty well could be. To reach some verdict, the inputs should be the 
same. Difference of 3.40 minutes seems little too excessive for just change in 
kernel and distribution versions. However, you can test it all (if you have the 
time and incentive). You can install the 3.8 Linux Kernel with 2.x Xenomai 
patch on Debian Stretch and vice versa. (But you will - probably - have to do 
the compiling yourself.)

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/LlgjPzb--3-1%40tuta.io.

Re: [Machinekit] Which kernel is the fastest running Machinekit on BBB?

[cern]

Hello,
Aug 6, 2019, 11:07 AM by fishpep...@gmail.com <mailto:fishpep...@gmail.com>:

> Hi!
>
> My old machinekit installation runs on a BBB under debian jessie with a 
> xenomai kernel.
> I start the axis gui via an SSH session using indirect OpenGL rendering.
> For normal CAM jobs this is reasonable fast and the gui is responsive.
> Only huge jobs with e.g. 3D cam operations take some time to load but then 
> they are fine as well.
> I want to switch to a more recent version because I can not get the XHC-HB04 
> pendant working under jessie
> (see https://github.com/machinekit/machinekit-hal/issues/209)
>
> So I  configured a second BBB using debian stretch.
> I tested various kernels but all seem to be way slower than the old kernel
> coming with my debian jessie image.
> Some kernels export the wrong cpu frequency settings and do not use the 
> maximum clock but even those who do are still slow.
> Opening a very basic CAM jobs in axis loads for a minute or more.
>
> Something seems wrong... When I open a second console via ssh
> while axis is running the console is laggy and unresponsive as well.
>
> Any hints?
>
I am not completely sure if you are talking about the latency of HAL instance 
or the general responsiveness of Linux OS. However, to use Debian 
Buster/Stretch with modern kernel version, you pretty much have to use 
Preempt_RT or Vanilla. The Xenomai currently in Machinekit is EOLed 
2.6.something version running in tandem with 3.something Linux kernel. To use 
4.19.something or 5.2.something kernel, you would need the Xenomai3 or EVL 
Core, for which support is currently not finished. 

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/Llbidjv--3-1%40tuta.io.

Re: [Machinekit] It's a whole new hardware concept then I am use to.

[cern]

Am I talking to myself. Was the discussion deleted?

Cern.

Jul 24, 2019, 3:59 AM by steve.parsons.jun...@gmail.com:

> (...)
>
>>  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/Lka2dgE--3-1%40tuta.io.

Re: [Machinekit] It's a whole new hardware concept then I am use to.

[cern]

You need to click on the "reply all" button to post to this list. Otherwise it 
will send the e-mail only to the person you are replying to and not to the 
machinekit@googlegroups.com <mailto:machinekit@googlegroups.com>, from where 
the mail-list server will fan it out to every list subscriber. (It's spam 
protection thing.)

Jul 24, 2019, 3:59 AM by steve.parsons.jun...@gmail.com:

> Yea I know I can't use mach3 with this table,
>
You can, just not with parts of the current electronics setup. By the looks 
from the JD2 website, they use the all-in-one BLDC servos with STEP/DIR inputs. 
That should be easy enough to interface to MACH3. I have no idea about what 
they use for THC.

> as far as in maybe they did or didn't tell me they didn't because good luck 
> on getting an answer without it being incorrect or they don't contact back. 
> I've only talked to them 4 times a laser replacement, an to ask about the 
> actual controller brand which is why I've never contacted them back for any 
> further questions or issues I've found a few bugs they have not addressed 
> they say stuff is coming soon and 6 months later still nothing. The big thing 
> about Mad Gui V3 is linuxcnc does tons upon tons of stuff that Mach 3 does 
> but he took tons of it out. I will live with the facts it's Linux based but 
> not using mad. If I can figure out what hardware I have I will fdisk the PC  
> hard drive and recreate the partition or let grub do it all an start getting 
> back into Linux I know for sure I am quite able to download Linux sources 
> codes &  > repositories>  adding or remove stuff I might not need then 
> compile a little bit of time it all will come back to me from long ago I'd 
> rather use Ubuntu but it is what it is.
>
You can use pretty much whatever you want with Machinekit and LinuxCNC both. It 
may just not be a turn-key solution. However, it still should not be that 
problematic to use Ubuntu. (I have never tried it.)

> I know machine kit is software I've seen all the dependencies in the mad 
> directly I also am sure the controller in the cabinet is a begalbone or begal 
>
Maybe, Beaglebone Black is popular hardware SBC for use with Machinekit. 
Problem is, without detailed photos only people deeply familiar with JD2 
offerings would be able to tell.

> something that's was my actual question was help identifying which one it's 
> only a matter of time I just get fed up and once my warranty is up the 
> hardware will go bye bye and what I replace it will will be known and not 
> lied too. Linux has came a long way since I've gotten out of it. In 30 years 
> I've never asked for help but I've  giving help nonstop I get fed lies so I 
> will buy their brand Devin isn't tech support at jd2 it's fred
>
I don't know any of them. Just what I read on the project pages.

> which knows his stuff the rest of them will remain in the grey area not being 
> mentioned. I figured having the table a year and I've fixed every problem 
> myself finding out what brand controller I have from there I will handle the 
> rest if no one is able to help I will year the control box apart and take the 
> shields off the boards and find out myself just to much business work atm 
> figure if someone knew heck yeah. Thanks for the reply with ideas about what 
> it might be. :)
>
Sure, Machinekit does not suit everybody. There are plenty to choose from. Just 
don't be offended if people on Machinekit forum are not inclined to bashing 
Machinekit.

Cern.

>
> On Tue, Jul 23, 2019, 9:09 PM  <> c...@tuta.io <mailto:c...@tuta.io>> > wrote:
>
>> Jul 24, 2019, 2:48 AM by >> steve.parsons.jun...@gmail.com 
>> <mailto:steve.parsons.jun...@gmail.com>>> :
>>  
>>  > Since I am new to this Google Groups stuff &  Linux based hardware here 
>> is a little bit of information about myself so people know that I i'm not a 
>> short bus I've been building computers & Networks plus tons of other 
>> electronic fields for 30 years 15 years ago I used to code windows software 
>> & also it's been 15 years since I left Linux  I've used 
>> dsl,Ubuntu,Slackware,deb,mint,backtrack,Kali,Red Hat, etc I know that I am 
>> out of date when it comes to using Linux  I have also been doing CNC Plasma 
>> cutting for the past 6 years 5 of them years the place I worked for their 
>> table used CandCNC hardware with Mach 3 which I love a lot.. I got to the 
>> point after 6 months I did all the maintenance & repairs for their table 
>> after 5 years I quit. Last year as I was looking to buy a table I am way to 
>> inpatient to browse & order & w

Re: [Machinekit] It's a whole new hardware concept then I am use to.

[cern]

Jul 24, 2019, 2:48 AM by steve.parsons.jun...@gmail.com:

> Since I am new to this Google Groups stuff &  Linux based hardware here is a 
> little bit of information about myself so people know that I i'm not a short 
> bus I've been building computers & Networks plus tons of other electronic 
> fields for 30 years 15 years ago I used to code windows software & also it's 
> been 15 years since I left Linux  I've used 
> dsl,Ubuntu,Slackware,deb,mint,backtrack,Kali,Red Hat, etc I know that I am 
> out of date when it comes to using Linux  I have also been doing CNC Plasma 
> cutting for the past 6 years 5 of them years the place I worked for their 
> table used CandCNC hardware with Mach 3 which I love a lot.. I got to the 
> point after 6 months I did all the maintenance & repairs for their table 
> after 5 years I quit. Last year as I was looking to buy a table I am way to 
> inpatient to browse & order & wait for all parts to arrive to build my own so 
> I found a new table I liked so i contacted JD Squared a year ago was told the 
> 4x4 table I bought will run mach 3 if i dislike their table software was told 
> their hardware they make in house well none of it was true My hardware is 
> machinekit 
>
Machinekit is a software which can run on variety of hardware. I seem to 
recallDevin Hughes posting somewhere that they use the FPGA+ARM code combo, you 
canget more info about the software side under machinekit/MKSOCFPGA on GitHub.

> with all the dlls etc. Well I hate their limited software I believe it's GUI 
> pulled over linuxcnc or EMC2 but my reasoning for being here is the 
> controllers etc have spiffy boxes built around them to cover the PCB board 
> with there logo on it like they in housed them.
>
Maybe they did, maybe they did not. It's hard to tell one way or another just 
from the table. However, for retrofit to Mach3, chances are nearing certainty 
that you will not be capable of reusing this hardware.

>
> I would like to know if anyone can tell me the easiest & best way to identify 
> which hardware I have in my control box. I've asked them to many times to get 
> the same bs answer so I took 7zip and extracted their 
> madgui3-3.1.3-full.nupkg to find out the Pc has windows 10 Pro with their 
> interrupter MAD GUI V3  that connects using V-host to the linux distro Deb.
>
They are probably using the QtQuickVCP framework. Try looking at the 
machinekit/qtquickvcp repository on GitHub

>
>  Then not having the users name nor pass to deb is there a way of changing it 
> or do I have to redo it in order to have the password Id rather use ubuntu 
> but with my luck i am stuck like chuck swimming in the water drowning unlike 
> a duck..
>
What did you try to log into the linux machine?

>  I have been reading bits here and there about Hal & the way this hardware 
> works. Once this is figured out mad gui will be trashed because personally 
> it's limited on what you can do. I will move to linuxcnc or find something 
> close to mach 3 any information directing me in the right direction would be 
> so appreciate. Thanks for your time..;)
>
Even if you hate the MAD UI, be aware that this is kind of time hole. Estimated 
6 weeks projects easily turn into 12 months.

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/LkWWZnd--3-1%40tuta.io.

Re: [Machinekit] VFD for 180v DC motor

[cern]

Jul 14, 2019, 7:53 PM by golfop...@gmail.com:

> Hi
>
>
> Thank a lot for reply 
>
> Great for UART5 I plan to play with this one soon.
>
> No I didn’t already bought this contrôler I have wait for some reply before. 
> At first I check for PWM controler (this one offers reversing direction this 
> is but the seller suggest me to use rs232.
>
> It is really ok to not be real-time regarding to constant surface cut speed 
> and threading ?
>
I haven't got the time to study the pertinent part of the code-base yet, so 
take my suggestions with grain of salt, but I assumed that the motion is 
synchronized on the speed of the spindle, so you need to have RT capable 
encoder read-out.

>
> I have write a instanciable component for ATC maybee i can use the same way 
> for drive this controler or adapt some vfd existing driver, because I have a 
> very short experience with python.
>
I have heard people say that python is "easy", but I personally don't like it 
myself. (Fact still is that there are tonnes of libraries for your pick.) If 
you are going to write some other component, you can use C/C++ for everything.

But be aware that the VFD components could not be all RT capable, so if you are 
after RT, always check. Also, mentioned driver wants in basic mode UART on 9600 
baudrate with 10 bits per one transferred byte. If you have 1kHz task, you 
could end missing your constraints only on writes alone. So you will need to 
look at advanced mode and setting own speed.

Cern.

>
> Br thanks for interest 
>
>
>
>> Le 14 juil. 2019 à 15:09,   a écrit :
>>
>> Jul 13, 2019, 1:46 PM by golfop...@gmail.com:
>>
>>> Hi
>>>
>>> I use machinekit for a CNC lathe with Beaglebone Black and Furaday cape, 
>>> debian 9 up to date, Axis GUI, icewm as DM.
>>>
>>> I need to replace my spindle controller board, this is a 180V DC shunt 
>>> motor 1Hp run ~200 to ~3500rpm.
>>>
>>> I have found this one over ebay : > 
>>> https://www.ebay.fr/itm/180V-200V-DC-230V-AC-16A-HP-motor-speed-controller-reversible-RS232-CNC-control/183788127346?hash=item2acaa04472:g:hq0AAOSwAE1cz7vg
>>>  
>>> <https://www.ebay.fr/itm/180V-200V-DC-230V-AC-16A-HP-motor-speed-controller-reversible-RS232-CNC-control/183788127346?hash=item2acaa04472:g:hq0AAOSwAE1cz7vg>
>>>
>>> For now i have only the attached document.
>>>
>>>
>>> I think this controller is ok for my motor, but for manage the RS232 
>>> protocol whith machinekit i'm unsure.
>>>
>>> https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps 
>>> <https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps>
>>> I suspect this need to use one of this VFD driver and adapt the protocol 
>>> for the ebay controller ?
>>>
>> Hi,
>> yes, you will need to write simple HAL module. Good thing is it needs not to 
>> be real-time, all you need is to send some command every 3 seconds, so 
>> simple python script with use of few ready-made libraries will be enough.
>>
>> Did you bought already or it is just theoretical question?
>>
>>>
>>> It is ok for use this with USB/RS232 or is better to use some onboard UART 
>>> from Beaglebone ?
>>>
>> Could be, looks like the pins for UART5 are not used by the cape, but 
>> somebody more knowledgeable will have to tell.
>>
>> Cern.
>>
>>>
>>>
>>> Best regards, Aurélien
>>>
>>>
>>>
>>> --
>>> website: > http://www.machinekit.io <http://www.machinekit.io>>  blog: > 
>>> http://blog.machinekit.io <http://blog.machinekit.io>>  github: > 
>>> https://github.com/machinekit <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 
>>> <https://groups.google.com/group/machinekit>> .
>>> To view this discussion on the web visit > 
>>> https://groups.google.com/d/msgid/machinekit/53c22a1f-0a11-48e2-9a0f-d461525381d5%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/machinekit/53c22a1f-0a11-48e2-9a0f-d461525381d5%40googlegroups.com?utm_medium=email&utm_source=footer>>

Re: [Machinekit] VFD for 180v DC motor

[cern]

Jul 14, 2019, 3:09 PM by c...@tuta.io:

> Jul 13, 2019, 1:46 PM by golfop...@gmail.com:
>
>> Hi
>>
>> I use machinekit for a CNC lathe with Beaglebone Black and Furaday cape, 
>> debian 9 up to date, Axis GUI, icewm as DM.
>>
>> I need to replace my spindle controller board, this is a 180V DC shunt motor 
>> 1Hp run ~200 to ~3500rpm.
>>
>> I have found this one over ebay : > 
>> https://www.ebay.fr/itm/180V-200V-DC-230V-AC-16A-HP-motor-speed-controller-reversible-RS232-CNC-control/183788127346?hash=item2acaa04472:g:hq0AAOSwAE1cz7vg
>>  
>> <https://www.ebay.fr/itm/180V-200V-DC-230V-AC-16A-HP-motor-speed-controller-reversible-RS232-CNC-control/183788127346?hash=item2acaa04472:g:hq0AAOSwAE1cz7vg>
>>
>> For now i have only the attached document.
>>
>>
>> I think this controller is ok for my motor, but for manage the RS232 
>> protocol whith machinekit i'm unsure.
>>
>> https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps 
>> <https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps>
>> I suspect this need to use one of this VFD driver and adapt the protocol for 
>> the ebay controller ?
>>
> Hi,
> yes, you will need to write simple HAL module. Good thing is it needs not to 
> be real-time, all you need is to send some command every 3 seconds, so simple 
> python script with use of few ready-made libraries will be enough.
>
BTW, it looks like the exact same problem like: 
https://forum.linuxcnc.org/24-hal-components/36469-rs232-spindle-control?start=0
 
<https://forum.linuxcnc.org/24-hal-components/36469-rs232-spindle-control?start=0>

>
> Did you bought already or it is just theoretical question?
>
>>
>> It is ok for use this with USB/RS232 or is better to use some onboard UART 
>> from Beaglebone ?
>>
> Could be, looks like the pins for UART5 are not used by the cape, but 
> somebody more knowledgeable will have to tell.
>
> Cern.
>
>>
>>
>> Best regards, Aurélien
>>
>>
>>
>> --
>>  website: > http://www.machinekit.io <http://www.machinekit.io>>  blog: > 
>> http://blog.machinekit.io <http://blog.machinekit.io>>  github: > 
>> https://github.com/machinekit <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 
>> <https://groups.google.com/group/machinekit>> .
>>  To view this discussion on the web visit > 
>> https://groups.google.com/d/msgid/machinekit/53c22a1f-0a11-48e2-9a0f-d461525381d5%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/machinekit/53c22a1f-0a11-48e2-9a0f-d461525381d5%40googlegroups.com?utm_medium=email&utm_source=footer>>
>>  .
>>  For more options, visit > https://groups.google.com/d/optout 
>> <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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/machinekit/Ljka_fF--3-1%40tuta.io.
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/LjkuA1Q--3-1%40tuta.io.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] VFD for 180v DC motor

[cern]

Jul 13, 2019, 1:46 PM by golfop...@gmail.com:

> Hi
>
> I use machinekit for a CNC lathe with Beaglebone Black and Furaday cape, 
> debian 9 up to date, Axis GUI, icewm as DM.
>
> I need to replace my spindle controller board, this is a 180V DC shunt motor 
> 1Hp run ~200 to ~3500rpm.
>
> I have found this one over ebay : > 
> https://www.ebay.fr/itm/180V-200V-DC-230V-AC-16A-HP-motor-speed-controller-reversible-RS232-CNC-control/183788127346?hash=item2acaa04472:g:hq0AAOSwAE1cz7vg
>  
> <https://www.ebay.fr/itm/180V-200V-DC-230V-AC-16A-HP-motor-speed-controller-reversible-RS232-CNC-control/183788127346?hash=item2acaa04472:g:hq0AAOSwAE1cz7vg>
>
> For now i have only the attached document.
>
>
> I think this controller is ok for my motor, but for manage the RS232 protocol 
> whith machinekit i'm unsure.
>
> https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps 
> <https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps>
> I suspect this need to use one of this VFD driver and adapt the protocol for 
> the ebay controller ?
>
Hi,
yes, you will need to write simple HAL module. Good thing is it needs not to be 
real-time, all you need is to send some command every 3 seconds, so simple 
python script with use of few ready-made libraries will be enough.

Did you bought already or it is just theoretical question?

>
> It is ok for use this with USB/RS232 or is better to use some onboard UART 
> from Beaglebone ?
>
Could be, looks like the pins for UART5 are not used by the cape, but somebody 
more knowledgeable will have to tell.

Cern.

>
>
> Best regards, Aurélien
>
>
>
> --
>  website: > http://www.machinekit.io <http://www.machinekit.io>>  blog: > 
> http://blog.machinekit.io <http://blog.machinekit.io>>  github: > 
> https://github.com/machinekit <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 
> <https://groups.google.com/group/machinekit>> .
>  To view this discussion on the web visit > 
> https://groups.google.com/d/msgid/machinekit/53c22a1f-0a11-48e2-9a0f-d461525381d5%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/53c22a1f-0a11-48e2-9a0f-d461525381d5%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>  For more options, visit > https://groups.google.com/d/optout 
> <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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/Ljka_fF--3-1%40tuta.io.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Build injection molding robot

[cern]

Jun 19, 2019, 1:46 PM by fedelato...@gmail.com:

> Hi, I want to build an injection  molding robot and I was looking the best 
> hardware and software to do it.
> My idea is to use a beaglebone black with the PBX-BB breakoutboard from 
> probotix, or any other wich doesn't came with on board drivers.
> It will have 2 cartessian axis and probably 1 rotary axis, and should do the 
> programmed cycle everytime the machine send a signal.
> Would this be acomplished with machinekit?
>
Hi, it pretty much could be. I seen in your description nothing which would not 
be possible. The question is how turn-key you need the solution to be?

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.
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/Lhzfu_W--3-1%40tuta.io.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[cern]

Jun 11, 2019, 12:53 AM by blazin...@gmail.com:

> Put the Machinekit setup stuff to the side for a bit to get a PCB going. Got 
> some boards getting fabbed and some components on the way.
>
>
>
>
>
Is some open-source project lurking in this image?

Cern.


>
> On Sunday, May 12, 2019 at 10:00:18 AM UTC-4, Michael Brown wrote:
>
>> It sounds to me like you are takling about opendrain:
>> https://github.com/the->> snowwhite/mksocfpga/blob/>> 
>> master/HW/QuartusProjects/>> Common/gpio_adr_decoder_reg.>> sv#L33 
>> <https://github.com/the-snowwhite/mksocfpga/blob/master/HW/QuartusProjects/Common/gpio_adr_decoder_reg.sv#L33>
>>
>> If you want this functionality for inputs you have to use the 
>>
>> active high:
>>
>>
>>
>> net limit-x-min <= hm2_[HOSTMOT2](BOARD).>> 0.gpio.>> 010.in 
>> <http://0.gpio.010.in>
>> active low:
>>
>>
>>
>>
>> net limit-x-min <= hm2_[HOSTMOT2](BOARD).0.gpio.>> 010.in_not
>>
>>
>>
>> On Sunday, 12 May 2019 13:21:46 UTC+2, justin White  wrote:
>>
>>> Got another silly question
>>>
>>> Is it possible to invert the default state of the GPIO pins? I've found 
>>> that pulling them up will bring them true, Hardware wise the easiest way 
>>> I've found to make the inputs capable of handling multiple input voltages 
>>> will require them to be pulled down when activated, so I'd have to pull 
>>> them up to a "false" state. This would only be something I need to do with 
>>> the gpio inputs.
>>>
>>> On Friday, May 10, 2019 at 6:40:30 PM UTC-4, Michael Brown wrote:
>>>
>>>> Ok
>>>> Great to hear you have progress.
>>>>
>>>> On a side note:
>>>> I managed to find the bug in the ADC system and the fix got out into the 
>>>> socfpga-rbf deb yesterday :-=)  
>>>>
>>>> On Friday, 10 May 2019 22:26:13 UTC+2, justin White  wrote:
>>>>
>>>>>> When you are laying out your own custom DExx interface board, you don't 
>>>>>> have to stay restricted to allready made pinouts.
>>>>>>
>>>>> Yeah that I know,  Like I said, I was mostly trying to determine how many 
>>>>> pins each tag type used and it's actual usage. I was a bit hung up on the 
>>>>> ADC thing because it didn't directly correspond with the pin tags but now 
>>>>> I realize it's an SPI interface.
>>>>>
>>>>> I'll have to come back to all of the above info once I try to create the 
>>>>> new FPGA project files, for now I think I get the idea.
>>>>>
>>>>> Purging the installed Machinekit packages and installing the new ones as 
>>>>> you suggested got HALshow working right away. 
>>>>>
>>>>> I've pretty much got my encoder interface and output hardware sorted, I 
>>>>> use 24v I/0 but it should handle multiple voltages.
>>>>>
>
>
>
> --
>  website: > http://www.machinekit.io <http://www.machinekit.io>>  blog: > 
> http://blog.machinekit.io <http://blog.machinekit.io>>  github: > 
> https://github.com/machinekit <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 
> <https://groups.google.com/group/machinekit>> .
>  To view this discussion on the web visit > 
> https://groups.google.com/d/msgid/machinekit/a53d1e3f-7211-4380-9186-edfe806f2635%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/machinekit/a53d1e3f-7211-4380-9186-edfe806f2635%40googlegroups.com?utm_medium=email&utm_source=footer>>
>  .
>  For more options, visit > https://groups.google.com/d/optout 
> <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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/Lh2bhLh--3-1%40tuta.io.
For more options, visit https://groups.google.com/d/optout.