Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Karlsson & Wang]

> The machine hardware needs to be smart enough to monitor for 
> communication failures. There should be full duplex communication so 
> that every command either way is answered by an ACK. No response, it 
> shuts down.

Real time data is usually sent periodically and in such other solutions are 
possible. If the receiver know then data should arrive it may turn off if not 
received, this is simple solution that work almost like an ordinary cable 
although with a longer delay. Usually there is data sent back periodically the 
other way and this could be used instead of an ack.

If you send data then changed and use an ack instead of periodic data you 
almost certainly end up using less bandwidth except then needed the most!

--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Charles Buckley]

  I have not been keeping up with machinekit as much as I should, but it
does look like they are moving to server/client. Looks like they have moved
the UI, task scheduler, RS274 interpreter, and basic machine commands to
use API's. Trajectory planner, kinematics, hardware drivers, etc, etc
remain on the Beaglebone. If I am reading this doc correctly, I would think
that you could program pretty much anything to connect to the API's. Should
be OS agnostic where the UI is running. I do know they are doing the
development against tablets as I have downloaded that.

Hmm..  there even looks to be a thread for windows machinekit clients..
https://groups.google.com/forum/#!searchin/machinekit/machinekit$20windows/machinekit/fHCykq4nXHA/3VYwQEQAFgAJ
 If I am reading this correctly, they just don't have a lot of developers
working compared to the tablet option.

Personally, I have been more interested in an industrial setting whereby I
could integrate a lot of systems into a monitoring and tracking system to
show where systems are in their machine cycle. If nothing else, then maybe
something as straightforward as SNMP traps so that monitoring systems -
such as Nagios - could pick that up. Or, a single UI driving multiple
machines, which would be possible with an API model - similar to octoprint.
With the cost of BBB and similar x86 or ARM systems, linuxcnc as a
standalone PC is not necessarily where things will end up long term.
(conjecture on my part. I am not involved in an architectural discussions
and I'm a weak coder).

On Tue, Sep 22, 2015 at 1:45 AM, Gregg Eshelman  wrote:

> On 9/21/2015 2:20 PM, Charles Buckley wrote:
> > Well, you can eliminate windows completely, if you have a phone or
> android
> > tablet.
> >
> >
> https://play.google.com/store/apps/details?id=io.machinekit.appdiscover=en
> >
> > I would argue that the ability to split the GUI from the engine is a good
> > thing overall, but at your core, you're still looking at having a full OS
> > sitting out there and the underlying architecture and filesystem layout
> can
> > not easily be circumvented.
>
> What that would be is a client-server type of system, with LCNC running
> on a micro-system in the role of the server, with the GUI running on the
> Windows or OS X or other system as the client.
>
> The trick is to achieve transparency of operation so that GCODE and
> commands for start, stop, E-stop etc sent to the LCNC server and
> feedback returned to the client operates seamlessly and without
> interference with the micro-system actually operating the CNC machine.
>
> It would (should) also be simpler to adapt the client to different
> versions of its host OS since the data going both ways from the server
> wouldn't change.
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> --
> ___
> 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] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Viesturs Lācis]

2015-09-22 21:54 GMT+03:00 Charles Buckley :
>  If I am reading this correctly, they just don't have a lot of developers
> working compared to the tablet option.

Well, it seems that you did not read correctly - Alex Rossler is the
author of machinekit-client application. All of its versions -
android, linux, windows, macos. So the number of devs is the same for
all the target environments. Regarding particular GUIs - Cetus,
Machineface or maybe something new - all the xml files reside on BBB,
so it does not depend on target environment.

Viesturs

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

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[John Dammeyer]

I Agree!  For the same reason seeing windows MACH3 hang and the USB smooth
stepper continue to send out stepping pulses on the Z throwing the machine
alignment out as it pushes against the table.  (router bit not turning and
didn't break).

An ESTOP and limits have to be part of the hardware interface side of the
equation.And there has to be enough intelligence to let the trajectory
planner know what has happened.  Even with as simple a feature as a remote
feed hold button.

One can't just send large blocks of motion information to the target
hardware and then tap feed hold and wait for 30 seconds worth of queued
motion to play out.  By the same token the graphic display and trajectory
planner needs to know when the hardware did actually stop so it can rewind
back to that point and start again.  So it's a tightly  coupled closed loop
control.  All currently done on one computer with access to both sets of
data structures for motion commands and motion implementation.

But the future _is_ separate drive and interface.   When I have some time
I'll look further into this.

John

> -Original Message-
> From: Mark Wendt [mailto:wendt.m...@gmail.com]
> Sent: September-22-15 2:47 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM
> for LinuxCNC
> 
> 
> On Tue, Sep 22, 2015 at 3:45 AM, Gregg Eshelman <g_ala...@yahoo.com>
> wrote:
> 
> > The trick is to achieve transparency of operation so that GCODE and
> > commands for start, stop, E-stop etc sent to the LCNC server and
> > feedback returned to the client operates seamlessly and without
> > interference with the micro-system actually operating the CNC machine.
> 
> That.
> 
> That's the biggest concern I have for a heavy machine, spinning sharp
> objects, and whoops!  The wireless went down.  Or the wired switch
> decided to take a dump.
> 
> Those reasons are why I don't use wireless or bluetooth keyboards,
> mice and pendants.  A hard wire connect to a single computer running
> the code to me is just the safest way of doing things.  Drip feed by
> DNC is okay, that's a horse of a different course.
> 
> Mark
> 
> --
> One Man, One Machine, One Computer!  
> 
>

--
> ___
> 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] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Gregg Eshelman]

On 9/22/2015 10:47 AM, John Dammeyer wrote:
> I Agree!  For the same reason seeing windows MACH3 hang and the USB smooth
> stepper continue to send out stepping pulses on the Z throwing the machine
> alignment out as it pushes against the table.  (router bit not turning and
> didn't break).
>
> An ESTOP and limits have to be part of the hardware interface side of the
> equation.And there has to be enough intelligence to let the trajectory
> planner know what has happened.  Even with as simple a feature as a remote
> feed hold button.
>
> One can't just send large blocks of motion information to the target
> hardware and then tap feed hold and wait for 30 seconds worth of queued
> motion to play out.  By the same token the graphic display and trajectory
> planner needs to know when the hardware did actually stop so it can rewind
> back to that point and start again.  So it's a tightly  coupled closed loop
> control.  All currently done on one computer with access to both sets of
> data structures for motion commands and motion implementation.
>
> But the future _is_ separate drive and interface.   When I have some time
> I'll look further into this.

The machine hardware needs to be smart enough to monitor for 
communication failures. There should be full duplex communication so 
that every command either way is answered by an ACK. No response, it 
shuts down.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[John Dammeyer]

Hi Charles,
> 
>   I have not been keeping up with machinekit as much as I should, but it
> does look like they are moving to server/client. Looks like they have
moved
> the UI, task scheduler, RS274 interpreter, and basic machine commands to
> use API's. Trajectory planner, kinematics, hardware drivers, etc, etc
> remain on the Beaglebone. If I am reading this doc correctly, I would
think
> that you could program pretty much anything to connect to the API's.
Should
> be OS agnostic where the UI is running. I do know they are doing the
> development against tablets as I have downloaded that.

Because the BBB has the two PRU processors all the stepping movement etc.
has been offloaded.  At the moment though, last I checked, support for a
spindle encoder for lathe threading isn't there yet.  With that in mind I
doubt that encoder feedback for DC Servos is there either.  And the Beagle
doesn't have 5 or 6 QEI devices (only 2) so some sort of external cape would
still be required if you wanted a full 5 axis system along with an encoder
on the spindle.  But then that's true for a desktop PC too right?

The Beagle won't be the ultimate solution even for the embedded systems I
design.  It's got only two CAN bus ports.  I'm still stuck using a Freescale
9S12 8/16 bit controller because it has 5 CAN bus channels of which I use 3
or 4.  And the development, debugging and programming software for that is
stuck at the WIN-XP level and isn't available at all for Linux.

The Beagle could do a Lathe with an encoder and stepper motors.  Even with a
small touch screen interface.  The world has changed a lot in the last 5
years.

John
  


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

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Gregg Eshelman]

On 9/21/2015 2:20 PM, Charles Buckley wrote:
> Well, you can eliminate windows completely, if you have a phone or android
> tablet.
>
> https://play.google.com/store/apps/details?id=io.machinekit.appdiscover=en
>
> I would argue that the ability to split the GUI from the engine is a good
> thing overall, but at your core, you're still looking at having a full OS
> sitting out there and the underlying architecture and filesystem layout can
> not easily be circumvented.

What that would be is a client-server type of system, with LCNC running 
on a micro-system in the role of the server, with the GUI running on the 
Windows or OS X or other system as the client.

The trick is to achieve transparency of operation so that GCODE and 
commands for start, stop, E-stop etc sent to the LCNC server and 
feedback returned to the client operates seamlessly and without 
interference with the micro-system actually operating the CNC machine.

It would (should) also be simpler to adapt the client to different 
versions of its host OS since the data going both ways from the server 
wouldn't change.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[John Dammeyer]

> 
> What that would be is a client-server type of system, with LCNC running
> on a micro-system in the role of the server, with the GUI running on the
> Windows or OS X or other system as the client.
> 
> The trick is to achieve transparency of operation so that GCODE and
> commands for start, stop, E-stop etc sent to the LCNC server and
> feedback returned to the client operates seamlessly and without
> interference with the micro-system actually operating the CNC machine.
> 
> It would (should) also be simpler to adapt the client to different
> versions of its host OS since the data going both ways from the server
> wouldn't change.
> 

Quite right but it does come down to the definition of LCNC.  What it is and
what it does.  I'd suggest, like on the Windows side the control of the
hardware part of the device driver and can be handled with some sort of
external controller.  Like on the windows side the Smooth Stepper family,
on the Linux side the Mesa cards and other specialty hardware.  

And that's where the Beagle Bone would fit in - as the mechanical interface
to the motion planning and display which is the core of Linux.

Given my experience with USB on Windows I'd suggest that it isn't the way to
go.  A dedicated Ethernet connection with 100Mbps data rates is more than
fast enough to provide any sort of timely feedback.  That means a WizNet
Ethernet Module at 9600 baud to an Arduino is _not_ the way to go.  I'm not
sure a tablet running windows with a wifi connection to a beagle is the
right way either.  Reliability is a bit suspect.

But Ethernet is becoming the new industrial control bus so it's not an
unreasonable assumption that splitting the system wouldn't work quite well.

John



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

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Mark Wendt]

On Tue, Sep 22, 2015 at 9:31 AM, Gene Heskett  wrote:
> On Tuesday 22 September 2015 05:46:42 Mark Wendt wrote:
>
>> On Tue, Sep 22, 2015 at 3:45 AM, Gregg Eshelman 
> wrote:
>> > The trick is to achieve transparency of operation so that GCODE and
>> > commands for start, stop, E-stop etc sent to the LCNC server and
>> > feedback returned to the client operates seamlessly and without
>> > interference with the micro-system actually operating the CNC
>> > machine.
>>
>> That.
>>
>> That's the biggest concern I have for a heavy machine, spinning sharp
>> objects, and whoops!  The wireless went down.  Or the wired switch
>> decided to take a dump.
>>
>> Those reasons are why I don't use wireless or bluetooth keyboards,
>> mice and pendants.  A hard wire connect to a single computer running
>> the code to me is just the safest way of doing things.  Drip feed by
>> DNC is okay, that's a horse of a different course.
>>
>> Mark
>
> And I haven't had a wireless mouse or keyboard that if the batteries were
> good, did anything but work.  The keyboard in particular is extremely
> handy without the distance limiting cord, as I can pick it up off its
> normal resting place about 3 deet from the machine, carry it over and
> park it on the Y motor when I am setting up for the next operation.
>
> >From where I sit at the operating position Z is the only axis I can see
> well enough when jogging. So I either need to get a camera, and camview
> and align setup and calibrated, or go over to the machine with the
> keyboard.  As for batteries failing, I've not had them fail in anything
> but the key up position.  Ever.
>
> Now, if I could just find a fitted cover for a logitech K360 keyboard to
> keep the swarf and coffee drippings out of it.  I find that even with
> the square sided keys, swarf can jam it.
>
> YMMV of course.
>
> Cheers, Gene Heskett

All it takes is a bit of interference in the band of radios waves
those devices use.  I still prefer hardwired connections rather than
trusting radio waves on stuff like that.  Or, as you mentioned, the
batteries.  It only has to happen once.

Mark

-- 
One Man, One Machine, One Computer!  

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

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Gene Heskett]

On Tuesday 22 September 2015 05:46:42 Mark Wendt wrote:

> On Tue, Sep 22, 2015 at 3:45 AM, Gregg Eshelman  
wrote:
> > The trick is to achieve transparency of operation so that GCODE and
> > commands for start, stop, E-stop etc sent to the LCNC server and
> > feedback returned to the client operates seamlessly and without
> > interference with the micro-system actually operating the CNC
> > machine.
>
> That.
>
> That's the biggest concern I have for a heavy machine, spinning sharp
> objects, and whoops!  The wireless went down.  Or the wired switch
> decided to take a dump.
>
> Those reasons are why I don't use wireless or bluetooth keyboards,
> mice and pendants.  A hard wire connect to a single computer running
> the code to me is just the safest way of doing things.  Drip feed by
> DNC is okay, that's a horse of a different course.
>
> Mark

And I haven't had a wireless mouse or keyboard that if the batteries were 
good, did anything but work.  The keyboard in particular is extremely 
handy without the distance limiting cord, as I can pick it up off its 
normal resting place about 3 deet from the machine, carry it over and 
park it on the Y motor when I am setting up for the next operation.

>From where I sit at the operating position Z is the only axis I can see 
well enough when jogging. So I either need to get a camera, and camview 
and align setup and calibrated, or go over to the machine with the  
keyboard.  As for batteries failing, I've not had them fail in anything 
but the key up position.  Ever.

Now, if I could just find a fitted cover for a logitech K360 keyboard to 
keep the swarf and coffee drippings out of it.  I find that even with 
the square sided keys, swarf can jam it.

YMMV of course.

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] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Mark Wendt]

On Tue, Sep 22, 2015 at 3:45 AM, Gregg Eshelman  wrote:

> The trick is to achieve transparency of operation so that GCODE and
> commands for start, stop, E-stop etc sent to the LCNC server and
> feedback returned to the client operates seamlessly and without
> interference with the micro-system actually operating the CNC machine.

That.

That's the biggest concern I have for a heavy machine, spinning sharp
objects, and whoops!  The wireless went down.  Or the wired switch
decided to take a dump.

Those reasons are why I don't use wireless or bluetooth keyboards,
mice and pendants.  A hard wire connect to a single computer running
the code to me is just the safest way of doing things.  Drip feed by
DNC is okay, that's a horse of a different course.

Mark

-- 
One Man, One Machine, One Computer!  

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

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Mark Wendt]

On Tue, Sep 22, 2015 at 10:54 AM, Gene Heskett  wrote:

>>
>> When something absolutely has to have a solid connection, whether it's
>> controller to machine, or keyboard to the controller, you just can't
>> beat a good shielded hardware connection between the two.
>>
>> Mark
>
> Chuckle, good, shielded, and hardware.  Pick any 2. :)
>
> Cheers, Gene Heskett

Nuts.  Typo on my part.  "Hardware" shoulda read "hardwire."  ;-)

Mark

-- 
One Man, One Machine, One Computer!  

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

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Gene Heskett]

On Tuesday 22 September 2015 10:39:05 Mark Wendt wrote:

> On Tue, Sep 22, 2015 at 10:20 AM, Gene Heskett  
wrote:
> >> All it takes is a bit of interference in the band of radios waves
> >> those devices use.  I still prefer hardwired connections rather
> >> than trusting radio waves on stuff like that.  Or, as you
> >> mentioned, the batteries.  It only has to happen once.
> >>
> >> Mark
> >
> > This also is true, but I am not in an industrial environment where
> > such interference is at all common.  Whats in the shop or garage is
> > not of course semi-shielded by the alu siding on this house and
> > would be 10+ db more susceptible.  This is a relatively quiet, 50
> > yards from the city limits residential area, with more electronics
> > here than exists anyplace but a fast food place in the whole town, a
> > physical limit enforced by a huge to me hill that only small
> > children could negotiate, very thick brush, but don't as its also
> > multiflora rose and copperhead country.  So here, that interference
> > has not been a problem. I think that isolation from technology is
> > without a doubt a good thing for me.
> >
> > I have no experience in a busy job shop with 5 or more machines in
> > the same big room.  In the shop in the back yard, the toy mill and
> > the lathe are about 4 feet apart, but the lathe is the only wireless
> > equipt machine.  The operating position of the toy mill is actually
> > above the right end of its table, so I can see it well while jogging
> > with my right hand.  No need for the radios.
> >
> > In the garage with the GO704, I do need to put up a sheet of lexan
> > to deflect airborne swarf between the operating position and the
> > machine as it would help keep swarf out of both the keyboard and my
> > coffee cup. :)
> >
> > OTOH, the spindle motors max at 1 hp here, are the strongest motors
> > involved. All could throw a key on startup plenty hard enough to
> > hurt.
> >
> > Axis motors are more than strong enough to break or crush tools
> > though. I sheared a 4 mm capscrew sunday by leaving something on the
> > bellows I had added to better shield the Y ball screw from debris,
> > so they are certainly capable of crushing a wayward finger.  One of
> > todays projects I think along with finding a fly cutter to level the
> > front of that jig addition installed yesterday. And I need to make
> > some narrow, say 5" wide, binder high pocket shelving additions to
> > the "furniture" for holding gcode manuals and printouts of some of
> > the files so I don't forget what it was I was doing. :)
> >
> > Cheers, Gene Heskett
>
> Gene,
>
> Like I said, it's my dislike for radio waves in an environment where
> they are the connection between the controller and the machine.  Being
> a radio tech in the USAF, working with both voice radios and ECM gear,
> I know it doesn't take much to disrupt communications, both voice and
> data.  Voice is a little more forgiving than data.  If a voice
> transmission is disrupted/corrupted, you can ask for a repeat.  If a
> data transmission is corrupted, the machine isn't always smart enough
> to ask for a repeat - it may take the corrupted packet as legit.
>
> There may not be any commercial or residential interference nearby
> you, but there's that really big interference generator 93 million
> miles away from your doorstep that appears every day.  ;-)
>
> When something absolutely has to have a solid connection, whether it's
> controller to machine, or keyboard to the controller, you just can't
> beat a good shielded hardware connection between the two.
>
> Mark

Chuckle, good, shielded, and hardware.  Pick any 2. :)

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] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Gene Heskett]

On Tuesday 22 September 2015 09:36:24 Mark Wendt wrote:

> On Tue, Sep 22, 2015 at 9:31 AM, Gene Heskett  
wrote:
> > On Tuesday 22 September 2015 05:46:42 Mark Wendt wrote:
> >> On Tue, Sep 22, 2015 at 3:45 AM, Gregg Eshelman
> >> 
> >
> > wrote:
> >> > The trick is to achieve transparency of operation so that GCODE
> >> > and commands for start, stop, E-stop etc sent to the LCNC server
> >> > and feedback returned to the client operates seamlessly and
> >> > without interference with the micro-system actually operating the
> >> > CNC machine.
> >>
> >> That.
> >>
> >> That's the biggest concern I have for a heavy machine, spinning
> >> sharp objects, and whoops!  The wireless went down.  Or the wired
> >> switch decided to take a dump.
> >>
> >> Those reasons are why I don't use wireless or bluetooth keyboards,
> >> mice and pendants.  A hard wire connect to a single computer
> >> running the code to me is just the safest way of doing things. 
> >> Drip feed by DNC is okay, that's a horse of a different course.
> >>
> >> Mark
> >
> > And I haven't had a wireless mouse or keyboard that if the batteries
> > were good, did anything but work.  The keyboard in particular is
> > extremely handy without the distance limiting cord, as I can pick it
> > up off its normal resting place about 3 deet from the machine, carry
> > it over and park it on the Y motor when I am setting up for the next
> > operation.
> >
> > >From where I sit at the operating position Z is the only axis I can
> > > see
> >
> > well enough when jogging. So I either need to get a camera, and
> > camview and align setup and calibrated, or go over to the machine
> > with the keyboard.  As for batteries failing, I've not had them fail
> > in anything but the key up position.  Ever.
> >
> > Now, if I could just find a fitted cover for a logitech K360
> > keyboard to keep the swarf and coffee drippings out of it.  I find
> > that even with the square sided keys, swarf can jam it.
> >
> > YMMV of course.
> >
> > Cheers, Gene Heskett
>
> All it takes is a bit of interference in the band of radios waves
> those devices use.  I still prefer hardwired connections rather than
> trusting radio waves on stuff like that.  Or, as you mentioned, the
> batteries.  It only has to happen once.
>
> Mark

This also is true, but I am not in an industrial environment where such 
interference is at all common.  Whats in the shop or garage is not of 
course semi-shielded by the alu siding on this house and would be 10+ db 
more susceptible.  This is a relatively quiet, 50 yards from the city 
limits residential area, with more electronics here than exists anyplace 
but a fast food place in the whole town, a physical limit enforced by a 
huge to me hill that only small children could negotiate, very thick 
brush, but don't as its also multiflora rose and copperhead country.  So 
here, that interference has not been a problem. I think that isolation 
from technology is without a doubt a good thing for me.

I have no experience in a busy job shop with 5 or more machines in the 
same big room.  In the shop in the back yard, the toy mill and the lathe 
are about 4 feet apart, but the lathe is the only wireless equipt 
machine.  The operating position of the toy mill is actually above the 
right end of its table, so I can see it well while jogging with my right 
hand.  No need for the radios.

In the garage with the GO704, I do need to put up a sheet of lexan to 
deflect airborne swarf between the operating position and the machine as 
it would help keep swarf out of both the keyboard and my coffee cup. :)

OTOH, the spindle motors max at 1 hp here, are the strongest motors 
involved. All could throw a key on startup plenty hard enough to hurt.

Axis motors are more than strong enough to break or crush tools though. I 
sheared a 4 mm capscrew sunday by leaving something on the bellows I had 
added to better shield the Y ball screw from debris, so they are 
certainly capable of crushing a wayward finger.  One of todays projects 
I think along with finding a fly cutter to level the front of that jig 
addition installed yesterday. And I need to make some narrow, say 5" 
wide, binder high pocket shelving additions to the "furniture" for 
holding gcode manuals and printouts of some of the files so I don't 
forget what it was I was doing. :)

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] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Mark Wendt]

On Tue, Sep 22, 2015 at 10:20 AM, Gene Heskett  wrote:

>>
>> All it takes is a bit of interference in the band of radios waves
>> those devices use.  I still prefer hardwired connections rather than
>> trusting radio waves on stuff like that.  Or, as you mentioned, the
>> batteries.  It only has to happen once.
>>
>> Mark
>
> This also is true, but I am not in an industrial environment where such
> interference is at all common.  Whats in the shop or garage is not of
> course semi-shielded by the alu siding on this house and would be 10+ db
> more susceptible.  This is a relatively quiet, 50 yards from the city
> limits residential area, with more electronics here than exists anyplace
> but a fast food place in the whole town, a physical limit enforced by a
> huge to me hill that only small children could negotiate, very thick
> brush, but don't as its also multiflora rose and copperhead country.  So
> here, that interference has not been a problem. I think that isolation
> from technology is without a doubt a good thing for me.
>
> I have no experience in a busy job shop with 5 or more machines in the
> same big room.  In the shop in the back yard, the toy mill and the lathe
> are about 4 feet apart, but the lathe is the only wireless equipt
> machine.  The operating position of the toy mill is actually above the
> right end of its table, so I can see it well while jogging with my right
> hand.  No need for the radios.
>
> In the garage with the GO704, I do need to put up a sheet of lexan to
> deflect airborne swarf between the operating position and the machine as
> it would help keep swarf out of both the keyboard and my coffee cup. :)
>
> OTOH, the spindle motors max at 1 hp here, are the strongest motors
> involved. All could throw a key on startup plenty hard enough to hurt.
>
> Axis motors are more than strong enough to break or crush tools though. I
> sheared a 4 mm capscrew sunday by leaving something on the bellows I had
> added to better shield the Y ball screw from debris, so they are
> certainly capable of crushing a wayward finger.  One of todays projects
> I think along with finding a fly cutter to level the front of that jig
> addition installed yesterday. And I need to make some narrow, say 5"
> wide, binder high pocket shelving additions to the "furniture" for
> holding gcode manuals and printouts of some of the files so I don't
> forget what it was I was doing. :)
>
> Cheers, Gene Heskett

Gene,

Like I said, it's my dislike for radio waves in an environment where
they are the connection between the controller and the machine.  Being
a radio tech in the USAF, working with both voice radios and ECM gear,
I know it doesn't take much to disrupt communications, both voice and
data.  Voice is a little more forgiving than data.  If a voice
transmission is disrupted/corrupted, you can ask for a repeat.  If a
data transmission is corrupted, the machine isn't always smart enough
to ask for a repeat - it may take the corrupted packet as legit.

There may not be any commercial or residential interference nearby
you, but there's that really big interference generator 93 million
miles away from your doorstep that appears every day.  ;-)

When something absolutely has to have a solid connection, whether it's
controller to machine, or keyboard to the controller, you just can't
beat a good shielded hardware connection between the two.

Mark

-- 
One Man, One Machine, One Computer!  

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

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Charles Buckley]

Well, you can eliminate windows completely, if you have a phone or android
tablet.

https://play.google.com/store/apps/details?id=io.machinekit.appdiscover=en

I would argue that the ability to split the GUI from the engine is a good
thing overall, but at your core, you're still looking at having a full OS
sitting out there and the underlying architecture and filesystem layout can
not easily be circumvented.



On Sat, Sep 19, 2015 at 12:49 PM, John Dammeyer <jo...@autoartisans.com>
wrote:

> Ultimately remoting into the BBB still means learning two operating systems
> when 99.9% of my work is done under Windows.
>
> To drag a drop a file onto the desktop on the Debian BBB MachineKit port
> involves dragging it to the desktop folder and then using the ever present
> and needed text editor to edit the shortcut to make it work properly with
> the correct icon.
>
> In windows you drag it onto the desktop.  Period.  If you want to change
> parameters right click and change stuff in a dialog.  No command line
> needed.
>
> So if LinuxCNC is to be used in windows getting rid of the "Linux Guru
> required"  option is  a major feature.
>
> John
>
> > -Original Message-
> > From: Kyle Kerr [mailto:ker...@gmail.com]
> > Sent: September-19-15 10:52 AM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM
> > for LinuxCNC
> >
> >
> > Maybe I don't understand what you are getting at. Why go through all the
> > effort of breaking the software up between BBB and a Windows machine?
> > Why
> > not just remote in to the BBB and call it a day?
> >
> > On Sat, Sep 19, 2015, 11:59 AM John Dammeyer <jo...@autoartisans.com>
> > wrote:
> >
> > > > On 19/09/15 05:55, John Dammeyer wrote:
> > > > > WIN-8 and up don't support
> > > > > parallel ports or even serial ports directly.
> > > >
> > > > 64bit windows does not support parallel port. Even on 32bit W10 it
> still
> > > > works fine ... I have some legacy kit which is still going strong but
> we
> > > > had to move off 32bit XP for some spurious reason ;) Running a couple
> of
> > > > serial ports as well, but I think they are OK on the 64bit builds as
> > > well.
> > > >
> > > > --
> > > > Lester Caine - G8HFL
> > > Ah,  I didn't realize if you stayed 32 bit that support was still
> there.
> > >
> > > However, your previous posting about cross platform movement of
> > LinuxCNC to
> > > the Windows environment is interesting.
> > >
> > > The argument against it has always been that:
> > > a)  hard real time is possible with Linux and isn't with Windows
> > > b) low level access to the hardware allows closed loop servo control
> with
> > > expansion cards like MESA for servo's or steppers.
> > >
> > > So given the cost of a MESA or other expansion boards perhaps a tightly
> > > coupled system using a BeagleBone Black (BBB) with a cape as the real
> time
> > > component and on a windows platform starts to make sense.  The BBB has
> > both
> > > USB and Ethernet.Also a lot more I/O if you don't use the HDMI
> video
> > > capability.
> > >
> > > One doesn't even have to move it to Windows immediately.  It becomes a
> > > 'hardware device' like a what's already out there for LinuxCNC.  It's
> > > possible it can even keep the real time components used in the
> MachineKit
> > > port so it remains a Linux hosted processor.  So development and
> testing
> > > become a two part project.
> > >
> > > 1. Move the motion part of LinuxCNC to the BBB via dedicated Ethernet
> > > tcp/ip.  Requires second Ethernet port on workstation PC.  Surely
> 100Mbps
> > > Ethernet can handle data motion and position feedback to LinuxCNC
> > software
> > > for screen updating and G-Code parsing.  The Smooth Stepper can do it
> at
> a
> > > lower level on the non-real time Windows so Linux should find this
> easy?
> > >
> > >  2. When that's working and tested, port the LinuxCNC non-hard real
> time
> > > code to Windows C or C++ (not .NET though)
> > >
> > > There is a big plus to step 2 for the LinuxCNC community.  The act of
> > > porting can result in code cleanup of LinuxCNC where normally sections
> are
> > > left alone because they work and there isn't any pressing need to
> change
> > > them.  So old legacy stuff stays old even though now 

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Mark Wendt]

On Sat, Sep 19, 2015 at 2:49 PM, John Dammeyer  wrote:
> Ultimately remoting into the BBB still means learning two operating systems
> when 99.9% of my work is done under Windows.
>
> To drag a drop a file onto the desktop on the Debian BBB MachineKit port
> involves dragging it to the desktop folder and then using the ever present
> and needed text editor to edit the shortcut to make it work properly with
> the correct icon.
>
> In windows you drag it onto the desktop.  Period.  If you want to change
> parameters right click and change stuff in a dialog.  No command line
> needed.
>
> So if LinuxCNC is to be used in windows getting rid of the "Linux Guru
> required"  option is  a major feature.
>
> John

Are you talking about a regular file, or an executable?  Either way,
you can right-click on an icon and adjust the properties there, and
make the file executable if you wish, which has been available since
at least 10.04 LTS..  All done through the GUI.  On my Ubuntu machines
at home and work, I can drag and drop, or cut and paste.  Maybe that's
a legacy of the version of Debian being used in the MachineKit port?


Mark
-- 
One Man, One Machine, One Computer!  

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

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Dave Cole]

John,

Using the BBB is bleeding edge.  But you should know that if you are 
frequenting the Machinekit email list.

>>For me to have to
be conversant in all things Linux for only the machine control side of
things on a BBB is a real waste of time when everything else I do must be
done on Windows.  My clients expect it.

No one is making you use the BBB, that is your choice..  You will get bloody!

>>>And there in a nutshell is the reason Windows and Macs  outnumber Linux for
PCs used by almost everyone.

Blah blah blah  refer to the first line again.  :-)

>>  But for the Linux proponent I'm a troglodyte who just hasn't found the light
of the wonders of Linux.

If you want to make your LinuxCNC experience easy, get yourself some proven PC 
hardware and some
known supporting hardware and the live DVD for LinuxCNC 2.7 and install it.

Want to know why this is all worthwhile?

When you install a system on a commercial machine that is run every day and 
after commissioning and training they never call you with problems!
I need to think about where I have installed machines because I only hear from 
them when the hardware fails or they want another machine conversion.
Out of character behavior, like your router taking off and slamming into the 
stops just doesn't happen.

And that makes all of this very worthwhile!  :-)

Dave



On 9/20/2015 11:47 AM, John Dammeyer wrote:
> Hi Mark,
> I'm using the latest BeagleBone Black Debian and I've been told on this
> forum that the Machinekit for BBB was forked off from the original EMC and
> not to ask for help here.  So I don't.
>
> The executable application dragged onto the desktop folder (not the desktop)
> shows up on the desktop.   And then clicking on that executable results in a
> dialog popping up every single time with the question as to whether I want
> to run it, or run it in a command window, or cancel.  Also the icon for the
> app is the generic gear icon.  A right click dialog does not have options to
> change that.
> I solved the problem after a an hour or two of searching.  Edit the shortcut
> file in a command line editor and add the appropriate instructions to
> prevent the dialog pop up and add in the path to the correct icon file.
> Should all that be on the right click dialog?  Of course it should.   But
> it's not.
> And there in a nutshell is the reason Windows and Macs  outnumber Linux for
> PCs used by almost everyone.  Forcing someone to use the command line
> interface for a graphical user interface application is embedded into the
> brain of the Linux fans as "not a problem".  It is a problem!  A huge one!
> But for the Linux proponent I'm a troglodyte who just hasn't found the light
> of the wonders of Linux.
>
> I think I fair discussion for LinuxCNC would be on a version that separates
> how the physical machine interface is done and how the graphical user
> interface and G-Code/ladder logic/macro language is done.  For me to have to
> be conversant in all things Linux for only the machine control side of
> things on a BBB is a real waste of time when everything else I do must be
> done on Windows.  My clients expect it.  Some of the tools only run on
> windows.  So the argument to use WINE or some other VBox falls apart when
> something like the In Circuit Debugger doesn't run in the VBox.
>
> So let's put that 'religious' argument aside too.
>
> >From an embedded perspective what was available 5 years ago to what is
> available now is very different.  A BBB with an Ethernet connection like the
> Ethernet Smooth Stepper could likely do everything the Real Time part of
> Linux is doing.  Especially with the two 200MHz Co-Processors.  It might
> have to run a dedicated RTOS rather than real time Linux to be effective but
> if the Real Time component is removed from LinuxCNC is there any reason that
> part can't run as a Windows or  iOS Application?
>
> And maybe that's a Fork in the code that is finally a really good idea.
>
> John
>
>
>> -Original Message-----
>> From: Mark Wendt [mailto:wendt.m...@gmail.com]
>> Sent: September-20-15 4:08 AM
>> To: Enhanced Machine Controller (EMC)
>> Subject: Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM
>> for LinuxCNC
>>
>>
>> On Sat, Sep 19, 2015 at 2:49 PM, John Dammeyer <jo...@autoartisans.com>
>> wrote:
>>> Ultimately remoting into the BBB still means learning two operating
>> systems
>>> when 99.9% of my work is done under Windows.
>>>
>>> To drag a drop a file onto the desktop on the Debian BBB MachineKit port
>>> involves dragging it to the desktop folder and then using the ever
> present
>>> and needed text editor to edit the shortcut to make it work properly
> with
&g

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[John Dammeyer]

The concept of a PRU isn't new either.   There's one on the M9S12 that
although not recommended for new projects is still in use.  The 9S12 is
based on the original 6809 processor with some 16 bit operations but mostly
still an 8 bit unit.  Development still possible under WIN-XP and debugging
with P hardware.
John

> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> Sent: September-20-15 12:47 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM
> for LinuxCNC
> 
> 
> On 09/20/2015 12:45 PM, Dave Cole wrote:
> > John,
> >
> > Using the BBB is bleeding edge.  But you should know that if you are
> > frequenting the Machinekit email list.
> >
> >
> Actually, it is not so bleeding edge anymore.  There are
> apparently thousands of people using it, mostly on 3D
> printers, but also on routers and mills.  These all use the
> PRU to do essentially what external step generators do on
> X86 LinuxCNC systems.  This has been running for almost 2
> years, now.
> 
> Jon
> 
>

--
> ___
> 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] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[John Dammeyer]

Hi Mark,
I'm using the latest BeagleBone Black Debian and I've been told on this
forum that the Machinekit for BBB was forked off from the original EMC and
not to ask for help here.  So I don't.

The executable application dragged onto the desktop folder (not the desktop)
shows up on the desktop.   And then clicking on that executable results in a
dialog popping up every single time with the question as to whether I want
to run it, or run it in a command window, or cancel.  Also the icon for the
app is the generic gear icon.  A right click dialog does not have options to
change that.
I solved the problem after a an hour or two of searching.  Edit the shortcut
file in a command line editor and add the appropriate instructions to
prevent the dialog pop up and add in the path to the correct icon file.
Should all that be on the right click dialog?  Of course it should.   But
it's not.
And there in a nutshell is the reason Windows and Macs  outnumber Linux for
PCs used by almost everyone.  Forcing someone to use the command line
interface for a graphical user interface application is embedded into the
brain of the Linux fans as "not a problem".  It is a problem!  A huge one!
But for the Linux proponent I'm a troglodyte who just hasn't found the light
of the wonders of Linux.

I think I fair discussion for LinuxCNC would be on a version that separates
how the physical machine interface is done and how the graphical user
interface and G-Code/ladder logic/macro language is done.  For me to have to
be conversant in all things Linux for only the machine control side of
things on a BBB is a real waste of time when everything else I do must be
done on Windows.  My clients expect it.  Some of the tools only run on
windows.  So the argument to use WINE or some other VBox falls apart when
something like the In Circuit Debugger doesn't run in the VBox.

So let's put that 'religious' argument aside too.  

>From an embedded perspective what was available 5 years ago to what is
available now is very different.  A BBB with an Ethernet connection like the
Ethernet Smooth Stepper could likely do everything the Real Time part of
Linux is doing.  Especially with the two 200MHz Co-Processors.  It might
have to run a dedicated RTOS rather than real time Linux to be effective but
if the Real Time component is removed from LinuxCNC is there any reason that
part can't run as a Windows or  iOS Application?

And maybe that's a Fork in the code that is finally a really good idea.  

John


> -Original Message-
> From: Mark Wendt [mailto:wendt.m...@gmail.com]
> Sent: September-20-15 4:08 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM
> for LinuxCNC
> 
> 
> On Sat, Sep 19, 2015 at 2:49 PM, John Dammeyer <jo...@autoartisans.com>
> wrote:
> > Ultimately remoting into the BBB still means learning two operating
> systems
> > when 99.9% of my work is done under Windows.
> >
> > To drag a drop a file onto the desktop on the Debian BBB MachineKit port
> > involves dragging it to the desktop folder and then using the ever
present
> > and needed text editor to edit the shortcut to make it work properly
with
> > the correct icon.
> >
> > In windows you drag it onto the desktop.  Period.  If you want to change
> > parameters right click and change stuff in a dialog.  No command line
> > needed.
> >
> > So if LinuxCNC is to be used in windows getting rid of the "Linux Guru
> > required"  option is  a major feature.
> >
> > John
> 
> Are you talking about a regular file, or an executable?  Either way,
> you can right-click on an icon and adjust the properties there, and
> make the file executable if you wish, which has been available since
> at least 10.04 LTS..  All done through the GUI.  On my Ubuntu machines
> at home and work, I can drag and drop, or cut and paste.  Maybe that's
> a legacy of the version of Debian being used in the MachineKit port?
> 
> 
> Mark
> --
> One Man, One Machine, One Computer!  
> 
>

--
> ___
> 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] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Przemek Klosowski]

On Sun, Sep 20, 2015 at 11:47 AM, John Dammeyer 
wrote:

>
> And there in a nutshell is the reason Windows and Macs  outnumber Linux for
> PCs used by almost everyone.  Forcing someone to use the command line
> interface for a graphical user interface application is embedded into the
> brain of the Linux fans as "not a problem".  It is a problem!  A huge one!
>

Windows and Macs are very good at anticipating what you'll need and
providing a convenient GUI to accomplish that. The flip side of this is
that if your need happens not to be anticipated, you're Simply Out of Luck.
There's a nice way of saying this: "easy things are easy, but difficult
things are nigh impossible".
By the way, I use commandline on Windows a lot; pray tell, how to check
your IP address? You can click around in the network drivers trying to
remember how to get them up in this particular version of Windows, or just
hit the Windows key, and type cmd, and ipconfig. In general, I find it much
faster to use the Windows key and type the command (whether it's "word",
"firefox", "device manager", or whatever else), than hunt for the
particular place where this Windows and this user decided to place the
relevant icon. This is the part that people who complain about Windows 8
are missing---it simply doesn't matter that icons keep moving around if you
use the keyboard to say what you want.



> But for the Linux proponent I'm a troglodyte who just hasn't found the
> light
> of the wonders of Linux.
>

No, I do not consider you any of those things---I think people here just
are trying to tell you that you should learn that skill because it will
make you more productive. Maybe you'll even contribute a GUI shortcut for
the things that wre most annoying to you.
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Jon Elson]

On 09/20/2015 12:45 PM, Dave Cole wrote:
> John,
>
> Using the BBB is bleeding edge.  But you should know that if you are
> frequenting the Machinekit email list.
>
>
Actually, it is not so bleeding edge anymore.  There are 
apparently thousands of people using it, mostly on 3D 
printers, but also on routers and mills.  These all use the 
PRU to do essentially what external step generators do on 
X86 LinuxCNC systems.  This has been running for almost 2 
years, now.

Jon

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

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[John Dammeyer]

Ultimately remoting into the BBB still means learning two operating systems
when 99.9% of my work is done under Windows.  

To drag a drop a file onto the desktop on the Debian BBB MachineKit port
involves dragging it to the desktop folder and then using the ever present
and needed text editor to edit the shortcut to make it work properly with
the correct icon.  

In windows you drag it onto the desktop.  Period.  If you want to change
parameters right click and change stuff in a dialog.  No command line
needed. 

So if LinuxCNC is to be used in windows getting rid of the "Linux Guru
required"  option is  a major feature.

John

> -Original Message-
> From: Kyle Kerr [mailto:ker...@gmail.com]
> Sent: September-19-15 10:52 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM
> for LinuxCNC
> 
> 
> Maybe I don't understand what you are getting at. Why go through all the
> effort of breaking the software up between BBB and a Windows machine?
> Why
> not just remote in to the BBB and call it a day?
> 
> On Sat, Sep 19, 2015, 11:59 AM John Dammeyer <jo...@autoartisans.com>
> wrote:
> 
> > > On 19/09/15 05:55, John Dammeyer wrote:
> > > > WIN-8 and up don't support
> > > > parallel ports or even serial ports directly.
> > >
> > > 64bit windows does not support parallel port. Even on 32bit W10 it
still
> > > works fine ... I have some legacy kit which is still going strong but
we
> > > had to move off 32bit XP for some spurious reason ;) Running a couple
of
> > > serial ports as well, but I think they are OK on the 64bit builds as
> > well.
> > >
> > > --
> > > Lester Caine - G8HFL
> > Ah,  I didn't realize if you stayed 32 bit that support was still there.
> >
> > However, your previous posting about cross platform movement of
> LinuxCNC to
> > the Windows environment is interesting.
> >
> > The argument against it has always been that:
> > a)  hard real time is possible with Linux and isn't with Windows
> > b) low level access to the hardware allows closed loop servo control
with
> > expansion cards like MESA for servo's or steppers.
> >
> > So given the cost of a MESA or other expansion boards perhaps a tightly
> > coupled system using a BeagleBone Black (BBB) with a cape as the real
time
> > component and on a windows platform starts to make sense.  The BBB has
> both
> > USB and Ethernet.Also a lot more I/O if you don't use the HDMI video
> > capability.
> >
> > One doesn't even have to move it to Windows immediately.  It becomes a
> > 'hardware device' like a what's already out there for LinuxCNC.  It's
> > possible it can even keep the real time components used in the
MachineKit
> > port so it remains a Linux hosted processor.  So development and testing
> > become a two part project.
> >
> > 1. Move the motion part of LinuxCNC to the BBB via dedicated Ethernet
> > tcp/ip.  Requires second Ethernet port on workstation PC.  Surely
100Mbps
> > Ethernet can handle data motion and position feedback to LinuxCNC
> software
> > for screen updating and G-Code parsing.  The Smooth Stepper can do it at
a
> > lower level on the non-real time Windows so Linux should find this easy?
> >
> >  2. When that's working and tested, port the LinuxCNC non-hard real time
> > code to Windows C or C++ (not .NET though)
> >
> > There is a big plus to step 2 for the LinuxCNC community.  The act of
> > porting can result in code cleanup of LinuxCNC where normally sections
are
> > left alone because they work and there isn't any pressing need to change
> > them.  So old legacy stuff stays old even though now with experience it
> > could be improved.
> >
> > Perhaps this idea has been bounced around before.  But the BBB is not
like
> > the Raspberry PI or the Arduino.  It's got an extra  couple of 200MHz
> > hardware processors in addition to the 1GHz ARM.  The schematics and
> > software are all public.  The potential for an open source expansion is
> > mind
> > boggling.
> >
> > John
> >
> >
> >
> >
> >

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


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

Re: [Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[Kyle Kerr]

Maybe I don't understand what you are getting at. Why go through all the
effort of breaking the software up between BBB and a Windows machine? Why
not just remote in to the BBB and call it a day?

On Sat, Sep 19, 2015, 11:59 AM John Dammeyer  wrote:

> > On 19/09/15 05:55, John Dammeyer wrote:
> > > WIN-8 and up don't support
> > > parallel ports or even serial ports directly.
> >
> > 64bit windows does not support parallel port. Even on 32bit W10 it still
> > works fine ... I have some legacy kit which is still going strong but we
> > had to move off 32bit XP for some spurious reason ;) Running a couple of
> > serial ports as well, but I think they are OK on the 64bit builds as
> well.
> >
> > --
> > Lester Caine - G8HFL
> Ah,  I didn't realize if you stayed 32 bit that support was still there.
>
> However, your previous posting about cross platform movement of LinuxCNC to
> the Windows environment is interesting.
>
> The argument against it has always been that:
> a)  hard real time is possible with Linux and isn't with Windows
> b) low level access to the hardware allows closed loop servo control with
> expansion cards like MESA for servo's or steppers.
>
> So given the cost of a MESA or other expansion boards perhaps a tightly
> coupled system using a BeagleBone Black (BBB) with a cape as the real time
> component and on a windows platform starts to make sense.  The BBB has both
> USB and Ethernet.Also a lot more I/O if you don't use the HDMI video
> capability.
>
> One doesn't even have to move it to Windows immediately.  It becomes a
> 'hardware device' like a what's already out there for LinuxCNC.  It's
> possible it can even keep the real time components used in the MachineKit
> port so it remains a Linux hosted processor.  So development and testing
> become a two part project.
>
> 1. Move the motion part of LinuxCNC to the BBB via dedicated Ethernet
> tcp/ip.  Requires second Ethernet port on workstation PC.  Surely 100Mbps
> Ethernet can handle data motion and position feedback to LinuxCNC software
> for screen updating and G-Code parsing.  The Smooth Stepper can do it at a
> lower level on the non-real time Windows so Linux should find this easy?
>
>  2. When that's working and tested, port the LinuxCNC non-hard real time
> code to Windows C or C++ (not .NET though)
>
> There is a big plus to step 2 for the LinuxCNC community.  The act of
> porting can result in code cleanup of LinuxCNC where normally sections are
> left alone because they work and there isn't any pressing need to change
> them.  So old legacy stuff stays old even though now with experience it
> could be improved.
>
> Perhaps this idea has been bounced around before.  But the BBB is not like
> the Raspberry PI or the Arduino.  It's got an extra  couple of 200MHz
> hardware processors in addition to the 1GHz ARM.  The schematics and
> software are all public.  The potential for an open source expansion is
> mind
> boggling.
>
> John
>
>
>
>
> --
> ___
> 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

[Emc-users] Porting LinuxCNC(EMC) to Windows was CAD/CAM for LinuxCNC

[John Dammeyer]

> On 19/09/15 05:55, John Dammeyer wrote:
> > WIN-8 and up don't support
> > parallel ports or even serial ports directly.
> 
> 64bit windows does not support parallel port. Even on 32bit W10 it still
> works fine ... I have some legacy kit which is still going strong but we
> had to move off 32bit XP for some spurious reason ;) Running a couple of
> serial ports as well, but I think they are OK on the 64bit builds as well.
> 
> --
> Lester Caine - G8HFL
Ah,  I didn't realize if you stayed 32 bit that support was still there.

However, your previous posting about cross platform movement of LinuxCNC to
the Windows environment is interesting.  

The argument against it has always been that:
a)  hard real time is possible with Linux and isn't with Windows
b) low level access to the hardware allows closed loop servo control with
expansion cards like MESA for servo's or steppers.

So given the cost of a MESA or other expansion boards perhaps a tightly
coupled system using a BeagleBone Black (BBB) with a cape as the real time
component and on a windows platform starts to make sense.  The BBB has both
USB and Ethernet.Also a lot more I/O if you don't use the HDMI video
capability.

One doesn't even have to move it to Windows immediately.  It becomes a
'hardware device' like a what's already out there for LinuxCNC.  It's
possible it can even keep the real time components used in the MachineKit
port so it remains a Linux hosted processor.  So development and testing
become a two part project. 

1. Move the motion part of LinuxCNC to the BBB via dedicated Ethernet
tcp/ip.  Requires second Ethernet port on workstation PC.  Surely 100Mbps
Ethernet can handle data motion and position feedback to LinuxCNC software
for screen updating and G-Code parsing.  The Smooth Stepper can do it at a
lower level on the non-real time Windows so Linux should find this easy?

 2. When that's working and tested, port the LinuxCNC non-hard real time
code to Windows C or C++ (not .NET though) 

There is a big plus to step 2 for the LinuxCNC community.  The act of
porting can result in code cleanup of LinuxCNC where normally sections are
left alone because they work and there isn't any pressing need to change
them.  So old legacy stuff stays old even though now with experience it
could be improved.  

Perhaps this idea has been bounced around before.  But the BBB is not like
the Raspberry PI or the Arduino.  It's got an extra  couple of 200MHz
hardware processors in addition to the 1GHz ARM.  The schematics and
software are all public.  The potential for an open source expansion is mind
boggling.

John



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