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

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

[Chris Morley]

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

[Emc-developers] xemc not supported from 2.7 ... but can run on 2.7/2.8?? why not?

[theman whosoldtheworld]

Fron long time I search for time to study better exchange signal from NML
to gui for make my own GUI on c++ QT5 or QML java  I have some
instructions from Sebastian Kuminzky (very thanks) but at leas I have no
time to study and develop these things. Recentely I have some time and i
study xemc.cc file  I saw that it would be simple enough (ie it would
not be a big job) to convert it to a qtharead and send signals to it to
make it work smoothly. Obviously you should "clean" all the graphics and
keep only sending and receiving signals to NML.

so a big question before to start ... there are some reason that i not see
because is not a good things to use xemc gui as start of these works?

Why these? simply I Have not time to study python ... and I use Lcnc to run
different type of machine so interface is every time different  QT5 in
these is a very big help.

in my linuxcnc-dev folder not found : emcglb.hh, emccfg.hh, nml_io.hh only
 These is change in to other library or it is disappear at all? If not
use X11/../...h library because use signal/slot of QT gui, emcglb.hh,
emccfg.hh, nml_io.hh are they still necessary?

I see now: emccfg.hh/emcglb.hh is a global library (so can change it to an
other if necessary), nml_io.hh define messages structures these file is
changed into wath? someone can help me?

VERY THANKS AT ALL
regards
bkt

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

Re: [Emc-developers] unwanted x offset, and cannot be touched off to zero

[Gene Heskett]

On Friday 07 September 2018 20:31:27 Gene Heskett wrote:

The offset I may have found. I was using position-cmd to drive x,
maybe s/b motor-pos-cmd. Now homes to 0.000
I've put a limit3 between Z and lincurve.in wih a maxa of 3 & a 
smooth-step of 10 and its nice to feel x stepping in and out according
to the z position. It plays with the +- sign in front of the X dro 
though.

Now to see if its possible to use an X HOME_OFFSET.
HOME and HOME_OFFSET could stand an improvement in the Docs.

IMO HOME_OFFSET should represent the switches location from the
centerline of the lathe which s/b around +5.5 theoretically although in 
this case the toolpost would need to be re-adjusted to reach the maximum 
of 5.5" radius as when set to that, and driven inward, the slot in the 
carriage becomes exposed behind the toolpost holder, allowing wayward 
swarf access to the ball screw. That whole area of the carriage has been 
sealed up to protect the ball screw from air hose driven flying swarf 
although I did design the the nut holder with swarf wipers, something I 
should redo on TLM.

With the offcentered design of the replacement compound/toolpost holder, 
I can adjust the real position of a cutting tool by at least 3". Since 
its a lathe, and touch-offs are used to match the real diameter to the 
DRO, thats a grand "mox nix" anyway.

But not being able to setup the points and corrections with the 
hal_show_config is still a major PITA. Being able to setp those values 
of the lincurve would let me move along, using a setp to adjust it for 
zero on a dial as it moves along my slightly crooked, therefore rotating 
slowly, calibration rod, is the pita as the only way to do it is edit 
the hal file, and re-run lcnc going thru all the homing etc to get back 
to the position being worked on.

To add fuzz to it, changing the z motion direction appears to cause about 
a .0026" offset in x according to the dial. Tests that I've done don't 
appear to be related to the possibility of my home made way wipers 
lifting the carriage, but I suppose its possible. The other, and highly 
probable cause would be the vway groove of the carriage is worn bell 
shaped. Fixing that now would be a major teardown. But I'd do it if I 
could confirm that IS the problem. :(

With this puppy being close to 70 yo, most anything is possible.

The command line in the hal-show-config doesn't apply a setp, and the 
failure disables/freezes it until restarted again. Which is making the 
application of the bed wear settings very very very time consuming.

Is this one of the effects of a pi's (only 1GB) low main memory? Or has a 
bug found its way into master?

Thanks to any and all commentators.

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