Re: [Emc-users] A great goal - to make a interface for LiuxCNC to this stuff

[Jack Coats]

Hopefully, they are just trying to make a well defined, public, and easy
to use set of standards.  That is easy to document, implement, understand
(by less formally educated in the field), and use effectively and
efficiently.

All the things they are trying to bring together are well known methods and
processes.  But they SEEM to need to be re-build/re-designed/re-coded
with little re-use between implementations (except for general philosophy).

At least that is my current cut at it.
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] A great goal - to make a interface for LiuxCNC to this stuff

[Dave Cole]

I've done this before using conventional PLC controls, CNCs, and Robots.

With the fairly open protocols available now that run on Ethernet, it 
really isn't that difficult to establish communications using Modbus 
TCP, EthernetIP, etc.   LinuxCNC already supports Modbus and Modbus TCP.

I'm at a loss regarding what they are trying to standardize. Sounds like 
a solution looking for a problem.

Hard wired safeties are required to protect people but the same is not 
required to protect machines.  IE, if you crash a robot into a machine tool
OSHA does not come knocking. The conventional way to protect people 
is simply lock them out of the Robot cell.  If the cell door/gate is 
open, the machines are disabled.

Aram, I don't follow your comment about Siemens.   I am an ex-Siemens 
application engineer for their Automation products.

Dave

On 6/21/2014 10:39 PM, a k wrote:
> Hi
> I like video about Robot Integration.
> Why, because it talks about problem that i had - software integration etc.
> For sure for specialized software companies it is simple for example a
> SIEMENS .
>   And people that have engineering degree in electronics/electrical/software
>   engineering (or who spent long time working in related industries) - no
> problem to understand and use "building blocks" and do everything with it.
> Why i mentioned about SIEMENS ?
> ones i work in http://www.leupold.com/ and they mostly use machine
> http://www.indextraub.com/
> http://www.index-werke.de/ic/englisch/index_ENU_HTML.htm
>   to make tubular parts for scope.
> Interesting is that they use robot that takes semi finish part from one
> machine and puts it in second and than in third machine.
>
> I can see that SIEMENS -engineer can call everyone else-- "bottomless pit"
> etc,  but do they really do that?
>
> aram
>
>
> On Sat, Jun 21, 2014 at 10:21 AM, Roland Jollivet > wrote:
>> Most Injection moulding machines use a 'Euromap" interface for robots. Been
>> around for a while, but obviously European. I don't know what lathes or
>> milling machines have.
>>
>> My feeling is that any machine only needs a few parallel lines to signify
>> status. The interaction is usually at a very simple level in any case. The
>> critical part is the validity and reliability of the handshake signal.
>>
>> It is sometimes prudent to add additional hardware switches to doors or
>> arms to safeguard each machine from the other as well as the operators. I
>> would be loathe to rely on a serial interface. It's a bit like the scenario
>> of a software versus hardware Estop. Accidents happen when people change
>> configs, or run a different job without the right settings. However, they
>> are very unlikely to remove a hard-wired door switch.
>>
>> I suppose you could have both; passing serial info and hard-wired safety
>> interlocks.
>>
>> Roland
>>
>>
>>
>> On 21 June 2014 18:37, Jack Coats  wrote:
>>
>>> Thanks for all the replies.
>>>
>>> It sounds like that this can be done by folks that know more than I do.
>>> I am guessing, we may need an 'appropriate' interface (possibly something
>>> like
>>> lynx with some glue code) to read web posting from other machines and
>>> be able to read those settings with an interface to HAL.
>>>
>>> Another thing to take outputs from HAL and be able to post them on a
>>> simple web server (possibly dynamic pages that query HAL settings or
>>> variables upon request).
>>>
>>> Ok all that is from not knowing much about HAL.  This is just a suggested
>>> thumbnail of a design.  I am sure others can do much better!
>>>
>>> I agree with Gene.  Thanks to all the talented folks that can and do
>>> support
>>> LinuxCNC in every way!  We don't want to turn this into a attaboy
>> session,
>>> but I cannot deny they are well warranted!  So thank you, for all you
>> have
>>> done and will do.
>>>
>>>
>>>
>>> On Sat, Jun 21, 2014 at 10:30 AM, Gene Heskett 
>> wrote:
 On Saturday 21 June 2014 09:44:36 Jack Coats did opine
 And Gene did reply:
> http://youtu.be/hnDKqr-g3t4
>
> Any ideas on how to implement this kind of thing?
>
> I know it is more than I have the ability for, but it could be a
> fantastic edition that allows
> LinuxCNC to be even more useful to small businesses.
>
>> <> ... Jack
 I think so too Jack, but at the same time, with our ability to build
 custom Mwords, and carve up hal files, I would state that the limits of
 what LCNC can do right now, are far from being fully explored.  I can
 envision a row of machines, each doing a specific operation to work
>> mount
 on a pallet, with nothing more than a tally signal to indicate state of
 each machine, busy or finished, that in turn tells the robot to unload
 that pallet, park it, and get another pallet and reload that particular
 machine.  Each machine would be running at its own best pace so the
 overall production would be limited by the slowest operation of course,
 but still, with say 5 o

Re: [Emc-users] A great goal - to make a interface for LiuxCNC to this stuff

[a k]

Hi
I like video about Robot Integration.
Why, because it talks about problem that i had - software integration etc.
For sure for specialized software companies it is simple for example a
SIEMENS .
 And people that have engineering degree in electronics/electrical/software
 engineering (or who spent long time working in related industries) - no
problem to understand and use "building blocks" and do everything with it.
Why i mentioned about SIEMENS ?
ones i work in http://www.leupold.com/ and they mostly use machine
http://www.indextraub.com/
http://www.index-werke.de/ic/englisch/index_ENU_HTML.htm
 to make tubular parts for scope.
Interesting is that they use robot that takes semi finish part from one
machine and puts it in second and than in third machine.

I can see that SIEMENS -engineer can call everyone else-- "bottomless pit"
etc,  but do they really do that?

aram


On Sat, Jun 21, 2014 at 10:21 AM, Roland Jollivet  wrote:

> Most Injection moulding machines use a 'Euromap" interface for robots. Been
> around for a while, but obviously European. I don't know what lathes or
> milling machines have.
>
> My feeling is that any machine only needs a few parallel lines to signify
> status. The interaction is usually at a very simple level in any case. The
> critical part is the validity and reliability of the handshake signal.
>
> It is sometimes prudent to add additional hardware switches to doors or
> arms to safeguard each machine from the other as well as the operators. I
> would be loathe to rely on a serial interface. It's a bit like the scenario
> of a software versus hardware Estop. Accidents happen when people change
> configs, or run a different job without the right settings. However, they
> are very unlikely to remove a hard-wired door switch.
>
> I suppose you could have both; passing serial info and hard-wired safety
> interlocks.
>
> Roland
>
>
>
> On 21 June 2014 18:37, Jack Coats  wrote:
>
> > Thanks for all the replies.
> >
> > It sounds like that this can be done by folks that know more than I do.
> > I am guessing, we may need an 'appropriate' interface (possibly something
> > like
> > lynx with some glue code) to read web posting from other machines and
> > be able to read those settings with an interface to HAL.
> >
> > Another thing to take outputs from HAL and be able to post them on a
> > simple web server (possibly dynamic pages that query HAL settings or
> > variables upon request).
> >
> > Ok all that is from not knowing much about HAL.  This is just a suggested
> > thumbnail of a design.  I am sure others can do much better!
> >
> > I agree with Gene.  Thanks to all the talented folks that can and do
> > support
> > LinuxCNC in every way!  We don't want to turn this into a attaboy
> session,
> > but I cannot deny they are well warranted!  So thank you, for all you
> have
> > done and will do.
> >
> >
> >
> > On Sat, Jun 21, 2014 at 10:30 AM, Gene Heskett 
> wrote:
> >
> > > On Saturday 21 June 2014 09:44:36 Jack Coats did opine
> > > And Gene did reply:
> > > > http://youtu.be/hnDKqr-g3t4
> > > >
> > > > Any ideas on how to implement this kind of thing?
> > > >
> > > > I know it is more than I have the ability for, but it could be a
> > > > fantastic edition that allows
> > > > LinuxCNC to be even more useful to small businesses.
> > > >
> > > > ><> ... Jack
> > >
> > > I think so too Jack, but at the same time, with our ability to build
> > > custom Mwords, and carve up hal files, I would state that the limits of
> > > what LCNC can do right now, are far from being fully explored.  I can
> > > envision a row of machines, each doing a specific operation to work
> mount
> > > on a pallet, with nothing more than a tally signal to indicate state of
> > > each machine, busy or finished, that in turn tells the robot to unload
> > > that pallet, park it, and get another pallet and reload that particular
> > > machine.  Each machine would be running at its own best pace so the
> > > overall production would be limited by the slowest operation of course,
> > > but still, with say 5 or 6 machines in a row, it would outrun a human
> > > trying to keep up.
> > >
> > > That doesn't neutralize the fact that 99% of such setups are going to
> be
> > > one offs though.  And they will need someone familiar enough with that
> > > setup to reset/reprogram it for the next, different part.  It will also
> > > need, built into each machine, or into the robot, a means of servicing
> > > dull tooling.
> > >
> > > Code for an individual operation will tend to be made into reusable
> > > modules, perhaps even taking stored in memory, globally named values
> for
> > > how deep this hole is going to be, set by the master program.
> > >
> > > I don't think any of this is beyond what LCNC can do right now.
> >  Obviously
> > > not thru the pin limited parport, but folks like PCW sell the stuff to
> > > blow that limit into the next drainage.
> > >
> > > I'm your old fart here, but every time I come across a

Re: [Emc-users] A great goal - to make a interface for LiuxCNC to this stuff

[Gregg Eshelman]

On 6/21/2014 11:21 AM, Roland Jollivet wrote:

> It is sometimes prudent to add additional hardware switches to doors or
> arms to safeguard each machine from the other as well as the operators. I
> would be loathe to rely on a serial interface. It's a bit like the scenario
> of a software versus hardware Estop. Accidents happen when people change
> configs, or run a different job without the right settings. However, they
> are very unlikely to remove a hard-wired door switch.

The classic case of failure from relying solely on software for safety 
was the Therac 25. The models it replaced were already poorly designed 
but had mechanical switches and fuses that would pop if things went worng.

The 25 had no major differences in its software, but eliminated all the 
mechanical interlocks and fuses so when an experienced operator got 
ahead of the software it could fire whatever amount of radiation it had 
ready, from next to zero to a lethal blast. On top of that it had a bug 
with a rollover timer and a trigger in the treatment chamber. If the 
operator pressed the fire button at the instant the timer rolled over it 
did the uncontrolled firing thing.

One of the problems was a race condition between code that accepted 
operator input and code that setup the system to adjust the radiation 
dose. There was no check for proper settings before firing, the 
programmers just assumed no operator would be quick enough to input the 
parameters and hit the fire button before the machine was ready.

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] A great goal - to make a interface for LiuxCNC to this stuff

[Jack Coats]

Thanks for all the replies.

It sounds like that this can be done by folks that know more than I do.
I am guessing, we may need an 'appropriate' interface (possibly something
like
lynx with some glue code) to read web posting from other machines and
be able to read those settings with an interface to HAL.

Another thing to take outputs from HAL and be able to post them on a
simple web server (possibly dynamic pages that query HAL settings or
variables upon request).

Ok all that is from not knowing much about HAL.  This is just a suggested
thumbnail of a design.  I am sure others can do much better!

I agree with Gene.  Thanks to all the talented folks that can and do support
LinuxCNC in every way!  We don't want to turn this into a attaboy session,
but I cannot deny they are well warranted!  So thank you, for all you have
done and will do.



On Sat, Jun 21, 2014 at 10:30 AM, Gene Heskett  wrote:

> On Saturday 21 June 2014 09:44:36 Jack Coats did opine
> And Gene did reply:
> > http://youtu.be/hnDKqr-g3t4
> >
> > Any ideas on how to implement this kind of thing?
> >
> > I know it is more than I have the ability for, but it could be a
> > fantastic edition that allows
> > LinuxCNC to be even more useful to small businesses.
> >
> > ><> ... Jack
>
> I think so too Jack, but at the same time, with our ability to build
> custom Mwords, and carve up hal files, I would state that the limits of
> what LCNC can do right now, are far from being fully explored.  I can
> envision a row of machines, each doing a specific operation to work mount
> on a pallet, with nothing more than a tally signal to indicate state of
> each machine, busy or finished, that in turn tells the robot to unload
> that pallet, park it, and get another pallet and reload that particular
> machine.  Each machine would be running at its own best pace so the
> overall production would be limited by the slowest operation of course,
> but still, with say 5 or 6 machines in a row, it would outrun a human
> trying to keep up.
>
> That doesn't neutralize the fact that 99% of such setups are going to be
> one offs though.  And they will need someone familiar enough with that
> setup to reset/reprogram it for the next, different part.  It will also
> need, built into each machine, or into the robot, a means of servicing
> dull tooling.
>
> Code for an individual operation will tend to be made into reusable
> modules, perhaps even taking stored in memory, globally named values for
> how deep this hole is going to be, set by the master program.
>
> I don't think any of this is beyond what LCNC can do right now.  Obviously
> not thru the pin limited parport, but folks like PCW sell the stuff to
> blow that limit into the next drainage.
>
> I'm your old fart here, but every time I come across an operation that my
> toys can't do, I find its usually nothing more than a dozen or so more
> lines in the hal file to make it do it, G33.1 for instance on a lathe with
> a single quadrant spindle drive.  A few lines of hal to synthesize the
> stop missing from G33.1 when it turns around, a triplet of ice cube relays
> to rig up dynamic braking, staged in effect by 2 more relays from the
> instantly known spindle speed, and a loop of gcode running g33.1 with
> variable arguments each pass thru the loop, and I can put a 1/4" or 6mm
> tap, in a drill chuck mounted in a boring bar holder, and I can tap that
> hole an inch deep (or however long the tap is) without stressing the tap.
> I program it to pull the tap out far enough I have time to blow it clean
> and drop enough cutting oil on it for the next pass back in, usually going
> between 1/2 and 3/4 turn farther each time.
>
> The only problem with that I found while cutting air, is that if it hits
> the -z limit set in the .ini file, a g33.1 comes uncoupled at the limit,
> the carriage stops moving until the spindle has completed the reverse and
> the phantom Z comes back past that limit, at which point the carriage
> resumes tracking the rigid tapping motion for the back out move.  Found by
> cutting air so no broken tap (yet).
>
> Thats why, at nearly 300 LOC, my hal file for a puny little 7x12 seems to
> be the longest hal file extant here. But it works.
>
> I won't say its unlimited, but we have NOT fully explored what it can do
> right now.
>
> We certainly have no shortage of talented people here who CAN do this
> stuff.  And I thank them for these tools every time I open the shop door.
> But not loud enough I fear.  Thank you all.
>
> 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 
> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
>
>
> --
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in

Re: [Emc-users] A great goal - to make a interface for LiuxCNC to this stuff

[Gene Heskett]

On Saturday 21 June 2014 09:44:36 Jack Coats did opine
And Gene did reply:
> http://youtu.be/hnDKqr-g3t4
> 
> Any ideas on how to implement this kind of thing?
> 
> I know it is more than I have the ability for, but it could be a
> fantastic edition that allows
> LinuxCNC to be even more useful to small businesses.
> 
> ><> ... Jack

I think so too Jack, but at the same time, with our ability to build 
custom Mwords, and carve up hal files, I would state that the limits of 
what LCNC can do right now, are far from being fully explored.  I can 
envision a row of machines, each doing a specific operation to work mount 
on a pallet, with nothing more than a tally signal to indicate state of 
each machine, busy or finished, that in turn tells the robot to unload 
that pallet, park it, and get another pallet and reload that particular 
machine.  Each machine would be running at its own best pace so the 
overall production would be limited by the slowest operation of course, 
but still, with say 5 or 6 machines in a row, it would outrun a human 
trying to keep up.

That doesn't neutralize the fact that 99% of such setups are going to be 
one offs though.  And they will need someone familiar enough with that 
setup to reset/reprogram it for the next, different part.  It will also 
need, built into each machine, or into the robot, a means of servicing 
dull tooling.

Code for an individual operation will tend to be made into reusable 
modules, perhaps even taking stored in memory, globally named values for 
how deep this hole is going to be, set by the master program.

I don't think any of this is beyond what LCNC can do right now.  Obviously 
not thru the pin limited parport, but folks like PCW sell the stuff to 
blow that limit into the next drainage.

I'm your old fart here, but every time I come across an operation that my 
toys can't do, I find its usually nothing more than a dozen or so more 
lines in the hal file to make it do it, G33.1 for instance on a lathe with 
a single quadrant spindle drive.  A few lines of hal to synthesize the 
stop missing from G33.1 when it turns around, a triplet of ice cube relays 
to rig up dynamic braking, staged in effect by 2 more relays from the 
instantly known spindle speed, and a loop of gcode running g33.1 with 
variable arguments each pass thru the loop, and I can put a 1/4" or 6mm 
tap, in a drill chuck mounted in a boring bar holder, and I can tap that 
hole an inch deep (or however long the tap is) without stressing the tap.  
I program it to pull the tap out far enough I have time to blow it clean 
and drop enough cutting oil on it for the next pass back in, usually going 
between 1/2 and 3/4 turn farther each time.

The only problem with that I found while cutting air, is that if it hits 
the -z limit set in the .ini file, a g33.1 comes uncoupled at the limit, 
the carriage stops moving until the spindle has completed the reverse and 
the phantom Z comes back past that limit, at which point the carriage 
resumes tracking the rigid tapping motion for the back out move.  Found by 
cutting air so no broken tap (yet).

Thats why, at nearly 300 LOC, my hal file for a puny little 7x12 seems to 
be the longest hal file extant here. But it works.

I won't say its unlimited, but we have NOT fully explored what it can do 
right now.

We certainly have no shortage of talented people here who CAN do this 
stuff.  And I thank them for these tools every time I open the shop door.  
But not loud enough I fear.  Thank you all.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] A great goal - to make a interface for LiuxCNC to this stuff

[Dave Caroline]

Looks like a hal or user space mtconnect needs writing then it should
just work TM when an integrator adds it to his machine (lathe/mill)
along with a network interface.

As for the ROS to linuxcnc interface I leave that as an exercise.

Dave Caroline

On 21/06/2014, Jack Coats  wrote:
> http://youtu.be/hnDKqr-g3t4
>
> Any ideas on how to implement this kind of thing?
>
> I know it is more than I have the ability for, but it could be a fantastic
> edition that allows
> LinuxCNC to be even more useful to small businesses.
>
> --
>><> ... Jack
> --
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] A great goal - to make a interface for LiuxCNC to this stuff

[TJoseph Powderly]

On 06/21/2014 08:44 AM, Jack Coats wrote:
> http://youtu.be/hnDKqr-g3t4
>
> Any ideas on how to implement this kind of thing?
>
> I know it is more than I have the ability for, but it could be a fantastic
> edition that allows
> LinuxCNC to be even more useful to small businesses.
>
wow
watch http://www.youtube.com/watch?v=hnDKqr-g3t4&feature=youtu.be
to see Fred Proctor
one of the original EMC devs

this is again a great idea
the pessimist in me says the cnc mfctrs will adapt it as they did the 
EMC recommendations.
the optimist sez "have at it!"

tjtr33

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users