Discussion:
[Emc-developers] Reverse Run
Robert Ellenberg
2015-04-09 00:25:57 UTC
Permalink
Hi All,

I've been playing around with reverse run for the last few days, and I
think I have a crude but working solution based off of 2.7. Here's a branch
on my github repo that has an example (also pushed to the official repo to
run on the buildbot):

https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/reverse-run-2.7

The major changes are in motion / TP, but I also set up a quick way to test
using axis. I added 2 new key bindings to axis to enable / disable reverse
run:

SHIFT + R = reverse run (only switches while paused)
SHIFT + F = forward run (default, only switches while paused)

Here's the behavior I was going for (tested so far against some examples of
each):

- Be able to reverse run up to about 20 segments
- only allow exact-stop motion in reverse (adding blending is a much
bigger change)
- Do not allow reversing through spindle-sync moves or at-speed moves

There are definitely some warts in this code I'd like to clean up before
merging, but it should be test-ready at least. As always, if you find
anything wrong or have ideas for how to improve this, let me know and I'll
take a stab at it.

Best,
-Rob
andy pugh
2015-04-09 00:30:25 UTC
Permalink
Post by Robert Ellenberg
I've been playing around with reverse run for the last few days,
Oooh! That would be very nice for wire-eroders
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
Sebastian Kuzminsky
2015-04-09 00:34:23 UTC
Permalink
Post by andy pugh
Post by Robert Ellenberg
I've been playing around with reverse run for the last few days,
Oooh! That would be very nice for wire-eroders
And possibly for an in-controller moveoff.

Robert, what motivated you to start implementing this?
--
Sebastian Kuzminsky
Robert Ellenberg
2015-04-09 03:24:55 UTC
Permalink
People have been asking about that for a while, and I just never got around
to it until now (other things going on). I thing EDM is a great
application, though I'm sure there are others.
Post by andy pugh
Post by Robert Ellenberg
I've been playing around with reverse run for the last few days,
Oooh! That would be very nice for wire-eroders
And possibly for an in-controller moveoff.

Robert, what motivated you to start implementing this?


--
Sebastian Kuzminsky

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
sam sokolik
2015-04-09 02:05:25 UTC
Permalink
well that is pretty darn neat..

couple issues I found
-the first time you hit play after pausing and reversing the motion
(while still paused) - no movement.
-if you reverse run to the end of 20 segments (either manually or
unpausing) you cannot get it move anymore. shift-f will not go forward
again.

sam
Post by Robert Ellenberg
Hi All,
I've been playing around with reverse run for the last few days, and I
think I have a crude but working solution based off of 2.7. Here's a branch
on my github repo that has an example (also pushed to the official repo to
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/reverse-run-2.7
The major changes are in motion / TP, but I also set up a quick way to test
using axis. I added 2 new key bindings to axis to enable / disable reverse
SHIFT + R = reverse run (only switches while paused)
SHIFT + F = forward run (default, only switches while paused)
Here's the behavior I was going for (tested so far against some examples of
- Be able to reverse run up to about 20 segments
- only allow exact-stop motion in reverse (adding blending is a much
bigger change)
- Do not allow reversing through spindle-sync moves or at-speed moves
There are definitely some warts in this code I'd like to clean up before
merging, but it should be test-ready at least. As always, if you find
anything wrong or have ideas for how to improve this, let me know and I'll
take a stab at it.
Best,
-Rob
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
Robert Ellenberg
2015-04-09 03:29:55 UTC
Permalink
Post by sam sokolik
well that is pretty darn neat..
couple issues I found
-the first time you hit play after pausing and reversing the motion
(while still paused) - no movement.
Hmm, I'll try to reproduce this and see. If I can track down the cause.
Post by sam sokolik
-if you reverse run to the end of 20 segments (either manually or
unpausing) you cannot get it move anymore. shift-f will not go forward
again.
That happens because it has to be paused to switch direction, so you have
to manually pause it, then switch to forward, then resume. I'm looking into
a way to automatically pause when it runs out of reverse motion. One issue
I have with this now is that the pause button in axis doesn't show the
correct state if tpPause is called within motion at an arbitrary time. That
could be something I'm doing wrong, though. I'll take another look and see
what I can find.
Post by sam sokolik
sam
Post by Robert Ellenberg
Hi All,
I've been playing around with reverse run for the last few days, and I
think I have a crude but working solution based off of 2.7. Here's a branch
on my github repo that has an example (also pushed to the official repo to
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/reverse-run-2.7
Post by sam sokolik
Post by Robert Ellenberg
The major changes are in motion / TP, but I also set up a quick way to test
using axis. I added 2 new key bindings to axis to enable / disable reverse
SHIFT + R = reverse run (only switches while paused)
SHIFT + F = forward run (default, only switches while paused)
Here's the behavior I was going for (tested so far against some examples of
- Be able to reverse run up to about 20 segments
- only allow exact-stop motion in reverse (adding blending is a much
bigger change)
- Do not allow reversing through spindle-sync moves or at-speed moves
There are definitely some warts in this code I'd like to clean up before
merging, but it should be test-ready at least. As always, if you find
anything wrong or have ideas for how to improve this, let me know and I'll
take a stab at it.
Best,
-Rob
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by sam sokolik
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
sam sokolik
2015-04-09 11:32:00 UTC
Permalink
The latest pushes you did work a lot better. I do see movement when
switching from reverse to forward in some situations that i have not
figured out. Seem more common when you run it all the way back 20
segments then shift+f -> movement.

I did get it to be unresponsive once also (have not figured out the steps).

I think for it to work with edm - (or other applications) there needs to
be a hal pin motion.reverse-run or some such thing..

Very cool - nice work!
sam
Post by Robert Ellenberg
Post by sam sokolik
well that is pretty darn neat..
couple issues I found
-the first time you hit play after pausing and reversing the motion
(while still paused) - no movement.
Hmm, I'll try to reproduce this and see. If I can track down the cause.
Post by sam sokolik
-if you reverse run to the end of 20 segments (either manually or
unpausing) you cannot get it move anymore. shift-f will not go forward
again.
That happens because it has to be paused to switch direction, so you have
to manually pause it, then switch to forward, then resume. I'm looking into
a way to automatically pause when it runs out of reverse motion. One issue
I have with this now is that the pause button in axis doesn't show the
correct state if tpPause is called within motion at an arbitrary time. That
could be something I'm doing wrong, though. I'll take another look and see
what I can find.
Post by sam sokolik
sam
Post by Robert Ellenberg
Hi All,
I've been playing around with reverse run for the last few days, and I
think I have a crude but working solution based off of 2.7. Here's a
branch
Post by sam sokolik
Post by Robert Ellenberg
on my github repo that has an example (also pushed to the official repo
to
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/reverse-run-2.7
Post by sam sokolik
Post by Robert Ellenberg
The major changes are in motion / TP, but I also set up a quick way to
test
Post by sam sokolik
Post by Robert Ellenberg
using axis. I added 2 new key bindings to axis to enable / disable
reverse
Post by sam sokolik
Post by Robert Ellenberg
SHIFT + R = reverse run (only switches while paused)
SHIFT + F = forward run (default, only switches while paused)
Here's the behavior I was going for (tested so far against some
examples of
Post by sam sokolik
Post by Robert Ellenberg
- Be able to reverse run up to about 20 segments
- only allow exact-stop motion in reverse (adding blending is a much
bigger change)
- Do not allow reversing through spindle-sync moves or at-speed moves
There are definitely some warts in this code I'd like to clean up before
merging, but it should be test-ready at least. As always, if you find
anything wrong or have ideas for how to improve this, let me know and
I'll
Post by sam sokolik
Post by Robert Ellenberg
take a stab at it.
Best,
-Rob
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
Post by sam sokolik
Post by Robert Ellenberg
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Post by sam sokolik
Post by Robert Ellenberg
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by sam sokolik
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
Post by sam sokolik
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Post by sam sokolik
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
andy pugh
2015-04-09 11:41:57 UTC
Permalink
Post by sam sokolik
I think for it to work with edm - (or other applications) there needs to
be a hal pin motion.reverse-run or some such thing..
It has always felt to me that reversing motion should happen when
motion.adaptive-feed goes negative.

That would allow very easy EDM integration.
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
sam sokolik
2015-04-09 12:04:55 UTC
Permalink
oh - better yet...

sam
Post by andy pugh
Post by sam sokolik
I think for it to work with edm - (or other applications) there needs to
be a hal pin motion.reverse-run or some such thing..
It has always felt to me that reversing motion should happen when
motion.adaptive-feed goes negative.
That would allow very easy EDM integration.
Robert Ellenberg
2015-04-09 15:59:20 UTC
Permalink
The adaptive feed pin as direction control is a great idea, and I think I
can make this work. I've got some code written towards this already. Does
anyone have a GUI flavor with an adaptive feed slider? I'm looking for a
quick way to test the direction-switch behavior to work out the kinks.

-Rob
Post by sam sokolik
oh - better yet...
sam
Post by andy pugh
Post by sam sokolik
I think for it to work with edm - (or other applications) there needs to
be a hal pin motion.reverse-run or some such thing..
It has always felt to me that reversing motion should happen when
motion.adaptive-feed goes negative.
That would allow very easy EDM integration.
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
EBo
2015-04-09 18:59:40 UTC
Permalink
No GUI yet, but an idea -- a +/- slider that will move forward/back at
some speed (slowing down as as I tweak it). For my application I was
planning to make a foot peddle which is at 0 when flat, forward to the
mechanical stop would be 1.0, and back to the heal stop woult be -1.0.
Easy enough to build...
Post by Robert Ellenberg
The adaptive feed pin as direction control is a great idea, and I think I
can make this work. I've got some code written towards this already. Does
anyone have a GUI flavor with an adaptive feed slider? I'm looking for a
quick way to test the direction-switch behavior to work out the kinks.
Gene Heskett
2015-04-09 16:02:37 UTC
Permalink
Post by andy pugh
Post by sam sokolik
I think for it to work with edm - (or other applications) there
needs to be a hal pin motion.reverse-run or some such thing..
It has always felt to me that reversing motion should happen when
motion.adaptive-feed goes negative.
That would allow very easy EDM integration.
Following that thought Andy, would there be a way to determine which
direction (as in axis to effect if it wasn't Z) by that method?

My experience with edm has all been Z driven as I was removing broken
screws from blind holes, which because of the lack of dielectric
electrolyte circulation in a blind hole means you eventually short and
have to back all the way out, vacuum out as much as you can, refill the
hole with k2, and go burn another 10 or 15 thou. Pain in the butt. But
I did get it done. Eventually. Did I mention it was slow? Very slow. 2
broken 6-32 screws were about 3 days to remove.

But later when I needed some holes in the web of a table saw blade, I
rigged 2x the voltage, to about 80 and 5x the cap (2uf to 10uf), and
using a piece of brass tubeing of the correct OD, that worked much
better, about 10 minutes per hole, but I did have to wear my Silencio
Magnum ear muffs (30db loss) as I expect it could be heard several
blocks away. Even with the muffs on, I'd guess my ears were getting
130db. There is loud, there is damned loud, and there is "Oh my Gawd is
that painfull" loud even with the muffs on. That was definitely in the
latter category.

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 <http://geneslinuxbox.net:6309/gene>
andy pugh
2015-04-09 16:10:41 UTC
Permalink
Post by Gene Heskett
Following that thought Andy, would there be a way to determine which
direction (as in axis to effect if it wasn't Z) by that method?
Back along the programmed path is exactly that.
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
Gene Heskett
2015-04-09 16:17:39 UTC
Permalink
Post by andy pugh
Post by Gene Heskett
Following that thought Andy, would there be a way to determine which
direction (as in axis to effect if it wasn't Z) by that method?
Back along the programmed path is exactly that.
Okayy. Now we need that hal pin. ;-)

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 <http://geneslinuxbox.net:6309/gene>
Robert Ellenberg
2015-04-09 16:37:48 UTC
Permalink
Ok, based on what everyone has said, I'm imagining the following interface:
* a HAL pin to allow / disallow reverse run
* a HAL pin to command reverse /forward direction (with safe state change
handled by TP)
* adaptive feeds of -1.0 to 0 trigger reverse run at the scaled feed rate
(with safe state change handled by TP)
* motion commands to switch direction (as implemented now)

Am I missing anything?

Rob
Post by Gene Heskett
Post by andy pugh
Post by Gene Heskett
Following that thought Andy, would there be a way to determine which
direction (as in axis to effect if it wasn't Z) by that method?
Back along the programmed path is exactly that.
Okayy. Now we need that hal pin. ;-)
Thanks Andy.
Cheers, Gene Heskett
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
sam sokolik
2015-04-09 18:56:22 UTC
Permalink
Sounds good to me...

I was playing with motion.tp-reverse and must not be doing it right.
(like I cannot change it from hal - but I see it change when I do it
from the gui)

sam
Post by Robert Ellenberg
* a HAL pin to allow / disallow reverse run
* a HAL pin to command reverse /forward direction (with safe state change
handled by TP)
* adaptive feeds of -1.0 to 0 trigger reverse run at the scaled feed rate
(with safe state change handled by TP)
* motion commands to switch direction (as implemented now)
Am I missing anything?
Rob
Post by Gene Heskett
Post by andy pugh
Post by Gene Heskett
Following that thought Andy, would there be a way to determine which
direction (as in axis to effect if it wasn't Z) by that method?
Back along the programmed path is exactly that.
Okayy. Now we need that hal pin. ;-)
Thanks Andy.
Cheers, Gene Heskett
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
Robert Ellenberg
2015-04-09 19:00:28 UTC
Permalink
Ahh, that's because I just threw that pin in as a debug output to see if
the state was being changed properly. I think we'll need some kind of
command / feedback pin arrangement, since we won't always be able to flip
between forward / reverse.
Post by sam sokolik
Sounds good to me...
I was playing with motion.tp-reverse and must not be doing it right.
(like I cannot change it from hal - but I see it change when I do it
from the gui)
sam
Post by Robert Ellenberg
Ok, based on what everyone has said, I'm imagining the following
* a HAL pin to allow / disallow reverse run
* a HAL pin to command reverse /forward direction (with safe state change
handled by TP)
* adaptive feeds of -1.0 to 0 trigger reverse run at the scaled feed rate
(with safe state change handled by TP)
* motion commands to switch direction (as implemented now)
Am I missing anything?
Rob
Post by Gene Heskett
Post by andy pugh
Post by Gene Heskett
Following that thought Andy, would there be a way to determine which
direction (as in axis to effect if it wasn't Z) by that method?
Back along the programmed path is exactly that.
Okayy. Now we need that hal pin. ;-)
Thanks Andy.
Cheers, Gene Heskett
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
------------------------------------------------------------------------------
Post by Robert Ellenberg
Post by Gene Heskett
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by Robert Ellenberg
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
Post by Robert Ellenberg
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Post by Robert Ellenberg
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
TJoseph Powderly
2015-04-09 19:33:41 UTC
Permalink
Robert
Post by Robert Ellenberg
Ahh, that's because I just threw that pin in as a debug output to see if
the state was being changed properly. I think we'll need some kind of
command / feedback pin arrangement, since we won't always be able to flip
between forward / reverse.
for edm
its modal
when in edm mode, enable fwd/bwd
when in feed mode ( positioning for next cut ), disable it

and if you want to try faking edm
the error signal that generate velocity and direction
can be faked by the analog hat of an old usb joystick
ctr = null pt
fwd = analog advance
rev = analog reverse
(or use even older joystick to old db15 joystick input )
tomp tjtr33
TJoseph Powderly
2015-04-10 03:13:34 UTC
Permalink
Robert
i dont know if you looked at the work done at CNC Club RU last year

reverse:
http://www.cnc-club.ru/forum/viewtopic.php?f=15&t=2430&start=80#p102002
and the video ( lines and arc and simple gui )


regards
TomP tjtr33
Gene Heskett
2015-04-10 03:23:24 UTC
Permalink
Post by Sebastian Kuzminsky
Robert
i dont know if you looked at the work done at CNC Club RU last year
http://www.cnc-club.ru/forum/viewtopic.php?f=15&t=2430&start=80#p10200
2 and the video ( lines and arc and simple gui )
http://youtu.be/zhTuBUDefs8
regards
TomP tjtr33
Looks like pretty cool trix there TomP.

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 <http://geneslinuxbox.net:6309/gene>
EBo
2015-04-10 08:07:28 UTC
Permalink
Post by Sebastian Kuzminsky
Robert
i dont know if you looked at the work done at CNC Club RU last year
http://www.cnc-club.ru/forum/viewtopic.php?f=15&t=2430&start=80#p102002
and the video ( lines and arc and simple gui )
http://youtu.be/zhTuBUDefs8
Looks cool! The one thing I could not tell for sure was it looked like
the command being run highlight might not have been being updated, but I
could be wrong.

I will have to see if I can incorporate that into one of my projects...

EBo --
TJoseph Powderly
2015-04-10 14:45:59 UTC
Permalink
re: reverse path by CNC Club RU:
note you have to create the reversed file yourself and edit the path to
it in the .py file.
press stop, then rev, then rerev ( read the source & experiment :)

run linuxcnc from a terminal so you get the debug output ( button
pressed and line to execute )

and i didnt look at the hilight.

this is not the same strategy as Robert Ellenberg's,
this is a bit hacky but a good trick..

tomp tjtr33
Post by EBo
Looks cool! The one thing I could not tell for sure was it looked like
the command being run highlight might not have been being updated, but I
could be wrong.
I will have to see if I can incorporate that into one of my projects...
EBo --
sam sokolik
2015-09-08 01:53:16 UTC
Permalink
Rob had some time to look at this branch - rebased it on 2.7 and made a
few fixes

I have played with it off and on for the last day or so - it is pretty
cool. If you set M52P1 (turning on adaptive feed) You can run the
program in reverse for 100 segments. (I don't know the in and out of
how far back is practical - rob would have to weigh in..)

Loading Image... (look at the slider in the right pyvcp
panel..)

There is control in the axis interface - pause program, shift r,
unpause. To go forward - pause program, sift f, unpause.

I think the gui control could disapear in my opinion. (you can do it
from a hal pin (motion.adaptive-feed) but that might be a discussion...

Currently the reverse run is exact stop - rob would like to add basic
blending.

The branch lives here if someone wants to play.
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/reverse-run-2.7-rebase

Did I mention that rob is a genius? Pretty darn cool.
sam
Post by sam sokolik
The latest pushes you did work a lot better. I do see movement when
switching from reverse to forward in some situations that i have not
figured out. Seem more common when you run it all the way back 20
segments then shift+f -> movement.
I did get it to be unresponsive once also (have not figured out the steps).
I think for it to work with edm - (or other applications) there needs to
be a hal pin motion.reverse-run or some such thing..
Very cool - nice work!
sam
Post by Robert Ellenberg
Post by sam sokolik
well that is pretty darn neat..
couple issues I found
-the first time you hit play after pausing and reversing the motion
(while still paused) - no movement.
Hmm, I'll try to reproduce this and see. If I can track down the cause.
Post by sam sokolik
-if you reverse run to the end of 20 segments (either manually or
unpausing) you cannot get it move anymore. shift-f will not go forward
again.
That happens because it has to be paused to switch direction, so you have
to manually pause it, then switch to forward, then resume. I'm looking into
a way to automatically pause when it runs out of reverse motion. One issue
I have with this now is that the pause button in axis doesn't show the
correct state if tpPause is called within motion at an arbitrary time. That
could be something I'm doing wrong, though. I'll take another look and see
what I can find.
Post by sam sokolik
sam
Post by Robert Ellenberg
Hi All,
I've been playing around with reverse run for the last few days, and I
think I have a crude but working solution based off of 2.7. Here's a
branch
Post by sam sokolik
Post by Robert Ellenberg
on my github repo that has an example (also pushed to the official repo
to
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/reverse-run-2.7
Post by sam sokolik
Post by Robert Ellenberg
The major changes are in motion / TP, but I also set up a quick way to
test
Post by sam sokolik
Post by Robert Ellenberg
using axis. I added 2 new key bindings to axis to enable / disable
reverse
Post by sam sokolik
Post by Robert Ellenberg
SHIFT + R = reverse run (only switches while paused)
SHIFT + F = forward run (default, only switches while paused)
Here's the behavior I was going for (tested so far against some
examples of
Post by sam sokolik
Post by Robert Ellenberg
- Be able to reverse run up to about 20 segments
- only allow exact-stop motion in reverse (adding blending is a much
bigger change)
- Do not allow reversing through spindle-sync moves or at-speed moves
There are definitely some warts in this code I'd like to clean up before
merging, but it should be test-ready at least. As always, if you find
anything wrong or have ideas for how to improve this, let me know and
I'll
Post by sam sokolik
Post by Robert Ellenberg
take a stab at it.
Best,
-Rob
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
Post by sam sokolik
Post by Robert Ellenberg
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Post by sam sokolik
Post by Robert Ellenberg
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by sam sokolik
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
Post by sam sokolik
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Post by sam sokolik
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
TJoseph Powderly
2015-09-08 04:20:13 UTC
Permalink
Sam & Rob
this is great news.

I'm guessing here, but,
exact stop may not bother some really slow processes
(like WEDM wink wink nudge nudge ).

WEDM Max velocities are often < 1meter per minute ( way less ).

yes Rob is a genius!

Thanks
TomP TjTr33
Post by sam sokolik
Rob had some time to look at this branch - rebased it on 2.7 and made a
few fixes
I have played with it off and on for the last day or so - it is pretty
cool. If you set M52P1 (turning on adaptive feed) You can run the
program in reverse for 100 segments. (I don't know the in and out of
how far back is practical - rob would have to weigh in..)
http://i.imgur.com/0PhNYEd.png (look at the slider in the right pyvcp
panel..)
There is control in the axis interface - pause program, shift r,
unpause. To go forward - pause program, sift f, unpause.
I think the gui control could disapear in my opinion. (you can do it
from a hal pin (motion.adaptive-feed) but that might be a discussion...
Currently the reverse run is exact stop - rob would like to add basic
blending.
The branch lives here if someone wants to play.
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/reverse-run-2.7-rebase
Did I mention that rob is a genius? Pretty darn cool.
sam
------------------------------------------------------------------------------
andy pugh
2015-09-08 10:01:16 UTC
Permalink
Post by sam sokolik
Currently the reverse run is exact stop - rob would like to add basic
blending.
I guess this is a problem if the forward run was blended then the
reverse run might take a fractionally different path.
However, the likely application is wire spark erosion, and I wouldn't
expect there to be much path difference between blended and exact stop
in that type of machine.
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

------------------------------------------------------------------------------
EBo
2015-09-08 11:52:52 UTC
Permalink
Post by andy pugh
Post by sam sokolik
Currently the reverse run is exact stop - rob would like to add basic
blending.
I guess this is a problem if the forward run was blended then the
reverse run might take a fractionally different path.
However, the likely application is wire spark erosion, and I wouldn't
expect there to be much path difference between blended and exact stop
in that type of machine.
Is there some way to set up some simulations and test the variance?
Even if there is a little difference between them, if they are only off
a couple of 10'ths it might not matter. If we can set up some
simulations and dump out the actual trajectory, then we can
statistically analyse the geometric as a function of forward and reverse
speeds. This should give various applications the information needed to
know if it is safe or not. Actually, with a little more work we could
even set this up as a simulation analysis application so that you can
test the appropriateness on a part by part basis.

EBo --

------------------------------------------------------------------------------
TJoseph Powderly
2015-09-08 13:42:01 UTC
Permalink
In the old days, we always wrote completely tangential paths for WEDM.
Not hard to do, kept you aware of the minimum radii that the wire kerf
could actually fit in. If its tangential ( never line to line
transitions ), how can there be any blending? I'd think only velocity
blending might occur, not path.
TomP TjTr33
Post by andy pugh
Post by sam sokolik
Currently the reverse run is exact stop - rob would like to add basic
blending.
I guess this is a problem if the forward run was blended then the
reverse run might take a fractionally different path.
However, the likely application is wire spark erosion, and I wouldn't
expect there to be much path difference between blended and exact stop
in that type of machine.
------------------------------------------------------------------------------
Kenneth Lerman
2015-09-08 12:43:28 UTC
Permalink
Why is there a 100 step limit? If it is because that's way more than anyone
would ever need, that's fine.

Memory is cheap. At 1000 bytes per step, storing 10 thousand steps is only
10 meg. That's not much in a machine with a gigabyte or more.

(Written by a man who owned a computer with 16K of memory -- although he
expanded it to 48K.)

Regards,

Ken
Post by sam sokolik
Rob had some time to look at this branch - rebased it on 2.7 and made a
few fixes
I have played with it off and on for the last day or so - it is pretty
cool. If you set M52P1 (turning on adaptive feed) You can run the
program in reverse for 100 segments. (I don't know the in and out of
how far back is practical - rob would have to weigh in..)
http://i.imgur.com/0PhNYEd.png (look at the slider in the right pyvcp
panel..)
There is control in the axis interface - pause program, shift r,
unpause. To go forward - pause program, sift f, unpause.
I think the gui control could disapear in my opinion. (you can do it
from a hal pin (motion.adaptive-feed) but that might be a discussion...
Currently the reverse run is exact stop - rob would like to add basic
blending.
The branch lives here if someone wants to play.
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/reverse-run-2.7-rebase
Did I mention that rob is a genius? Pretty darn cool.
sam
Post by sam sokolik
The latest pushes you did work a lot better. I do see movement when
switching from reverse to forward in some situations that i have not
figured out. Seem more common when you run it all the way back 20
segments then shift+f -> movement.
I did get it to be unresponsive once also (have not figured out the
steps).
Post by sam sokolik
I think for it to work with edm - (or other applications) there needs to
be a hal pin motion.reverse-run or some such thing..
Very cool - nice work!
sam
Post by Robert Ellenberg
Post by sam sokolik
well that is pretty darn neat..
couple issues I found
-the first time you hit play after pausing and reversing the motion
(while still paused) - no movement.
Hmm, I'll try to reproduce this and see. If I can track down the cause.
Post by sam sokolik
-if you reverse run to the end of 20 segments (either manually or
unpausing) you cannot get it move anymore. shift-f will not go forward
again.
That happens because it has to be paused to switch direction, so you
have
Post by sam sokolik
Post by Robert Ellenberg
to manually pause it, then switch to forward, then resume. I'm looking
into
Post by sam sokolik
Post by Robert Ellenberg
a way to automatically pause when it runs out of reverse motion. One
issue
Post by sam sokolik
Post by Robert Ellenberg
I have with this now is that the pause button in axis doesn't show the
correct state if tpPause is called within motion at an arbitrary time.
That
Post by sam sokolik
Post by Robert Ellenberg
could be something I'm doing wrong, though. I'll take another look and
see
Post by sam sokolik
Post by Robert Ellenberg
what I can find.
Post by sam sokolik
sam
Post by Robert Ellenberg
Hi All,
I've been playing around with reverse run for the last few days, and I
think I have a crude but working solution based off of 2.7. Here's a
branch
Post by sam sokolik
Post by Robert Ellenberg
on my github repo that has an example (also pushed to the official
repo
Post by sam sokolik
Post by Robert Ellenberg
to
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/reverse-run-2.7
Post by sam sokolik
Post by Robert Ellenberg
Post by sam sokolik
Post by Robert Ellenberg
The major changes are in motion / TP, but I also set up a quick way to
test
Post by sam sokolik
Post by Robert Ellenberg
using axis. I added 2 new key bindings to axis to enable / disable
reverse
Post by sam sokolik
Post by Robert Ellenberg
SHIFT + R = reverse run (only switches while paused)
SHIFT + F = forward run (default, only switches while paused)
Here's the behavior I was going for (tested so far against some
examples of
Post by sam sokolik
Post by Robert Ellenberg
- Be able to reverse run up to about 20 segments
- only allow exact-stop motion in reverse (adding blending is a
much
Post by sam sokolik
Post by Robert Ellenberg
Post by sam sokolik
Post by Robert Ellenberg
bigger change)
- Do not allow reversing through spindle-sync moves or at-speed
moves
Post by sam sokolik
Post by Robert Ellenberg
Post by sam sokolik
Post by Robert Ellenberg
There are definitely some warts in this code I'd like to clean up
before
Post by sam sokolik
Post by Robert Ellenberg
Post by sam sokolik
Post by Robert Ellenberg
merging, but it should be test-ready at least. As always, if you find
anything wrong or have ideas for how to improve this, let me know and
I'll
Post by sam sokolik
Post by Robert Ellenberg
take a stab at it.
Best,
-Rob
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
Post by sam sokolik
Post by Robert Ellenberg
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
Post by sam sokolik
Post by Robert Ellenberg
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Post by sam sokolik
Post by Robert Ellenberg
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
Post by sam sokolik
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
Post by sam sokolik
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Post by sam sokolik
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
Post by sam sokolik
Post by Robert Ellenberg
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Post by sam sokolik
Post by Robert Ellenberg
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by sam sokolik
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
Post by sam sokolik
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Post by sam sokolik
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
Kenneth Lerman
55 Main Street
Newtown, CT 06470
------------------------------------------------------------------------------
sam sokolik
2015-09-08 14:49:28 UTC
Permalink

Post by Kenneth Lerman
Why is there a 100 step limit? If it is because that's way more than anyone
would ever need, that's fine.
Memory is cheap. At 1000 bytes per step, storing 10 thousand steps is only
10 meg. That's not much in a machine with a gigabyte or more.
(Written by a man who owned a computer with 16K of memory -- although he
expanded it to 48K.)
Regards,
Ken
Post by sam sokolik
Rob had some time to look at this branch - rebased it on 2.7 and made a
few fixes
I have played with it off and on for the last day or so - it is pretty
cool. If you set M52P1 (turning on adaptive feed) You can run the
program in reverse for 100 segments. (I don't know the in and out of
how far back is practical - rob would have to weigh in..)
http://i.imgur.com/0PhNYEd.png (look at the slider in the right pyvcp
panel..)
There is control in the axis interface - pause program, shift r,
unpause. To go forward - pause program, sift f, unpause.
I think the gui control could disapear in my opinion. (you can do it
from a hal pin (motion.adaptive-feed) but that might be a discussion...
Currently the reverse run is exact stop - rob would like to add basic
blending.
The branch lives here if someone wants to play.
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/reverse-run-2.7-rebase
Did I mention that rob is a genius? Pretty darn cool.
sam
Post by sam sokolik
The latest pushes you did work a lot better. I do see movement when
switching from reverse to forward in some situations that i have not
figured out. Seem more common when you run it all the way back 20
segments then shift+f -> movement.
I did get it to be unresponsive once also (have not figured out the
steps).
Post by sam sokolik
I think for it to work with edm - (or other applications) there needs to
be a hal pin motion.reverse-run or some such thing..
Very cool - nice work!
sam
Post by Robert Ellenberg
Post by sam sokolik
well that is pretty darn neat..
couple issues I found
-the first time you hit play after pausing and reversing the motion
(while still paused) - no movement.
Hmm, I'll try to reproduce this and see. If I can track down the cause.
Post by sam sokolik
-if you reverse run to the end of 20 segments (either manually or
unpausing) you cannot get it move anymore. shift-f will not go forward
again.
That happens because it has to be paused to switch direction, so you
have
Post by sam sokolik
Post by Robert Ellenberg
to manually pause it, then switch to forward, then resume. I'm looking
into
Post by sam sokolik
Post by Robert Ellenberg
a way to automatically pause when it runs out of reverse motion. One
issue
Post by sam sokolik
Post by Robert Ellenberg
I have with this now is that the pause button in axis doesn't show the
correct state if tpPause is called within motion at an arbitrary time.
That
Post by sam sokolik
Post by Robert Ellenberg
could be something I'm doing wrong, though. I'll take another look and
see
Post by sam sokolik
Post by Robert Ellenberg
what I can find.
Post by sam sokolik
sam
Post by Robert Ellenberg
Hi All,
I've been playing around with reverse run for the last few days, and I
think I have a crude but working solution based off of 2.7. Here's a
branch
Post by sam sokolik
Post by Robert Ellenberg
on my github repo that has an example (also pushed to the official
repo
Post by sam sokolik
Post by Robert Ellenberg
to
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/reverse-run-2.7
Post by sam sokolik
Post by Robert Ellenberg
Post by sam sokolik
Post by Robert Ellenberg
The major changes are in motion / TP, but I also set up a quick way to
test
Post by sam sokolik
Post by Robert Ellenberg
using axis. I added 2 new key bindings to axis to enable / disable
reverse
Post by sam sokolik
Post by Robert Ellenberg
SHIFT + R = reverse run (only switches while paused)
SHIFT + F = forward run (default, only switches while paused)
Here's the behavior I was going for (tested so far against some
examples of
Post by sam sokolik
Post by Robert Ellenberg
- Be able to reverse run up to about 20 segments
- only allow exact-stop motion in reverse (adding blending is a
much
Post by sam sokolik
Post by Robert Ellenberg
Post by sam sokolik
Post by Robert Ellenberg
bigger change)
- Do not allow reversing through spindle-sync moves or at-speed
moves
Post by sam sokolik
Post by Robert Ellenberg
Post by sam sokolik
Post by Robert Ellenberg
There are definitely some warts in this code I'd like to clean up
before
Post by sam sokolik
Post by Robert Ellenberg
Post by sam sokolik
Post by Robert Ellenberg
merging, but it should be test-ready at least. As always, if you find
anything wrong or have ideas for how to improve this, let me know and
I'll
Post by sam sokolik
Post by Robert Ellenberg
take a stab at it.
Best,
-Rob
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
Post by sam sokolik
Post by Robert Ellenberg
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
Post by sam sokolik
Post by Robert Ellenberg
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Post by sam sokolik
Post by Robert Ellenberg
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
Post by sam sokolik
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
Post by sam sokolik
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Post by sam sokolik
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
Post by sam sokolik
Post by Robert Ellenberg
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Post by sam sokolik
Post by Robert Ellenberg
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by sam sokolik
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
Post by sam sokolik
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Post by sam sokolik
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Gene Heskett
2015-09-08 15:14:47 UTC
Permalink
Post by sam sokolik
http://youtu.be/3aYaHxT6ZnQ
That's very impressive Sam.

[...]

While I agree that Rob is a genius, that almost borders on magic. kewl
even.

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 <http://geneslinuxbox.net:6309/gene>

------------------------------------------------------------------------------
Jon Elson
2015-09-08 16:25:17 UTC
Permalink
Post by Kenneth Lerman
Why is there a 100 step limit? If it is because that's way more than anyone
would ever need, that's fine.
Memory is cheap. At 1000 bytes per step, storing 10 thousand steps is only
10 meg. That's not much in a machine with a gigabyte or more.
it is not "steps" as in stepper motor steps. it is move
segments, which is either blocks of G-code for linear moves,
or maybe interpolated segments of arcs for non-linear
moves. That covers a lot more territory!

Jon

------------------------------------------------------------------------------
Kenneth Lerman
2015-09-08 16:32:09 UTC
Permalink
I realize that, but CAM generated gcode might have hundreds of steps per
inch.

Ken
Post by Robert Ellenberg
Post by Kenneth Lerman
Why is there a 100 step limit? If it is because that's way more than
anyone
Post by Kenneth Lerman
would ever need, that's fine.
Memory is cheap. At 1000 bytes per step, storing 10 thousand steps is
only
Post by Kenneth Lerman
10 meg. That's not much in a machine with a gigabyte or more.
it is not "steps" as in stepper motor steps. it is move
segments, which is either blocks of G-code for linear moves,
or maybe interpolated segments of arcs for non-linear
moves. That covers a lot more territory!
Jon
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
Kenneth Lerman
55 Main Street
Newtown, CT 06470
------------------------------------------------------------------------------
Robert Ellenberg
2015-09-09 00:51:40 UTC
Permalink
Hi Kenneth,

There's no fundamental limitation here, it's just a matter of how big we
make the queue structure. It's a circular buffer, so it could be 1000
segments longer if we could afford the space. I just made it 100 segments
because it seemed reasonable. For context, the stock queue is 2000 segments
(forward only, of course). One reason to limit the size is that if I ever
get tangent blends working in reverse, it will be more expensive to
optimize a lot of segments.

Seb, l'll rebase onto master before I push it to the main repo.

Rob
Post by Robert Ellenberg
Post by Kenneth Lerman
Why is there a 100 step limit? If it is because that's way more than
anyone
Post by Kenneth Lerman
would ever need, that's fine.
Memory is cheap. At 1000 bytes per step, storing 10 thousand steps is
only
Post by Kenneth Lerman
10 meg. That's not much in a machine with a gigabyte or more.
it is not "steps" as in stepper motor steps. it is move
segments, which is either blocks of G-code for linear moves,
or maybe interpolated segments of arcs for non-linear
moves. That covers a lot more territory!
Jon
------------------------------------------------------------------------------
Post by Robert Ellenberg
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
Kenneth Lerman
55 Main Street
Newtown, CT 06470
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
sam sokolik
2015-09-09 18:30:50 UTC
Permalink
And to show more of robs awesomeness - Jeff said I should try reversing
through a tool change..

It stops reversing once it backs up to the tool change location...

sam
Post by Robert Ellenberg
Hi Kenneth,
There's no fundamental limitation here, it's just a matter of how big we
make the queue structure. It's a circular buffer, so it could be 1000
segments longer if we could afford the space. I just made it 100 segments
because it seemed reasonable. For context, the stock queue is 2000 segments
(forward only, of course). One reason to limit the size is that if I ever
get tangent blends working in reverse, it will be more expensive to
optimize a lot of segments.
Seb, l'll rebase onto master before I push it to the main repo.
Rob
Post by Robert Ellenberg
Post by Kenneth Lerman
Why is there a 100 step limit? If it is because that's way more than
anyone
Post by Kenneth Lerman
would ever need, that's fine.
Memory is cheap. At 1000 bytes per step, storing 10 thousand steps is
only
Post by Kenneth Lerman
10 meg. That's not much in a machine with a gigabyte or more.
it is not "steps" as in stepper motor steps. it is move
segments, which is either blocks of G-code for linear moves,
or maybe interpolated segments of arcs for non-linear
moves. That covers a lot more territory!
Jon
------------------------------------------------------------------------------
Post by Robert Ellenberg
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
Kenneth Lerman
55 Main Street
Newtown, CT 06470
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
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-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
EBo
2015-09-10 03:20:11 UTC
Permalink
Is it possible that the motions (including blending) are cached? Then
it would be a lot easier to roll them back over the exact same
trajectory. Just a thought...
Post by sam sokolik
And to show more of robs awesomeness - Jeff said I should try
reversing
through a tool change..
It stops reversing once it backs up to the tool change location...
sam
Post by Robert Ellenberg
Hi Kenneth,
There's no fundamental limitation here, it's just a matter of how big we
make the queue structure. It's a circular buffer, so it could be 1000
segments longer if we could afford the space. I just made it 100 segments
because it seemed reasonable. For context, the stock queue is 2000 segments
(forward only, of course). One reason to limit the size is that if I ever
get tangent blends working in reverse, it will be more expensive to
optimize a lot of segments.
Seb, l'll rebase onto master before I push it to the main repo.
Rob
Post by Robert Ellenberg
Post by Kenneth Lerman
Why is there a 100 step limit? If it is because that's way more than
anyone
Post by Kenneth Lerman
would ever need, that's fine.
Memory is cheap. At 1000 bytes per step, storing 10 thousand steps is
only
Post by Kenneth Lerman
10 meg. That's not much in a machine with a gigabyte or more.
it is not "steps" as in stepper motor steps. it is move
segments, which is either blocks of G-code for linear moves,
or maybe interpolated segments of arcs for non-linear
moves. That covers a lot more territory!
Jon
------------------------------------------------------------------------------
Post by Robert Ellenberg
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
Kenneth Lerman
55 Main Street
Newtown, CT 06470
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
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-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
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-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
Robert Ellenberg
2015-09-11 16:16:33 UTC
Permalink
Some information is saved in the queue structure, but the exact path taken
by a parabolic blend (as implemented in linuxcnc) depends on the initial
conditions, so you wouldn't really get the same path played back in reverse
unless you hit it at exactly the same speed.

Rob
Post by EBo
Is it possible that the motions (including blending) are cached? Then
it would be a lot easier to roll them back over the exact same
trajectory. Just a thought...
Post by sam sokolik
And to show more of robs awesomeness - Jeff said I should try reversing
through a tool change..
It stops reversing once it backs up to the tool change location...
sam
Post by Robert Ellenberg
Hi Kenneth,
There's no fundamental limitation here, it's just a matter of how big we
make the queue structure. It's a circular buffer, so it could be 1000
segments longer if we could afford the space. I just made it 100 segments
because it seemed reasonable. For context, the stock queue is 2000 segments
(forward only, of course). One reason to limit the size is that if I ever
get tangent blends working in reverse, it will be more expensive to
optimize a lot of segments.
Seb, l'll rebase onto master before I push it to the main repo.
Rob
Post by Robert Ellenberg
Post by Kenneth Lerman
Why is there a 100 step limit? If it is because that's way more than
anyone
Post by Kenneth Lerman
would ever need, that's fine.
Memory is cheap. At 1000 bytes per step, storing 10 thousand steps is
only
Post by Kenneth Lerman
10 meg. That's not much in a machine with a gigabyte or more.
it is not "steps" as in stepper motor steps. it is move
segments, which is either blocks of G-code for linear moves,
or maybe interpolated segments of arcs for non-linear
moves. That covers a lot more territory!
Jon
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
Post by Robert Ellenberg
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
Kenneth Lerman
55 Main Street
Newtown, CT 06470
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
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-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by sam sokolik
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-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
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-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
TJoseph Powderly
2015-09-11 16:23:53 UTC
Permalink
Hello Robert,
If I program a completely tangential path,
does blending still occur?
With the new TP, what governs the actual speed along such a path?

regarding sam's note about reversing stopping at tool change
sounds like a 'glue stop' in WEDM speak,
where we'd change the power setting and offset ( like rpm and tool
diameter ), then reverse thru the path, refining the surface finish,
and get closer to the final diimension.

thanks
TomP tjtr33
Post by Robert Ellenberg
Some information is saved in the queue structure, but the exact path taken
by a parabolic blend (as implemented in linuxcnc) depends on the initial
conditions, so you wouldn't really get the same path played back in reverse
unless you hit it at exactly the same speed.
------------------------------------------------------------------------------
EBo
2015-09-11 16:36:24 UTC
Permalink
Hmmm... I can see ways to cache extra information (like entry and exit
velocities) to get it close/exact, but it would likely require changes
to the blending function. I will not have time for that any time soon.

On a related note, is there any way we can instrument the code to
generate some statistics on how far it varies given various normal and
extreme test cases? A few measurements will trump all the speculation
(in the absense of mathematical proofs).
Post by Robert Ellenberg
Some information is saved in the queue structure, but the exact path taken
by a parabolic blend (as implemented in linuxcnc) depends on the initial
conditions, so you wouldn't really get the same path played back in reverse
unless you hit it at exactly the same speed.
Rob
Post by EBo
Is it possible that the motions (including blending) are cached?
Then
it would be a lot easier to roll them back over the exact same
trajectory. Just a thought...
Post by sam sokolik
And to show more of robs awesomeness - Jeff said I should try reversing
through a tool change..
It stops reversing once it backs up to the tool change location...
sam
Post by Robert Ellenberg
Hi Kenneth,
There's no fundamental limitation here, it's just a matter of how big we
make the queue structure. It's a circular buffer, so it could be 1000
segments longer if we could afford the space. I just made it 100 segments
because it seemed reasonable. For context, the stock queue is
2000
Post by sam sokolik
Post by Robert Ellenberg
segments
(forward only, of course). One reason to limit the size is that
if I
Post by sam sokolik
Post by Robert Ellenberg
ever
get tangent blends working in reverse, it will be more expensive
to
Post by sam sokolik
Post by Robert Ellenberg
optimize a lot of segments.
Seb, l'll rebase onto master before I push it to the main repo.
Rob
On Tue, Sep 8, 2015 at 12:25 PM, Jon Elson
Post by Robert Ellenberg
Post by Kenneth Lerman
Why is there a 100 step limit? If it is because that's way more than
anyone
Post by Kenneth Lerman
would ever need, that's fine.
Memory is cheap. At 1000 bytes per step, storing 10 thousand
steps
Post by sam sokolik
Post by Robert Ellenberg
Post by Robert Ellenberg
Post by Kenneth Lerman
is
only
Post by Kenneth Lerman
10 meg. That's not much in a machine with a gigabyte or more.
it is not "steps" as in stepper motor steps. it is move
segments, which is either blocks of G-code for linear moves,
or maybe interpolated segments of arcs for non-linear
moves. That covers a lot more territory!
Jon
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
Post by Robert Ellenberg
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
Kenneth Lerman
55 Main Street
Newtown, CT 06470
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by sam sokolik
Post by Robert Ellenberg
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
Post by sam sokolik
Post by Robert Ellenberg
now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by sam sokolik
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-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
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-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Sebastian Kuzminsky
2015-09-08 19:26:16 UTC
Permalink
Post by sam sokolik
Rob had some time to look at this branch - rebased it on 2.7 and made a
few fixes
Very cool. My only comment is this: 2.7 is closed for new features like
this, please base this work on master instead.
--
Sebastian Kuzminsky

------------------------------------------------------------------------------
EBo
2015-04-09 09:08:01 UTC
Permalink
Post by Robert Ellenberg
Hi All,
I've been playing around with reverse run for the last few days, and I
think I have a crude but working solution based off of 2.7.
I had an application where I could have used that, and was planning to
hack a different program to implement... Cool. If I ever get these
projects off the back of my todo list I might even have a real run at
it. Thanks!
TJoseph Powderly
2015-04-11 15:13:01 UTC
Permalink
resending, no attachment
using url instead
Loading Image...


-------- Original Message --------
Subject: Re: [Emc-developers] Reverse Run
Date: Thu, 09 Apr 2015 13:07:06 -0500
From: TJoseph Powderly <***@gmail.com>
To: EMC developers <emc-***@lists.sourceforge.net>

Robert
thanks for looking into this

I'd like you to look at a real EDM cut
I've included a plot, but if you could actually watch the motor
during a real cut you would observe important info.

You may find that the adaptive feedrate idea is very wrong for edm.

The velocity is constantly changing sign during a real cut.
I include a plot of a real cut , and it is an extremely stable cut.
Its a sinker EDM plunging a .025x.375 rib into hastalloy.

notice the position proceeds in a single direction
but at any one servo update period, the direction is fwd or reverse
according the the process. The directional change is the jiggle of the line.
The direction of the last period has nothing to do with the value of the
next period.

so, imo the adaptive feed is incorrect
imo adaptive feed reduces the velocity to below the potential velocity
(the efficient target point of the control loop)
and thus forces inefficiency.

Adaptive feed ignores the process and 'works' by timidly staying way
behind any efficient/aggressive seeking of the control point.

Yes i know i saw the edm maple leaf cut once, ask the author how it
compared to the other machines in his edm repair shop.

But even with this reduction, the work you've done is very interesting.

Please remember there are 2 different EDM retracts/reversals
short term and long term

the immediate reversals are constant and of small dimension
see the picture, the jiggly advance is _necessary_ for the process.

The short term are controlled by the small fluctuations of the process
the efficiency of the cut is determined by following the process closely.

The long term reversals are after near fatal errors,
these attempt to clear the gap when the process control
has failed badly.

( the better the process control, the lower the need for
long term reversals )

I'd also suggest that there are 4 common forms of edm
Examining them shows their different TP strategies.

They are graduated in difficulty of control as follows
1) easiest, HOLE DRILLING, moves in 1 axis between 2 limits
this can be done in hal w/o tp changes

2) middle difficulty, SINK EROSION, including orbiting. this requires
a 'sky blue' safe position to retreat to.

During a roughing operation ( creates the net shape )
the tool simply can retract to the point where edm power was turned on.
IF the toll achieves the end of roughing,
i call its position ( duh ) the 'roughing point'.
All finishing operation move FROM the roughing point
and return TO the roughing point.

Several excursions (orbits) occur,
each with slightly lower power,
and slightly larger excursions
( the range of motion is 0 to 0.5mm in my experience )

Each excursion begins and ends at the roughing point
During each excursion the tool expands the eroded volume according to
a prescribed pattern.
DURING the excursion, the tool can retreat towards
the roughing point. ( think retreats to high ground )

Example: a 'circular orbit' is really a trace over a conical surface
the tip of the cone is the roughing point. The tool follows the
slope of the cone towards its base, then travels around the base.
IF there is a problem, the retract is towards the cone tip NOT
along the previous path. ( sky blue remember? )

theres more to this, i've written corner picking, square ,circular ,
spherical, barrel and other orbits but they all follow the sky blue rules.

3) WEDM this is the only EDM that needs to retrace the old path.
And the progress is still true EDM, not
adaptive-slowed-down-slower-than-the-process-wants strategy. So the
short term is constantly changing. The long term allows for retracting
thru previous geometric commands.

BTW, once this ( retract thru prev geometry) is needed, the process is
pretty much out of control and the action is NOT a strategy to make the
cut better.

4) EDM Grinding
i've only worked on a few edm grinders, and they really fall into
category 1. they really dont have a long term backup, as they have
pretty perfect flushing. I just never saw one back up far.
Yes they could use hal for stepover and drop,
like the hydro-mechanical trips and levers common on any wet grinder.

anyway
please look at the picture

the top trace is the immediate gap error value
( summary, its 0-5V with 2.5V= null velocity)
Post by Robert Ellenberg
* a HAL pin to allow / disallow reverse run
the hal pin would need to be on the servo thread
and expect it to get banged a lot
Post by Robert Ellenberg
* a HAL pin to command reverse /forward direction (with safe state change
handled by TP)
my elox agie and heidenhain used M3 or similar
Some used the 'spindle' to turn on the cutting power
Some had delay till the power was sensed before allowing 'edm motion'

If the power was turned on while the machine was shorted, the current
simply shunts thru the work ( no damage usually and a noobie mistake)
and the system see it has already backed up to the start point, and
stops ( it began there and didnt have to move to get to fatal condition)
Post by Robert Ellenberg
* adaptive feeds of -1.0 to 0 trigger reverse run at the scaled feed rate
(with safe state change handled by TP)
i disagree with adaptive feed and will move on

the velocity can be fed into a 'velocity curve' comp.

with the error signal as input, two simple curves meet at
the 0 velocity point ( no error = no motion )
the 2 curves are infeed and outfeed

as the error moves away from the null point there can be
a 'dont care zone' with minimal velocity changes.
the dampens an overactive system

further away there are 'pay attention' zones.

I set mine up to run away fast
and to approach cautiously.
Post by Robert Ellenberg
* motion commands to switch direction (as implemented now)
Am I missing anything?
i hope you best of luck in this work

i hope you dont work a lot on the TP side
without considering the process control side.

because driving down the street should not
be primarily avoiding the telephone poles.

that works but it aint good driving.

regards TomP tjtr33
Gene Heskett
2015-04-11 17:12:10 UTC
Permalink
Post by TJoseph Powderly
resending, no attachment
using url instead
https://www.dropbox.com/s/xbmd0cij2ml9knn/edmGapSignal-vs-XpositionOve
rTime.jpg?dl=0
This is not a viewer friendly site TomP. It opens the jpeg, and goes into
a loop displaying the join requestor on top of it for about 3/4 second,
then blanks the screen and reloads the site, doing this forever with the
join popup often getting there before a full reload has been
accomplished. We have zero chance of being able to see and interpret the
image itself.

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 <http://geneslinuxbox.net:6309/gene>
TJoseph Powderly
2015-04-11 18:08:50 UTC
Permalink
Sorry Gene,
opens for others, i had it tested by different people, np
no need to join anything, open to anyone given the url.

heres another version you might try
http://ibin.co/1xzMzQKBwggW

regards
tomp tjtr33
Post by Gene Heskett
Post by TJoseph Powderly
resending, no attachment
using url instead
https://www.dropbox.com/s/xbmd0cij2ml9knn/edmGapSignal-vs-XpositionOve
rTime.jpg?dl=0
This is not a viewer friendly site TomP. It opens the jpeg, and goes into
a loop displaying the join requestor on top of it for about 3/4 second,
then blanks the screen and reloads the site, doing this forever with the
join popup often getting there before a full reload has been
accomplished. We have zero chance of being able to see and interpret the
image itself.
Cheers, Gene Heskett
TJoseph Powderly
2015-04-11 23:51:08 UTC
Permalink
gene,
you're right
dropbox was suggested to me when the msg bounced 1st time
i finally got a tester that never used dropbox
and found he saw same as you

will use imagebin like i always did before

thx for catching this
tomp
TJoseph Powderly
2015-04-12 02:22:51 UTC
Permalink
yes Gene
this is imagebin
http://ibin.co/1xzMzQKBwggW
thx tomp
If you put it on image.bin and post the URL, I'll certainly go see how it
works for me. Many thanks for your efforts on behalf of LCNC.
Cheers, Gene Heskett
Robert Ellenberg
2015-04-14 15:17:50 UTC
Permalink
Very interesting stuff! I have some ideas for how to implement a more
EDM-appropriate reverse run mechanism based on what you describe. Here's a
short list of new features we would need to address your concerns

1) "Retract-to-setpoint-on-abort" modal code. If a retract point is set,
the machine would automatically retract to that position on abort. Abort
would also clear this set point.

Perhaps this pair of G codes could work (chosen somewhat arbitrarily):
G15 X## Y## Z## = set a retract point in local coordinates (and enable
auto-retract mode). Now, when a program is aborted early, the machine will
rapid to this position after stopping it's motion along the path.
G16 = disable auto-retract

I think we could do something like this by piggy-backing on the abort
command in task. I'd have to take a closer look at the logic surrounding
the abort process, but if we're lucky, this could happen without having to
change anything at the TP level.

2) WEDM-style "jitter" feeding via HAL velocity input of some sort.

I agree that process control is important to address. If you had to write
an EDM path velocity controller as a HAL component, what inputs / outputs
would you want? Here's my impression so far:

- Input: desired average feed
- Input: process data (voltage, current)
- Optional Parameter: maximum path velocity / acceleration
- Output: desired instantaneous velocity along cut path

It sounds like a HAL pin to directly specify target velocity along the
motion path would be useful for this. It would take a bit of plumbing in
motion to implement, but I think this is doable without major disruption.

-Rob
Post by TJoseph Powderly
resending, no attachment
using url instead
https://www.dropbox.com/s/xbmd0cij2ml9knn/edmGapSignal-vs-XpositionOverTime.jpg?dl=0
-------- Original Message --------
Subject: Re: [Emc-developers] Reverse Run
Date: Thu, 09 Apr 2015 13:07:06 -0500
Robert
thanks for looking into this
I'd like you to look at a real EDM cut
I've included a plot, but if you could actually watch the motor
during a real cut you would observe important info.
You may find that the adaptive feedrate idea is very wrong for edm.
The velocity is constantly changing sign during a real cut.
I include a plot of a real cut , and it is an extremely stable cut.
Its a sinker EDM plunging a .025x.375 rib into hastalloy.
notice the position proceeds in a single direction
but at any one servo update period, the direction is fwd or reverse
according the the process. The directional change is the jiggle of the line.
The direction of the last period has nothing to do with the value of the
next period.
so, imo the adaptive feed is incorrect
imo adaptive feed reduces the velocity to below the potential velocity
(the efficient target point of the control loop)
and thus forces inefficiency.
Adaptive feed ignores the process and 'works' by timidly staying way
behind any efficient/aggressive seeking of the control point.
Yes i know i saw the edm maple leaf cut once, ask the author how it
compared to the other machines in his edm repair shop.
But even with this reduction, the work you've done is very interesting.
Please remember there are 2 different EDM retracts/reversals
short term and long term
the immediate reversals are constant and of small dimension
see the picture, the jiggly advance is _necessary_ for the process.
The short term are controlled by the small fluctuations of the process
the efficiency of the cut is determined by following the process closely.
The long term reversals are after near fatal errors,
these attempt to clear the gap when the process control
has failed badly.
( the better the process control, the lower the need for
long term reversals )
I'd also suggest that there are 4 common forms of edm
Examining them shows their different TP strategies.
They are graduated in difficulty of control as follows
1) easiest, HOLE DRILLING, moves in 1 axis between 2 limits
this can be done in hal w/o tp changes
2) middle difficulty, SINK EROSION, including orbiting. this requires
a 'sky blue' safe position to retreat to.
During a roughing operation ( creates the net shape )
the tool simply can retract to the point where edm power was turned on.
IF the toll achieves the end of roughing,
i call its position ( duh ) the 'roughing point'.
All finishing operation move FROM the roughing point
and return TO the roughing point.
Several excursions (orbits) occur,
each with slightly lower power,
and slightly larger excursions
( the range of motion is 0 to 0.5mm in my experience )
Each excursion begins and ends at the roughing point
During each excursion the tool expands the eroded volume according to
a prescribed pattern.
DURING the excursion, the tool can retreat towards
the roughing point. ( think retreats to high ground )
Example: a 'circular orbit' is really a trace over a conical surface
the tip of the cone is the roughing point. The tool follows the
slope of the cone towards its base, then travels around the base.
IF there is a problem, the retract is towards the cone tip NOT
along the previous path. ( sky blue remember? )
theres more to this, i've written corner picking, square ,circular ,
spherical, barrel and other orbits but they all follow the sky blue rules.
3) WEDM this is the only EDM that needs to retrace the old path.
And the progress is still true EDM, not
adaptive-slowed-down-slower-than-the-process-wants strategy. So the
short term is constantly changing. The long term allows for retracting
thru previous geometric commands.
BTW, once this ( retract thru prev geometry) is needed, the process is
pretty much out of control and the action is NOT a strategy to make the
cut better.
4) EDM Grinding
i've only worked on a few edm grinders, and they really fall into
category 1. they really dont have a long term backup, as they have
pretty perfect flushing. I just never saw one back up far.
Yes they could use hal for stepover and drop,
like the hydro-mechanical trips and levers common on any wet grinder.
anyway
please look at the picture
the top trace is the immediate gap error value
( summary, its 0-5V with 2.5V= null velocity)
Post by Robert Ellenberg
Ok, based on what everyone has said, I'm imagining the following
* a HAL pin to allow / disallow reverse run
the hal pin would need to be on the servo thread
and expect it to get banged a lot
Post by Robert Ellenberg
* a HAL pin to command reverse /forward direction (with safe state change
handled by TP)
my elox agie and heidenhain used M3 or similar
Some used the 'spindle' to turn on the cutting power
Some had delay till the power was sensed before allowing 'edm motion'
If the power was turned on while the machine was shorted, the current
simply shunts thru the work ( no damage usually and a noobie mistake)
and the system see it has already backed up to the start point, and
stops ( it began there and didnt have to move to get to fatal condition)
Post by Robert Ellenberg
* adaptive feeds of -1.0 to 0 trigger reverse run at the scaled feed rate
(with safe state change handled by TP)
i disagree with adaptive feed and will move on
the velocity can be fed into a 'velocity curve' comp.
with the error signal as input, two simple curves meet at
the 0 velocity point ( no error = no motion )
the 2 curves are infeed and outfeed
as the error moves away from the null point there can be
a 'dont care zone' with minimal velocity changes.
the dampens an overactive system
further away there are 'pay attention' zones.
I set mine up to run away fast
and to approach cautiously.
Post by Robert Ellenberg
* motion commands to switch direction (as implemented now)
Am I missing anything?
i hope you best of luck in this work
i hope you dont work a lot on the TP side
without considering the process control side.
because driving down the street should not
be primarily avoiding the telephone poles.
that works but it aint good driving.
regards TomP tjtr33
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
andy pugh
2015-04-14 16:04:23 UTC
Permalink
Post by Robert Ellenberg
1) "Retract-to-setpoint-on-abort" modal code. If a retract point is set,
the machine would automatically retract to that position on abort. Abort
would also clear this set point.
G15 X## Y## Z## = set a retract point in local coordinates (and enable
auto-retract mode).
I see that this uses relative rather than absolute coordinates, but
does it really do anything that G20 and G30 don't already do?

For a standalone sink/orbit HAL module this would probably just remove
all offsets then start again.
As I said in my previous reply, I think I see reverse-run of G-code
and sink/orbit as completely separate problems.
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
Robert Ellenberg
2015-04-14 16:51:28 UTC
Permalink
Andy, I agree, they are two separate problems. I just wanted to answer both
questions in one place since they came up here.

My G15/G16 example is very similar to G28 and G30, but the difference would
be that the retract would happen immediately and automatically on abort of
a program (vs at a particular program line, or manually invoked via MDI
line). I don't have experience with this process myself, so I'm not sure
how important this distinction is.
Post by Robert Ellenberg
1) "Retract-to-setpoint-on-abort" modal code. If a retract point is set,
the machine would automatically retract to that position on abort. Abort
would also clear this set point.
G15 X## Y## Z## = set a retract point in local coordinates (and enable
auto-retract mode).
I see that this uses relative rather than absolute coordinates, but
does it really do anything that G20 and G30 don't already do?

For a standalone sink/orbit HAL module this would probably just remove
all offsets then start again.
As I said in my previous reply, I think I see reverse-run of G-code
and sink/orbit as completely separate problems.

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

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
TJoseph Powderly
2015-04-14 22:40:42 UTC
Permalink
g30 & g30.1?
interesting when combines with retract
and i see the intermediate point would be easy
( the rufpoint might be an intermediate point from
the cone surface towards the startpoint above the workpiece.

i really have to do some drawings :|
thx for the reminder about G30
tomp tjtr33
Post by andy pugh
Post by Robert Ellenberg
1) "Retract-to-setpoint-on-abort" modal code. If a retract point is set,
the machine would automatically retract to that position on abort. Abort
would also clear this set point.
G15 X## Y## Z## = set a retract point in local coordinates (and enable
auto-retract mode).
I see that this uses relative rather than absolute coordinates, but
does it really do anything that G20 and G30 don't already do?
For a standalone sink/orbit HAL module this would probably just remove
all offsets then start again.
As I said in my previous reply, I think I see reverse-run of G-code
and sink/orbit as completely separate problems.
TJoseph Powderly
2015-04-14 20:32:48 UTC
Permalink
Robert,
thanks for looking into it
Post by Robert Ellenberg
Very interesting stuff! I have some ideas for how to implement a more
EDM-appropriate reverse run mechanism based on what you describe. Here's a
short list of new features we would need to address your concerns
1) "Retract-to-setpoint-on-abort" modal code. If a retract point is set,
the machine would automatically retract to that position on abort. Abort
would also clear this set point.
G15 X## Y## Z## = set a retract point in local coordinates (and enable
auto-retract mode). Now, when a program is aborted early, the machine will
rapid to this position after stopping it's motion along the path.
G16 = disable auto-retract
sounds workable for me

could i change the retract point before returning to it?
( ruf cuts return to start point, but finishing cuts begin where
ruf ends, i call it the rufpoint, it is 1 undersize less than the print
depth )
so i'd set the 1st retact point where i turn on the power for a cut
say G0 x0 y0 z0.05; G15 x0 y0 z0.05
then cut to the rufpoint
say G1 x0 y0 z-.365
then set a new retract point G15 x0 y0 z0.05
the cut a conical path that retract to the apex if needed
G1 X0.002 Y0 Z-.367
G2 X0.002 Y0 I-.002 J0
( and if retract occurs along this circle,
the retract is towards x0y0z-.365 )

wow that'd be a great start
( yes theres other things to do,
like pecking would be towards retract point, not along path )
but one thing at one time eh?

oh yeah, its realy time to mention that for sinking theres
2 retarct points. not too tricky, but
if the apex of the cone is arrived at
then the retract ought to continue towards the previous
retract point
( retract along the cone surface, then along the mine shaft :)
Post by Robert Ellenberg
I think we could do something like this by piggy-backing on the abort
command in task. I'd have to take a closer look at the logic surrounding
the abort process, but if we're lucky, this could happen without having to
change anything at the TP level.
i dunno how quick it can happen
sink edms are quick but not fast
good acceleration but slow top end
and
is we do not runaway fast enough
were are having damaging pulse at rates
as slows as 100usOn 12usOff and proximity to
stock will cause damage to work. so
running away is a good thing to do well
( monty python was right )
Post by Robert Ellenberg
2) WEDM-style "jitter" feeding via HAL velocity input of some sort.
I agree that process control is important to address. If you had to write
an EDM path velocity controller as a HAL component, what inputs / outputs
- Input: desired average feed
yes all wedms i have used have a feedrate
and it is the max expected to be used

bottom line, you dont tell the machine the rate
the process determines the rate.
only experience and data logs can suggest possible rates.

edm is 'stochastic',
it _usually_ produces result A
if we make sure variables BCDEFGHIJK are all controlled.
Post by Robert Ellenberg
- Input: process data (voltage, current)
the macros i wrote to communicate with power supplies had

parameters that should not be changed ( changes overcut and finish )
Polarity PeakCurrent ontime

parameters that affect process stability
offtime TargetGapVoltage ServoGain

parameters for adjuncts
peckOn/Off cuttimebeforenextpeck pecktime/distance
( how far to jump) flushingVolume flushSyncWithPeck

parameters for safety
sensitivity electrode/workpieceMaterialPair

parameters for special circuits
capacitanceForCutting(mF) capacitanceForTransmission(nF,pF)
CarbideCircuit
SteelonSteelCircuit
Post by Robert Ellenberg
- Optional Parameter: maximum path velocity / acceleration
hmm, maybe look at a 'curve'
a curve is a function that returns velocity given process error

i include a pic
Post by Robert Ellenberg
- Output: desired instantaneous velocity along cut path
would be handled by curve

the control points of the curve were left to the integrator
so the general response could be tuned for hogging weight
reduction versus wave guides or chip bonding tools

the curve pic:
left to right is the process error
the difference bewteen the GapVoltage wanted and the ActualGapVoltage
This is sample at least once a servo update period
This dGV ( deltaGapVoltage) is reduced to 0-5Vdc and centered at 2.5.
2.5V meant 'dont move' ( 0 velocity)

the vertical axis is velocity

the curve ( 4 simple discontinuous rates )
has a few control points
2 determine the 'slow down you're almost right' zone near 0 velocity
2 more control the 'runaway' and the 'fall in'
these points were up to the integrator.

the sample was processed and a new velocity fed to the drives used
in this cut every 5mS.

the above is just one implementation ( Fanuc and AGie and MITs use
similar strategies )

personally, i bent the negative velocity curve to near vertical
so _very_ prone to running away and cautious to re-enter

in HAL with linuxcnc, i simply used a bang-bang controller using a
window comparator. i had setpoints for 2 thresholds, the comparator
said Hi, Low or Between. The Hal code reduced the current position by 1
unit if Hi, and increased the current position by 2 units if Low,
and didnt do anything if Between. ( thats bangbang control )
1unit was 1um on my test system

so, all of that yak was about,
a curve can do the last 2 points you spoke of

and acceleration.,,
well these were big machines and big masses
they had laughable accelerations
so i never limited the acceleration ( it was available but useless )

peck edm ( aka jump)
a valve is synchronized to the jump
so the valve open on up stroke
closes on down
more efficient cut
https://videobin.org/+8uk/br1.html
Post by Robert Ellenberg
It sounds like a HAL pin to directly specify target velocity along the
motion path would be useful for this. It would take a bit of plumbing in
motion to implement, but I think this is doable without major disruption.
-Rob
andy pugh
2015-04-14 16:02:36 UTC
Permalink
Post by TJoseph Powderly
You may find that the adaptive feedrate idea is very wrong for edm.
I think that the adaptive feed pin was introduced for wire EDM, and if
it doesn't work properly for that then it ought to change.
Post by TJoseph Powderly
so, imo the adaptive feed is incorrect
imo adaptive feed reduces the velocity to below the potential velocity
(the efficient target point of the control loop)
and thus forces inefficiency.
If adaptive feed could be negative to retract or positive to advance
at the programmed feed rate then I think it could still work properly.
Post by TJoseph Powderly
I'd also suggest that there are 4 common forms of edm
Examining them shows their different TP strategies.
I can only really see G-code and G-code reversal being useful for wire
EDM. I think that the other applications would be rather better served
by single-purpose motion control HAL modules.

For example an orbital sink module would have X, Y and orbit
amplitude input pins and X and Y outputs that included the orbital
amplitude (This would be very much like the module I have for
polygonal turning on the lathe, except that the "spindle" speed would
be a free-running counter incrementing at a settable rate.

The Z position output would increment/decrement depending on gap voltage.

Are you suggesting that there is no acceleration limitation in a
normal sink eroder?
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
TJoseph Powderly
2015-04-14 22:26:06 UTC
Permalink
On 04/14/2015 11:02 AM, andy pugh wrote:

sorry andy still working my way thru these posts, and i am slow
Post by andy pugh
Post by TJoseph Powderly
You may find that the adaptive feedrate idea is very wrong for edm.
I think that the adaptive feed pin was introduced for wire EDM, and if
it doesn't work properly for that then it ought to change.
it didnt do what i'd say was right
ymmv

adaptive feed had to be set or settle out to less than the correct
average rate ( it could never meet or exceed optimum )
so it was slower and caused most pulse to miss
( often nothing to strike )

Ray Henry (i think) developed the idea and MyDynac tested it
i can still google up a bit of it
MyDynac hacked an asian wedm and cut a maple leaf out of ~.75" alum.
Post by andy pugh
Post by TJoseph Powderly
so, imo the adaptive feed is incorrect
imo adaptive feed reduces the velocity to below the potential velocity
(the efficient target point of the control loop)
and thus forces inefficiency.
If adaptive feed could be negative to retract or positive to advance
at the programmed feed rate then I think it could still work properly.
yes, seems true.
i hope your view of the time sale for reversals is
at most millisecs. the immediate velocity has nothing to do with the
previous, there is no velocity smoothing. i may be redundant but i
really think people never got that idea. they thought edm reversal was
only like going to the end of the last block.
Post by andy pugh
Post by TJoseph Powderly
I'd also suggest that there are 4 common forms of edm
Examining them shows their different TP strategies.
I can only really see G-code and G-code reversal being useful for wire
EDM. I think that the other applications would be rather better served
by single-purpose motion control HAL modules.
For example an orbital sink module would have X, Y and orbit
amplitude input pins and X and Y outputs that included the orbital
amplitude (This would be very much like the module I have for
polygonal turning on the lathe, except that the "spindle" speed would
be a free-running counter incrementing at a settable rate.
yes John Kasunich's original hal example of moving x & y according to
a sine and a cosine generator, given the Z displacement from ruf point
as amplitude. I tried (failed apparently) to explain this years ago.
i even hacked a differnt square wave generator to allow square orbits
like circular orbits.
Post by andy pugh
The Z position output would increment/decrement depending on gap voltage.
i used position loops that coudl be used on stepper or servo
Post by andy pugh
Are you suggesting that there is no acceleration limitation in a
normal sink eroder?
i am suggesting that you move away as quickly as possible when the
process signal goes low. The machine itself can be measured to find how
quickly it can change position. this is the standard 'step' test done
on machine tools. the machine will tell you what it can do, fully
loaded, fully connected. that is the acceleration allowed.

the step test has nothing to do with steppers.
the test is. remove the cnc control from the drive.
determine the maximum servo command voltage ( eg 9 or 10V)
set up a voltage source with that voltage from a switch to the drive.
monitor the velocity ( tacho is nice, FtoV from encoder )
snap the switch
how long does it take the real system to achiev the velocity that the
voltage _should_produce?
thats the acceleration time
a real hard measure of your systems real acceleration potential
( in one axis in one direction , but a real non guessed start )
tomp tjtr33
andy pugh
2015-04-14 22:46:59 UTC
Permalink
Post by TJoseph Powderly
yes, seems true.
i hope your view of the time sale for reversals is
at most millisecs. the immediate velocity has nothing to do with the
previous, there is no velocity smoothing.
I remain confused by this.
If adaptive feed went from +1 on one servo cycle to -1 on the next
servo cycle I would expect the axis acceleration constraints to be
obeyed, as to do otherwise surely risks following errors?

Are you saying that wire EDM machines ignore the axis acceleration
limits and just hope for the best?
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
TJoseph Powderly
2015-04-14 23:02:17 UTC
Permalink
Post by andy pugh
Post by TJoseph Powderly
yes, seems true.
i hope your view of the time sale for reversals is
at most millisecs. the immediate velocity has nothing to do with the
previous, there is no velocity smoothing.
I remain confused by this.
If adaptive feed went from +1 on one servo cycle to -1 on the next
servo cycle I would expect the axis acceleration constraints to be
obeyed, as to do otherwise surely risks following errors?
Are you saying that wire EDM machines ignore the axis acceleration
limits and just hope for the best?
im confused too
do you mean 1 smallest unit of motion
where acc doesnt really mean much anyway
(eg acceleration when moving 1 micron )
and
the system was not moving at any feedrate to speak of already.

if the position change were 1mm
id not think it meant much jerk

and if 1 inch ok too big a jerk

and neither 1mm nor 1inch is achieved by any edm i've seen
inside a single servo cycle ( say 40mS )

humorous sidenote:
there is an app note from heidenhain where the engr complained
it ignored acc limits. so it does happen
he was not replied to, even funnier


i'd say the position change requested in 1 servo cycle is tiny
and
the change in velocity achievable in 1 servo time slot is tiny

oh and yes they do monitor following error
based on acc and velocity
and present position (Aktual) vs requested (Kommand)
but thats just one implementation

oh and i dont speak much of wedm
the edm process is the same
the imp[lementation is different.
still would never move more than a few microns in
an servo period.

my 2c
tomp tjtr33
TJoseph Powderly
2015-04-19 05:17:44 UTC
Permalink
Andy
sorry didnt get this out earlier, had to go out of town for work
(yay work :)
but
yes, there is no acceleration limit while edming
( for heidenhain sink eroders, i doubt you'll find as much internal
info from other mfctrs )

some may say that ignoring acc is just wrong
but thats not from experience in this process

in edm, we dont consider/remember/use the velocity of the previous servo
cycle

this system works and is tested

i include imagebin url for the diagram

specifically
the acceleration is ignored during cutting
( labeled 'in gapcontrol' on diagram)
and respected during positioning
( labeled 'in positioning' on diagram ).

and for S&G, this weekends repair result
videobin url https://videobin.org/+8v4/brq.html

hth
TomP tjtr33

imagebin url for control strategy diagram:
http://ibin.co/1ypbbY4RbG7A
Post by andy pugh
Post by TJoseph Powderly
You may find that the adaptive feedrate idea is very wrong for edm.
I think that the adaptive feed pin was introduced for wire EDM, and if
it doesn't work properly for that then it ought to change.
Post by TJoseph Powderly
so, imo the adaptive feed is incorrect
imo adaptive feed reduces the velocity to below the potential velocity
(the efficient target point of the control loop)
and thus forces inefficiency.
If adaptive feed could be negative to retract or positive to advance
at the programmed feed rate then I think it could still work properly.
Post by TJoseph Powderly
I'd also suggest that there are 4 common forms of edm
Examining them shows their different TP strategies.
I can only really see G-code and G-code reversal being useful for wire
EDM. I think that the other applications would be rather better served
by single-purpose motion control HAL modules.
For example an orbital sink module would have X, Y and orbit
amplitude input pins and X and Y outputs that included the orbital
amplitude (This would be very much like the module I have for
polygonal turning on the lathe, except that the "spindle" speed would
be a free-running counter incrementing at a settable rate.
The Z position output would increment/decrement depending on gap voltage.
Are you suggesting that there is no acceleration limitation in a
normal sink eroder?
TJoseph Powderly
2015-04-12 15:18:07 UTC
Permalink
Gene
i cnat show pix of the actual machine and parts ( proprietary)
but here's edm using linuxcnc to position ( pose)
and hal to cut
http://videobin.org/+6cw/786.html
^^^ no need to join here either,
regards
tomp
Sometime, you might describe how noisy it is. I tend to rate this stuff
with the 30 db shooting muffs on, as noisy, damned noisy, and ohmygawd
that hurts. ;-)
when i did 450 amp cuts for GE in Winston Salem
it was the extreme edge of edm.

it sounded like machine gun fire
just muffled by being done in a 1 meter deep tank.
we were matching two hammer die halves for props.

the process just cant be stabilized at that current density.

the acceptance requirement was 11cu in/hr. and i did that by
tossing the autopilot, putting 1 hand on the loop set point
and the other on the flush control. after 1hr, i relaxed.
Pete_Gruendeman
2015-09-12 12:53:43 UTC
Permalink
Hi:
My boss would suggest that we are slicing the baloney a little too thin here... While getting the trajectory as exact as possible in both forward and reverse directions is important, the practical limits of backlash, flexure under acceleration loads, etc. will likely provide greater error than what is caused by the trajectory planner. Or am I missing something here? Reversing a path will be most helpful for wire EDM, but only to a point. We will always be stuck with the limitations of the machine.

I am more interested in sinker EDM but will stay up on your developments and contribute in any way I can, including test running software for sinker.
Pete Gruendeman

--------------------------------------------
On Fri, 9/11/15, EBo <***@sandien.com> wrote:

Subject: Re: [Emc-developers] Reverse Run
To: emc-***@lists.sourceforge.net
Date: Friday, September 11, 2015, 11:36 AM

Hmmm...  I can see ways
to cache extra information (like entry and exit
velocities) to get it close/exact, but it would
likely require changes
to the blending
function.  I will not have time for that any time soon.

On a related note, is there
any way we can instrument the code to
generate some statistics on how far it varies
given various normal and
extreme test
cases?  A few measurements will trump all the speculation

(in the absense of mathematical proofs).

On Sep 11 2015 10:16 AM,
Post by Robert Ellenberg
Some
information is saved in the queue structure, but the exact
path
Post by Robert Ellenberg
taken
by a
parabolic blend (as implemented in linuxcnc) depends on the
Post by Robert Ellenberg
initial
conditions, so you wouldn't really get the same path
played back in
Post by Robert Ellenberg
reverse
unless you hit it at exactly the same
speed.
Post by Robert Ellenberg
Rob
On Sep 9, 2015 11:21 PM, "EBo"
Is it
possible that the motions (including blending) are cached? 
Post by Robert Ellenberg
Then
it
would be a lot easier to roll them back over the exact
same
Post by Robert Ellenberg
trajectory.  Just a
thought...
------------------------------------------------------------------------------
EBo
2015-09-12 16:16:49 UTC
Permalink
I was wondering the same thing, and is why I asked about some output
data. I once had such a discussion with a couple of people only to find
that when we instrumented the code the variance of the paths were less
that .00002" The machine was not even that tight! The machine I would
like to test reverse run on probably cannot even hold .001"
Post by Pete_Gruendeman
My boss would suggest that we are slicing the baloney a little
too thin here... While getting the trajectory as exact as possible
in
both forward and reverse directions is important, the practical
limits
of backlash, flexure under acceleration loads, etc. will likely
provide greater error than what is caused by the trajectory planner.
Or am I missing something here? Reversing a path will be most
helpful
for wire EDM, but only to a point. We will always be stuck with the
limitations of the machine.
I am more interested in sinker EDM but will stay up on your
developments and contribute in any way I can, including test running
software for sinker.
Pete Gruendeman
--------------------------------------------
Subject: Re: [Emc-developers] Reverse Run
Date: Friday, September 11, 2015, 11:36 AM
Hmmm...  I can see ways
to cache extra information (like entry and exit
velocities) to get it close/exact, but it would
likely require changes
to the blending
function.  I will not have time for that any time soon.
On a related note, is there
any way we can instrument the code to
generate some statistics on how far it varies
given various normal and
extreme test
cases?  A few measurements will trump all the speculation
(in the absense of mathematical proofs).
On Sep 11 2015 10:16 AM,
Post by Robert Ellenberg
Some
information is saved in the queue structure, but the exact
path
Post by Robert Ellenberg
taken
by a
parabolic blend (as implemented in linuxcnc) depends on the
Post by Robert Ellenberg
initial
conditions, so you wouldn't really get the same path
played back in
Post by Robert Ellenberg
reverse
unless you hit it at exactly the same
speed.
Post by Robert Ellenberg
Rob
On Sep 9, 2015 11:21 PM, "EBo"
Is it
possible that the motions (including blending) are cached? 
Post by Robert Ellenberg
Then
it
would be a lot easier to roll them back over the exact
same
Post by Robert Ellenberg
trajectory.  Just a
thought...
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Loading...