[Emc-users] multiple gcode streams in parallel

2015-09-25 Thread Roland Jollivet 
Have you looked at this? ;

http://www.jrkerr.com/

Regards
Roland


On 24 September 2015 at 17:05, Jerry Scharf  wrote:

> Hi,
>
> These are two completely independent machines with no coordination. Many
> times only 1 will be operating. I am trying to work out what happens when
> both are operating at the same time. It would be simpler to have two
> separate controller, but that's not where we are at right now.
>
> jerry
>
> On Thu, Sep 24, 2015 at 6:23 AM, TJoseph Powderly 
> wrote:
>
> > It doesnt sound like the task is well defined here on mail list.
> >
> > If the 2 independent(?) systems do not require interpolation _between_
> > them, then M65 thru M66 could provide the 'handshaking'.
> > Each would have a 'busy' and a 'fin' signal.
> > This is extremely sequential.
> >
> > Else please explain more,
> > and what did you see happen when
> > ~"it didnt seem ready to accept commands" ?
> >
> > TomP tjtr33
> >
> > On 09/24/2015 03:00 AM, Gregg Eshelman wrote:
> > > On 9/24/2015 12:57 AM, Dave Caroline wrote:
> > >> might be better to let the two talk to each other in some way so move
> > >> starts/runs are really synchronised properly rather than rely on
> > >> buffers.
> > >> eg classic ladder or some clocking or whatever
> > >>
> > >> Dave Caroline
> > >
> > > That sounds good. What you Do Not Want is a race condition where you
> > > have two or more independent parallel processes with nothing to ensure
> > > they always complete in the correct order.
> > >
> > > For an example of what can happen, google Therac 25
> > >
> >
> >
> >
> >
> --
> > 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&iu=/4140
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
>
>
> --
> Jerry Scharf
> FINsix IT
> 650.285.6361 w
> 650.279.7017 m
>
> --
> 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&iu=/4140
> ___
> 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] Keeping track of machine (g53) position

2015-09-25 Thread andy pugh 
On 25 September 2015 at 05:35, Gene Heskett  wrote:
> This means I have to pre-position it above the switch or it runs the
> wrong direction looking for it.
>
> Is there some way to make that initial search direction automatic?

You can make the search velocity negative to search upwards.
You would need to make the switch actuator longer to stop it searching
upwards if it was already above the switch.
(ie, you can tell it which way to search, but it can't know that it is
already bast the switch)

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

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

Re: [Emc-users] linuxcnc.org website layout

2015-09-25 Thread Axel Zöllich 
> done

Perfect, thank you.

Axel

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

Re: [Emc-users] Keeping track of machine (g53) position

2015-09-25 Thread Gene Heskett 
On Friday 25 September 2015 08:07:55 andy pugh wrote:

> On 25 September 2015 at 05:35, Gene Heskett  wrote:
> > This means I have to pre-position it above the switch or it runs the
> > wrong direction looking for it.
> >
> > Is there some way to make that initial search direction automatic?
>
> You can make the search velocity negative to search upwards.
> You would need to make the switch actuator longer to stop it searching
> upwards if it was already above the switch.
> (ie, you can tell it which way to search, but it can't know that it is
> already bast the switch)
Teeny roller tiped microswitches.  The pointer/cam that actuates it can 
roll right on by with no damage to the switch.  I had installed the 
pointer, then the switch but due to the lay of the casting at the top of 
the post, I was forced to put the switch at about 45mm's below the top 
of the post.  Mechanically, the nut holder shank for the ball nut hits 
the top of the slot when the sled is still about 2mm down from flush 
with the post top.

So, to get the pointer in a position where the limits would keep it from 
ever going on by the switch, I'd need to move the pointer down on the 
edge of the sled by 40+ mm's.  I should make a new pointer with a wider 
base and slots so I could adjust it I guess, drilling and tapping 2 new 
holes in the sled.

My switches are all on one wire, so the homing is sequential, Z first for 
obvious reasons.

What I was hoping for, without hacking up some hal memory, was that 
motion was aware of a switch closing and opening if it went by them in 
normal programmed motions, and was recording which direction the machine 
was moving the last time the switches opened.  That could then be 
consulted when the home all command was issued, to determine which side 
of the switch it was on, and that to find it, it needed to move toward 
it, then once found, the normal 2nd & slower phase of fine tuning the 
home would then be resumed.  All that would take is the sign of the 
motion, which could then be used to diddle the sign of the 
HOME_SEARCH_VELOCITY.

Not impossible IF the HOME_SEARCH_VELOCITY's were routed to motion by way 
of the hal engine. Or even by the interpreter, which can invert the sign 
of a # by the -# syntax.

I may do some "motion" detective work. I see output signals aplenty, but 
not all the inputs seem to be listed.  I was TBT, hoping I didn't have 
to re-invent the wheel. Sometimes mine don't roll so well until well 
past version 0.5. :(

In the meantime, I'll go see about moving the pointer.

Thanks Andy.
 
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] Keeping track of machine (g53) position

2015-09-25 Thread John Kasunich 


On Fri, Sep 25, 2015, at 12:00 PM, Gene Heskett wrote:

> 
> What I was hoping for, without hacking up some hal memory, was that 
> motion was aware of a switch closing and opening if it went by them in 
> normal programmed motions, and was recording which direction the machine 
> was moving the last time the switches opened.  That could then be 
> consulted when the home all command was issued, to determine which side 
> of the switch it was on, and that to find it, it needed to move toward 
> it, then once found, the normal 2nd & slower phase of fine tuning the 
> home would then be resumed.  All that would take is the sign of the 
> motion, which could then be used to diddle the sign of the 
> HOME_SEARCH_VELOCITY.

This cannot work.  Remembering where you are while running is one thing.
Starting up is another.  When the machine is powered up it has no way of
knowing which side of the switch it is on.  Storing the info somewhere is not
the answer - maybe the axis was moved manually (or even completely 
disassembled for repairs) since the last time the control was powered.
If the control doesn't know which side of the switch it is on, an attempt to
home has a 50% chance of running the axis into the hard stops.  Maybe
no big deal on a bench-top stepper machine.  Completely unacceptable
on an industrial class machine.

The proper answer is a long actuator for the switch, so that once the switch
is activated, it stays activated all the way to the end of the axis.

-- 
  John Kasunich
  jmkasun...@fastmail.fm

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

Re: [Emc-users] More Keeping track of machine (g53) position

2015-09-25 Thread Gene Heskett 
On Friday 25 September 2015 12:00:27 Gene Heskett wrote:

[...]

> In the meantime, I'll go see about moving the pointer.

Did that so it cannot mechanically rise far enough to open the switch, 
then parked it a mm down so the dro says -1.000mm after homed & reset 
the software up limit so it can just about touch the switch.

Then, because I've had the same which way problem on the x home, 
requiring I drive it by hand to the correct side of the switch before 
homing, so I moved the round quasi roller in the groove in the front of 
the table to the right several inches and re-adjusted the X home_offset 
to leave it parked well centered.

And I found my problem with the Tornach adapters ill fitting nut.
Not PEBKAC but PEBWAU (problem between wrench and user)

It seems that to properly engage the nut and collet, the collet MUST be 
empty so it can collapse enough to snap the nuts eccentric ridge into 
the mating groove in the collet.  /Then/ insert the tool, /then/ screw 
the but back onto the bottom of the adapter.  And then tighten 
everything to within 1/16th turn from stripped. Including the R8 drawbar 
bolt...  I will be turning the air blue if it drops another tool like it 
did yesterday, but it sure feels nice & smooth while tightening the nut 
now.

Off to go and make another stick of kindling out of some pine. :)

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] Keeping track of machine (g53) position

2015-09-25 Thread Gene Heskett 
On Friday 25 September 2015 13:31:03 John Kasunich wrote:

> On Fri, Sep 25, 2015, at 12:00 PM, Gene Heskett wrote:
> > What I was hoping for, without hacking up some hal memory, was that
> > motion was aware of a switch closing and opening if it went by them
> > in normal programmed motions, and was recording which direction the
> > machine was moving the last time the switches opened.  That could
> > then be consulted when the home all command was issued, to determine
> > which side of the switch it was on, and that to find it, it needed
> > to move toward it, then once found, the normal 2nd & slower phase of
> > fine tuning the home would then be resumed.  All that would take is
> > the sign of the motion, which could then be used to diddle the sign
> > of the
> > HOME_SEARCH_VELOCITY.
>
> This cannot work.  Remembering where you are while running is one
> thing. Starting up is another.  When the machine is powered up it has
> no way of knowing which side of the switch it is on.  Storing the info
> somewhere is not the answer - maybe the axis was moved manually (or
> even completely disassembled for repairs) since the last time the
> control was powered. If the control doesn't know which side of the
> switch it is on, an attempt to home has a 50% chance of running the
> axis into the hard stops.  Maybe no big deal on a bench-top stepper
> machine.  Completely unacceptable on an industrial class machine.
>
> The proper answer is a long actuator for the switch, so that once the
> switch is activated, it stays activated all the way to the end of the
> axis.

Or, as I just did, move the switch so it can't go on by it. :)

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] Keeping track of machine (g53) position

2015-09-25 Thread Todd Zuercher 
That is how most of the commercial machines we have do it. (several Fanuc 
machines and a couple of others) The only Fanuc machines we have that don't 
home this way have battery backed up absolute encoders and don't have any home 
or even limit switches at all. Ones with home switches usually have a long 
ramped platau 3-6" long that triggers the home switch before the limit.

- Original Message -
From: "John Kasunich" 
To: emc-users@lists.sourceforge.net
Sent: Friday, September 25, 2015 1:31:03 PM
Subject: Re: [Emc-users] Keeping track of machine (g53) position



On Fri, Sep 25, 2015, at 12:00 PM, Gene Heskett wrote:

> 
> What I was hoping for, without hacking up some hal memory, was that 
> motion was aware of a switch closing and opening if it went by them in 
> normal programmed motions, and was recording which direction the machine 
> was moving the last time the switches opened.  That could then be 
> consulted when the home all command was issued, to determine which side 
> of the switch it was on, and that to find it, it needed to move toward 
> it, then once found, the normal 2nd & slower phase of fine tuning the 
> home would then be resumed.  All that would take is the sign of the 
> motion, which could then be used to diddle the sign of the 
> HOME_SEARCH_VELOCITY.

This cannot work.  Remembering where you are while running is one thing.
Starting up is another.  When the machine is powered up it has no way of
knowing which side of the switch it is on.  Storing the info somewhere is not
the answer - maybe the axis was moved manually (or even completely 
disassembled for repairs) since the last time the control was powered.
If the control doesn't know which side of the switch it is on, an attempt to
home has a 50% chance of running the axis into the hard stops.  Maybe
no big deal on a bench-top stepper machine.  Completely unacceptable
on an industrial class machine.

The proper answer is a long actuator for the switch, so that once the switch
is activated, it stays activated all the way to the end of the axis.

-- 
  John Kasunich
  jmkasun...@fastmail.fm

--
___
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] multiple gcode streams in parallel

2015-09-25 Thread Ron Ginger 
Mach4 Industrial allows multiple instances of the full system including 
gcode interpretation. It is only being supported with 6 instances but 
the design is not limited. Lua scripts can start with

inst = mc.mcGetInstance()

if (inst == 0) then

so full coordination between instances and scripts is possible.

I talked to Brian Barker about this and he said it was one of the base 
design considerations on Mach4 and not likely to be something that could 
be added under existing code.

ron ginger


> On 24 September 2015 at 17:05, Jerry Scharf  wrote:
>
>> >Hi,
>> >
>> >These are two completely independent machines with no coordination. Many
>> >times only 1 will be operating. I am trying to work out what happens when
>> >both are operating at the same time. It would be simpler to have two
>> >separate controller, but that's not where we are at right now.
>> >
>> >jerry


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

Re: [Emc-users] multiple gcode streams in parallel

2015-09-25 Thread Dave Cole 
On 9/25/2015 4:31 PM, Ron Ginger wrote:
> Mach4 Industrial allows multiple instances of the full system including
> gcode interpretation. It is only being supported with 6 instances but
> the design is not limited.

That's really nice!  :-)

Dave

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