Re: [Emc-users] Rock64 pre-orders on Banggood.

[Erik Christiansen]

On 26.03.19 07:10, Alan Condit wrote:
> Erik,
> 
> Banggood is only one of the places selling the rock64. Look at Pine64’s
> website and google “rock64 stretch”
> There is an Armbian Stretch image available for download.
> 
> Ala

Many thanks, Alan. That price is unbelievable.
I guess the "4K60P HDR" is HDMI, so compatible with the new monitor
bought for the Udoo X86. (The acronyms came out at a slower pace in the
old days - either that or I'm slowing down. What's the saying? "If age
is catching up, walk faster.)

It'll be my first ARM board. Have been looking for an excuse for a
while.

Erik


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

Re: [Emc-users] For those who do not read the forum:

[Jon Elson]

On 03/26/2019 05:43 PM, Gene Heskett wrote:

On Tuesday 26 March 2019 11:06:16 andy pugh wrote:


Something that you might have missed is a bunch of new GUIs that are
being developed:

https://youtu.be/mb0nZEqhsS8
The ATC screen is super-fancy:
https://youtu.be/6Xxjk1UnpnI

Then Kurt and Jon are doing things with QT:
https://qtpyvcp.kcjengr.com/showcase/index.html

Something Fanuc-inspired:
https://forum.linuxcnc.org/41-guis/36224-my-qtpyvcp-vcp

BrendaEM designed a nice looking GUI, but I am not sure if it got any
further than graphical and useability design:
https://youtu.be/lRZ_AMuayoM

Now that is an improvement. Looks nice too!


The first links look way too "busy" to me.  The BrendaEM 
looks pretty nice, but did it ever get past mock-up state?  
Doesn't look like that from the comments in the Youtu.be video.


Jon


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

Re: [Emc-users] switch debounce experiment

[Erik Christiansen]

On 26.03.19 10:38, Chris Albertson wrote:
> A very basic question, unlike the hards ones being discussed here but,
> important I think.
> 
> How are people handling switch debouncing on home and limit switches?
> 
> Always in the past, I have treated the microswitch is a SPST device that is
> either open or closed.
> The common terminal is pulled up to Vcc voltage and when the switch closes
> it connects to ground.
> 
> But all my switches have three terminals.

OK, it's about 40 years ago now, but when I did hardware debouncing, it
was with a pair of cross-coupled 2-input NAND gates making a flip-flop,
a pull-up on each switch-connected input, and switch common to ground.
NO and NC went to the two FF inputs. That gave two debouncers per 7400
(74HC00 these days). That _will_ give latency in the nanosecond range,
and very sharp risetimes. N.B. If driving more than a few inches of
wire, buffer the output with a spare gate, otherwise line reflections
can flip the flop, as feedback is from the output. A tri-state buffer
was best practice on a line in the metre range.

It could also be done with two inverters, cross-coupled with resistors,
which then serve as the pull-ups. That gives 3 debouncers per package,
with no extra discrete components. (Or two with an output buffer each.)

Since then it's been software debouncing for me, including a specified
algorithm for the first generation of 2.048 Mb/s PCM trunk 30 channel
pair gain systems introducing digital telephony to Australia. Since it
was debouncing 10 PPS 60:40 rotary dial pulses, mark:space distortion
was an issue - though far less critical than a homing stop. Heck, that
was back in '81 - '82. Those trailblazing systems will be decommissioned
as superseded long ago now. The first used an 8085, the single-chip,
single voltage, version of the 3-chip 8080, yet handled the signalling
protocol with only 62.5 uS per channel on average.

> I did some experiments using my
> digital oscilloscope.   The normal
> method causes a long series of "bounces" that continue for some number of
> milliseconds the new method
> makes a near-perfect single pulse square wave.  I see oscillation for only
> about 10 nanoseconds when the switch
> closes and no bounce at all when it opens.
> 
> Common terminal goes to the computer and uses a 10K pull-up.   NC terminal
> goes to Vcc and NO to ground.  I place a 0.1 uF cap from common to ground.
>I notice the cap can "ring" and go below ground.   So I place a small
> diode from common to the ground to protect the uP from negative volts.
>   All the passive components are soldered directly to the switch terminals.

Yes, the fall time is short, but with a high switch current for nS, The
effect on contact life is uncertain, though it could melt the
micro-roughness peak which makes first contact. That then probably smoothes
out, and later contacts are over a surface area which happily absorbs
the nanojoules of energy. A switch replacement after a few years
would not be a great burden, if needed, but a 100 ohm discharge resistor
would allay any concerns, I figure.

> Yes, I know a switch can be de-bounced in software but this introduces
> latency as the software has to keep checking the state of the switch.
>  Reduced latency very much increases the accuracy of the microswitch.
> 
> If you have a digital scope you can try rig up some experiments.   Again
> the only "trick" is to use all three terminals on the switch.

Software can also respond on the first bounce, but your capacitor acts
as a noise filter on the input - without introducing delays, when
shorted by the switch. Can't do that in software. Time is the price of a
virtual solution.

> Yes, I foresaw all kinds of problems but as it turns out in practice I get
> nanosecond level latencies.
> 
> Perhaps everyone already is doing this and I was the last to think of it.
> The switch still actually bounce but in this case, bouncing does not cause
> a change of state.

No, the slow rise time, due to the pull-up timeconstant sees to that -
without introducing any latency.

Yes, it is too easy to forget the hardware path these days.

Erik


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

Re: [Emc-users] switch debounce experiment

[Gene Heskett]

On Tuesday 26 March 2019 14:20:58 Bruce Layne wrote:

> On 3/26/19 1:38 PM, Chris Albertson wrote:
> > Yes, I know a switch can be de-bounced in software but this
> > introduces latency as the software has to keep checking the state of
> > the switch. Reduced latency very much increases the accuracy of the
> > microswitch.
>
> Like Steve Ciarcia said in Byte magazine, circa 1978, my favorite
> programming language is SOLDER.  I usually prefer the hardware
> solution as the fastest and often most reliable solution.  However,
> rather than increased responsive time when debouncing a switch in
> software, an intelligent debounce algorithm can greatly reduce the
> response time. For a home or limit switch, you don't really care when
> the switch contacts become stable in the new state.  What you want to
> know is the moment the stable condition changes.  I'd debounce that
> limit switch activation by acting on the initial state change and then
> set a timer to ignore any subsequent bounces.  I definitely wouldn't
> wait for switch contacts to stabilize before acting on the new state. 
> That could be the difference between a machine crashing or not.
>
> Of course, hardware can implement the same debounce strategy, but it's
> easier to wire a bare switch and debounce it in software... even for
> an old hardware guy like me.
>
Unforch, our debounce doesn't work like that, for that, see man 9 edge, 
but it may trip on noise if your grounding layout is poor.
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] switch debounce experiment

[Gene Heskett]

On Tuesday 26 March 2019 13:38:32 Chris Albertson wrote:

> A very basic question, unlike the hards ones being discussed here but,
> important I think.
>
> How are people handling switch debouncing on home and limit switches?
>
We have a debounce module you can put in series with the swtches output. 
very handy where there is a fast base thread, but not so usefull with 
the much slower servo thread. It function is to block a switch status 
change until so many of the threads have passed. With a 1 millisecond 
servo thread, the switch has generally well settled, but in a 30 
microsecnd base thread, it might take a noisy switch 3 or more thread 
cycles to have 3 alike.

> Always in the past, I have treated the microswitch is a SPST device
> that is either open or closed.
> The common terminal is pulled up to Vcc voltage and when the switch
> closes it connects to ground.
>
> But all my switches have three terminals.  I did some experiments
> using my digital oscilloscope.   The normal
> method causes a long series of "bounces" that continue for some number
> of milliseconds the new method
> makes a near-perfect single pulse square wave.  I see oscillation for
> only about 10 nanoseconds when the switch
> closes and no bounce at all when it opens.
>
Chuckle, you need a slower scope. t=rc is generally greater than 10 
nanosecs anyway. The t is self-explanatory, the r is the pullup, and the 
c is a combo of the cable capacitance and its propagation delay at its 
surge impedance.  All of that is generally faster than LCNC anyway so 
its moot 99% of the time, delayed by one thread cycle the remaining 1% 
of the time. Might make .0003" diff to the machine at the speeds the 
machine can move in 1 millisecond.
> Common terminal goes to the computer and uses a 10K pull-up.   NC
> terminal goes to Vcc and NO to ground.  I place a 0.1 uF cap from
> common to ground. I notice the cap can "ring" and go below ground.  
> So I place a small diode from common to the ground to protect the uP
> from negative volts. All the passive components are soldered directly
> to the switch terminals.
>
> Yes, I know a switch can be de-bounced in software but this introduces
> latency as the software has to keep checking the state of the switch.
>  Reduced latency very much increases the accuracy of the microswitch.
>
> If you have a digital scope you can try rig up some experiments.  
> Again the only "trick" is to use all three terminals on the switch.
>
> Yes, I foresaw all kinds of problems but as it turns out in practice I
> get nanosecond level latencies.
>
> Perhaps everyone already is doing this and I was the last to think of
> it. The switch still actually bounce but in this case, bouncing does
> not cause a change of state.


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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] For those who do not read the forum:

[Gene Heskett]

On Tuesday 26 March 2019 11:06:16 andy pugh wrote:

> Something that you might have missed is a bunch of new GUIs that are
> being developed:
>
> https://youtu.be/mb0nZEqhsS8
> The ATC screen is super-fancy:
> https://youtu.be/6Xxjk1UnpnI
>
> Then Kurt and Jon are doing things with QT:
> https://qtpyvcp.kcjengr.com/showcase/index.html
>
> Something Fanuc-inspired:
> https://forum.linuxcnc.org/41-guis/36224-my-qtpyvcp-vcp
>
> BrendaEM designed a nice looking GUI, but I am not sure if it got any
> further than graphical and useability design:
> https://youtu.be/lRZ_AMuayoM

Now that is an improvement. Looks nice too!

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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Fusion 360

[Thaddeus Waldner]

The limitation on a free or non-edu OnShape account is that you can’t make 
private documents.
There’s also an iOS/Android app available for it. This works great as a mobile 
reference to your drawings. The iPad with Apple Pencil and OnShape is currently 
my favorite way to draw stuff.

It’s a shame they don’t do CAM.

Thaddeus Waldner
Newdale School
Elkton, SD 57026


From: Gene Heskett 
Sent: Tuesday, March 26, 2019 12:16 AM
To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Fusion 360

On Monday 25 March 2019 21:51:03 Chris Albertson wrote:

> A lot of people like OnShape.
> https://www.onshape.com

Impressive, much moreso than watching freecad video's. Looks like it has
canned constructs and built in error checking. Neat even.

That looks like I might be able to learn to use it. But even the trimmed
down version at $1500 is beyond my SS based budget. Sigh. So I muddle
along, writing my own gcode, using LCNC's backplot as a previewer. I
didn't check the trial duration as I know I'd not be able to produce
more than a screw in the usual 30 days. Which is likely more than I'd be
able to do with any of the others because it actually does look easier
to learn.

> It is web-based 3D CAD that has features comparable to Fusion 360 and
> SolidWorks. I've seen it used to
> make some complex parts. Right now I'm looking at some one's 1/4
> scale working model if a Mars Rover
> It has 6 powered wheels, four that steer. That is about as complex a
> project as most hobby user would attempt.
>
> THey hac=ve several teras, the free version is available to everyone
> and then you get some more features if you pay a license fee.
>
> It will even run on and computer that was a web browser, even a
> Chromebook (which is Google's brand of Linux on a low end Notebook)
>
> If you can't use Windows 10 or Mac OS and you want a good, high end
> free 3D CAD system look at it.

I didn't see any reference to a limited free version. Ah, the educator
version! But I can't truthfully qualify, I'm not an active educator,
nor do I have the minimum education of 12 years. 8+GED is all I can
claim. Old farts like me? Nope. No "slot" that fits a long time
graduate of the University of Hard Knocks. Yup, I do have a diploma from
that school hanging on the bedroom wall. It shares wall space with my
C.E.T certification.

> On Sat, Mar 23, 2019 at 4:07 PM Greg Bernard 
wrote:
> > Basically, it says if you download their 2019 Draftsight
> > version, you will no longer be able to use any older
> > version, and all free versions will cease to work after
> > 12/31/2019.
> > They are not clear on what happens with Mac and Linux
> > versions, but it doesn't sound good.

No it doesn't.

> > I was all excited to hear about another CAD package that
> > works on Linux, but now I'm not sure I should waste time
> > learning about it.
> >
> > It is indeed unclear. I would be unhappy about losing free access to
> > Draftsight but would grudgingly cough up the $99. If they
> > discontinued the Linux version I would be be devastated, though.
> > If you do have Autocad experience, you'll have no problem whatsoever
> > with Draftsight as it's practically a clone of Autocad. If that's
> > the case, you've got nothing to lose downloading it now and hoping
> > you can keep it.
> >
> > On Sat, Mar 23, 2019 at 4:44 PM Jon Elson 
wrote:
> > > On 03/23/2019 11:52 AM, Greg Bernard wrote:
> > > > Now that I'm retired and no longer have access to Autocad I'm
> > > > using Draftsight for all of my 2d work which is practically
> > > > indistinguishable from Autocad with the advantage of being free
> > > > and running on Linux.
> > >
> > > Wow, you need to read this web page :
> >
> > https://www.3ds.com/products-services/draftsight-cad-software/downlo
> >ad-draftsight//
> >
> > > Basically, it says if you download their 2019 Draftsight
> > > version, you will no longer be able to use any older
> > > version, and all free versions will cease to work after
> > > 12/31/2019.
> > > They are not clear on what happens with Mac and Linux
> > > versions, but it doesn't sound good.
> > >
> > > I was all excited to hear about another CAD package that
> > > works on Linux, but now I'm not sure I should waste time
> > > learning about it.
> > >
> > > Any comments are welcome.
> > >
> > > Jon

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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

Re: [Emc-users] Rock64 pre-orders on Banggood.

[Gene Heskett]

On Tuesday 26 March 2019 10:55:45 Peter C. Wallace wrote:

> On Tue, 26 Mar 2019, Gene Heskett wrote:
> > Date: Tue, 26 Mar 2019 08:03:17 -0400
> > From: Gene Heskett 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: emc-users@lists.sourceforge.net
> > Subject: Re: [Emc-users] Rock64 pre-orders on Banggood.
> >
> > On Tuesday 26 March 2019 07:19:19 andy pugh wrote:
> >> On Tue, 26 Mar 2019 at 06:35, Chris Albertson
> >
> >  wrote:
> >>> The loops do need data.  They need a target position or a target
> >>> velocity. These targets are sent across an SPI (or I2C or Ethernet
> >>> or,..) interface from a Linux machine.  But you MUST de-couple the
> >>> timing.   Linux can not be feeding one target number at a time.
> >>
> >> Drawing the boundary becomes more difficult when you add in
> >> probing, threading and spindle-synchronised motion.
> >
> > And it appears I may have to put a C1G rev4 back in service just for
> > limit and home switches, the 7i76 takes too long to recognize a
> > closed home switch.
>
> I dont think this is true, motion only samples the home switches at
> the servo thread rate so there is no speed advantage of sampling the
> inputs at the base thread.
>
> How wide is the home switch pulse at 120 degrees/sec?
> less than 1 ms seems unlikely...
>
I see it about half the time in a halmeter at 360/sec degrees as it flies 
on by without a stutter. At 120/sec it stops on top of the cam, running 
slow I'd guess 4 degrees wide. but haven't actually measured it.

Could be narrower. Its working now, which is the bottom line.

My next experiment is to see if some glue covered elastomer is sufficient 
to stop from smashing these switches flatter than a Coors can at a 
usable homing speed.  Theres far under a 0.5mm of motion between 
touching the switch and smashing it where I want to put the switches. So 
we'll have to play with home_search_vel's for all the linear axis's to 
make sure it can stop in time.

But now I'm stuck, waiting on Amazon to get me some wiring loom big 
enough to take the 2 additional 3/16" cables to the switches. What came 
with the mill just don't have room.  I just this morning replaced the 
2nd cable chain because there was no room left in them. I used 
everything putting the mister air line in the one across the top of the 
gantry. 2 less motor cables it it. No room for home or limit cables so 
change it for a wider chain too.  Some day. I hope to actually carve 
something on this...

Thanks Peter.

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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Thread timings: (Was: Rock64 pre-orders on Banggood.)

[Gene Heskett]

On Tuesday 26 March 2019 09:01:29 andy pugh wrote:

> On Tue, 26 Mar 2019 at 12:37, Gene Heskett  
wrote:
> > > This is why I was suggesting a 180 degree home switch target
> > > wheel.
> >
> > I must have got stoned and missed that. ;-) 'splain plz..
>
> You didn't miss it, you even discussed it:
>
> "Ahh, white turn one way, black the other. But once the boundary is
> encountered, do a fixed edge sequence so it always hits the stop from
> the same direction"

Duh...  So I did.  Need a hot wet washrag for the egg on my face...

And I didn't follow thru, using a normal roller tipped switch instead 
because I had it, and the cam was the corner of a plastic box laying on 
the table saw.  Didn't have the opto stuff on hand. 

Observing it now, the initial stop when its doing 120 degrees a sec, is 
right on the peak of the cam, probably a good 2 degrees past the switch 
click, then it creeps backwards till it opens, then a quick growp and 
its at the ini files stated offset showing 0. in the dro. Seems 
repeatable, so I quit screwing with it.  I do need to fiddle with that 
offset though, so that a lathe tool caught in the 3 jaw is pointing 
straight up. Then a precise grind is a piece of cake. :)

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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] switch debounce experiment

[Bruce Layne]

On 3/26/19 1:38 PM, Chris Albertson wrote:
> Yes, I know a switch can be de-bounced in software but this introduces
> latency as the software has to keep checking the state of the switch.
>  Reduced latency very much increases the accuracy of the microswitch.

Like Steve Ciarcia said in Byte magazine, circa 1978, my favorite
programming language is SOLDER.  I usually prefer the hardware solution
as the fastest and often most reliable solution.  However, rather than
increased responsive time when debouncing a switch in software, an
intelligent debounce algorithm can greatly reduce the response time. 
For a home or limit switch, you don't really care when the switch
contacts become stable in the new state.  What you want to know is the
moment the stable condition changes.  I'd debounce that limit switch
activation by acting on the initial state change and then set a timer to
ignore any subsequent bounces.  I definitely wouldn't wait for switch
contacts to stabilize before acting on the new state.  That could be the
difference between a machine crashing or not.

Of course, hardware can implement the same debounce strategy, but it's
easier to wire a bare switch and debounce it in software... even for an
old hardware guy like me.






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

[Emc-users] switch debounce experiment

[Chris Albertson]

A very basic question, unlike the hards ones being discussed here but,
important I think.

How are people handling switch debouncing on home and limit switches?

Always in the past, I have treated the microswitch is a SPST device that is
either open or closed.
The common terminal is pulled up to Vcc voltage and when the switch closes
it connects to ground.

But all my switches have three terminals.  I did some experiments using my
digital oscilloscope.   The normal
method causes a long series of "bounces" that continue for some number of
milliseconds the new method
makes a near-perfect single pulse square wave.  I see oscillation for only
about 10 nanoseconds when the switch
closes and no bounce at all when it opens.

Common terminal goes to the computer and uses a 10K pull-up.   NC terminal
goes to Vcc and NO to ground.  I place a 0.1 uF cap from common to ground.
   I notice the cap can "ring" and go below ground.   So I place a small
diode from common to the ground to protect the uP from negative volts.
  All the passive components are soldered directly to the switch terminals.

Yes, I know a switch can be de-bounced in software but this introduces
latency as the software has to keep checking the state of the switch.
 Reduced latency very much increases the accuracy of the microswitch.

If you have a digital scope you can try rig up some experiments.   Again
the only "trick" is to use all three terminals on the switch.

Yes, I foresaw all kinds of problems but as it turns out in practice I get
nanosecond level latencies.

Perhaps everyone already is doing this and I was the last to think of it.
The switch still actually bounce but in this case, bouncing does not cause
a change of state.
-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] Rock64 pre-orders on Banggood.

[Chris Albertson]

You don't need to do the motion planning on the uP, just the execution of
the plan.   Planning means deciding what point to go to and at what speed
and what acceleration.   Execution of the plan means updating the setpoints
of a few servo loops.

Planning is best done on the largest computer your budget for cost, space
and power can afford.  But the execution is best done on a computer that
can handle "hard" real-time.

Planning is also best done in a process that "knows" the most about the

On Tue, Mar 26, 2019 at 4:19 AM andy pugh  wrote:

> On Tue, 26 Mar 2019 at 03:41, Chris Albertson 
> wrote:
>
> > Yes, you have to patch Kernels.  I think this is the #1 weakness of
> > Linux CNC.   It would be good to eliminate the need for a real-time
> Kernal.
> >How?   Move the real-time parts to hardware such as the uP, PRU or
> Mesa
> > FPGA.
>
> The Mesa FPGA cards need updating in realtime. I think that the same
> is true of the PRU.
>
> There are existing controllers that run everything in a microprocessor
> (GRBL for example)
>
> If you just want a graphical front-end to feed G-code to a uP that
> does all the motion planning then I don't think that LinuxCNC is a
> good starting place.
> Better to start with GRBL and write a thin layer GUI on top of that to
> open files and display positions.
>
> --
> 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-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] ConFusion 360

[Chris Albertson]

The problem is not with Linux itself but with the way the programs are
distributed.   Almost all software depends on a LOT of external libraries
and these, in turn, depend on others.   And worse they depend on some
version of the library. Linux distributions come with many of these
libraries pre-installed.  If I compile a program in my Ubuntu 18.04 system
then the binary executable I have depends on the set of libraries found on
Ubuntu 18.04 systems.

In the "old days" of Linux on one would distribute a binary executable
because it would depend on a specif set of library software.They would
distribute source code.But today Linux is used by less sophisticated
users would don't know how to follow instal instruction that reads "Edit
the Makefile as required then Make, Make install"  If your users can follow
instructions like that then your Linux software is universally compatible,
possibly even into non-Linux systems.  But today the majority of users
can't do that.

The problem is how to distribute software to non-technical Linux users.
This CAN BE DONE but mostly it is not done because the developer has to
work harder and itis easier for him to simply compile several executables
and make them all available.

Apple solved this problem on Macs by distributing software in the form of
an "App Bundle"  Every last file needed to run an app is inside the bundle
and there is usually nothing to install other then copying the bundle to
the hard drive.   Linux ca do this too.e call these "app images"  and
some developers use the "app image".

The other way I see this done is to distribute the app as a Docker Image.
This is really the same idea.  The image contains ALL the files needed.

IN the past if I got some UNIX-like software it was NEVER an executable
binary and I would have to build it for SunOS, Or SiliconGraphis or Linux
but it would actually run on any system, even non-Linux.

If you want you Linux based software to run on any machine simply
distribute inside a container that includes the dependencies.  Some
containers hold even the entire operating system, some contain just a few
unusual libraries and the smallest container would be the executable binary.




On Tue, Mar 26, 2019 at 4:29 AM andy pugh  wrote:

> On Tue, 26 Mar 2019 at 04:11, Rafael Skodlar  wrote:
>
> > OK, so if you are a software developer, I respect your trade. I assume
> > you are making money. Great. If you ported that program to Linux then
> > perhaps you could sell to different crowd and brag about it also.
>
> He is the author of SheetCAM.
> He _does_ have a version for Linux.
>
> https://www.sheetcam.com/downloads (See "SheetCAM TNG For Linux")
>
> So I would tend to assume that  knows what he is talking about.
>
> I used to be able to run games written for the Motorola 68k on an
> Intel Mac (probably with an intermediate conversion to PowerPC).
> Linux deinitely does not have that level of binary compatibility. Will
> the Ubuntu LinuxCNC binaries run on Debian, even?
>
> --
> 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-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] Rock64 pre-orders on Banggood.

[Peter C. Wallace]

On Tue, 26 Mar 2019, andy pugh wrote:


Date: Tue, 26 Mar 2019 11:19:19 +
From: andy pugh 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Rock64 pre-orders on Banggood.

On Tue, 26 Mar 2019 at 06:35, Chris Albertson  wrote:



The loops do need data.  They need a target position or a target velocity.
These targets are sent across an SPI (or I2C or Ethernet or,..) interface
from a Linux machine.  But you MUST de-couple the timing.   Linux can not
be feeding one target number at a time.



Drawing the boundary becomes more difficult when you add in probing,
threading and spindle-synchronised motion.



Yes, if you have distributed controllers doing real time you have basically 
re-invented a buffered system like Mach3 with all its limitations.


Theres a reason most of these buffered systems have issues with threading, 
rigid tapping, probing, torch height control, adaptive feed, (or whatever new 
clever thing you want to do in real time)


Basically you substitute a complex buffered system model for the simple single 
locus of control that LinuxCNC has with HAL. Now its possible to move HAL to a 
remote device but for all of HALs features you need loadable modules and OS 
resources, (and realtime or course) so you basically end up running LinuxCNC 
on the remote device anyway...



Peter Wallace
Mesa Electronics



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

[Emc-users] For those who do not read the forum:

[andy pugh]

Something that you might have missed is a bunch of new GUIs that are
being developed:

https://youtu.be/mb0nZEqhsS8
The ATC screen is super-fancy:
https://youtu.be/6Xxjk1UnpnI

Then Kurt and Jon are doing things with QT:
https://qtpyvcp.kcjengr.com/showcase/index.html

Something Fanuc-inspired:
https://forum.linuxcnc.org/41-guis/36224-my-qtpyvcp-vcp

BrendaEM designed a nice looking GUI, but I am not sure if it got any
further than graphical and useability design:
https://youtu.be/lRZ_AMuayoM

-- 
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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rock64 pre-orders on Banggood.

[Peter C. Wallace]

On Tue, 26 Mar 2019, Gene Heskett wrote:


Date: Tue, 26 Mar 2019 08:03:17 -0400
From: Gene Heskett 
Reply-To: "Enhanced Machine Controller (EMC)"

To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Rock64 pre-orders on Banggood.

On Tuesday 26 March 2019 07:19:19 andy pugh wrote:


On Tue, 26 Mar 2019 at 06:35, Chris Albertson

 wrote:

The loops do need data.  They need a target position or a target
velocity. These targets are sent across an SPI (or I2C or Ethernet
or,..) interface from a Linux machine.  But you MUST de-couple the
timing.   Linux can not be feeding one target number at a time.


Drawing the boundary becomes more difficult when you add in probing,
threading and spindle-synchronised motion.

And it appears I may have to put a C1G rev4 back in service just for
limit and home switches, the 7i76 takes too long to recognize a closed
home switch.



I dont think this is true, motion only samples the home switches at the servo 
thread rate so there is no speed advantage of sampling the inputs at the base 
thread.


How wide is the home switch pulse at 120 degrees/sec?
less than 1 ms seems unlikely...





I've not more than though of it, but have wondered if it would be
possible to set up a 10 kilohertz base thread that accessed the parport,
while leaving the 1 kilohertz stuff on the 7i76? I just had to slow the
home_search to 120 degrees a sec to get a rotary's home switch to be
recognized, otherwise it just sails on by. By putting the home/limit
switches on the parport, limiting me to 5 switches which is not enough,
would any response time be gained?

I got the home switches I ordered yesterday, but I can readily see that
they are going to have to be mounted on a springy material, seriously
complicating the switch mount, otherwise they'll be smashed flatter than
a coors can before the machine can get stopped. Or I use search_vels no
faster than cutting vels if even that fast. This machine, with its puny
motors, can still make x-y moves slightly above 200 ipm. I will probably
set the homes as I intended, but it means I'll have to use very
leasurely homeing moves. After switch closure, I'll have about 10 thou
to get stopped before a hard smash stop. To rig more clearance means
some elastomeric on the frame to cushion the button push. That will
imply glue to hold it in place failures...  Not what I intended when I
ordered 100 of this switch for <$3.

I also rxed the bigger cable chains, and got one of them installed before
dinner last night, one to go. Otherwise no room left for switch wiring.

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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-users] Rock64 pre-orders on Banggood.

[Alan Condit]

Erik,

Banggood is only one of the places selling the rock64. Look at Pine64’s
website and google “rock64 stretch”
There is an Armbian Stretch image available for download.

Ala

From: Erik Christiansen 
> To: emc-users@lists.sourceforge.net
> Cc:
> Bcc:
> Date: Tue, 26 Mar 2019 17:21:30 +1100
> Subject: Re: [Emc-users] Rock64 pre-orders on Banggood.
> On 26.03.19 02:08, andy pugh wrote:
> > Most of them seem to need a kernel specifically patched for the
> > hardware, though. So you need (for example) the Udoo-patched kernel
> > then need to apply Xenomia / RTAI / Preempt-RT on top of that.
> > And often the fit is not exact.
>
> Thought I'd order one, until seeing I'd have to run Android, as there's
> explicitly no support for GNU Linux. (My Udoo X86 has, after a rather
> short life, started checkerboarding the video after a few minutes
> running, then crashing. I wonder if it's due to cheap supply bypass
> caps, i.e. not low ESR?. That'd be fixable when I have time.)
>
> Looks like I'll have to keep looking for a cheap video streamer for
> viewing news clips and some old Sci-Fi episodes I have on a hard drive -
> still unviewed, sadly.
>
> > One kernel to suit every SBC? I don't think that is even possible
> without RT.
>
> When porting Linux to a new board, you're up for writing or borrowing
> drivers for the BSP (Board Support Package) (= HAL in other lingo). I've
> only started on that once, and never carried it through to completion.
>
> Erik
>
>

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

Re: [Emc-users] Thread timings: (Was: Rock64 pre-orders on Banggood.)

[andy pugh]

On Tue, 26 Mar 2019 at 12:37, Gene Heskett  wrote:

> > This is why I was suggesting a 180 degree home switch target wheel.
>
> I must have got stoned and missed that. ;-) 'splain plz..

You didn't miss it, you even discussed it:

"Ahh, white turn one way, black the other. But once the boundary is
encountered, do a fixed edge sequence so it always hits the stop from
the same direction"


-- 
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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Mister/Coolant

[andy pugh]

On Tue, 26 Mar 2019 at 11:00, Roland Jollivet  wrote:

> I find that the smell of some coolants make me feel really nauseous,

I like that smell. It reminds me of happy times with my dad in his workshop.

-- 
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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Thread timings: (Was: Rock64 pre-orders on Banggood.)

[Gene Heskett]

On Tuesday 26 March 2019 08:08:02 andy pugh wrote:

> On Tue, 26 Mar 2019 at 12:05, Gene Heskett  
wrote:
> > I've not more than thought of it, but have wondered if it would be
> > possible to set up a 10 kilohertz base thread that accessed the
> > parport, while leaving the 1 kilohertz stuff on the 7i76?
>
> Yes, but it wouldn't necessarily help. LinuxCNC only checks the home
> switch state in the servo thread.
>
Oh, no help there then. That leaves a triangular accel pattern to the 
search_vel. Unforch I could see things being demolished if it guessed 
where it is wrong as it starts the home switch search move.

> This is why I was suggesting a 180 degree home switch target wheel.

I must have got stoned and missed that. ;-) 'splain plz..

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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Thread timings: (Was: Rock64 pre-orders on Banggood.)

[andy pugh]

On Tue, 26 Mar 2019 at 12:05, Gene Heskett  wrote:

> I've not more than though of it, but have wondered if it would be
> possible to set up a 10 kilohertz base thread that accessed the parport,
> while leaving the 1 kilohertz stuff on the 7i76?

Yes, but it wouldn't necessarily help. LinuxCNC only checks the home
switch state in the servo thread.

This is why I was suggesting a 180 degree home switch target wheel.

-- 
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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Mister/Coolant

[Peter Blodow]

I had a similar problem, coughing away as soon as I had worked on my PC 
for some time. Moving my laser printers to the adjacent room solved the 
problem. Besides, getting up and moving a few steps now and then in 
order to fetch papers from the printer next room helped my back pains, too.

Peter

Am 25.03.2019 um 20:47 schrieb Marshland Engineering:

Just spent 2-3 years wondering why I kept getting sick so often and sometimes
coughing for 3-4 hours a day. (I'm a non smoker and otherwise healthy) I spent
most of the weekend machining aly blocks with coolant splashing all over the
place on a knee mill and on Sunday night felt really sick. Finally the penny
dropped, it is the coolant in the air I was breathing in that was the cause.
The realization only came as I was doing 2 x 8 hour days machining which
exacerbated the problem.

I was booked in to see a immunologist next week for the coughing but I think I
found the source of the problem. There could be 2 issues, the composition of
the soluble oil or bacteria growth in the sump. The sump is a separate 60
litre tank and is clean but I'm getting a bacteria test done on it now.

This the reading that struck a cord. See here

https://www.osha.gov/SLTC/metalworkingfluids/metalworkingfluids_manual.html#e

Look at Respiratory Diseases.

I may not be the only one this has happened to.

Cheers Wallace.



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





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

Re: [Emc-users] Rock64 pre-orders on Banggood.

[Gene Heskett]

On Tuesday 26 March 2019 07:19:19 andy pugh wrote:

> On Tue, 26 Mar 2019 at 06:35, Chris Albertson 
 wrote:
> > The loops do need data.  They need a target position or a target
> > velocity. These targets are sent across an SPI (or I2C or Ethernet
> > or,..) interface from a Linux machine.  But you MUST de-couple the
> > timing.   Linux can not be feeding one target number at a time.
>
> Drawing the boundary becomes more difficult when you add in probing,
> threading and spindle-synchronised motion.
And it appears I may have to put a C1G rev4 back in service just for 
limit and home switches, the 7i76 takes too long to recognize a closed 
home switch.

I've not more than though of it, but have wondered if it would be 
possible to set up a 10 kilohertz base thread that accessed the parport, 
while leaving the 1 kilohertz stuff on the 7i76? I just had to slow the 
home_search to 120 degrees a sec to get a rotary's home switch to be 
recognized, otherwise it just sails on by. By putting the home/limit 
switches on the parport, limiting me to 5 switches which is not enough, 
would any response time be gained?

I got the home switches I ordered yesterday, but I can readily see that 
they are going to have to be mounted on a springy material, seriously 
complicating the switch mount, otherwise they'll be smashed flatter than 
a coors can before the machine can get stopped. Or I use search_vels no 
faster than cutting vels if even that fast. This machine, with its puny 
motors, can still make x-y moves slightly above 200 ipm. I will probably 
set the homes as I intended, but it means I'll have to use very 
leasurely homeing moves. After switch closure, I'll have about 10 thou 
to get stopped before a hard smash stop. To rig more clearance means 
some elastomeric on the frame to cushion the button push. That will 
imply glue to hold it in place failures...  Not what I intended when I 
ordered 100 of this switch for <$3.

I also rxed the bigger cable chains, and got one of them installed before 
dinner last night, one to go. Otherwise no room left for switch wiring.

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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] ConFusion 360

[andy pugh]

On Tue, 26 Mar 2019 at 04:11, Rafael Skodlar  wrote:

> OK, so if you are a software developer, I respect your trade. I assume
> you are making money. Great. If you ported that program to Linux then
> perhaps you could sell to different crowd and brag about it also.

He is the author of SheetCAM.
He _does_ have a version for Linux.

https://www.sheetcam.com/downloads (See "SheetCAM TNG For Linux")

So I would tend to assume that  knows what he is talking about.

I used to be able to run games written for the Motorola 68k on an
Intel Mac (probably with an intermediate conversion to PowerPC).
Linux deinitely does not have that level of binary compatibility. Will
the Ubuntu LinuxCNC binaries run on Debian, even?

-- 
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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rock64 pre-orders on Banggood.

[andy pugh]

On Tue, 26 Mar 2019 at 06:35, Chris Albertson  wrote:

> The loops do need data.  They need a target position or a target velocity.
> These targets are sent across an SPI (or I2C or Ethernet or,..) interface
> from a Linux machine.  But you MUST de-couple the timing.   Linux can not
> be feeding one target number at a time.

Drawing the boundary becomes more difficult when you add in probing,
threading and spindle-synchronised motion.

-- 
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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rock64 pre-orders on Banggood.

[andy pugh]

On Tue, 26 Mar 2019 at 03:41, Chris Albertson  wrote:

> Yes, you have to patch Kernels.  I think this is the #1 weakness of
> Linux CNC.   It would be good to eliminate the need for a real-time Kernal.
>How?   Move the real-time parts to hardware such as the uP, PRU or Mesa
> FPGA.

The Mesa FPGA cards need updating in realtime. I think that the same
is true of the PRU.

There are existing controllers that run everything in a microprocessor
(GRBL for example)

If you just want a graphical front-end to feed G-code to a uP that
does all the motion planning then I don't think that LinuxCNC is a
good starting place.
Better to start with GRBL and write a thin layer GUI on top of that to
open files and display positions.

-- 
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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Mister/Coolant

[Roland Jollivet]

> I tried a few coolants for flood.  First was Tri-Cool, which
> constantly grew stuff and was a real problem.  Then, I got a
> gallon of Encool-9 concentrate, which was recommended by
> them for the mix of materials and work I do.  It can sit for
> MONTHS before it shows growth very slightly.
> I was very impressed with it.  This is from Engineered
> Lubricants, a local outfit in Missouri, US.
> I kind of doubt it is available in NZ, though.  I don't get
> any detectable coolant in the air when I use this stuff in
> flood mode.
>
> Jon



I find that the smell of some coolants make me feel really nauseous, and
the best I found in Ecocool green from Fuch's. It's also translucent so I
see what I'm doing.

However, after seeing a video of 'titans of CNC' he spoke of the Blaser
coolant. I'm still trying to source some locally.

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

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

Re: [Emc-users] ConFusion 360

[Chris Albertson]

On Mon, Mar 25, 2019 at 9:11 PM Rafael Skodlar  wrote:

> On 3/25/19 4:01 AM, Les Newell wrote:
> >
> >> Is this a mailing list about LinuxCNC or windows crap?!
>

Both, I think.It is pretty clear that to use CNC you need some kind of
design software (or stay with very simple designs that can be hand coded)
and the best, profesional level design software seems to be Windows or Mac
based.

In any case, it was pointed out that Fusion 360 runs on Wine.   That
basically means it runs on Linux with no need to install Windows.

Then in another thread, I suggested moving all real-time code to a uP.
This would meen there would no longer be a need for RT Linux and even for
Linux.   The reaming code might run on Windows.   If it did, interrest in
LiuxCNC would explode.

-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] Rock64 pre-orders on Banggood.

[Chris Albertson]

To elaborate my idea (no I did not invent this)

the servo loop and pulse generation and all other "hard" real time is run
on a 32-bit uP.  The lops will run with nearly zero jitter as the timing is
control from a divide down crystal clock.The loop does not do a command
then say "I'm done".  No.  the loop just runs so many time persecond,
forever.

The loops do need data.  They need a target position or a target velocity.
These targets are sent across an SPI (or I2C or Ethernet or,..) interface
from a Linux machine.  But you MUST de-couple the timing.   Linux can not
be feeding one target number at a time.

One way to decouple is to use a queue or "buffer"  The Linux machine sends
the targt points faster then the phu=ysical milling machine needs then so
that 20 or 1,000 targets are queued.   Each target has a time stamp that
tells the real-time loop when the target become valid.

Also there might be more than one uP in the system.   Perhaps the Machine
is complex and has many switches and collent pumps and 6 axles.  then maybe
three of the uP to run the real-time loops.

Actualy nothing changes, The same loops that now run under Linux could run
on a uP.

WHy move the loops to the uP?  Because then you no longer need Linux to be
real-tiime.  and more impotently, you don't need Linux.   Now that the PC
side is the nonreal-time you can use any OS you like.   Many people might
like to run on Andriod or Windows or Mac OS.  The "PC" could be a tablet.

One of the functions of the PC/Linus side is flashing the STM32 uP.  So
users need not understand much about how the uP works

On Mon, Mar 25, 2019 at 10:31 PM Rafael Skodlar  wrote:

> On 3/25/19 8:39 PM, Chris Albertson wrote:
> > Yes, you have to patch Kernels.  I think this is the #1 weakness of
> > Linux CNC.   It would be good to eliminate the need for a real-time
> Kernal.
>
> Patching is not a weakness IMO. This is done all the time. FPGAs for
> example would get loaded with "binary blobs" during bootup to do their
> things as programmed. Another way to handle this is with kernel modules.
> Load modules for whatever a particular SBC needs.
>
> > How?   Move the real-time parts to hardware such as the uP, PRU or
> Mesa
> > FPGA.Clearly, it can be done because people are controlling machines
> > with only a uP, PRU or FPGA.
>
> Brilliant IMO! In this scenario, microcontrollers accept commands from
> LinuxCNC for example and handle their tasks in loops or whatever program
> flow until the task is finished then send interrupt back to main
> processor board saying "I'm done".
>
> Subcontrollers could be advanced in some cases, a RaspberryPi or some
> such running it's own Linux for specialized tasks: drive stepper motors,
> read sensors, etc.
>
> Easier said than done I know, but better than do that all in RT kernel
> to fiddle with parallel port and other silly obsolete things.
>
> >
> > The interface was designed around a parallel printer port when outbound
> > processors had poor performance andhad to be on custom PCBs.Today we
> > have 32-bit STM32 uP on a board.The real-time code can move off the Linux
> > PC.
>
> I like this idea. Kernel params can be tweaked so that certain processes
> are 'niced' above the others. I remember tweaking kernel parameters long
> ago for mouse, keyboard, etc. response time. Workstations one way,
> servers that were not using keyboards and mouse most of the time
> another. In this case, LinuxCNC would get highest priority over anything
> else in the system for example.
>
> --
> Rafael
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] Rock64 pre-orders on Banggood.

[Erik Christiansen]

On 26.03.19 02:08, andy pugh wrote:
> Most of them seem to need a kernel specifically patched for the
> hardware, though. So you need (for example) the Udoo-patched kernel
> then need to apply Xenomia / RTAI / Preempt-RT on top of that.
> And often the fit is not exact.

Thought I'd order one, until seeing I'd have to run Android, as there's
explicitly no support for GNU Linux. (My Udoo X86 has, after a rather
short life, started checkerboarding the video after a few minutes
running, then crashing. I wonder if it's due to cheap supply bypass
caps, i.e. not low ESR?. That'd be fixable when I have time.)

Looks like I'll have to keep looking for a cheap video streamer for
viewing news clips and some old Sci-Fi episodes I have on a hard drive -
still unviewed, sadly.

> One kernel to suit every SBC? I don't think that is even possible without RT.

When porting Linux to a new board, you're up for writing or borrowing
drivers for the BSP (Board Support Package) (= HAL in other lingo). I've
only started on that once, and never carried it through to completion.

Erik


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

Re: [Emc-users] Autonomous machines

[Chris Albertson]

On Mon, Mar 25, 2019 at 3:54 PM andy pugh  wrote:

> On Mon, 25 Mar 2019 at 22:18, Rafael Skodlar  wrote:
>
> > PCs were NEVER intended to be used for CNC yet some of you out there use
> > it for that purpose.
>
> That is the _entire_ raison d'etre of LinuxCNC.
>
> The point of the EMC project was to do machine control on
> off-the-shelf PC hardware rather than on specialist hardware.
>
> Maybe that no longer makes sense, if so then LinuxCNC no longer makes
> sense.
>

Itcontinues to make perfet sense.  nowmore than before.   But what has
changde is the off the shelf hardware.   Today I can buy a Raspberry Pi or
a PC and both can run the same Linux based software. But I can also buy an
offthe shelf STM32F (ARMCortex-M) board for betweed $3 and $15 that can run
a milling machine, or at least a 3D printer of wood router.  Back when EMC
was new the PC was the only, low cost off the shelf computer.  But now
there are many

What's chaged is the variety of off the shelf hardware and the price of it.


>
> --
> 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-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

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