What is the big diff between Machinekit and LinuxCNC.

[and...@roughedge.se]

Is there a good page for illuminating the differences between linuxcnc and machinekit.. how far apart are they these days since the first fork ?? Is any of the core parts of linuxcnc project maintained, like the updated motion planner , new mesa drivers and such?

I'm heavily consdering swapping linuxcnc for machinekit on my lattepanda + mesa card project.. Because the old linuxcnc is horrible to get working and perform well. But if it lacks features or differs to much.. then that would be non-benficial. =)

[schoo...@btinternet.com]

On 05/12/16 22:24, and...@roughedge.se wrote:

Is there a good page for illuminating the differences between linuxcnc and machinekit.. how far apart are they these days since the first fork ??

No, I don't think anyone is interested in being judged in comparison to linuxcnc (or Mach for that matter)

You can diff the repos and look at the documentation for specific features / differences.

Is any of the core parts of linuxcnc project maintained, like the updated motion planner , new mesa drivers and such?

The new tp planner was not in linuxcnc when Machinekit was forked.  It is in both projects.

What 'new' mesa drivers are you referring to?
Machinekit has mesa support and even has support for Soc FPGA boards emulating Mesa boards which is unique to Machinekit.

I'm heavily consdering swapping linuxcnc for machinekit on my lattepanda + mesa card project.. Because the old linuxcnc is horrible to get working and perform well.

You are not going to find Machinekit any easier if you don't have the technical knowledge.
There is no distro to install and the full images available are for BBB and Rpi 2-3 only.

By the look of the lattepanda it was designed as a windoze 10 board and any linux support is fledgeling.
The fact that it is an Atom processor does not fill me with joy, Intel actually produced some of these for tablets etc
that were so tied into windoze, you could not run linux on them.
It also uses UEFI boot, with no obvious info as to whether this can be disabled, further restricting choice and complicating matters.

A quick search leaves me uncertain what linux system is actually supported, Ubuntu 16 does not seem to run on it.
There might be Debian Jessie support, but the link just takes you to a blurb about the Debian distro.
The LUbuntu link is dead.

The libraries required by machinekit mean you would need Debian Wheezy or Jessie preferably, to be able to use the packages available.

Looks like a technically interesting project, but if you actually want to cut metal in particular, putting the Mesa board(s) into a x86 desktop
is a much easier solution.

regards

But if it lacks features or differs to much.. then that would be non-benficial. =)

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Andreas Pettersson]

Well the intention is not to judge anything in comparison.. Both has their own good and bad sides im guessing.
Would still be interesting out of a feature perspective to know what makes them differ.

I do think machinekit is the way togo, i have found LinuxCNC being tad bit outdated in several ways when compiling and
modifying the code in it. And machinekit seems to have breathed some fresh air into it out of that regard.

And well i have been fiddling with LinuxCNCon and off for the past 6 years tech knowledge no issues, compiling and modifying it
for different hardware no issues there either. I actually got both machinekit and linuxcnc running on the lattepanda as of late yesterday.
Running them under Linuxmint 18, thats Ubuntu 16 if i remember correctly it was not that "plug and play" as it could have been.
But really not an issue either if you have some basic knowledge of Linux overall.

I was just curious.. excuse my curiosity.. Both machinekit and linuxcnc communitys seems to take offense at straight forward questions
regarding the code base is there so much prestige invested in them ?? really.. its just code.. it should stand up to a straight down comparison
to see what fits the individual why is that so hard to understand.. and no i dont talk about mach don't know how that could even be compared.

But apprently i should stop being curious. It's better to just accept things as is and never question anything. Thats the way to go.. *the stupid way*

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/w9poGXTfzYI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.

[schoo...@btinternet.com]

On 06/12/16 10:05, Andreas Pettersson wrote:

Well the intention is not to judge anything in comparison.. Both has their own good and bad sides im guessing.
Would still be interesting out of a feature perspective to know what makes them differ.

I do think machinekit is the way togo, i have found LinuxCNC being tad bit outdated in several ways when compiling and
modifying the code in it. And machinekit seems to have breathed some fresh air into it out of that regard.

And well i have been fiddling with LinuxCNCon and off for the past 6 years tech knowledge no issues, compiling and modifying it
for different hardware no issues there either. I actually got both machinekit and linuxcnc running on the lattepanda as of late yesterday.
Running them under Linuxmint 18, thats Ubuntu 16 if i remember correctly it was not that "plug and play" as it could have been.
But really not an issue either if you have some basic knowledge of Linux overall.

I was just curious.. excuse my curiosity.. Both machinekit and linuxcnc communitys seems to take offense at straight forward questions
regarding the code base is there so much prestige invested in them ?? really.. its just code..

I am not taking offence, the 'straight forward question' is just so general with no advantage to anyone to research, it has not been done.
This a collaborative open source project, no one makes money from it, so don't have much interest in evangelising it 'advantages'.

If you have specific questions, they are much easier to cater for.

[Andreas Pettersson]

I just assumed someone would know.. Someone did the changes.
Best thing i've seen so far in the code seems to be memory management and middlware changes.
Making it more reliable and im guessing fast.

It was way less dependencies when compiling from source as well thats nice. didnt have to go exploring outdated
packages from some distribution no one wants to use anymore (for other reasons).

You did mention the mesa driver emulator for DS0-Nano tho, would that make the nano a "general" IO card or could it
run stepper and servo cycles as well?! Seems like an interesting low cost fix for the expensive mesa cards (even though i have a pile of em).

// Andreas

[schoo...@btinternet.com]

On 06/12/16 10:30, Andreas Pettersson wrote:

I just assumed someone would know.. Someone did the changes.
Best thing i've seen so far in the code seems to be memory management and middlware changes.
Making it more reliable and im guessing fast.

It was way less dependencies when compiling from source as well thats nice. didnt have to go exploring outdated
packages from some distribution no one wants to use anymore (for other reasons).

You did mention the mesa driver emulator for DS0-Nano tho, would that make the nano a "general" IO card or could it
run stepper and servo cycles as well?! Seems like an interesting low cost fix for the expensive mesa cards (even though i have a pile of em).

The DE0-Nano-Soc is a development board for FPGA programming

It runs and ARM image of MK with the FPGA programmed to act as a 5i25, I have run my mill from one using the 7i76 (stepper) firmware, I think there is a 7i77 one and some others too

https://github.com/machinekit/mksocfpga

https://github.com/machinekit/machinekit/issues/915

http://blog.machinekit.io/2016/11/you-will-recall-that-while-back-charles.html

http://blog.machinekit.io/2016/11/de0-nano-soc-update-on-sd-card-images.html

[Andreas Pettersson]

Thats just incredible cool.
Gonna have to dig out my DE0-Nano-Soc card out of the electronics bin then.. Thought it was just acting like a IO card or similar like attaching an Arduino.
But if it can act as the 7i76 or 7i77 cards and a generic 5i25.. that makes alot more sense then.. because that would be rather cheap. =)

Thanks, this can be an amusing evening. =)

// Andreas

[Mathias Giacomuzzi]

So the goal of that DE0-Nano-Soc is a replacement for BBB and CRAMPs as an example?

[Andreas Pettersson]

thats is a relevant question.. i havent got that far.. but that thing runs machinekit and a drummed down version of debian im guessing with a custom kernel?!
It's not acting as an addon board no?!

// A

Den 2016-12-06 kl. 12:29, skrev Mathias Giacomuzzi:

So the goal of that DE0-Nano-Soc is a replacement for BBB and CRAMPs as an example?

[Bas de Bruijn]

> On 06 Dec 2016, at 12:29, Mathias Giacomuzzi <eca...@gmail.com> wrote:
>
> So the goal of that DE0-Nano-Soc is a replacement for BBB and CRAMPs as an example?

No, this not a replacement. It’s just another example of hardware from which you can run Machinekit.

The biggest “difference” if you will is that Machinekit aims to run on different platforms and hardware. Where the BBB and De0-nano-soc are not replacing the other. In some situations you want neither, so there you’d choose for a PC and a Mesa card.

The De0 nano soc together with Charles adapter board makes it easy to use Mesa daughter boards, without the 5i25 Pci card.

Machinekit can run on PC’s as well as arm boards, like the BBB. But Machinekit is not a BBB project.

[Charles Steinkuehler]

On 12/6/2016 5:30 AM, Andreas Pettersson wrote:
> thats is a relevant question.. i havent got that far.. but that thing runs
> machinekit and a drummed down version of debian im guessing with a custom kernel?!
> It's not acting as an addon board no?!

The DE0-Nano (and any of the other FPGA+SoC platforms supported in the
mksocfpga repository) function both as a control computer (with Linux
and machinekit running on the ARM hard core processors) and as a Mesa
open-source VHDL add-on card (ie: like a 5i24 or 5i25) running in the
FPGA fabric (with the full details depending on what you compile into
the FPGA). With a simple adapter board, it is possible to connect
Mesa 25 or 50 pin daughter cards to the FPGA as well (I have a 25-pin
adapter designed for the DE0-Nano).

Pretty much the only big missing piece for a full machine controller
is a decent graphics display, since none of the SoC+FPGA chips have
bulit-in graphics or GPUs, and those are complex enough it doesn't
really make sense to try and build a GPU with FPGA gates. You would
probably want to use a remote system or a tablet/touchscreen for the
display, or run a machine that doesn't require much in the way of a UI.

--
Charles Steinkuehler
cha...@steinkuehler.net

[schoo...@btinternet.com]

On 06/12/16 11:00, Andreas Pettersson wrote:

Thats just incredible cool.
Gonna have to dig out my DE0-Nano-Soc card out of the electronics bin then.. Thought it was just acting like a IO card or similar like attaching an Arduino.
But if it can act as the 7i76 or 7i77 cards and a generic 5i25..

It doesn't, you need to read the links etc

It is programmed as a 5i25, you still need a 7i76 or whatever to interface with as a daughter board to get all the IO etc.

The DE0-Nano costs about the same as a 5i25 board so no immediate saving there and you are running everything off a rather low power board.

The big achievement is the FPGA programming itself and the hm2_ driver.
(That is translatable to other boards too)

This gives you an embeddable Soc board which has very powerful FPGA, with hardware encoders and step generators etc. and can interface
with existing industrial quality boards.

[Andreas Pettersson]

I see, i actually thought it replaced both the host card and the
daughter card and didnt run an OS.
That after reading repo readmes and some of the issues i was linked to
before.

So it would still need an external daughter card. Still that is quite
interesting. if one could save on buying mesa cards why wouldnt one want
todo that. =)

The screen issue is a minor thing i dont think you reaaally would need a
full blown graphics display.. a alphanumeric display for basic network
and get it up and running
display would be nice tho - but that isnt hard to get running on those.

Nice compact solution anyway. =)

// A

[Andreas Pettersson]

think i paid less than 70 dollars for my DE0-Nano-Soc board. and the 6i25 board i have in my running machine is like 150 dollars.
I would call that a 50% save tho.. maybe gotten more expensive as of late.

// A

[Charles Steinkuehler]

On 12/6/2016 6:18 AM, Andreas Pettersson wrote:
> I see, i actually thought it replaced both the host card and the
> daughter card and didnt run an OS.
> That after reading repo readmes and some of the issues i was linked to
> before.
>
> So it would still need an external daughter card. Still that is quite
> interesting. if one could save on buying mesa cards why wouldnt one
> want todo that. =)

You are not required to have an external daughter card. For things
like step/dir or (non muxed) encoder inputs, you can tie the signals
directly to the FPGA board if you want. The daughter cards provide
protection, isolation, an easy way to connect signals, and support the
"complex" interfaces (smart serial, multiplexed encoders) that allow
connecting more signals than there are FPGA pins.

Whether or not a Mesa daughter card makes sense depends on your
particular needs. You might find one handy for the protection and
isolation features. For pin expansion, the DE0-Nano supports 68
directly connected I/O pins (up to four DB25 connectors with 17
signals each if you use my adapter card), which ought to be enough
control lines for most machines.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Andreas Pettersson]

As of know im trying to couple a lattepanda with a 7i46E card instead of
having to rely on several mesa boards as in my servo setup (6i25+7i77+7i84).
The test bed is just a plasma table wit 3 stepper motors.. nothing
fancy.. and it will see its fair share of time ouside in the rain..
thats why i try to shrink
everything down as much as possible. And started to look at machinekit
to be able to choose something smaller in formfactor to run it off of.

gonna try to get my DE0 running and connect it to some stepper drivers i
can prob. throw an optocoupler in the mix for good measure. =)

// Andreas

[DaBit]

>No, I don't think anyone is interested in being judged in comparison to linuxcnc (or Mach for that matter)
>You can diff the repos and look at the documentation for specific features / differences.

It is not about 'being judged'. It is about 'what advantages would MachineKit provide me over LinuxCNC?'. I am struggling with this also.

I am happily running LinuxCNC on my mill and lathe, and now I am contemplating a 3D printer. Not because I would like to have a functional 3D printer asap, but because I like to construct and tinker. See it more as a motorcyclists way of thinking: 'the destination is the excuse'. Here is a screenshot of the thing under construction: https://dl.dropboxusercontent.com/u/2762301/3dprinter/frame5.png

I have been succesfull at running LinuxCNC on a Raspberry Pi using a cheap ($2,51) USB-connected STM32 board on that thing: https://www.youtube.com/watch?v=5WsugS7hTLk
Works well enough, even considering the fact that USB is just not optimal for this purpose (I did that STM32/USB thing to be able to do a LinuxCNC workshop on laptops). So I more or less decided to base the controller on a Pi with the 7" touchscreen and use SPI-controlled L6470 dSpin drives for the motors. Waiting for those to arrive from China; will take a few weeks.

I know how to do this using LinuxCNC. Write a few HAL components to drive the hardware, remap some G-codes, etc.
However, what I don't know is whether Machinekit would be a better platform for this and why. When I look at the documentation I mostly see things that are familiar from LinuxCNC. The developer manual talks about NML, I'm seeing the familiar Axis/Touchy/Mini/etc. GUI's and no Machineface/Cetus, etc. Hard to figure out what the strong and weak points of MK are compared to LCNC.

Questions, for example:
- How similar to LinuxCNC is it to write components in C?
- Does MK use the actual servo cycle time instead of assuming it is 1ms for a 1kHz servo thread? It is not really important that the time between invocations of the component functions is 800us at time t and 1200us at time t+1. Computers can calculate, so when moving in a straight line at 100mm/s position has advanced 0,08mm for time t and 0,12mm for time t+1. Same goes for integrators in a PI controller, etc. However, the LinuxCNC assumption that 1ms has passed (and just passing a period of 1e6 nsec to the components) is not optimal, especially on a system with a fairly high jitter such as a Pi and a motion platform capable of high accelerations.
- Does the trajectory planner still switch back to 'slow' when using more than only XYZ axes, forcing the use of velocity-based extrusion as a workaround?

I guess I have to try out MK to find the answers.

[Charles Steinkuehler]

On 12/6/2016 3:16 PM, DaBit wrote:
>
> Questions, for example:
> - How similar to LinuxCNC is it to write components in C?

Virtually identical.

> - Does MK use the actual servo cycle time instead of assuming it is 1ms for
> a 1kHz servo thread? It is not really important that the time between
> invocations of the component functions is 800us at time t and 1200us at
> time t+1. Computers can calculate, so when moving in a straight line at
> 100mm/s position has advanced 0,08mm for time t and 0,12mm for time t+1.
> Same goes for integrators in a PI controller, etc. However, the LinuxCNC
> assumption that 1ms has passed (and just passing a period of 1e6 nsec to
> the components) is not optimal, especially on a system with a fairly high
> jitter such as a Pi and a motion platform capable of high accelerations.

Not yet. There have been experiments to show the benefit of using the
actual cycle time but for now the closest you can get is to use a Mesa
card (or one of the SoC+FPGA platforms) and use hardware triggered
timing. The software still assumes the servo period is exactly what was
requested, but since hardware captures the machine state at the correct
time (no software IRQ latency involved), that assumption is actually
correct (as it relates to the encoder and stepper positions used to do
motion calculations). :)

Note: This is still somewhat experimental. It has been shown to work
but is not yet in general use. Testers welcome!

> - Does the trajectory planner still switch back to 'slow' when using more
> than only XYZ axes, forcing the use of velocity-based extrusion as a
> workaround?

Yes, I believe this is still the case in both Machinekit and LCNC.

--
Charles Steinkuehler
cha...@steinkuehler.net

[and...@roughedge.se]

Getting more and more curious of running this DE0-Nano stuff.. couldnt find my card so considering order a new one.
that expansion board you made for it, i assume is to connecto to mesa expansion board. But could it be modify to include the isolation
needed so you could connect directly to the pins that way..

And i do enjoy the experimental stuff, getting lcnc or MK up and running and just working has been done both works im just diving deeper into the esoteric stuff (fun stuff)
and figuring out on the way what can be achieved with no particular goal in mind.. =)

[Charles Steinkuehler]

On 12/8/2016 4:26 AM, and...@roughedge.se wrote:
> Getting more and more curious of running this DE0-Nano stuff.. couldnt find
> my card so considering order a new one.
> that expansion board you made for it, i assume is to connecto to mesa
> expansion board. But could it be modify to include the isolation
> needed so you could connect directly to the pins that way..

It will connect to Mesa daughter cards, but should also work with most
any parallel port breakout board that works with 3.3V signal levels.

...and of course you can modify the adapter board to include any other
logic needed. I just figured getting something that looked pretty much
like a 5i25 was a good start and should be generally useful for a wide
variety of machines.

If you want to make changes, the KiCAD source is here:

https://github.com/cdsteinkuehler/bobc_hardware/tree/CRAMPS/DE0-Nano_DB25

> And i do enjoy the experimental stuff, getting lcnc or MK up and running
> and just working has been done both works im just diving deeper into the
> esoteric stuff (fun stuff)
> and figuring out on the way what can be achieved with no particular goal in
> mind.. =)

Yep! It's an open source, volunteer project. If it wasn't fun, none of
us would be working on it! :)

--
Charles Steinkuehler
cha...@steinkuehler.net

[Daniel Skrlin]

Hey Charles how well will this board work for a servo system? Let me know. Thanks.

[Daniel Skrlin]

Current hardware is x86 with a 7i92/7i77.

[Charles Steinkuehler]

On 12/18/2016 11:14 AM, Daniel Skrlin wrote:
> Hey Charles how well will this board work for a servo system? Let me know. Thanks.

As well as any other Mesa FPGA board, given the limitations of the ARM
SoC (no GPU, and relatively slow performance compared to recent x86
systems).

The actual motor control for servos will work fine. If you're OK with
using new/experimental features (likely, or you wouldn't be
considering this platform) the closed-loop servo performance will
likely be better than any other available platform if you drive the
HAL thread timing with interrupts generated by the hostmot2 VHDL code
which effectively removes the effects of SW interrupt latency and jitter.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Daniel Skrlin]

I think this gets a little beyond me but I can def see how this can be a solid setup in one small package. Thanks Charles maybe you can shed some light on this at the MK meetup.

On Sunday, December 18, 2016 at 11:44:54 AM UTC-6, Charles Steinkuehler wrote:

if you drive the HAL thread timing with interrupts generated by the hostmot2 VHDL code

--
Charles Steinkuehler
cha...@steinkuehler.net

[tromb...@gmail.com]

Hi,
when we are talking about FPGA cards and closing servo loops in them, is it possible to use this SoC board as a Mesa I/O card 7I80DB? So as to connect it by ethernet to i386 PC Machinekit controller.

I have been thinking about FPGA combo (back then PCI based) for long time but was completely turned off Mesa by how they conduct business and unfortunately these is no viable competition.

I know that I would still have to solve somehow the 7i77 side but that's for another day.

[Charles Steinkuehler]

On 12/19/2016 6:10 PM, tromb...@gmail.com wrote:
> Hi,
> when we are talking about FPGA cards and closing servo loops in them, is it

> possible to use this SoC board as a Mesa I/O card7I80DB? So as to connect it by

> ethernet to i386 PC Machinekit controller.
>
> I have been thinking about FPGA combo (back then PCI based) for long time but
> was completely turned off Mesa by how they conduct business and unfortunately
> these is no viable competition.
>
> I know that I would still have to solve somehow the 7i77 side but that's for
> another day.

I suppose it would be possible to turn one of the SoC+FPGA boards into
a 7I80DB clone, but it wouldn't be easy. The 7I80 FPGA logic is open
source, but it uses a custom CPU built from FPGA gates for the IP
stack, and it expects to talk to the specific embedded Ethernet
controller chip used on the Mesa board. Worse, the Ethernet ports on
all the SoC+FPGA dev kit boards I am aware of are tied to the ARM
processor side, not the FPGA fabric, so you would have a difficult
time getting the 7I80 code running.

You would also pretty much be throwing away the entire ARM side of the
SoC+FPGA board. You'd probably be better off starting with a more
traditional FPGA only dev. kit if you're wanting to mimic one of the
Mesa Ethernet cards.

--
Charles Steinkuehler
cha...@steinkuehler.net

[DaBit]

Hi Charles,

Sorry for the delayed response; end of year is always an extremely busy time.
But thanks a lot for the answer.

Not yet.  There have been experiments to show the benefit of using the
actual cycle time but for now the closest you can get is to use a Mesa
card (or one of the SoC+FPGA platforms) and use hardware triggered
timing.  The software still assumes the servo period is exactly what was
requested, but since hardware captures the machine state at the correct
time (no software IRQ latency involved), that assumption is actually
correct (as it relates to the encoder and stepper positions used to do
motion calculations).  :)

Note: This is still somewhat experimental.  It has been shown to work
but is not yet in general use.  Testers welcome!

This sounds very interesting for my mill. That one runs a 7kHz servo thread. The servo amplifiers are used in torque mode and all control loops including glass scale corrections, notch filters to suppress known resonances, etc. are implemented in HAL.
Would be a nice testbench. Where do I obtain more information about this?

Regarding MachineKit:  I have been toying with a Raspberry Pi 3 and ST Microelectronics SPI-controlled L6470 stepper drives: https://dl.dropboxusercontent.com/u/2762301/3dprinter/L6470_motorstroom_linuxcnc.png
Works very well; the voltage-mode control of the motor combined with 128-step microstepping is very silent, the builtin trapezoidal motion planner is a good fit for LinuxCNC, and the error reporting (overcurrent, steploss, overheating, etc.) is excellent. There is even a 80V/10A big brother available as powerSTEP01.

For a 3D printer I will implement the fan control and heaters using one of those cheap ($2,50) STM32F103 boards connected to the host using USB/custom HID device. Doing it that way prevents me from becoming locked to one specific board or platform. I used USB before together with LiunxCNC ont he Pi, even for motion control, and it works fine: https://www.youtube.com/watch?v=5WsugS7hTLk

Now, I am stil interested in MachineKit and I still don't know what the advantages/disadvantages would be. Machineface would be a nice feature.
If I have a system running Raspbian Jessie with PREEMPT-RT kernel, what would be the easiest way to set up MK? Can I also do a RIP build and run both LinuxCNC and MK next to each other?

[Daniel Skrlin]

Holy cow 7kHz is fast, I wouldnt know what sytem could even run this, correct me if I am wrong but there was a post regarding PREEMPT-RT on x86 systems where I saw up to 4kHz, and that was pushing the envelope, Again maybe this SoC will work out for you. Keeping my eyes on this thread.....

[tromb...@gmail.com]

Thanks for answer. What I had in mind was little different. I was not thinking about clone in everything but only in function. I was actually thinking about using the ARM part of the SoC to function as a kind of bridge. So the initialization of FPGA would not come from the controller but from something running on the ARM itself. Maybe two Machinekits, one running on standard x86 computer with user interface, trajectory planner and so on, LPT/Serial used for non realtime machine data (I have power/voltage/health monitor), and some bastardized version of Machinekit running as slave on the ARM doing the communication with parent Machinekit. Maybe with Machinetalk? (I am not that far into my study of Machinekit.)

My main idea was to avoid programming FPGA as I am complete green at this.

[Charles Steinkuehler]

On 12/21/2016 3:56 AM, DaBit wrote:
>
> If I have a system running Raspbian Jessie with PREEMPT-RT kernel,
> what would be the easiest way to set up MK?

You can build from source or I think someone is maintaining packages
for the RPi.

> Can I also do a RIP build and run both LinuxCNC and MK next to each
> other?

You should be able to have RIP builds of both LinuxCNC and MK on the
same system, just run the rip-environment script from the one you want
to use when starting a command shell.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Charles Steinkuehler]

On 12/23/2016 2:36 PM, tromb...@gmail.com wrote:
> Thanks for answer. What I had in mind was little different. I was not thinking
> about clone in everything but only in function. I was actually thinking about
> using the ARM part of the SoC to function as a kind of bridge. So the
> initialization of FPGA would not come from the controller but from something
> running on the ARM itself. Maybe two Machinekits, one running on standard x86
> computer with user interface, trajectory planner and so on, LPT/Serial used for
> non realtime machine data (I have power/voltage/health monitor), and some
> bastardized version of Machinekit running as slave on the ARM doing the
> communication with parent Machinekit. Maybe with Machinetalk? (I am not that far
> into my study of Machinekit.)

That's where things are headed with Machinetalk and the ability to
have a distributed HAL ecosystem with independent HAL "islands"
running on different processors and communicating via Haltalk.

A lot of this is available and works now, but no one has done much
with it yet and you probably won't get good enough performance between
the different HAL machines to allow a typical CNC machine with motion
planning on one system and low-level HAL setup on the SoC+FPGA box.

--
Charles Steinkuehler
cha...@steinkuehler.net

[DeWayne Young]

[DeWayne Young]

Hello DaBit,

Can you please post some instructions or an image for what you did to get LinuxCNC running on the the Pi.  Been trying to replicate what you have done for last few days and running into a brickwall. Also the version as well.

Thanks

On Wednesday, December 7, 2016 at 4:16:41 AM UTC+7, DaBit wrote:

[Aleksandr Kolomeetc]

Hi

A year later, how would you answer this question now?

regards