Re: [Emc-developers] Breakout of HAL/ machinekits's HAL --> NML

[Nicklas Karlsson]

> Mick
> 
> I hope you don't mind I pushed this back to the list.
> 
> I too was hoping to make inroads for modularity, future proofing, and 
> lowering the bar for future developers.
Instead of NML there might be some kind of standard protocol to use to talk 
with machine running real time part? Or machine running g-code?


> I'm not an expert of course but the multi core approach did seem to make 
> sense for the future.
To run real time parts on simple micro controller and GUI on ordinary computer 
make a lot of sense.

> It was also conveniently already done and already modular.
It is modular with NML communication in between.

> I do appreciate, everyone's participation in the discussion.
> 
> I feel it's good to stop and ask these kinds of questions from time to time.
> 
> Chris M

I am still working on hardware but are pretty sure I nailed which physical 
buses I should use and suitable protocol. Then this is done I will continue 
with Linuxcnc, I have one or two drivers partly added.


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[theman whosoldtheworld]

I put myself in the speech hoping to bring a useful opinion and to be too
much ... I'm very new and my coding is very simple ... for first never try
to use machinekit but I read all docs. I appreciate a lot comunication
across thread and multicore approach i think is very interesting. Of course
not for simple mill machine 3 axis ... but actually the world of motion is
much more interested to unconventional robot for example than milling
machine ... so start 2 or more Lcnc/machinekit istance on the same I5/I7
platform is a very appreciate things ... plus the modern industrial bus
needs isolcpu triks so isolate the various rt istance on the various core
is better than assemble a machine with 3/4 rt-pc. I think these
"advantages" of makinekit vs. Lcnc is not so secondary.

Aphart from that I think NML is a very simple and roboust way to do the
things ...it is a real pity that nobody has thought something similar in a
modern way.

regards
bkt

Il giorno ven 14 set 2018 alle ore 20:14 Chris Morley <
chrisinnana...@hotmail.com> ha scritto:

> Mick
>
> I hope you don't mind I pushed this back to the list.
>
> I too was hoping to make inroads for modularity, future proofing, and
> lowering the bar for future developers.
>
> I'm not an expert of course but the multi core approach did seem to make
> sense for the future.
>
> It was also conveniently already done and already modular.
>
> If we had made our HAL similarly modular then one could conceivably used
> either library.
>
> I also thought that by using a HAL library maintained by someone else, the
> small amount of active developers
>
> could concentrate on other things, while still expanding the utility of
> HAL.
>
>
> It seems, at least on the linuxcnc side there is little interest in the
> work/idea of using MK's HAL.
>
> There are multiple reasons that i draw this conclusion, but it doesn't
> really matter.
>
>
> I do appreciate, everyone's participation in the discussion.
>
> I feel it's good to stop and ask these kinds of questions from time to
> time.
>
> Chris M
>
> ____________
> From: schoone...@gmail.com 
> Sent: September 14, 2018 5:19 PM
> To: EMC developers; Chris Morley
> Subject: Re: [Emc-developers] Breakout of HAL/ machinekits's HAL
>
>
>
>
>
>
>
>
>
>
>
>
>
> For some reason this did not go and has not hit the list
>
>
> Chris
>
> I have no interest in evangelising Machinekit, it is there, if people
> don't like it
> or are in other ways resistant, I'm not bothered.
>
> I was merely outlining a possibility.  The big issue regards the CNC stack
> IMHO is not
> whether we need joints/axes, but getting rid of NML and making the whole
> CNC stack more modular.
>
> NML was written by C programmers operating on single core machines with
> linear programs,
> who never expected anything else to exist.
> It is littered with global variables, structures and many other things
> that make any
> sort of OOP impossible as it stands.
>
> The assumptions are similar to those in components we changed in
> Machinekit, where for example,
> data exchange between threads was reliant upon an assumed model of
> preemption giving
> priority to one thread and it being allowed to complete before the other
> one began.
> Michael showed that they fell apart when exposed to cached multi-cored
> processors
> and started producing some very strange results.
>
> If you want any help, contact me, but you know your own code base better
> than me.
>
> Machinekit is GPL2 AFAIK, ie. there is no binary stipulation.
>
> The problem with GPL2+ as I see it, is it allows later bad versions to
> supercede it, at the
> users arbitration of what version is most advantageous to them.
> (Linus certainly seems to think GPL3 is bad)
>
> Good luck
>
> Mick
>
>
> From: Chris Morley  chrisinnana...@hotmail.com>
> To: EMC developers  emc-developers@lists.sourceforge.net>
> Subject: Re: [Emc-developers] Breakout of HAL/ machinekits's HAL
> Message-ID:
> <
> by2pr05mb224801f1ed450b05292c91e2c0...@by2pr05mb2248.namprd05.prod.outlook.com
> > by2pr05mb224801f1ed450b05292c91e2c0...@by2pr05mb2248.namprd05.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> We are getting off topic here
> I was suggesting we separate our HAL and cnc stack with the idea of
> possibly using MK HAL.
>
> NML is part of the cnc stack.
> That would be future work, I'd someone wanted to tackle it.
>
> Though just the act of splitting hal from CNC without adopting anything
> would make future work easier.
>
> 

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Chris Morley]

Mick

I hope you don't mind I pushed this back to the list.

I too was hoping to make inroads for modularity, future proofing, and lowering 
the bar for future developers.

I'm not an expert of course but the multi core approach did seem to make sense 
for the future.

It was also conveniently already done and already modular.

If we had made our HAL similarly modular then one could conceivably used either 
library.

I also thought that by using a HAL library maintained by someone else, the 
small amount of active developers

could concentrate on other things, while still expanding the utility of HAL.


It seems, at least on the linuxcnc side there is little interest in the 
work/idea of using MK's HAL.

There are multiple reasons that i draw this conclusion, but it doesn't really 
matter.


I do appreciate, everyone's participation in the discussion.

I feel it's good to stop and ask these kinds of questions from time to time.

Chris M


From: schoone...@gmail.com 
Sent: September 14, 2018 5:19 PM
To: EMC developers; Chris Morley
Subject: Re: [Emc-developers] Breakout of HAL/ machinekits's HAL













For some reason this did not go and has not hit the list


Chris

I have no interest in evangelising Machinekit, it is there, if people don't 
like it
or are in other ways resistant, I'm not bothered.

I was merely outlining a possibility.  The big issue regards the CNC stack IMHO 
is not
whether we need joints/axes, but getting rid of NML and making the whole CNC 
stack more modular.

NML was written by C programmers operating on single core machines with linear 
programs,
who never expected anything else to exist.
It is littered with global variables, structures and many other things that 
make any
sort of OOP impossible as it stands.

The assumptions are similar to those in components we changed in Machinekit, 
where for example,
data exchange between threads was reliant upon an assumed model of preemption 
giving
priority to one thread and it being allowed to complete before the other one 
began.
Michael showed that they fell apart when exposed to cached multi-cored 
processors
and started producing some very strange results.

If you want any help, contact me, but you know your own code base better than 
me.

Machinekit is GPL2 AFAIK, ie. there is no binary stipulation.

The problem with GPL2+ as I see it, is it allows later bad versions to 
supercede it, at the
users arbitration of what version is most advantageous to them.
(Linus certainly seems to think GPL3 is bad)

Good luck

Mick


From: Chris Morley 
<mailto:chrisinnana...@hotmail.com>
To: EMC developers 
<mailto:emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] Breakout of HAL/ machinekits's HAL
Message-ID:

<mailto:by2pr05mb224801f1ed450b05292c91e2c0...@by2pr05mb2248.namprd05.prod.outlook.com>

Content-Type: text/plain; charset="us-ascii"

We are getting off topic here
I was suggesting we separate our HAL and cnc stack with the idea of possibly 
using MK HAL.

NML is part of the cnc stack.
That would be future work, I'd someone wanted to tackle it.

Though just the act of splitting hal from CNC without adopting anything would 
make future work easier.

Chris M

Can you tell us about license of MK HAL work.

AFAIK Linuxcnc is GPL2 for some and GPL2+ for most(?)



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Steve Better]

They wrote something about the replacing of NML. Hope it helpful.


https://machinekoder.com/machinetalk-explained-part-1-introduction/


On 09/13/2018 10:49 AM, Jon Elson wrote:
> On 09/12/2018 03:34 PM, Stuart Stevenson wrote:
>> What is wrong with NML? If it doesn't have some needed process is it not
>> able to be extended?
>>
>>
> The problem, AS I UNDERSTAND IT, is that NML treats the entire real 
> time state of the system as one atomic block.  Works fine on any 
> system with one memory.  So, multi-core systems are fine. But, if you 
> want to extend something that uses NML communication across the 
> network, it has to send 20+K of real time state across the network at 
> the servo rate.  That IS a problem.  NML can ONLY send the WHOLE real 
> time state.  The feature of zmq (apparently they have now converged on 
> one way to spell it) is that it can send ONLY the part that a 
> requester asks for.  So, if the remote thing only needs a few 
> variables out of the whole real time state, ONLY those variables will 
> be sent.
>
> This is my understanding of the major feature of zmq that they want to 
> use.  There MAY be a talk by one of the MK developers about this that 
> is more authoritative and goes into vastly more detail.  We had at 
> least 2 MK meetings at Tormach a few years ago, and there were some 
> talks by Michael Haberler and Alex Rossler, among others, that went 
> WAY over my head.  I think some of these talks should be online.
>
> Jon
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Jon Elson]

On 09/12/2018 03:34 PM, Stuart Stevenson wrote:

What is wrong with NML? If it doesn't have some needed process is it not
able to be extended?


The problem, AS I UNDERSTAND IT, is that NML treats the 
entire real time state of the system as one atomic block.  
Works fine on any system with one memory.  So, multi-core 
systems are fine.  But, if you want to extend something that 
uses NML communication across the network, it has to send 
20+K of real time state across the network at the servo 
rate.  That IS a problem.  NML can ONLY send the WHOLE real 
time state.  The feature of zmq (apparently they have now 
converged on one way to spell it) is that it can send ONLY 
the part that a requester asks for.  So, if the remote thing 
only needs a few variables out of the whole real time state, 
ONLY those variables will be sent.


This is my understanding of the major feature of zmq that 
they want to use.  There MAY be a talk by one of the MK 
developers about this that is more authoritative and goes 
into vastly more detail.  We had at least 2 MK meetings at 
Tormach a few years ago, and there were some talks by 
Michael Haberler and Alex Rossler, among others, that went 
WAY over my head.  I think some of these talks should be online.


Jon


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Chris Morley]

Mick


Can you tell us about license of MK HAL work.

AFAIK Linuxcnc is GPL2 for some and GPL2+ for most(?)

Chris M


From: schoone...@gmail.com 
Sent: September 9, 2018 10:27 AM
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

Hi Chris,

As my paws are all over a lot of the work you are mentioning (multicore
in collaboration with Michael Haberler some years back)
and the splitting into HAL and CNC stacks, why not contact me direct to
discuss.

I think there is scope for collaboration which could be to both our projects
benefit, not least from a reduction in maintenance.

The multicore work you mention, primarily adds atomic operations and
other measures
to prevent things like the side effects of multi core, multi cache
operations, where values can be updated
by one cache before another has finished.

Machinekit's HAL generally has hugely diversified from the original
linuxcnc, instantiated components for instance
which can be added or removed at any time, even in a running system.
Because of backwardly compatible measures however, its use is not
visibly greatly different.

The splitting out of HAL, not only allows the stack to be used for non
CNC projects, such as ROS,
but is arranged so that installing machinekit-cnc on top of
machinekit-hal, brings you back to a fully functioning machinekit again.

We are contemplating moving to a 2 package installation and deprecating
the original machinekit repo and packages.

If you were to split out your CNC stack, which has some features we do
not have,
with the correct tweaks it could even sit on our HAL stack and result in
a fully functioning
CNC controller again.

Unfortunately we have not replaced NML with zmq, that would be the 'holy
grail'.
Michael Haberler and Alex's protobuf message headers and zmq
(machinetalk) would probably be the way to go there

It is something we would be interested in discussing, I am sure.

regards

Mick
On 09/09/18 01:27, emc-developers-requ...@lists.sourceforge.net wrote:
> From: Chris Morley
> To: EMC DEV
> Subject: [Emc-developers] Breakout of HAL/ machinekits's HAL
> Message-ID:
>
> 
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I see that machinekit has broken out HAL and cnc (Well and lots of others) 
> into different repositories.
>
> https://github.com/machinekit
[https://avatars1.githubusercontent.com/u/6759549?s=280&v=4]<https://github.com/machinekit>

machinekit · GitHub<https://github.com/machinekit>
github.com
GitHub is where people build software. More than 28 million people use GitHub 
to discover, fork, and contribute to over 85 million projects.


>
> [https://avatars1.githubusercontent.com/u/6759549?s=280&v=4]<https://github.com/machinekit>
>
> machinekit ? GitHub<https://github.com/machinekit>
> github.com
> GitHub is where people build software. More than 28 million people use GitHub 
> to discover, fork, and contribute to over 85 million projects.
>
> It also seems they have updated HAL considerably,
>
> They were working on RT multicore support, anytime instantiation of HAL 
> components
>
> cython support.. probably other stuff - I'm not sure if it includes ARM or 
> FPGA upgrades.
>
>
> I was thinking that maybe linuxcnc should discuss if that is something that 
> would be of interested.
>
>
> pros I see:
>
> -chance to break HAL out of cnc stack
>
> -seemingly an upgrade in capability
>
> -someone else has done a lot of work/testing already
>
> -might allow more cross work of developers between the projects
>
>
> cons:
>
> -surely a lot of work to incorporate (though it does support legacy code, if 
> I understand right)
>
> -lack of experience with concepts/code - will take time to become comfortable
>
> -we'd have to admit they are not bad people:)
>
>
> Ok that last one was meant as fun.
>
>
> There are very smart and hard working people on both projects, it would be 
> nice to benefit both
>
> projects.
>
>
> I have not really looked at the code, nor am qualified to give indepth 
> opinion of the code.
>
> I have watched the video of the multicore idea.
>
> https://www.youtube.com/watch?v=brT0bEkJLSY
>
> There are more videos (including one about the trajectory planner that we now 
> use)
>
>
> Thoughts?
>
>
> Chris M



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Chris Morley]

We are getting off topic here
I was suggesting we separate our HAL and cnc stack with the idea of possibly 
using MK HAL.

NML is part of the cnc stack.
That would be future work, I'd someone wanted to tackle it.

Though just the act of splitting hal from CNC without adopting anything would 
make future work easier.

Chris M


 Original message 
From: Stuart Stevenson 
Date: 2018-09-12 1:36 PM (GMT-08:00)
To: Emc2-developers 
Subject: Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

What is wrong with NML? If it doesn't have some needed process is it not
able to be extended?

On Wed, Sep 12, 2018, 2:52 PM Sebastian Kuzminsky 
wrote:

> On Sat, Sep 8, 2018 at 6:28 PM Chris Morley 
> wrote:
>
> >
> > I'm not sure where they are at with replacing NML, but that is not what I
> > was talking of.
> >
>
> Machinekit has not gotten rid of NML, it's still how you get commands from
> the UIs into Task.
>
> My understanding from a cursory reading of their code is: They have added a
> new program called machinetalk that you can think of as a "network UI", in
> the same sense that our "halui" is a "HAL UI".  Machinetalk takes 0mq
> messages from the network and turns them into NML messages, then sends
> those NML messages to Task just like a "native NML" UI does.
>
> It adds the capability of talking to the motion controller via 0mq, but at
> the cost of an additional IPC hop.
>
> That's how it looks to me but of course I'm no expert, I'd welcome
> corrections from anyone who knows the MK code.
>
> In my opinion it is a mistake to add another layer of communication on
> top.  Far better to clean up the internals to replace NML with 0mq (or
> whatever the correct transport is, I don't know the answer to that
> question).
>
>
> --
> Sebastian Kuzminsky
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Stuart Stevenson]

What is wrong with NML? If it doesn't have some needed process is it not
able to be extended?

On Wed, Sep 12, 2018, 2:52 PM Sebastian Kuzminsky 
wrote:

> On Sat, Sep 8, 2018 at 6:28 PM Chris Morley 
> wrote:
>
> >
> > I'm not sure where they are at with replacing NML, but that is not what I
> > was talking of.
> >
>
> Machinekit has not gotten rid of NML, it's still how you get commands from
> the UIs into Task.
>
> My understanding from a cursory reading of their code is: They have added a
> new program called machinetalk that you can think of as a "network UI", in
> the same sense that our "halui" is a "HAL UI".  Machinetalk takes 0mq
> messages from the network and turns them into NML messages, then sends
> those NML messages to Task just like a "native NML" UI does.
>
> It adds the capability of talking to the motion controller via 0mq, but at
> the cost of an additional IPC hop.
>
> That's how it looks to me but of course I'm no expert, I'd welcome
> corrections from anyone who knows the MK code.
>
> In my opinion it is a mistake to add another layer of communication on
> top.  Far better to clean up the internals to replace NML with 0mq (or
> whatever the correct transport is, I don't know the answer to that
> question).
>
>
> --
> Sebastian Kuzminsky
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Sebastian Kuzminsky]

On Sat, Sep 8, 2018 at 6:28 PM Chris Morley 
wrote:

>
> I'm not sure where they are at with replacing NML, but that is not what I
> was talking of.
>

Machinekit has not gotten rid of NML, it's still how you get commands from
the UIs into Task.

My understanding from a cursory reading of their code is: They have added a
new program called machinetalk that you can think of as a "network UI", in
the same sense that our "halui" is a "HAL UI".  Machinetalk takes 0mq
messages from the network and turns them into NML messages, then sends
those NML messages to Task just like a "native NML" UI does.

It adds the capability of talking to the motion controller via 0mq, but at
the cost of an additional IPC hop.

That's how it looks to me but of course I'm no expert, I'd welcome
corrections from anyone who knows the MK code.

In my opinion it is a mistake to add another layer of communication on
top.  Far better to clean up the internals to replace NML with 0mq (or
whatever the correct transport is, I don't know the answer to that
question).


-- 
Sebastian Kuzminsky

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[bari]

In addition to breaking out  HAL I've considered:

Support for Vulkan (openGL's successor)
https://en.wikipedia.org/wiki/Vulkan_(API)

Replace NML with ZeroMQ
https://en.wikipedia.org/wiki/ZeroMQ

Up until now we have just been keeping RTAI alive and pretty much using
LCNC as is.

-Bari


On 09/11/2018 11:17 PM, Chris Morley wrote:
> So far I have got more response from MK developers then Linuxcnc developers.
>
> Seb, Chris, Andy, Jeff - anyone else?
>
> Opinion?
>
> Dead set against?
>
> Don't care?
>
> Go for it?
>
>
> hey maybe your busy right now - life happens...
>
> But If our core guys don't respond at all - what does that mean?
>
> looking forward to some feedback!
>
>
> Chris M
>
>



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Sebastian Kuzminsky]

I haven't looked at the patch set.  How does it ensure rate-monotonic
scheduling across multiple cores?

On Wed, Sep 12, 2018 at 7:58 AM Moses McKnight  wrote:

> I have not looked at it much, but I have some questions:
>
> What exactly IS it?
> What are the advantages of it?
> Does it require a bunch of extra dependencies?
>
> Moses
>
> On 09/12/2018 04:20 AM, andy pugh wrote:
> > On Wed, 12 Sep 2018 at 05:19, Chris Morley 
> wrote:
> >
> >> Seb, Chris, Andy, Jeff - anyone else?
> >>
> >> Opinion?
> >
> > I don't care, if somebody else is doing the work,
> > I don't really see the advantage for anything that I want to do.
> >
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


-- 
Sebastian Kuzminsky

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Moses McKnight]

I have not looked at it much, but I have some questions:

What exactly IS it?
What are the advantages of it?
Does it require a bunch of extra dependencies?

Moses

On 09/12/2018 04:20 AM, andy pugh wrote:

On Wed, 12 Sep 2018 at 05:19, Chris Morley  wrote:


Seb, Chris, Andy, Jeff - anyone else?

Opinion?


I don't care, if somebody else is doing the work,
I don't really see the advantage for anything that I want to do.




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[andy pugh]

On Wed, 12 Sep 2018 at 05:19, Chris Morley  wrote:

> Seb, Chris, Andy, Jeff - anyone else?
>
> Opinion?

I don't care, if somebody else is doing the work,
I don't really see the advantage for anything that I want to do.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[bari]

I'm interested but have been holding off on any work until the i.mx8
silicon is less buggy.
https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/i.mx-applications-processors/i.mx-8-processors:IMX8-SERIES

It's similar to the  AM335x (2x PRU's, cores for real time and non-real
time, integrated NIC, etc) only with a GPU that has open Linux drivers
for a local GUIat HD res at 30+ fps.

-Bari

On 09/11/2018 11:17 PM, Chris Morley wrote:
> So far I have got more response from MK developers then Linuxcnc developers.
>
> Seb, Chris, Andy, Jeff - anyone else?
>
> Opinion?
>
> Dead set against?
>
> Don't care?
>
> Go for it?
>
>
> hey maybe your busy right now - life happens...
>
> But If our core guys don't respond at all - what does that mean?
>
> looking forward to some feedback!
>
>
> Chris M
>
> 
>
>> [https://avatars1.githubusercontent.com/u/6759549?s=280&v=4]
>>
>> machinekit · GitHub
>> github.com
>> GitHub is where people build software. More than 28 million people use 
>> GitHub to discover, fork, and contribute to over 85 million projects.
>>
>> It also seems they have updated HAL considerably,
>>
>> They were working on RT multicore support, anytime instantiation of HAL 
>> components
>>
>> cython support.. probably other stuff - I'm not sure if it includes ARM or 
>> FPGA upgrades.
>>
>>
>> I was thinking that maybe linuxcnc should discuss if that is something that 
>> would be of interested.
>>
>>
>> pros I see:
>>
>> -chance to break HAL out of cnc stack
>>
>> -seemingly an upgrade in capability
>>
>> -someone else has done a lot of work/testing already
>>
>> -might allow more cross work of developers between the projects
>>
>>
>> cons:
>>
>> -surely a lot of work to incorporate (though it does support legacy code, if 
>> I understand right)
>>
>> -lack of experience with concepts/code - will take time to become comfortable
>>
>> -we'd have to admit they are not bad people :)
>>
>>
>> Ok that last one was meant as fun.
>>
>>
>> There are very smart and hard working people on both projects, it would be 
>> nice to benefit both
>>
>> projects.
>>
>>
>> I have not really looked at the code, nor am qualified to give indepth 
>> opinion of the code.
>>
>> I have watched the video of the multicore idea.
>>
>> https://www.youtube.com/watch?v=brT0bEkJLSY
>>
>> There are more videos (including one about the trajectory planner that we 
>> now use)
>>
>>
>> Thoughts?
>>
>>
>> Chris M
> 【I accidentally sent this from the wrong address, and it was bounced...]
>
> Thanks for raising this topic, Chris, it would be great to see more
> cooperation between the LCNC and MK projects.
>
> I'd also like to bring the more actively maintained EMC application from
> the LCNC project together with the new features in HAL from the MK
> project.  Another way to achieve that is to update LCNC so that EMC can
> be built against an external MK HAL.  That might be an easy way to get
> something started where we could start exploring the problem early.  If
> it were successful, this approach could also be a conservative way to
> give users the option of using MK HAL from mainline LCNC branches while
> still maintaining the current HAL as the default.
>
> [Chris M replied to ask what's new in MK HAL that's not in LCNC HAL, and
> I replied...]
>
> TBH, at some point I lost track of what was added to MK HAL.  I think
> you're right, connecting LCNC EMC with MK HAL would be an all-or-nothing
> affair, since the major restructuring would make it difficult to pick
> out individual features, if they're even separable at this point.  I
> still think that LCNC could be taught to build against MK HAL, though,
> without committing to throwing away current HAL.
>
> Also, IMO, the MK project's splitting HAL and EMC was a good move, since
> HAL is awesome on its own:  I've used it to build dumb things like an
> incubator and autoclave, and smart things like a ros_control hardware
> interface (dig through my GH repos to find these).  Splitting these not
> only dumps a huge amount of build complexity and unnecessary
> dependencies for HAL-only projects, but also exposes HAL as something
> that can gain its own following.
>
> Off the top of my head, here are the MK HAL-specific features I am
> familiar with:
> - `rtapi_msgd` runs alongside `rtapi_app` and relays log messages over
> ZeroMQ
> - "HAL talk" passes signals over ZeroMQ, enabling remote components
> (I've used this extensively in combination with Alexander Roessler's
> QtQuickVCP remote GUI; my incubator and autoclave are public examples)
> - "Instantiable components" allow adding new comp instances on the fly;
> useful when e.g. including a HAL file so you don't have to declare all
> instances at the first `loadrt`
> - Cython bindings to HAL enable replacing traditional `.hal` files with
> Python code; this has been useful to me when writing configuration

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Chris Morley]

So far I have got more response from MK developers then Linuxcnc developers.

Seb, Chris, Andy, Jeff - anyone else?

Opinion?

Dead set against?

Don't care?

Go for it?


hey maybe your busy right now - life happens...

But If our core guys don't respond at all - what does that mean?

looking forward to some feedback!


Chris M



>
> [https://avatars1.githubusercontent.com/u/6759549?s=280&v=4]
>
> machinekit · GitHub
> github.com
> GitHub is where people build software. More than 28 million people use GitHub 
> to discover, fork, and contribute to over 85 million projects.
>
> It also seems they have updated HAL considerably,
>
> They were working on RT multicore support, anytime instantiation of HAL 
> components
>
> cython support.. probably other stuff - I'm not sure if it includes ARM or 
> FPGA upgrades.
>
>
> I was thinking that maybe linuxcnc should discuss if that is something that 
> would be of interested.
>
>
> pros I see:
>
> -chance to break HAL out of cnc stack
>
> -seemingly an upgrade in capability
>
> -someone else has done a lot of work/testing already
>
> -might allow more cross work of developers between the projects
>
>
> cons:
>
> -surely a lot of work to incorporate (though it does support legacy code, if 
> I understand right)
>
> -lack of experience with concepts/code - will take time to become comfortable
>
> -we'd have to admit they are not bad people :)
>
>
> Ok that last one was meant as fun.
>
>
> There are very smart and hard working people on both projects, it would be 
> nice to benefit both
>
> projects.
>
>
> I have not really looked at the code, nor am qualified to give indepth 
> opinion of the code.
>
> I have watched the video of the multicore idea.
>
> https://www.youtube.com/watch?v=brT0bEkJLSY
>
> There are more videos (including one about the trajectory planner that we now 
> use)
>
>
> Thoughts?
>
>
> Chris M

【I accidentally sent this from the wrong address, and it was bounced...]

Thanks for raising this topic, Chris, it would be great to see more
cooperation between the LCNC and MK projects.

I'd also like to bring the more actively maintained EMC application from
the LCNC project together with the new features in HAL from the MK
project.  Another way to achieve that is to update LCNC so that EMC can
be built against an external MK HAL.  That might be an easy way to get
something started where we could start exploring the problem early.  If
it were successful, this approach could also be a conservative way to
give users the option of using MK HAL from mainline LCNC branches while
still maintaining the current HAL as the default.

[Chris M replied to ask what's new in MK HAL that's not in LCNC HAL, and
I replied...]

TBH, at some point I lost track of what was added to MK HAL.  I think
you're right, connecting LCNC EMC with MK HAL would be an all-or-nothing
affair, since the major restructuring would make it difficult to pick
out individual features, if they're even separable at this point.  I
still think that LCNC could be taught to build against MK HAL, though,
without committing to throwing away current HAL.

Also, IMO, the MK project's splitting HAL and EMC was a good move, since
HAL is awesome on its own:  I've used it to build dumb things like an
incubator and autoclave, and smart things like a ros_control hardware
interface (dig through my GH repos to find these).  Splitting these not
only dumps a huge amount of build complexity and unnecessary
dependencies for HAL-only projects, but also exposes HAL as something
that can gain its own following.

Off the top of my head, here are the MK HAL-specific features I am
familiar with:
- `rtapi_msgd` runs alongside `rtapi_app` and relays log messages over
ZeroMQ
- "HAL talk" passes signals over ZeroMQ, enabling remote components
(I've used this extensively in combination with Alexander Roessler's
QtQuickVCP remote GUI; my incubator and autoclave are public examples)
- "Instantiable components" allow adding new comp instances on the fly;
useful when e.g. including a HAL file so you don't have to declare all
instances at the first `loadrt`
- Cython bindings to HAL enable replacing traditional `.hal` files with
Python code; this has been useful to me when writing configurations for
robots that have several variants:  the flexibility of Python greatly
simplifies the HAL config
- Multi-core:  enables running HAL threads with CPU affinity; I recently
found that combined with `rtpart`, a `latency-test` that normally has
40us jitter (on a J1900) has 6us when the HAL thread is given a
dedicated core (this may help solve some chronic EtherCAT "missed
datagram" issues we've been suffering)
- Ring buffer API:  Currently only used by HAL talk AFAIK, a
standardized way of passing blocks of data into/out of HAL in a RT-safe way
- (Not sure how much in HAL and how much in the hm2 firmware, but)
Support for hm2 on Zynq SOCs

...and

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Alexander Rössler]

Steve,

You probably need to get libczmq4 from a third party repo or Debian Stretch. I 
think we had a custom package for Wheezy. But libczmq isn't hard to install 
from source either, so you might give it a shot.
I have to agree with the visionary part of the 2 projects. ROS is starting get 
more traction these days, there are already quite a few companies relying on 
ROS for their products (especially for mobile robots) and I know about several 
who are working on ROS 2.0 integration. Unfortunately ROS 2.0 adopted DDS as 
middleware, Machinetalk evolved at approximately the same time. Altough I do 
not like the proprietary and patented nature of DDS, it might be worth 
considering adopting it when eyeing ROS 2.0 integration as a future goal.
Alex
On Sep 9 2018, at 5:06 pm, Steve Better  wrote:
>
> Hi Schooner,
> Glad you are here!
> I tried to install Machinekit-HAL today. My OS is Ubuntu 16.04. After
> I installed libczmq-dev with apt-get, I just cannot continue
> successfully with the following error:
>
> "Requested 'libczmq > 4.0' but version of libczmq is 3.0.2"
> This is not friendly to attract more people to participate in this project.
> I think the Machinekit project and the LinuxCNC project need to be more
> visionary. Not just in the software aspect, but also in the motion
> control aspect. We need more advanced technologies these days to control
> a manipulator or a mobile robot. OROCOS and ROS is still not very
> successful in practice, and maybe they won't get there ever.
> Well, young people are attracted by mobile internet and AI, the CNC
> technology seems to be old since the EMC emerging in 1990s. We need
> modern visions like OROCOS and ROS to push this project further.
>
>
> On 09/09/2018 06:27 PM, schoone...@gmail.com wrote:
> > Hi Chris,
> >
> > As my paws are all over a lot of the work you are mentioning
> > (multicore in collaboration with Michael Haberler some years back)
> > and the splitting into HAL and CNC stacks, why not contact me direct
> > to discuss.
> >
> > I think there is scope for collaboration which could be to both our
> > projects
> > benefit, not least from a reduction in maintenance.
> >
> > The multicore work you mention, primarily adds atomic operations and
> > other measures
> > to prevent things like the side effects of multi core, multi cache
> > operations, where values can be updated
> > by one cache before another has finished.
> >
> > Machinekit's HAL generally has hugely diversified from the original
> > linuxcnc, instantiated components for instance
> > which can be added or removed at any time, even in a running system.
> > Because of backwardly compatible measures however, its use is not
> > visibly greatly different.
> >
> > The splitting out of HAL, not only allows the stack to be used for non
> > CNC projects, such as ROS,
> > but is arranged so that installing machinekit-cnc on top of
> > machinekit-hal, brings you back to a fully functioning machinekit again.
> >
> > We are contemplating moving to a 2 package installation and
> > deprecating the original machinekit repo and packages.
> >
> > If you were to split out your CNC stack, which has some features we do
> > not have,
> > with the correct tweaks it could even sit on our HAL stack and result
> > in a fully functioning
> > CNC controller again.
> >
> > Unfortunately we have not replaced NML with zmq, that would be the
> > 'holy grail'.
> > Michael Haberler and Alex's protobuf message headers and zmq
> > (machinetalk) would probably be the way to go there
> >
> > It is something we would be interested in discussing, I am sure.
> > regards
> > Mick
> > On 09/09/18 01:27, emc-developers-requ...@lists.sourceforge.net wrote:
> > > From: Chris Morley
> > > To: EMC DEV
> > > Subject: [Emc-developers] Breakout of HAL/ machinekits's HAL
> > > Message-ID:
> > > 
> > >
> > >
> > > Content-Type: text/plain; charset="iso-8859-1"
> > > I see that machinekit has broken out HAL and cnc (Well and lots of
> > > others) into different repositories.
> > >
> > > https://github.com/machinekit
> > > [https://avatars1.githubusercontent.com/u/6759549?s=280&v=4]
> > >
> > > machinekit ? GitHub
> > > github.com
> > > GitHub is where people build software. More than 28 million people
> > > use GitHub to discover, fork, and contribute to over 85 million
> > > projects.
> > >
> > > It also seems they have updated HAL considerably,
> > > They were working on RT multicore support, anytime instantiation of
> > > HAL components
> > >
> > > cython support.. probably other stuff - I'm not sure if it includes
> > > ARM or FPGA upgrades.
> > >
> > >
> > > I was thinking that maybe linuxcnc should discuss if that is
> > > something that would be of interested.
> > >
> > >
> > > pros I see:
> > > -chance to break HAL out of cnc stack
> > > -seemingly an upgrade in capability
> > > -someone else has done a lot of work/testing already
> > > -might allow more cross work o

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[schoone...@gmail.com]

Hi Chris,

I actually approached it from the other direction.
What we required initially was a HAL only stack, it was only later that I
tried to get the CNC stack to build.

The repo's show what is in each stack so I won't detail that.
The process is largely just hard slog through the Makefiles, 
configure.ac etc

to eliminate what is not required for each stack.
Then doing it all again in debian/ to ensure the package is right.

Some things are quite easy and straightforward but there are some overlaps
between the stacks, both for instance use inifiles,
and in each case that overlapping file or lib resides in the HAL stack.

The big problem with packages, is that dpkg will not accept a single 
file duplication

between two packages, even if it is identical.
If package A contains file1 and so does package B, when package B is 
installed dpkg

will refuse to overwrite file1 and the install fails.

Therefore the CNC stack, does not contain a lot of the very files it 
needs to build or run.

I got around this with some trickery in the Jenkins / Docker builder.
It first builds machinekit-hal, then copies a preset list of headers and 
libs to two
directories called 'fakelib' and 'fakeinclude', which whilst in the 
build path are not in the
debian install specs and the contents are just there to facilitate the 
build.


Therefore the CNC stack is completely reliant upon libs which are part 
of the HAL stack

and only does anything when combined with it.

It does however remove a lot of the clutter and hopefully make it easier 
for someone in future
to play with 'drop in' interpreters, replacing NML and many of the 
things it could really do with.


The HAL stack has the gladevcp / pyvcp elements.
Whilst you could argue that they are largely used with Axis say, a 
standalone panel is in fact

very useful when using HAL on its own.

Realistically it matters not, anything that could be of use is in the 
HAL stack and as the CNC stack

can only be used with the HAL stack, it will have access to it too.

regards

Mick

From: Chris Morley

Mick

Thanks for joining in.

I should point out that this idea was formed and brought up me me alone.

There has been no internal discussion in linuxcnc.


That was the point of this - to gauge interest and see if there are immediate 
road blocks,

such as license, philosophy, or complete lack of interest.


I personally don't have the technical programming skill to understand how to do 
this.

If the work is mostly mechanical - I can be helpful.

I would guess that a lot of it is mechanical - particularly since you guys 
support legacy components.


I am hoping some more linuxcnc developers chime in their opinions - good or bad.


Could you summarizer what was required to breakout the cnc stack from the HAL 
stack?


Thank you

Chris M



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Chris Morley]

Mick

Thanks for joining in.

I should point out that this idea was formed and brought up me me alone.

There has been no internal discussion in linuxcnc.


That was the point of this - to gauge interest and see if there are immediate 
road blocks,

such as license, philosophy, or complete lack of interest.


I personally don't have the technical programming skill to understand how to do 
this.

If the work is mostly mechanical - I can be helpful.

I would guess that a lot of it is mechanical - particularly since you guys 
support legacy components.


I am hoping some more linuxcnc developers chime in their opinions - good or bad.


Could you summarizer what was required to breakout the cnc stack from the HAL 
stack?


Thank you

Chris M



From: schoone...@gmail.com 
Sent: September 9, 2018 10:27 AM
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

Hi Chris,

As my paws are all over a lot of the work you are mentioning (multicore
in collaboration with Michael Haberler some years back)
and the splitting into HAL and CNC stacks, why not contact me direct to
discuss.

I think there is scope for collaboration which could be to both our projects
benefit, not least from a reduction in maintenance.

The multicore work you mention, primarily adds atomic operations and
other measures
to prevent things like the side effects of multi core, multi cache
operations, where values can be updated
by one cache before another has finished.

Machinekit's HAL generally has hugely diversified from the original
linuxcnc, instantiated components for instance
which can be added or removed at any time, even in a running system.
Because of backwardly compatible measures however, its use is not
visibly greatly different.

The splitting out of HAL, not only allows the stack to be used for non
CNC projects, such as ROS,
but is arranged so that installing machinekit-cnc on top of
machinekit-hal, brings you back to a fully functioning machinekit again.

We are contemplating moving to a 2 package installation and deprecating
the original machinekit repo and packages.

If you were to split out your CNC stack, which has some features we do
not have,
with the correct tweaks it could even sit on our HAL stack and result in
a fully functioning
CNC controller again.

Unfortunately we have not replaced NML with zmq, that would be the 'holy
grail'.
Michael Haberler and Alex's protobuf message headers and zmq
(machinetalk) would probably be the way to go there

It is something we would be interested in discussing, I am sure.

regards

Mick


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Steve Better]

Thanks your reply. I will have a try, though I am not involved in this with my 
work now. Really hope this project will make a great difference.

From: schoone...@gmail.com 
Sent: Sunday, September 9, 2018 3:47:44 PM
To: Steve Better; EMC developers
Subject: Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

Hi Steve

The main problem is probably your OS
We only support Debian and the package dependencies are based upon what
is in the Debian repos.

Ubuntu tends to just do whatever it likes and wants to 'Ubuntuise'
everything.
There is a reason why the linuxcnc distro image is also Debian based.

The czmq / zmq libraries are a particular problem because they were changed
to a new version that is backwardly incompatible with the old one by the
zmq project.

At great trouble we ported our code to the new API, to enable Machinekit
to run on later
versions of debian where it is the default.

The new libs are now backported by Debian as far back as Jessie thankfully.
The version requirements are to get the correct ones from Debian repos.

If you install Debian Jessie / Stretch (even Buster if you use my repo),
it will just work.

The docs clearly state "You should first have a working Debian installation"
http://www.machinekit.io/docs/getting-started/getting-started-platform/

Hope that clarifies


On 09/09/18 16:06, Steve Better wrote:
> Hi Schooner,
>
> Glad you are here!
>
> I tried to install Machinekit-HAL today. My OS is Ubuntu 16.04. After
> I installed libczmq-dev with apt-get, I just cannot continue
> successfully with the following error:
>
> "Requested 'libczmq > 4.0' but version of libczmq is 3.0.2"
>
> This is not friendly to attract more people to participate in this project.
>
> I think the Machinekit project and the LinuxCNC project need to be more
> visionary. Not just in the software aspect, but also in the motion
> control aspect. We need more advanced technologies these days to control
> a manipulator or a mobile robot. OROCOS and ROS is still not very
> successful in practice, and maybe they won't get there ever.
> Well, young people are attracted by mobile internet and AI, the CNC
> technology seems to be old since the EMC emerging in 1990s. We need
> modern visions like OROCOS and ROS to push this project further.
>
>
> On 09/09/2018 06:27 PM, schoone...@gmail.com wrote:
>> Hi Chris,
>>
>> As my paws are all over a lot of the work you are mentioning
>> (multicore in collaboration with Michael Haberler some years back)
>> and the splitting into HAL and CNC stacks, why not contact me direct
>> to discuss.
>>
>> I think there is scope for collaboration which could be to both our
>> projects
>> benefit, not least from a reduction in maintenance.
>>
>> The multicore work you mention, primarily adds atomic operations and
>> other measures
>> to prevent things like the side effects of multi core, multi cache
>> operations, where values can be updated
>> by one cache before another has finished.
>>
>> Machinekit's HAL generally has hugely diversified from the original
>> linuxcnc, instantiated components for instance
>> which can be added or removed at any time, even in a running system.
>> Because of backwardly compatible measures however, its use is not
>> visibly greatly different.
>>
>> The splitting out of HAL, not only allows the stack to be used for non
>> CNC projects, such as ROS,
>> but is arranged so that installing machinekit-cnc on top of
>> machinekit-hal, brings you back to a fully functioning machinekit again.
>>
>> We are contemplating moving to a 2 package installation and
>> deprecating the original machinekit repo and packages.
>>
>> If you were to split out your CNC stack, which has some features we do
>> not have,
>> with the correct tweaks it could even sit on our HAL stack and result
>> in a fully functioning
>> CNC controller again.
>>
>> Unfortunately we have not replaced NML with zmq, that would be the
>> 'holy grail'.
>> Michael Haberler and Alex's protobuf message headers and zmq
>> (machinetalk) would probably be the way to go there
>>
>> It is something we would be interested in discussing, I am sure.
>>
>> regards
>>
>> Mick
>> On 09/09/18 01:27, emc-developers-requ...@lists.sourceforge.net wrote:
>>> From: Chris Morley
>>> To: EMC DEV
>>> Subject: [Emc-developers] Breakout of HAL/ machinekits's HAL
>>> Message-ID:
>>>  
>>> 
>>>
>>>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
&g

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[schoone...@gmail.com]

Hi Steve

The main problem is probably your OS
We only support Debian and the package dependencies are based upon what 
is in the Debian repos.


Ubuntu tends to just do whatever it likes and wants to 'Ubuntuise' 
everything.

There is a reason why the linuxcnc distro image is also Debian based.

The czmq / zmq libraries are a particular problem because they were changed
to a new version that is backwardly incompatible with the old one by the 
zmq project.


At great trouble we ported our code to the new API, to enable Machinekit 
to run on later

versions of debian where it is the default.

The new libs are now backported by Debian as far back as Jessie thankfully.
The version requirements are to get the correct ones from Debian repos.

If you install Debian Jessie / Stretch (even Buster if you use my repo), 
it will just work.


The docs clearly state "You should first have a working Debian installation"
http://www.machinekit.io/docs/getting-started/getting-started-platform/

Hope that clarifies


On 09/09/18 16:06, Steve Better wrote:

Hi Schooner,

Glad you are here!

I tried to install Machinekit-HAL today. My OS is Ubuntu 16.04. After
I installed libczmq-dev with apt-get, I just cannot continue
successfully with the following error:

"Requested 'libczmq > 4.0' but version of libczmq is 3.0.2"

This is not friendly to attract more people to participate in this project.

I think the Machinekit project and the LinuxCNC project need to be more
visionary. Not just in the software aspect, but also in the motion
control aspect. We need more advanced technologies these days to control
a manipulator or a mobile robot. OROCOS and ROS is still not very
successful in practice, and maybe they won't get there ever.
Well, young people are attracted by mobile internet and AI, the CNC
technology seems to be old since the EMC emerging in 1990s. We need
modern visions like OROCOS and ROS to push this project further.


On 09/09/2018 06:27 PM, schoone...@gmail.com wrote:

Hi Chris,

As my paws are all over a lot of the work you are mentioning
(multicore in collaboration with Michael Haberler some years back)
and the splitting into HAL and CNC stacks, why not contact me direct
to discuss.

I think there is scope for collaboration which could be to both our
projects
benefit, not least from a reduction in maintenance.

The multicore work you mention, primarily adds atomic operations and
other measures
to prevent things like the side effects of multi core, multi cache
operations, where values can be updated
by one cache before another has finished.

Machinekit's HAL generally has hugely diversified from the original
linuxcnc, instantiated components for instance
which can be added or removed at any time, even in a running system.
Because of backwardly compatible measures however, its use is not
visibly greatly different.

The splitting out of HAL, not only allows the stack to be used for non
CNC projects, such as ROS,
but is arranged so that installing machinekit-cnc on top of
machinekit-hal, brings you back to a fully functioning machinekit again.

We are contemplating moving to a 2 package installation and
deprecating the original machinekit repo and packages.

If you were to split out your CNC stack, which has some features we do
not have,
with the correct tweaks it could even sit on our HAL stack and result
in a fully functioning
CNC controller again.

Unfortunately we have not replaced NML with zmq, that would be the
'holy grail'.
Michael Haberler and Alex's protobuf message headers and zmq
(machinetalk) would probably be the way to go there

It is something we would be interested in discussing, I am sure.

regards

Mick
On 09/09/18 01:27, emc-developers-requ...@lists.sourceforge.net wrote:

From: Chris Morley
To: EMC DEV
Subject: [Emc-developers] Breakout of HAL/ machinekits's HAL
Message-ID:
 



Content-Type: text/plain; charset="iso-8859-1"

I see that machinekit has broken out HAL and cnc (Well and lots of
others) into different repositories.

https://github.com/machinekit

[https://avatars1.githubusercontent.com/u/6759549?s=280&v=4]


machinekit ? GitHub
github.com
GitHub is where people build software. More than 28 million people
use GitHub to discover, fork, and contribute to over 85 million
projects.

It also seems they have updated HAL considerably,

They were working on RT multicore support, anytime instantiation of
HAL components

cython support.. probably other stuff - I'm not sure if it includes
ARM or FPGA upgrades.


I was thinking that maybe linuxcnc should discuss if that is
something that would be of interested.


pros I see:

-chance to break HAL out of cnc stack

-seemingly an upgrade in capability

-someone else has done a lot of work/testing already

-might allow more cross work of developers between the projects


cons:

-surely a lot of work to incorporate (though it does support legacy
code, if I understand right)

-lac

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Jon Elson]

On 09/09/2018 12:23 AM, Chris Morley wrote:


The possibility of moving our realtime system with the modern trends seems 
important to at least

consider.



Well, the ability to interconnect multiple instances of 
LinuxCNC seems like it could be useful in a lot of special 
applications, especially things like work cells where 
robot-like devices load and unload parts to traditional 
machines.


There are people doing really oddball things with LinuxCNC.  
One I know of is a silkscreen printer in Brazil.  There is a 
YouTube video of it, and the guy is loading the material by 
hand.  That looked like something that could be automated, 
and might benefit from this.


Jon


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Steve Better]

Hi Schooner,

   Glad you are here!

   I tried to install Machinekit-HAL today. My OS is Ubuntu 16.04. After 
I installed libczmq-dev with apt-get, I just cannot continue 
successfully with the following error:

"Requested 'libczmq > 4.0' but version of libczmq is 3.0.2"

This is not friendly to attract more people to participate in this project.

I think the Machinekit project and the LinuxCNC project need to be more 
visionary. Not just in the software aspect, but also in the motion 
control aspect. We need more advanced technologies these days to control 
a manipulator or a mobile robot. OROCOS and ROS is still not very 
successful in practice, and maybe they won't get there ever.
Well, young people are attracted by mobile internet and AI, the CNC 
technology seems to be old since the EMC emerging in 1990s. We need 
modern visions like OROCOS and ROS to push this project further.


On 09/09/2018 06:27 PM, schoone...@gmail.com wrote:
> Hi Chris,
>
> As my paws are all over a lot of the work you are mentioning 
> (multicore in collaboration with Michael Haberler some years back)
> and the splitting into HAL and CNC stacks, why not contact me direct 
> to discuss.
>
> I think there is scope for collaboration which could be to both our 
> projects
> benefit, not least from a reduction in maintenance.
>
> The multicore work you mention, primarily adds atomic operations and 
> other measures
> to prevent things like the side effects of multi core, multi cache 
> operations, where values can be updated
> by one cache before another has finished.
>
> Machinekit's HAL generally has hugely diversified from the original 
> linuxcnc, instantiated components for instance
> which can be added or removed at any time, even in a running system.
> Because of backwardly compatible measures however, its use is not 
> visibly greatly different.
>
> The splitting out of HAL, not only allows the stack to be used for non 
> CNC projects, such as ROS,
> but is arranged so that installing machinekit-cnc on top of 
> machinekit-hal, brings you back to a fully functioning machinekit again.
>
> We are contemplating moving to a 2 package installation and 
> deprecating the original machinekit repo and packages.
>
> If you were to split out your CNC stack, which has some features we do 
> not have,
> with the correct tweaks it could even sit on our HAL stack and result 
> in a fully functioning
> CNC controller again.
>
> Unfortunately we have not replaced NML with zmq, that would be the 
> 'holy grail'.
> Michael Haberler and Alex's protobuf message headers and zmq 
> (machinetalk) would probably be the way to go there
>
> It is something we would be interested in discussing, I am sure.
>
> regards
>
> Mick
> On 09/09/18 01:27, emc-developers-requ...@lists.sourceforge.net wrote:
>> From: Chris Morley
>> To: EMC DEV
>> Subject: [Emc-developers] Breakout of HAL/ machinekits's HAL
>> Message-ID:
>> 
>> 
>>  
>>
>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> I see that machinekit has broken out HAL and cnc (Well and lots of 
>> others) into different repositories.
>>
>> https://github.com/machinekit
>>
>> [https://avatars1.githubusercontent.com/u/6759549?s=280&v=4]
>>  
>>
>>
>> machinekit ? GitHub
>> github.com
>> GitHub is where people build software. More than 28 million people 
>> use GitHub to discover, fork, and contribute to over 85 million 
>> projects.
>>
>> It also seems they have updated HAL considerably,
>>
>> They were working on RT multicore support, anytime instantiation of 
>> HAL components
>>
>> cython support.. probably other stuff - I'm not sure if it includes 
>> ARM or FPGA upgrades.
>>
>>
>> I was thinking that maybe linuxcnc should discuss if that is 
>> something that would be of interested.
>>
>>
>> pros I see:
>>
>> -chance to break HAL out of cnc stack
>>
>> -seemingly an upgrade in capability
>>
>> -someone else has done a lot of work/testing already
>>
>> -might allow more cross work of developers between the projects
>>
>>
>> cons:
>>
>> -surely a lot of work to incorporate (though it does support legacy 
>> code, if I understand right)
>>
>> -lack of experience with concepts/code - will take time to become 
>> comfortable
>>
>> -we'd have to admit they are not bad people:)
>>
>>
>> Ok that last one was meant as fun.
>>
>>
>> There are very smart and hard working people on both projects, it 
>> would be nice to benefit both
>>
>> projects.
>>
>>
>> I have not really looked at the code, nor am qualified to give 
>> indepth opinion of the code.
>>
>> I have watched the video of the multicore idea.
>>
>> https://www.youtube.com/watch?v=brT0bEkJLSY
>>
>> There are more videos (including one about the trajectory planner 
>> that we now use)
>>
>>
>> Thoughts?
>>
>>
>> Chris M
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lis

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[schoone...@gmail.com]

Hi Chris,

As my paws are all over a lot of the work you are mentioning (multicore 
in collaboration with Michael Haberler some years back)
and the splitting into HAL and CNC stacks, why not contact me direct to 
discuss.


I think there is scope for collaboration which could be to both our projects
benefit, not least from a reduction in maintenance.

The multicore work you mention, primarily adds atomic operations and 
other measures
to prevent things like the side effects of multi core, multi cache 
operations, where values can be updated

by one cache before another has finished.

Machinekit's HAL generally has hugely diversified from the original 
linuxcnc, instantiated components for instance

which can be added or removed at any time, even in a running system.
Because of backwardly compatible measures however, its use is not 
visibly greatly different.


The splitting out of HAL, not only allows the stack to be used for non 
CNC projects, such as ROS,
but is arranged so that installing machinekit-cnc on top of 
machinekit-hal, brings you back to a fully functioning machinekit again.


We are contemplating moving to a 2 package installation and deprecating 
the original machinekit repo and packages.


If you were to split out your CNC stack, which has some features we do 
not have,
with the correct tweaks it could even sit on our HAL stack and result in 
a fully functioning

CNC controller again.

Unfortunately we have not replaced NML with zmq, that would be the 'holy 
grail'.
Michael Haberler and Alex's protobuf message headers and zmq 
(machinetalk) would probably be the way to go there


It is something we would be interested in discussing, I am sure.

regards

Mick
On 09/09/18 01:27, emc-developers-requ...@lists.sourceforge.net wrote:

From: Chris Morley
To: EMC DEV
Subject: [Emc-developers] Breakout of HAL/ machinekits's HAL
Message-ID:



Content-Type: text/plain; charset="iso-8859-1"

I see that machinekit has broken out HAL and cnc (Well and lots of others) into 
different repositories.

https://github.com/machinekit

[https://avatars1.githubusercontent.com/u/6759549?s=280&v=4]

machinekit ? GitHub
github.com
GitHub is where people build software. More than 28 million people use GitHub 
to discover, fork, and contribute to over 85 million projects.

It also seems they have updated HAL considerably,

They were working on RT multicore support, anytime instantiation of HAL 
components

cython support.. probably other stuff - I'm not sure if it includes ARM or FPGA 
upgrades.


I was thinking that maybe linuxcnc should discuss if that is something that 
would be of interested.


pros I see:

-chance to break HAL out of cnc stack

-seemingly an upgrade in capability

-someone else has done a lot of work/testing already

-might allow more cross work of developers between the projects


cons:

-surely a lot of work to incorporate (though it does support legacy code, if I 
understand right)

-lack of experience with concepts/code - will take time to become comfortable

-we'd have to admit they are not bad people:)


Ok that last one was meant as fun.


There are very smart and hard working people on both projects, it would be nice 
to benefit both

projects.


I have not really looked at the code, nor am qualified to give indepth opinion 
of the code.

I have watched the video of the multicore idea.

https://www.youtube.com/watch?v=brT0bEkJLSY

There are more videos (including one about the trajectory planner that we now 
use)


Thoughts?


Chris M




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[John Morris]

On 09/09/2018 03:05 AM, Chris Morley wrote:

I see that machinekit has broken out HAL and cnc (Well and lots of others) into 
different repositories.

https://github.com/machinekit

[https://avatars1.githubusercontent.com/u/6759549?s=280&v=4]

machinekit · GitHub
github.com
GitHub is where people build software. More than 28 million people use GitHub 
to discover, fork, and contribute to over 85 million projects.

It also seems they have updated HAL considerably,

They were working on RT multicore support, anytime instantiation of HAL 
components

cython support.. probably other stuff - I'm not sure if it includes ARM or FPGA 
upgrades.


I was thinking that maybe linuxcnc should discuss if that is something that 
would be of interested.


pros I see:

-chance to break HAL out of cnc stack

-seemingly an upgrade in capability

-someone else has done a lot of work/testing already

-might allow more cross work of developers between the projects


cons:

-surely a lot of work to incorporate (though it does support legacy code, if I 
understand right)

-lack of experience with concepts/code - will take time to become comfortable

-we'd have to admit they are not bad people :)


Ok that last one was meant as fun.


There are very smart and hard working people on both projects, it would be nice 
to benefit both

projects.


I have not really looked at the code, nor am qualified to give indepth opinion 
of the code.

I have watched the video of the multicore idea.

https://www.youtube.com/watch?v=brT0bEkJLSY

There are more videos (including one about the trajectory planner that we now 
use)


Thoughts?


Chris M


【I accidentally sent this from the wrong address, and it was bounced...]

Thanks for raising this topic, Chris, it would be great to see more 
cooperation between the LCNC and MK projects.


I'd also like to bring the more actively maintained EMC application from 
the LCNC project together with the new features in HAL from the MK 
project.  Another way to achieve that is to update LCNC so that EMC can 
be built against an external MK HAL.  That might be an easy way to get 
something started where we could start exploring the problem early.  If 
it were successful, this approach could also be a conservative way to 
give users the option of using MK HAL from mainline LCNC branches while 
still maintaining the current HAL as the default.


[Chris M replied to ask what's new in MK HAL that's not in LCNC HAL, and 
I replied...]


TBH, at some point I lost track of what was added to MK HAL.  I think 
you're right, connecting LCNC EMC with MK HAL would be an all-or-nothing 
affair, since the major restructuring would make it difficult to pick 
out individual features, if they're even separable at this point.  I 
still think that LCNC could be taught to build against MK HAL, though, 
without committing to throwing away current HAL.


Also, IMO, the MK project's splitting HAL and EMC was a good move, since 
HAL is awesome on its own:  I've used it to build dumb things like an 
incubator and autoclave, and smart things like a ros_control hardware 
interface (dig through my GH repos to find these).  Splitting these not 
only dumps a huge amount of build complexity and unnecessary 
dependencies for HAL-only projects, but also exposes HAL as something 
that can gain its own following.


Off the top of my head, here are the MK HAL-specific features I am 
familiar with:
- `rtapi_msgd` runs alongside `rtapi_app` and relays log messages over 
ZeroMQ
- "HAL talk" passes signals over ZeroMQ, enabling remote components 
(I've used this extensively in combination with Alexander Roessler's 
QtQuickVCP remote GUI; my incubator and autoclave are public examples)
- "Instantiable components" allow adding new comp instances on the fly; 
useful when e.g. including a HAL file so you don't have to declare all 
instances at the first `loadrt`
- Cython bindings to HAL enable replacing traditional `.hal` files with 
Python code; this has been useful to me when writing configurations for 
robots that have several variants:  the flexibility of Python greatly 
simplifies the HAL config
- Multi-core:  enables running HAL threads with CPU affinity; I recently 
found that combined with `rtpart`, a `latency-test` that normally has 
40us jitter (on a J1900) has 6us when the HAL thread is given a 
dedicated core (this may help solve some chronic EtherCAT "missed 
datagram" issues we've been suffering)
- Ring buffer API:  Currently only used by HAL talk AFAIK, a 
standardized way of passing blocks of data into/out of HAL in a RT-safe way
- (Not sure how much in HAL and how much in the hm2 firmware, but) 
Support for hm2 on Zynq SOCs


...and probably other things I'm unaware of or have forgotten.  I have 
never seen documentation for these things, but I may not have looked in 
the right place.


NML is part of EMC, and connects the UIs (status, command, error) and 
motion/io to ta

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Gene Heskett]

On Saturday 08 September 2018 23:54:33 Jon Elson wrote:

> On 09/08/2018 07:27 PM, Chris Morley wrote:
> > Jon
> >
> > I'm not sure where they are at with replacing NML, but that is not
> > what I was talking of.
> >
> > They have split the cnc stack from the HAL stack
> >
> > HAL is what I am talking of, which would include the realtime code I
> > suppose.
>
> Anybody, NOW, can download LinuxCNC and just USE the hal
> components of their choice, without ever using the G-code
> interpreter or trajectory planner.  It has always been that
> way, although NOT well publicized.
>
> But, yes, the LinuxCNC version of hal (I'm pretty sure) can
> only run on a single core.  I can see some real issues to
> solve when different components are running on different
> cores concurrently. That could get quite complicated.
> Running different real time threads on different cores ought
> to be safe to do,  but I kind of doubt our rtapi can handle
> that right now.
>
> Jon

I don't believe the kernel I'm using on the pi is either rtapi, or 
limited to a single core , at least not with an obvious isolcpu's kernel 
argument, just a fully preemptable version. A uname -a says:

4.4.4-rt9-v7+ #7 SMP PREEMPT RT Mon Mar 7 14:53:11 UTC 2016 armv7l

I have it and its matching library pinned to prevent apt from upgrading 
it and spoiling my playground. But that has not prevented apt from 
keeping the rest of that jessie based install uptodate with jessie.

So lets play what if in the wishfull thinking category:

As for using more cores, in particular it might be desirable to setup, 
using "threads" as I am now, such that it might be possible to have each 
thread run on its own core, or have on a 4 core cpu, 4 named threads 
with 3 of them running at a slower rate as I am presently doing with a 
200 hz thread rate for the slower stuff like the jog dials which I 
cannot turn at a 1 millisecond step rate anyway. Encoders are 100 ppt, 
quadrature, so a full turn is 400 edges to count, works well in a 200hz 
thread. Works well even if that thread is slowed to 100hz, but the pi is 
loafing in either case.

For the same reason, this bed wear stuff doesn't need up to update the X 
offset values at a kilohertz rate since the fastest z speed is 45 ipm 
due to that Z motor being the slow one I took off the g0704's Z drive.

I think having the ability to setup a 3rd and 4th thread, running at even 
slower rates might allow the stuff for x to run in a 2nd 200 hz thread 
and Z running in its own 200 hz thread could be usefull in unloading the 
1 millisecond main thread.

The pi is not being pushed to an overheat condition by what I am doing 
now, as the main 1khz thread seems to use only about 40% of that 
millisecond now according to htop. Latency jitter is excellent.

My 2 cents. I see exciting times ahead in any event.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Chris Morley]

Jon


The point about MK breaking out HAL is that makes it easier for us to 
incorporate it,

not that it makes it easier for people to do HAL-only projects.

Breaking out HAL for us (surely) in the long run would be helpful.

Linuxcnc and MK's strengths come a lot from being modular and this is a step in 
that direction.

But that is the bonus part.


The possibility of moving our realtime system with the modern trends seems 
important to at least

consider.


Chris M


From: Jon Elson 
Sent: September 9, 2018 3:54 AM
To: EMC developers
Subject: Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

On 09/08/2018 07:27 PM, Chris Morley wrote:
> Jon
>
> I'm not sure where they are at with replacing NML, but that is not what I was 
> talking of.
>
> They have split the cnc stack from the HAL stack
>
> HAL is what I am talking of, which would include the realtime code I suppose.
>
Anybody, NOW, can download LinuxCNC and just USE the hal
components of their choice, without ever using the G-code
interpreter or trajectory planner.  It has always been that
way, although NOT well publicized.

But, yes, the LinuxCNC version of hal (I'm pretty sure) can
only run on a single core.  I can see some real issues to
solve when different components are running on different
cores concurrently. That could get quite complicated.
Running different real time threads on different cores ought
to be safe to do,  but I kind of doubt our rtapi can handle
that right now.

Jon




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Jon Elson]

On 09/08/2018 07:27 PM, Chris Morley wrote:

Jon

I'm not sure where they are at with replacing NML, but that is not what I was 
talking of.

They have split the cnc stack from the HAL stack

HAL is what I am talking of, which would include the realtime code I suppose.

Anybody, NOW, can download LinuxCNC and just USE the hal 
components of their choice, without ever using the G-code 
interpreter or trajectory planner.  It has always been that 
way, although NOT well publicized.


But, yes, the LinuxCNC version of hal (I'm pretty sure) can 
only run on a single core.  I can see some real issues to 
solve when different components are running on different 
cores concurrently. That could get quite complicated.  
Running different real time threads on different cores ought 
to be safe to do,  but I kind of doubt our rtapi can handle 
that right now.


Jon


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Chris Morley]

Jon

I'm not sure where they are at with replacing NML, but that is not what I was 
talking of.

They have split the cnc stack from the HAL stack

HAL is what I am talking of, which would include the realtime code I suppose.



(Talking above my pay grade but to summarize)

Because of their needs for ARM support they wanted to utilize multiple cores 
for realtime.

Our HAL system works very well with single core or isolating realtime to a 
single core.

Apparently it breaks in subtle, hard to find ways on multicore.

They rewrote it with multicore in mind.

It also still supports legacy (linuxcnc) components.

I do believe it means 32bit is not supported anymore though..


Chris M


From: Jon Elson 
Sent: September 8, 2018 11:44 PM
To: EMC developers
Subject: Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

On 09/08/2018 02:05 PM, Chris Morley wrote:
>>
>
> There are very smart and hard working people on both
> projects, it would be nice to benefit both
>
> projects.
>
>
>
I _THINK_ that the biggest thing they have done is to
replace NML with 0mq.  While I don't know the details at
all, NML ships the entire real-time context with every
message, incurring a LOT of overhead.  With 0mq, all
requesters tell it what structure they need, and then ONLY
the requested structure is sent.
This has some impact within one node, but has HUGE impact
when the system has some HAL components on different nodes,
over the network.

This replacement of NML was VERY complicated, as almost
everything in LinuxCNC is interfaced through it.

Jon



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Jon Elson]

On 09/08/2018 02:05 PM, Chris Morley wrote:




There are very smart and hard working people on both 
projects, it would be nice to benefit both


projects.



I _THINK_ that the biggest thing they have done is to 
replace NML with 0mq.  While I don't know the details at 
all, NML ships the entire real-time context with every 
message, incurring a LOT of overhead.  With 0mq, all 
requesters tell it what structure they need, and then ONLY 
the requested structure is sent.
This has some impact within one node, but has HUGE impact 
when the system has some HAL components on different nodes, 
over the network.


This replacement of NML was VERY complicated, as almost 
everything in LinuxCNC is interfaced through it.


Jon




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[Gene Heskett]

On Saturday 08 September 2018 15:05:48 Chris Morley wrote:

> I see that machinekit has broken out HAL and cnc (Well and lots of
> others) into different repositories.
>
> https://github.com/machinekit
>
> [https://avatars1.githubusercontent.com/u/6759549?s=280&v=4]ithub.com/machinekit>
>
> machinekit · GitHub
> github.com
> GitHub is where people build software. More than 28 million people use
> GitHub to discover, fork, and contribute to over 85 million projects.
>
> It also seems they have updated HAL considerably,
>
> They were working on RT multicore support, anytime instantiation of
> HAL components
>
> cython support.. probably other stuff - I'm not sure if it includes
> ARM or FPGA upgrades.
>
>
> I was thinking that maybe linuxcnc should discuss if that is something
> that would be of interested.
>
>
> pros I see:
>
> -chance to break HAL out of cnc stack
>
> -seemingly an upgrade in capability
>
> -someone else has done a lot of work/testing already
>
> -might allow more cross work of developers between the projects
>
>
> cons:
>
> -surely a lot of work to incorporate (though it does support legacy
> code, if I understand right)
>
> -lack of experience with concepts/code - will take time to become
> comfortable
>
> -we'd have to admit they are not bad people :)
>
>
> Ok that last one was meant as fun.
>
>
> There are very smart and hard working people on both projects, it
> would be nice to benefit both
>
> projects.
>
>
> I have not really looked at the code, nor am qualified to give indepth
> opinion of the code.
>
> I have watched the video of the multicore idea.
>
> https://www.youtube.com/watch?v=brT0bEkJLSY
>
> There are more videos (including one about the trajectory planner that
> we now use)
>
>
> Thoughts?
>
>
> Chris M

Tom's accent is pretty thick to this old Iowa farm kid, and his audio a/d 
is being overdriven and is clipping the audio pretty bad, so I'm missing 
some details while watching the video, but I rather like the basic 
outline as it would also appear to make a realtime kernel much less 
important (or I don't fully understand due to the accent). In any event, 
it seems like its worth investigating. Particularly in view of the fact 
that 8 core arm64's are already shipping.

Twould be most encouraging if a 40 to 50 MHz spi interface has been 
developed to interface to the likes of a mesa 7i90.  Or a fast parport 
has been done on the gpio available on these credit card sized things.

No negative vibes from here IOW.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers