Re: [Emc-developers] Looking for rtapi_shmem example between RT- C comp and Uspace Python comp?

[Sam Sokolik]

are you talking e-offset pins?  Those are realtime..  I am using a realtime
comp to do spindle synced motion...  It works great..

https://www.youtube.com/shorts/nViXP9SsdWc

sam

On Fri, Nov 17, 2023 at 10:39 AM Ted  wrote:

> On 11/17/2023 10:49 AM, andy pugh wrote:
> > Is this related to wanting to do height mapping, or laser rastering,
> > or something?
>
> The end result is a multi-layer z-height and x-y-z-thermal compensation
> system. (Yes, I know we have the "compensation" components, but both
> offerings present by pushing data into the LCNC "offset" pins which is
> far too late in processing for my application, as well as being purely
> userspace). I need to be able to do my compensation directly after the
> mag scales I have attached (to my CMM - a larger project scope) and
> before any other value modification or motion decisions.
>
> I looked at raster also; at first pass it might be a little too involved
> as designed, but using hal_port with less complexity might be quite
> viable. The next question would be to see if I will need to "chunk" that
> data or if I can single-blob it all without losses. Not having the
> realtime side need to handshake back to the userspace would be a
> preferred path for stability. (Says he who grew up with 25 pin serial
> ports...)
>
> Thanks,
>
> TH.
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] lcnc bug in master?

[Sam Sokolik]

I have actually seen this playing with axis from master on bookworm.  At
some point the refresh button in axis just quits working.  You have to
physically re-open the gcode file for the changes to show up.  Then the
refresh button will work for a bit.

I thought it was just me...

On Sat, Oct 14, 2023, 5:01 AM gene heskett  wrote:

> On 10/14/23 05:29, andy pugh wrote:
> > On Sat, 14 Oct 2023 at 03:10, gene heskett  wrote:
> >
> >> What I found may not actually be linuxcnc, but in linux itself. All the
> >> indications are that its a stale cache problem. The only way to get the
> >> edited code into linuxcnc is to use the pulldown to load it by displayed
> >> name, which apparently, because it has to show the dir contents, is the
> >> only way to refresh the cache.
> >
> > I haven't observed this problem. Which Linux version and LinuxCNC GUI
> > are you using?
>
> axis, on uname=Linux GO704 4.19.0-25-rt-amd64 #1 SMP PREEMPT RT Debian
> 4.19.289-2 (2023-08-08) x86_64, and etc/issue: Debian GNU/Linux 10
>
> 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, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Fwd: Upcoming stable (12.2) and oldstable (11.8) point releases

[Sam Sokolik]

What is involved?

On Sat, Sep 2, 2023 at 3:05 AM Hans Unzner  wrote:

> Yes we should use the opportunity and build a debian package from the
> current 2.9 branch.
>
> Am Freitag, 1. September 2023 schrieb andy pugh :
> > Is this an opportunity to get some bugfixes into the version that we
> > are distributing? It is fairly broken.
> >
> > -- Forwarded message -
> > From: Jonathan Wiltshire 
> > Date: Fri, 1 Sept 2023 at 17:58
> > Subject: Upcoming stable (12.2) and oldstable (11.8) point releases
> > To: 
> >
> >
> > The next point releases for "bookworm" (12.2) and "bullseye" (11.8) will
> > take place on Saturday, October 7th 2023. Processing of new uploads into
> > the relevant queues will be frozen the preceding weekend.
> >
> > --
> > Jonathan Wiltshire  j...@debian.org
> > Debian Developer http://people.debian.org/~jmw
> >
> > 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> > ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
> >
> >
> >
> > --
> > atp
> > "A motorcycle is a bicycle with a pandemonium attachment and is
> > designed for the especial use of mechanical geniuses, daredevils and
> > lunatics."
> > — George Fitch, Atlanta Constitution Newspaper, 1912
> >
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Trajectory planner shortcomings

[Sam Sokolik]

Any movement involving the rotary axis is limited to the old
trajectory planner - 1 segment look ahead..

sam

On Tue, Jul 4, 2023 at 1:47 PM gene heskett  wrote:

> On 7/4/23 13:31, Marius wrote:
> > Hi
> >
> > I have been trying to get a rotary fourth axis setup going with the help
> > of regular and knowledgable contributors to LinuxCnc. We came up against
> > a brick wall as many other project developers have done.
> >
> > The problem seems to be that our trajectory planner lack the ability to
> > look ahead for any rotary axis. This means that a coordinated move that
> > includes a rotary move will be dysfunctional at best.
> >
> Not true Marius, if you are having problems, something about your config
> is wrong. I am presently carving a 2 start screw in wood with my B axis
> on the 6040 gantry mill.  And its accurate to a fraction of a degree
> anyplace in the 400mm length of that screw.  With no PID's in use on
> that machine.  All you should have to do is calculate the end points
> related to where it starts for the b axis and issue the two end points
> in the same command line. I carve a two start buttress thread by pre
> positioning at the shape point of the tooth, and carve that position for
> the length of that screw. That rotates the b axis in perfect sync with
> the y motion.  At the far end of the screw, I add 180 degrees to the b,
> move it that addition 180, then come back to the y starting point with b
> coming bavk to 180, which is about 6mm off the end of the screw, then I
> move b back to zero, reposition the tool for the next pass, and do it
> again till its done.  The 7 degree angle of the load bearing face of
> that thread is established by a wedge under the motor, an angle
> duplicated in the tooths shape. The nuts are printed on a 3d printer in
> PETG, with a dozen teeth engaged in the length of the nut.
>
> There are no PID's and my B axis is a 3NM, 3 phase stepper/servo driving
> a 5/1 worm which is driving a square socket that turns a 2x2 stick
> nearly 600 mm long.live center at the other end of the stick, shimmed to
> reduce the z motion required to do as close to a true cylinder the
> length of that thread.  And it all Just Works. My Z axis is also driven
> by a 1NM version of that stepper/servo.
>
> Start by checking your .ini file. under:
> [DISPLAY]
> you should have something like this:
> GEOMETRY = XYZA
> then down file a ways:
> [TRAJ]
> AXES = 4
> COORDINATES =  XYZA
>
> Now, that's wrong but my i/o channels are limited to 4 axis so my B axis
> is actually wired to what would be the A terminals in the interface as I
> am using a 5i25 and a 7i76 plus a std breakout for other functions. A
> 7i90HD would fix that but bring another wagon load of shekels for
> 7i42TA's, takes 3 of them as the 7i90 has no buffers to protect the fpga
> used from 5 volt stuff. I've forgotten how, but on screen in axis it
> does show as B.
> Check the above, the rest of my .ini has it as A and JOINT_3.
>
> Digging thru my .hal file will get more complex as its been a couple
> years since I first rigged a different B axis.
>
> So start with the above.
> And have a happy 4th Marous.
>
> > I understand that there is a free trajectory planner on offer to
> > LinuxCnc but it has not been integrated. It would seem that some lack of
> > skills or time has a role to play in getting it integrated.
> >
> > I unfortunately do not have the skills nor the time to tender to assist
> > with this however, someone made the suggestion that maybe the community
> > could embark on a fund raising project to enable us to pay for someone
> > to get the trajectory planner integrated. I am sure that many would
> > stand to benefit from this and other users that I have spoken to has
> > indicated that they would gladly contribute.
> >
> > I would at least want to start a discussion around the idea.
> >
> >
> > Regards
> >
> > Marius
> >
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> > .
>
> 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, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
> Genes Web page 
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] 5-axis video at Tormach meet up

[Sam Sokolik]

downloading them first probably is the best solution...

On Mon, May 1, 2023 at 7:15 PM gene heskett  wrote:

> On 5/1/23 19:37, John Allwine wrote:
> > I used VLC to view them.
> >
> >> On May 1, 2023, at 5:02 PM, gene heskett  wrote:
> >>
> >> On 5/1/23 17:25, John Allwine wrote:
> >>> Hi everyone,
> >>> Jon sent them over to me and I've uploaded them here:
> >>> https://demos.pentamachine.com/linuxcnc/stevenson.wmv
> >>> https://demos.pentamachine.com/linuxcnc/stevenson2.wmv
> >>> I don't think this is a great permanent spot for them, but I imagine
> they
> >>> can sit here for a while.
> >>> -John
> vlc from a cli, stuttered and paused 90% of the time complaing mightily
> about a lacking reference clock.
> my connection seems to be sub par. or the site is busier than a one
> armed paper hanger. :o)>  I have also seen them before.  thanks.
>
> >> and firefox doesn't know what to do with a .wmv.  Am I missing a plugin?
> >>
>  On Wed, Apr 26, 2023 at 7:17 PM Greg C 
> wrote:
>  I think we’d all like to see them (and I don’t even know what “them”
>  entails).
> 
>  Can they be uploaded to YouTube or something?
> 
>  -Greg
> 
>  On Wed, Apr 26, 2023 at 8:49 PM Stuart Stevenson 
>  wrote:
> 
> > I sent Jon copies. He can give them to anyone he wishes. I will give
> them
> > to anyone that asks.
> > regards
> > Stuart
> >
> > On Wed, Apr 26, 2023 at 2:53 PM Bari  wrote:
> >
> >> Looks like it might be Jon Elson's PC showing a 5-axis machine
> video by
> >> Stuart Stevenson.
> >>
> >> I believe that Stuart took his "youtubes" down. Maybe someone has
>  copies
> >> to share.
> >>
> >> On 4/26/23 13:57, John Allwine wrote:
> >>> Hi all,
> >>>
> >>> Thanks for the great weekend! It was nice to be able to put faces
> to
> > all
> >>> the names I see in the commits and forums.
> >>>
> >>> I forget who was showing it, but I was hoping to get the video of
> the
> > big
> >>> 5-axis machine that was rigged up with dial indicators.  I snapped
> a
> >>> picture of it (see here,
> >>> https://demos.pentamachine.com/linuxcnc/linuxcnc-5-axis.jpg). Does
> >> anyone
> >>> have that?
> >>>
> >>> Thanks!
> >>>
> >>> -John
> >>>
> >>> ___
> >>> Emc-developers mailing list
> >>> Emc-developers@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>
> >>
> >> ___
> >> Emc-developers mailing list
> >> Emc-developers@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>
> >
> >
> > --
> > Addressee is the intended audience.
> > If you are not the addressee then my consent is not given for you to
> read
> > this email furthermore it is my wish you would close this without
> saving
>  or
> > reading, and cease and desist from saving or opening my private
> > correspondence.
> > Thank you for honoring my wish.
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> 
>  ___
>  Emc-developers mailing list
>  Emc-developers@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/emc-developers
> 
> >>> ___
> >>> Emc-developers mailing list
> >>> Emc-developers@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>
> >> 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, 1940)
> >> If we desire respect for the law, we must first make the law
> respectable.
> >> - Louis D. Brandeis
> >> Genes Web page 
> >>
> >>
> >>
> >> ___
> >> Emc-developers mailing list
> >> Emc-developers@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
> 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, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
> Genes Web page 
>
>
>
> ___
> Emc-developers mailing list
> 

Re: [Emc-developers] April 2023 LinuxCNC meeting at Tormach headquarters

[Sam Sokolik]

Thank you tormach for letting us use your space for the get together!  It
was so good to see old friends and meet new!

On Fri, Apr 21, 2023, 2:06 PM Daniel Rogge  wrote:

> If people want to set things up we have plenty of AV equipment (including
> some top notch microphones) that could be used to broadcast the meeting to
> remote attendees.  The group is welcome to use Tormach's paid Zoom account
> to host.
>
> I will set things up this afternoon and Rob Ellenberg and others may be
> able to help connect and send out the correct Zoom links to the list
> tomorrow.
>
> Rogge
>
>
>
>
> -Original Message-
> From: ken.stra...@sympatico.ca 
> Sent: Friday, April 21, 2023 11:40 AM
> To: 'EMC developers' 
> Subject: Re: [Emc-developers] April 2023 LinuxCNC meeting at Tormach
> headquarters
>
> [You don't often get email from ken.stra...@sympatico.ca. Learn why this
> is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> Is it possible that at least some of the discussions could be on Zoom or
> recorded for later viewing?
>
> -Original Message-
> From: Daniel Rogge 
> Sent: Friday, April 21, 2023 9:58 AM
> To: EMC developers 
> Subject: Re: [Emc-developers] April 2023 LinuxCNC meeting at Tormach
> headquarters
>
> All,
>
> Tormach can open the doors at any reasonable time.  I've had a few people
> ask me for an agenda, but I have no idea what people plan to discuss and I
> won't be able to attend most of the meeting personally (family has Covid).
> Perhaps someone on this list can put together a rough agenda for the
> weekend with times?
>
> Thanks,
>
> Rogge
>
>
> -Original Message-
> From: Ed 
> Sent: Friday, April 21, 2023 8:14 AM
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] April 2023 LinuxCNC meeting at Tormach
> headquarters
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> On 3/20/23 12:21 PM, Jon Elson wrote:
> > Will people who plan to attend (weekend of April 22-23) please confirm?
>
> I left a message here earlier and plan to attend.
>
> I see the address listed on the Linuxcnc forum and am wondering about what
> time to arrive?
>
> I have been to a couple of meets in Galesburg and one in Wichita and have
> noticed it was then a mostly afternoon and evening event.
>
>
> Thanks, Ed.
>
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] April 2023 LinuxCNC meeting at Tormach headquarters

[Sam Sokolik]

andy - asked here at work and they don't have any vfd's that have modbus.
I will look at the shop - but I don't think we have anything that new.

sam

On Fri, Apr 21, 2023 at 9:10 AM John Thornton  wrote:

> On the linuxcnc-devel channel rene-dev5 said 9-10 yesterday
>
> JT
>
> On 4/21/2023 8:14 AM, Ed wrote:
> > On 3/20/23 12:21 PM, Jon Elson wrote:
> >> Will people who plan to attend (weekend of April 22-23) please confirm?
> >
> > I left a message here earlier and plan to attend.
> >
> > I see the address listed on the Linuxcnc forum and am wondering about
> > what time to arrive?
> >
> > I have been to a couple of meets in Galesburg and one in Wichita and
> > have noticed it was then a mostly afternoon and evening event.
> >
> >
> > Thanks, Ed.
> >
> >
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] [Emc-users] April 2023 LinuxCNC meeting at Tormach headquarters

[Sam Sokolik]

I will be there.

On Fri, Mar 17, 2023 at 7:08 AM andy pugh  wrote:

> On Fri, 17 Mar 2023 at 11:41, Steffen Möller 
> wrote:
>
> >
> > I just checked the travel time and am a bit surprised about this being
> > minimum 15 hours one-way, more like a median 21 h.
>
>
> That's much longer than I would have guessed. Where is that from?
> It looks like 9-12 hours from London.
>
> I have a prior engagement that weekend. I am trying to decide if I want to
> cancel it in favour of this.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is designed
> for the especial use of mechanical geniuses, daredevils and lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Reminder: It's Today! (January 2023 Online Meeting)

[Sam Sokolik]

Jon had reached out to me to ask if I could do a fest. (I am a 2 hours from
tormach) I would love to and so would my dad..  But dad is fighting a big
fight currently and we just don't have the extra time to get organized to
have a fest.

This has always been the plan - to open the shop up for a fest - but boy -
life sure throws you curve balls.  Hopefully a year from now - things will
be better.

thanks
sam

On Fri, Jan 20, 2023 at 5:09 PM Daniel Rogge  wrote:

> Hi Jon and others on the EMC-dev list,
>
> Tormach is happy to host a meet up at our facility in Madison WI.  We
> happen to be bringing many of our remote staff and collaborators on site in
> April as well for an in-person meeting, so John Morris, Alex Rossler, Rob
> Ellenberg, Nico Stute, and others who you may know from either LCNC or
> MachineKit will be in town some time mid or late April.  If the two events
> happen to coincide with one another, I bet a few Tormachians will be happy
> to attend the LCNC meet up.
>
> Daniel Rogge
>
>
>
> -Original Message-
> From: Jon Elson 
> Sent: Wednesday, January 18, 2023 6:29 PM
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] Reminder: It's Today! (January 2023 Online
> Meeting)
>
> Daniel Rogge of Tormach has mentioned that he is trying to set up a
> meeting in April with Robert Ellenberg, John Morris and Alex Rossler over a
> weekend.  Does anybody have a specific date they would prefer or can't
> attend?  We could possibly set up a meeting that partly overlaps the one
> with the above people.
>
> Thanks,
>
> Jon
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Backplot MAX_POINTS

[Sam Sokolik]

Iirc it was just to make the preview more responsive...

On Thu, Dec 8, 2022, 8:16 PM Greg C  wrote:

> Good evening all,
>
> Recently on the forum turbostew brought up an issue that I've noticed in
> the past (in PathPilot) where on large cut files, the backplot starts to
> turn back to white at the beginning of the previewed cut paths.  Thread
> <
> https://forum.linuxcnc.org/qtvcp/41566-seems-like-a-buffer-size-limit-on-toolpath-highlighting?start=0#200370
> >
>
> What is actually happening is the max number of points is reached and the
> oldest points are falling off as the new points are added.  Since the
> number of MAX_POINTS is defined in emcmodule.cc, this would affect all
> guis.  emcmodule.cc L1981
> <
> https://github.com/LinuxCNC/linuxcnc/blob/131761f462ff0194a5403500f03f1f47c5899896/src/emc/usr_intf/axis/extensions/emcmodule.cc#L1981
> >
>
> Back in June of 2009 Jeff Epler lowered this value from 10 to 1,
> and unfortunately the commit doesn't give any details as to why.  Jeff's
> Commit
> <
> https://github.com/LinuxCNC/linuxcnc/commit/13e76953aaa61da0c560418cfbc117436d8c9f38
> >
>
> I wonder if anyone has insight to:
> 1. Why MAX_POINTS was lowered?
> 2. If I increased this back to 10 or even 100, are there any
> potential negative side effects (I didn't see anything obvious in the brief
> testing I did)?
>
> Thanks,
> Greg
>
> P.S. the way the backplotter "unwinds" on the beginning of the preview
> while adding to the current points of the cut path reminds me of the old
> computer game "Snake".  So I wonder if I increase the length of the snake,
> is there potential for it to "crash" into itself.  
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] LinuxCNC 2.8.2 Debian 10 Buster PREEMPT-RT ISO can't install Grub

[Sam Sokolik]

I have had issues installing debian from the boot menu..  but so far - the
installer when you boot into the live has worked every time.

On Sat, Oct 1, 2022, 1:06 PM  wrote:

> I just installed from the 2.8.4 ISO in a virtual machine
> (virtual box) with a network card active, but no connected
> ethernet cable, with success. No problems with grub.
>
> Joachim
>
> Am 01.10.22 um 13:06 schrieb andy pugh:
> > On Sat, 7 Aug 2021 at 13:47, Rod Webster  wrote:
> >>
> >> Just a heads up. It looks like the Buster ISO has a dependency for Grub
> >> that has to be installed from the network while installing. The install
> >> fails at this point in an endless loop and no way to boot the machine if
> >> you don't have internet access during the installation.
> >
> > I would assume that this is still the case with the 2.8.4 ISO?
> >
> > Does anyone know of a viable solution?
> >
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] un-wanted pauses

[Sam Sokolik]

or a rodent...

On Tue, Sep 20, 2022 at 7:55 PM Sam Sokolik  wrote:

> P pauses a program...   Sounds like keyboard noise..
>
> sam
>
> On Tue, Sep 20, 2022 at 7:36 PM gene heskett  wrote:
>
>> On 9/20/22 18:03, andy pugh wrote:
>> > On Fri, 16 Sept 2022 at 10:46, gene heskett 
>> wrote:
>> >
>> > I have my 6040 running a long time prpgram, and twice now I've gone out
>> >> to check the status,
>> >> and found it paused, in single step mode. In the middle of a movement
>> >> stroke stroke in a while
>> >> statement. There are no pause commands in the program.
>> >>
>> > So it is spontaneously going into single-step mode?
>> Yes. Twice now, but hasn't repeated since.
>> > I don't even know how to do that deliberately mid-program.
>> >
>> > Which GUI are you using?
>> Axis. w/lots of pyvcp eye candy. All we can do now is wait for the other
>> shoe to drop.
>> It won't get started again for at least a week, I need to  get what's in
>> progress wrapped
>> up and maybe even boxed & out of the way.
>>
>> 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, 1940)
>> If we desire respect for the law, we must first make the law respectable.
>>   - Louis D. Brandeis
>> Genes Web page <http://geneslinuxbox.net:6309/>
>>
>>
>>
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>

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

Re: [Emc-developers] un-wanted pauses

[Sam Sokolik]

P pauses a program...   Sounds like keyboard noise..

sam

On Tue, Sep 20, 2022 at 7:36 PM gene heskett  wrote:

> On 9/20/22 18:03, andy pugh wrote:
> > On Fri, 16 Sept 2022 at 10:46, gene heskett 
> wrote:
> >
> > I have my 6040 running a long time prpgram, and twice now I've gone out
> >> to check the status,
> >> and found it paused, in single step mode. In the middle of a movement
> >> stroke stroke in a while
> >> statement. There are no pause commands in the program.
> >>
> > So it is spontaneously going into single-step mode?
> Yes. Twice now, but hasn't repeated since.
> > I don't even know how to do that deliberately mid-program.
> >
> > Which GUI are you using?
> Axis. w/lots of pyvcp eye candy. All we can do now is wait for the other
> shoe to drop.
> It won't get started again for at least a week, I need to  get what's in
> progress wrapped
> up and maybe even boxed & out of the way.
>
> 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, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
> Genes Web page 
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] PCIe EPP parport issues

[Sam Sokolik]

one interesting thing...  If you crash out of 2.9 - the installed 2.8 won't
start until you re-launch and exit 2.9..  (no - linuxcnc is already running
- do you want to exit?)

I will get the error that comes up when you try to launch 2.8...

sam

On Tue, Sep 6, 2022 at 4:43 PM andy pugh  wrote:

> On Tue, 6 Sept 2022 at 22:34, Bari  wrote:
>
> > So it looks like an RTAI bug with 2.8 at least about the encoders
> > signals to spindle RPM GUI in Axis.
> >
> > Will go back and trace why preempt_rt has issues with LPT encoders in
> > LCNC 2.9.
>
> If there is a difference between the realtime versions then I would be
> looking in the rtapi code for different implementations of rtapi_inb
> https://linuxcnc.org/docs/stable/html/man/man3/rtapi_inb.3rtapi.html
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] BIG Quirk in Axis??

[Sam Sokolik]

G20/21 issue?

On Sat, Jul 30, 2022, 8:52 PM Jon Elson  wrote:

> I have been setting up an R2E3 mill using the 2.8.2
> distribution from a couple weeks ago.
>
> I now have 2 servo amps running and tuned.  Now I tried to
> run a stripped-down axis.ngc program, but get no motion!
> Then, I tried doing some moves in MDI mode, and again no
> motion!  I can jog around just fine, but any moves in auto
> mode don't happen.  Has anybody seen this or have any idea
> what is going on?  I'm totally mystified!
>
> Thanks in advance for any hints.
>
> Jon
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] LXRT Realtime (RTAI uspace) and hm2_eth

[Sam Sokolik]

Yah.  Iirc - the initial realtime that worked with Ethernet was xenomai...
(I used it with the help of Peter and Micheal h? ).  Then rt-prempt was
integrated by Jeff (I think).  I have no clue if xenomai even works either.

On Sat, Jul 9, 2022, 9:53 AM andy pugh  wrote:

> On Tue, 28 Jun 2022 at 21:40, andy pugh  wrote:
>
> > That seems like it can work, in that compiling uspace on the rtai
> > kernel works, and says "using LXRT realtime"
>
> It seems that uspace RTAI does not work with hm2_eth:
> andypugh@rm-one:~/linuxcnc-dev/src$ uname -a
> Linux rm-one 4.19.195-rtai-amd64 #5 SMP PREEMPT Sun Jul 11 19:13:27
> BST 2021 x86_64 GNU/Linux
> andypugh@rm-one:~/linuxcnc-dev/src$ halrun
> halcmd: loadrt hostmot2
> Note: Using LXRT realtime
> hm2: loading Mesa HostMot2 driver version 0.15
> halcmd: loadrt hm2_eth board_ip=192.168.1.121
> hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
> hm2_eth: 192.168.1.121: INFO: Hardware address (MAC): 00:60:1b:10:00:08
> hm2_eth: discovered 7I80DB-16
> hm2/hm2_7i80.0: Low Level init 0.15
>
> {machine locks solid}
>
> Nothing appeared in the kernel log to show what the issue was before
> it locked. So I think we may need to deprecate this mode of operation.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] curious about the ethernet protocol

[Sam Sokolik]

Linuxcnc doesn't care where you close the feedback loop (linuxcnc always
closes the feedback loop).   Simple step/direction closes the loop between
the step-gen and linuxcnc.



sam

On Wed, Apr 20, 2022 at 3:57 PM Torsten Curdt via Emc-developers <
emc-developers@lists.sourceforge.net> wrote:

> > > That said - that's a dual loop with two different encoders.
> > > That's not really the same dual loop when you have LinuxCNC and a
> Closed
> > > Loop Stepper/Servo Driver.
> >
> > If you only have one feedback source, how can you have a dual feedback
> > loop? With the feedback closed on the driver, your joint will be treated
> as
> > if its open loop by linuxcnc.
> > Yes, Linuxcnc will use a pid but its generally not aware of the drive's
> > encoder. Its just dealing with step and direction pulses.
> >
>
> That is exactly the point I was trying to make.
> I guess the closed loop on the driver will do a decent job.
> But such a system does not really seem to be in the full spirit of LinuxCNC
> being in control.
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] curious about the ethernet protocol

[Sam Sokolik]

You can do all sorts of fancy stuff - with realtime tucked comfortably in
the computer...  (not excluding torch height control all within linuxcnc)

https://www.youtube.com/shorts/nViXP9SsdWc

Linuxcnc is like a large real time lego set...

sam

On Sun, Apr 17, 2022 at 8:42 PM Rod Webster  wrote:

> So Andy's post brings is right back to Peters comment
>
> Basically just following the LinuxCNC model of having the host be the
> > locus of control. This is the basic difference between buffered systems
> > like Mach and LinuxCNC. By having the LinuxCNC host be the controller
> > you gain a number of advantages:
>
>
> 1. The external hardware is simpler (and more uniform)
> > 2. The more complex parts of the control are located on a host
> > with basically unlimited memory and CPU capabilities so real time
> behaviour
> > is extensible by a large group of users/developers using standard tools.
> > 3. Specifically, returning actual position allows use of the following
> > error mechanism for tuning and robust fault detection without a side
> > channel of status information.
>
>
> Aside from continual improvement to the core tc (trajectory controller),
> The hidden gem in Linuxcnc is the ability to write your own components in C
> that are compiled and installed with a single command. Once implemented in
> hal (hardware extraction layer) via your hal file with loadrt and addf
> commands, your custom component has access to that infinite memory and CPU
> capability AND it is treated as if it is part of the Linuxcnc core viar the
> controlling servo thread.
>
> Whether it is possible to use a serial modbus encoder in the real time
> environment might be problematic though. You might be able to use external
> hardware with a UART (perhaps from Mesa) that accumulated the encoder count
> for linuxcnc to read every millisecond. In theory, you should only need one
> UART in a multidrop environment but whether a serial protocol would be fast
> enough to service all encoders in a single servo thread cycle would be a
> moot point.
>
> If you wanted an alternative to Mesa there are always solutions from Jon or
> you could use ethercat. Linuxcnc will not care at the tc level.
>
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> Vehicle Modifications Network
> www.vehiclemods.net.au
>
>
> On Mon, 18 Apr 2022 at 10:00, andy pugh  wrote:
>
> > On Sat, 16 Apr 2022 at 00:42, Torsten Curdt via Emc-developers
> >  wrote:
> >
> > > IIUC the GCODE interpreter runs in the non-realtime part. It sends the
> > step
> > > instructions to a card to execute the steps. This is obvious when
> using a
> > > LPT port, but how does this work via Ethernet?
> >
> > There are some steps missing here that have not been explained in
> > later posts which might explain the process.
> >
> > The interpreter, as you said, runs in user space, it reads G-code and
> > converts it in to "canonical commands" which are fed to the motion
> > queue.
> > These commands are the basic things that a CNC machine needs to do. It
> > is worth noting that many G and M-codes only affect the internal
> > status of the interpreter, and that is partly why the program line
> > counter skips non-movement commands, they simply don't exist in te
> > queue)
> > Also, the interpreter is a pluggable module, it doesn't have to be
> G-code.
> >
> > There are several steps from here, including converting the commands
> > into NML messages (
> >
> >
> https://www.nist.gov/publications/neutral-message-language-model-and-method-message-passing-heterogeneous-environments
> > ) but eventually the commands get to the "trajectory planner" (tp)
> > (userspace) where they are put into the motion queue, which is
> > consumed by the (realtime) "trajectory controller" (tc).
> >
> > Every 1mS the tc calculates new positions for all axes, and puts those
> > positions on to HAL pins.
> >
> > What happens next depends on the system. With an LPT system the HAL
> > "stepgen" component 1mS thread reads how many steps have been made in
> > the last period, and from that and the new position calculates the
> > required step-rate to hit the new position at the end of the current
> > period. Then, in the fast thread the (integer maths only) step
> > generator makes the pulses.
> >
> > With a Mesa or Pico stepper system there is no fast thread, the HAL
> > driver does the same calculations as the LPT driver, though, but
> > passes the required step rate through PCI, EPP, SPI or ethernet to the
> > FPGA (or processor) on the card by writing to registers on the card.
> >
> > So, the cards are doing very little.
> >
> > As far as I know an ethernet smoothstepper does not do this. I don't
> > even think that they "buffer" as is often suggested. In fact I think
> > that they move all of the "tc" on to the hardware. So probing and
> > spindle-synched motion is handled inside the card, not on the host
> > controller.
> >
> > --
> > atp
> > "A motorcycle is a bicycle with a pandemonium attachment and is
> > 

Re: [Emc-developers] LinuxCNC is in Debian!

[Sam Sokolik]

This is amazing...   This will make Linuxcnc even easier to access..   Game
changer?  Maybe!

sam

On Sun, Feb 27, 2022 at 1:32 PM Nicklas SB Karlsson  wrote:

> Metoo use debian. Great!
>
> On Sun, 27 Feb 2022 11:36:37 -0700
> Sebastian Kuzminsky  wrote:
>
> > On 2/27/22 04:00, Debian FTP Masters wrote:
> >  > Accepted:
> >  >
> > > Format: 1.8
> > > Date: Fri, 25 Feb 2022 18:40:12 +0100
> > > Source: linuxcnc
> > > Binary: linuxcnc-doc-en linuxcnc-doc-es linuxcnc-doc-fr
> linuxcnc-doc-zh-cn linuxcnc-uspace linuxcnc-uspace-dbgsym
> linuxcnc-uspace-dev
> > > Architecture: source all amd64
> > > Version: 2.9.0~pre0+git20220224.3ba0951743-1
> > > Distribution: unstable
> >
> > Yayyy!  Thank you Steffen, and Petter and everyone who's been working on
> > getting LinuxCNC into Debian!
> >
> > If you're running sid/unstable you can now just `apt-get install
> > linuxcnc-uspace`, right from the debian.org package archive:
> >
> >  
> >
> >
> > It'll hopefully make it into bookworm/testing in a couple of days.
> > We'll work on bullseye after that.  :-)
> >
> >
> > --
> > Sebastian Kuzminsky
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Buildbot Asleep

[Sam Sokolik]

I don't understand why any one or thing would want to stay in 2021..

On Sun, Jan 2, 2022, 6:59 PM Phill Carter  wrote:

> Buildbot seems to not want to leave 2021.
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Processing of linuxcnc_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.changes

[Sam Sokolik]

Amazing work!

On Tue, Nov 9, 2021, 9:35 AM Chris Radek  wrote:

> On Mon, Nov 08, 2021 at 06:31:20PM -0700, Sebastian Kuzminsky wrote:
> >
> > This will make it much easier for people to try out LinuxCNC, and will
> > greatly increase our visibility in the CNC software world.
> >
> > This is an exciting time for LinuxCNC, and we could not have done it
> > without Steffen and Petter.  Thank you!  <3
>
> Wow, thank you for doing this work.  It's a goal the project has had
> for 20 years and I very much appreciate everyone who helped make it
> possible.
>
> Cheers,
> Chris
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Updating linuxcnc

[Sam Sokolik]

I changed it back to  <http://linuxcnc.org>
deb http://linuxcnc.org stretch base 2.8-rtpreempt

And update/upgrade didn't change anything..  so it worked?

On Tue, Oct 5, 2021, 6:49 PM andy pugh  wrote:

> On Wed, 6 Oct 2021 at 00:08, Sam Sokolik  wrote:
> >
> > The docs say to use
> > deb http://linuxcnc.org stretch base 2.8-rtpreempt
> >
> > But It only upgrades it to 2.8.1
>
> Try it now?
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

[Emc-developers] Updating linuxcnc

[Sam Sokolik]

The docs say to use
deb http://linuxcnc.org stretch base 2.8-rtpreempt

But It only upgrades it to 2.8.1

If I use
deb http://buildbot.linuxcnc.org/ stretch 2.8-rtpreempt
deb-src http://buildbot.linuxcnc.org/ stretch 2.8-rtpreempt

I get 2.8.2

(just editing the source file)

thanks
sam

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

Re: [Emc-developers] crazy BIOS(?) interference with EPP parallel port

[Sam Sokolik]

The hp 8300 sff have a printer port header on the motherboard...

On Tue, Jun 29, 2021, 9:25 PM Bari  wrote:

> I used to design motherboards and write BIOS. BIOS from the major
> vendors pretty much works the same way. Hardly anyone works with source
> you just glue a bunch of modules together in the "configurator" and hope
> they work. Testing is just running and rebooting in Windows.
>
> On 7/2/17 12:50 PM, Jon Elson wrote:
> > But, the REAL issue is, there is no definitive document that tells how
> > to operate an EPP port!  Everybody invents his own code, and tries it
> > on a few cards, and hopes that it is right.  UGH!!!
> >
> > Jon
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] RTAI 5.3.1 for LinuxCNC

[Sam Sokolik]

Andy - random thought..  are you using wicd?  I had issues getting USB wifi
to work  Ended up installing network manager...

On Mon, Jun 21, 2021, 4:45 PM andy pugh  wrote:

> On Mon, 21 Jun 2021 at 21:12, andy pugh  wrote:
>
> > The same device _does_ work with the 4.14.174-rtai kernel (from last
> April)
>
> The drivers seem to be installed.
>
>   AR  drivers/net/wireless/mediatek/built-in.a
>   AR  drivers/net/wireless/quantenna/built-in.a
>   AR  drivers/net/wireless/ralink/rt2x00/built-in.a
>   AR  drivers/net/wireless/ralink/built-in.a
>   AR  drivers/net/wireless/realtek/built-in.a
>
> It is like it isn't aware that USB WiFi is a possibility. It sees the
> devices but does not try to load a driver.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] at_pid

[Sam Sokolik]

I tried it with both velocity mode and current mode loops..  didn't create
a usable results...

On Fri, May 7, 2021, 6:39 PM Gene Heskett  wrote:

> On Friday 07 May 2021 18:47:21 andy pugh wrote:
>
> > http://linuxcnc.org/docs/2.8/html/man/man9/at_pid.9.html
> >
> > I have just remembered that, as far as I am aware, this simply does
> > not work.
> >
> > Has anyone ever made it work?
> >
> > Should we just remove it? Or does someone want to try to fix it?
>
> I spent about 10 days playing with it a year or so back, never got it to
> work like the docs say, failed miserably IOW. I'd like to see it work if
> somebody wants to drag it, kicking and screaming out of the '90's.
>
> Making it Just Work would be quite a feather in LinuxCNC's hat.
>
> 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)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Home_use_index issue revisited

[Sam Sokolik]

Because - I think in that situation - the index pulse also goes to the
encoder counter and resets the encoder count to zero.   You don't have that
happening because you don't have an encoder counter.

On Sat, Apr 3, 2021, 11:49 PM Feral Engineer 
wrote:

> Yeah, I mean it's kinda what I'm trying to do now, but I'd like to get it
> to work native to how I think it should in my mind.
>
> Here's what the page says:
> When using encoder index homing, the home switch offset is calculated from
> the encoder reference position, after the home switch has been tripped.
>
> To me, it sounds like it should hit the switch, back up until it finds the
> "encoder index" pulse and zero right there. Why it moves and zeroes at its
> original power up location is messing with my head.
>
> Phil T.
> The Feral Engineer
>
> Check out my LinuxCNC tutorials, machine builds and other antics at
> www.youtube.com/c/theferalengineer
>
> On Sun, Apr 4, 2021, 12:39 AM Sam Sokolik  wrote:
>
> > Initially I would just try 'and-ing' the 2 in hal or classic ladder and
> run
> > strait to the home input.  (Not using the home to index)
> >
> > On Sat, Apr 3, 2021, 11:20 PM Feral Engineer  >
> > wrote:
> >
> > > Mechanical switch and a proximity sensor (mechanical on 7i76 input 5,
> > prox
> > > on input 30, powered by output 15 after latching input 5)
> > >
> > > Stepper motors, 7i76e board, emco pc turn 55. It originally had this
> > setup
> > > (dual switch and prox home sequence). Tried doing this a while back but
> > > gave up, then had the idea to try and circumvent the weird return to
> > random
> > > spot via ladder logic, to no avail.
> > >
> > > Phil T.
> > > The Feral Engineer
> > >
> > > Check out my LinuxCNC tutorials, machine builds and other antics at
> > > www.youtube.com/c/theferalengineer
> > >
> > > On Sun, Apr 4, 2021, 12:15 AM Sam Sokolik  wrote:
> > >
> > > > So your not using an actual encoder to home but using a home switch
> and
> > > an
> > > > 'index' pulse.   Thinking out loud - in a normal homing sequence -
> the
> > > > index would reset the encoder counts to zero.  In effect you don't
> have
> > > > that functionality.   Is this steppers?  Using a Stepgens of some
> kind?
> > > > Maybe that needs to be reset somehow?  Again - thinking out loud and
> it
> > > is
> > > > late.
> > > >
> > > > On Sat, Apr 3, 2021, 10:58 PM Feral Engineer <
> > theferalengin...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Finally getting back around to messing with this mechanical/prox
> home
> > > > > issue. See attached video link. I show what it is doing and explain
> > > what
> > > > I
> > > > > want it to do.
> > > > >
> > > > > Thanks in advance for your help
> > > > >
> > > > > https://youtu.be/XVz6v2YNXJQ
> > > > >
> > > > > Phil T.
> > > > > The Feral Engineer
> > > > >
> > > > > Check out my LinuxCNC tutorials, machine builds and other antics at
> > > > > www.youtube.com/c/theferalengineer
> > > > >
> > > > > ___
> > > > > Emc-developers mailing list
> > > > > Emc-developers@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/emc-developers
> > > > >
> > > >
> > > > ___
> > > > Emc-developers mailing list
> > > > Emc-developers@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/emc-developers
> > > >
> > >
> > > ___
> > > Emc-developers mailing list
> > > Emc-developers@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-developers
> > >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Home_use_index issue revisited

[Sam Sokolik]

Initially I would just try 'and-ing' the 2 in hal or classic ladder and run
strait to the home input.  (Not using the home to index)

On Sat, Apr 3, 2021, 11:20 PM Feral Engineer 
wrote:

> Mechanical switch and a proximity sensor (mechanical on 7i76 input 5, prox
> on input 30, powered by output 15 after latching input 5)
>
> Stepper motors, 7i76e board, emco pc turn 55. It originally had this setup
> (dual switch and prox home sequence). Tried doing this a while back but
> gave up, then had the idea to try and circumvent the weird return to random
> spot via ladder logic, to no avail.
>
> Phil T.
> The Feral Engineer
>
> Check out my LinuxCNC tutorials, machine builds and other antics at
> www.youtube.com/c/theferalengineer
>
> On Sun, Apr 4, 2021, 12:15 AM Sam Sokolik  wrote:
>
> > So your not using an actual encoder to home but using a home switch and
> an
> > 'index' pulse.   Thinking out loud - in a normal homing sequence - the
> > index would reset the encoder counts to zero.  In effect you don't have
> > that functionality.   Is this steppers?  Using a Stepgens of some kind?
> > Maybe that needs to be reset somehow?  Again - thinking out loud and it
> is
> > late.
> >
> > On Sat, Apr 3, 2021, 10:58 PM Feral Engineer  >
> > wrote:
> >
> > > Finally getting back around to messing with this mechanical/prox home
> > > issue. See attached video link. I show what it is doing and explain
> what
> > I
> > > want it to do.
> > >
> > > Thanks in advance for your help
> > >
> > > https://youtu.be/XVz6v2YNXJQ
> > >
> > > Phil T.
> > > The Feral Engineer
> > >
> > > Check out my LinuxCNC tutorials, machine builds and other antics at
> > > www.youtube.com/c/theferalengineer
> > >
> > > ___
> > > Emc-developers mailing list
> > > Emc-developers@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-developers
> > >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Home_use_index issue revisited

[Sam Sokolik]

So your not using an actual encoder to home but using a home switch and an
'index' pulse.   Thinking out loud - in a normal homing sequence - the
index would reset the encoder counts to zero.  In effect you don't have
that functionality.   Is this steppers?  Using a Stepgens of some kind?
Maybe that needs to be reset somehow?  Again - thinking out loud and it is
late.

On Sat, Apr 3, 2021, 10:58 PM Feral Engineer 
wrote:

> Finally getting back around to messing with this mechanical/prox home
> issue. See attached video link. I show what it is doing and explain what I
> want it to do.
>
> Thanks in advance for your help
>
> https://youtu.be/XVz6v2YNXJQ
>
> Phil T.
> The Feral Engineer
>
> Check out my LinuxCNC tutorials, machine builds and other antics at
> www.youtube.com/c/theferalengineer
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Beagle Bone / PRU support ?

[Sam Sokolik]

Isolcpus certainly does work.   The best latencey I get it with 1,2,3

Sam

On Mon, Mar 29, 2021, 11:52 AM Gene Heskett  wrote:

> On Monday 29 March 2021 10:46:54 Jon Elson wrote:
>
> > On 03/28/2021 09:46 PM, Gene Heskett wrote:
> > > I, for comparison, I just built the latest git pull on my pi4,
> > > getting these times, which I don't quite grok:
> > > real81m28.218s
> > > user133m40.185s
> > > sys 30m24.466s
> > >
> > > How do I get user+sys at nearly 2x the real which is the same as the
> > > actual wall time?
> >
> > Doesn't the Pi4 have multiple CPU cores?  With 2 cores,
> > total times can be 2X wall clock time.
> >
> > Jon
>
> The pi4 has 4 cores. /boot/cmdline.txt contains isolcpus=3, but I've
> since read that isolcpus doesn't work on arms of any flavor. Not an
> error in dmesg but supposedly ignored. Or is it? Running htop from
> another login shell here, htop numbers them in base 1 format and core 4
> is never used, even when linuxcnc is running, so maybe it does work and
> the uspace version doesn't use it?
>
> I'll take that out of /boot/cmdline.txt just for S  And now lcnc is
> using cpu4 at nominally 23% while sitting idle. And does not appear to
> be jumping around from the deadline scheduler activity. Interesting...
> But "latency-test -period" is much worse. peaks at 60 some microseconds
> very quckly. Put it back in, rebooted and now latency-test -period takes
> 2 minutes to get past 10 microseconds. Strange but thats a kernel I
> built too.
>
> However, htop is seeing it running? On a buster install on an old i5
> too!!!
>
> Crazy, so isocpus is indeed working on the arms, at least with my armhf
> kernel.  But that kernel install ain't easy. You can't "sudo make
> install", you have to make a tarball containing the kernel /boot stuff
> and its /lib stuffs which is about a 30 meg tarball, ship it to this
> machine, and unpack it to the u-sd card, overwriting the /boot and /lib
> contents already there.
>
> Theres a lot more to it than that doing it the first time though.  Read
> the README.txt in that directory. Goto the link in my sig, and extend
> the address bar by adding lathe-stf/ which will then show you another
> directory named linucnc4pi4b where the whole story resides in that
> README
>
> And I forgot but I'd made another link, to the below address, add
> buildbot-repo, gets you to the same dir. I'll update the lcnc files
> there shortly.
>
> [ 0.601192] SMP: Total of 4 processors activated (432.00 BogoMIPS)
>
> Running linuxcnc at 900 mhz/core, it has plemty of time left. I've been
> out on the net with firefox while lathe-pawn was running in a loop, no
> problems with how lcnc was running while I was browsing the news sites.
>
> Thanks Jon
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

[Emc-developers] Some e-offset questions.

[Sam Sokolik]

I have been playing with it for a bit now and am wondering about a few
things...

Could there be a e-offset error?  (difference between where the axis is and
the o-ffset input)

Can the e-offset ratio be disabled or changed from within linuxcnc?  I
don't see an ini. hal pin for it.  The reason is - for doing some of the
fancy spindle synced motion stuff I need to apply most of the acc/vel to
e-offset.  This makes for very slow normal motion.  In this situation - I
only need the high ratio during polygon motion

Is this making sense?

thanks!
sam

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

Re: [Emc-developers] Debian 10 Install

[Sam Sokolik]

(and I mean - installing linuxcnc on top.)

On Thu, Sep 24, 2020 at 9:26 AM Sam Sokolik  wrote:

> I just did a fresh install of the debian 10 livecd with xfce - worked as
> expected.
>
> sam
>
> On Thu, Sep 24, 2020 at 7:58 AM andy pugh  wrote:
>
>> On Thu, 24 Sep 2020 at 13:38, John  wrote:
>>
>> > echo deb http://linuxcnc.org/ buster base 2.8-rtpreempt | sudo tee -a
>> > /etc/apt/sources.list.d/linuxcnc.list
>> >
>> > This line corrupts the terminal session by some kind of redirect of
>> > stdin and when I try and install LinuxCNC apt simply aborts after the
>> > Y/n question.
>>
>> Maybe we should just state that Mate is clearly broken in many ways
>> and shouldn't be used.
>>
>> The line above works exactly as expected in Debian. Does Mate use some
>> unusual shell or other?
>>
>> --
>> atp
>> "A motorcycle is a bicycle with a pandemonium attachment and is
>> designed for the especial use of mechanical geniuses, daredevils and
>> lunatics."
>> — George Fitch, Atlanta Constitution Newspaper, 1912
>>
>>
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>

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

Re: [Emc-developers] Debian 10 Install

[Sam Sokolik]

I just did a fresh install of the debian 10 livecd with xfce - worked as
expected.

sam

On Thu, Sep 24, 2020 at 7:58 AM andy pugh  wrote:

> On Thu, 24 Sep 2020 at 13:38, John  wrote:
>
> > echo deb http://linuxcnc.org/ buster base 2.8-rtpreempt | sudo tee -a
> > /etc/apt/sources.list.d/linuxcnc.list
> >
> > This line corrupts the terminal session by some kind of redirect of
> > stdin and when I try and install LinuxCNC apt simply aborts after the
> > Y/n question.
>
> Maybe we should just state that Mate is clearly broken in many ways
> and shouldn't be used.
>
> The line above works exactly as expected in Debian. Does Mate use some
> unusual shell or other?
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Wheezy install vs. editors

[Sam Sokolik]

I use mousepad all the time.  No issue.


On Fri, Sep 18, 2020, 1:26 PM Jon Elson  wrote:

> One of my customers is having issues with editing hal
> files.  He says he is using the Wheezy iso install, and the
> only editor on it is "mousepad".  Never heard of that.  He
> reports that if he opens a hal file for editing,
> LinuxCNC/Axis will no longer come up.
>
> I remembered an issue about CR/LF being corrupted by editing
> some time ago, and suggested he download another editor,
> like emacs. He's going to try that, now.
>
> Has anyone seen this issue?
>
> Jon
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Looking for Lcnc Dev's to interview on podcast for the 2.8 update

[Sam Sokolik]

Subtractive machining...

On Thu, Sep 17, 2020, 3:41 PM Bari  wrote:

> On 9/17/20 2:09 PM, Robert Murphy wrote:
>
> > One thing that really intrigues me is that when did maker, I really hate
> that term and it’s sounds a little childish, replace hobbyist ?
> >
> > Composed with my Crayons
>
>
> Bad or worse than expansion boards being called capes, shields, cloak,
> pashmina, serape, poncho, etc?
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] startup anomaly on OLD LinuxCNC

[Sam Sokolik]

I think the splash gcode sets the units to mm...  So if your program
doesn't change it back to inches you will get odd behavior...   (I think)


On Tue, May 5, 2020, 3:55 PM Jon Elson  wrote:

> Yes, I KNOW, this is a REALLY old version, but just thought
> I'd report it.
>
> I'm running LinuxCNC 2.5.4 on my Bridgeport mill.  I just
> used it a couple days ago, everything worked
> fine.  I started it up today, homed, and forgot to load the
> toolpath, and pressed R with the LinuxCNC
> toolpath still loaded.  I immediately noticed it was heading
> for the wrong place and hit esc to abort it.
> I then loaded the correct .ngc file, and when I pressed R,
> it again headed toward (0,0).
> I reloaded the toolpath several times, getting the same
> response from that path and another old toolpath I tried.
>
> Finally, I exited LinuxCNC and restarted, homed, loaded the
> toolpath and all was fine.
> I believe I have experienced something like this behavior
> twice before, and never was able to put my finger on what
> was wrong.
>
> I am using the Axis GUI.
>
> Yes, someday I will update this system, but it does all I
> need right now, I don't do any LinuxCNC development on it,
> just cut metal.
>
> Thanks for any comments,
>
> Jon
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] State-synch G-code.

[Sam Sokolik]

G4?

On Thu, Apr 9, 2020, 5:34 PM andy pugh  wrote:

> Should we invent a new G-code that functions specifically to bust the
> queue?
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] charge_pump no longer works w/o a base thread it 2.9.0-pre

[Sam Sokolik]

There is no reason why it shouldn't run in the servo thread...

Master seems to work (It is running at 500hz in the servo thread)

sam

On Fri, Feb 21, 2020 at 9:34 PM Gene Heskett  wrote:

> Greeting all;
>
> In going thru my hal file to add a machine power control, hooked to
> e-stop-out, which yu can click on or tap the F1 key to toggle, I found
> the charge_pumps man page say it needs a base thread ??  It did work in
> the past when I was using that circuit from mist or flood to run a motor
> the brought a locator bar into the end of a shop made jig, to locate the
> board while machining the green and green fingers for a blanket chest,
> but which by shutting off that button, opened the bar, getting it out of
> the way of being cut to pieces by the tool as it cut the finger patterns
> into the ends of the boards.  There was no base thread running then
> either but the charge_pump happily toggled along at half the servo
> thread or 500 hz.  Now it doesn't work and the man page now says so.
>
> Why? I did that, made up a charge bucket in hardware because it was not
> possible to control that bar with a dc signal so it was only engaged
> when mill power was engaged and enabled with the gui button toggle.
>
> Now I will need to come up with something to duplicate that. I can, I did
> it on the 6040 controlling the mister when I found it came on and
> drained the tank overnight when linuxcnc was shut down.  Except I got
> plumb fawncy and made both half cycles adjustable as a very wide range
> flow control with 1 millisecond resolution.
>
> But why was the charge_pump disabled from running in the servo thread?
> There must have been a reason, but its hidden from me.
>
> 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)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] [Emc-users] Raspberry Pi

[Sam Sokolik]

I just tested the hal_pi_gpio component in 2.8,

Using the example here
https://github.com/LinuxCNC/linuxcnc/commit/e0dc3a0bb9e9ff4b283f52586d505f4b9bcda60d

(the hal example all the way at the bottom)

The only gocha for me was the hal GPIO numbering is the actual pin numbers
of the RPI header (not the RPI gpio numbering)  Figured it out.

http://electronicsam.com/images/greenmachine/IMG_20191103_112558.jpg

sam

On Sun, Nov 3, 2019 at 8:22 AM Gene Heskett  wrote:

> On Sunday 03 November 2019 08:45:28 Thomas J Powderly wrote:
>
> > Gene
> >
> > I trimmed your url back 1 level
> >
> > to http://geneslinuxbox.net:6309/gene/lathe-stf/
> >
> > then i got the typical directory
> >
> > from there i could enter linuxcnc4pi4b/
> >
> > and access the files fine
> >
> Which is exactly my observation here.
>
> > so it was only the link in the email ( and firefox-esr )
> >
> > thanks, grabbing mage now
> >
> > TomP
>
> Shit Tomp, I just restarted apache2 because bingbot, yandex.com/bot and
> semrush have figure out a way past my host.deny blocks and were using up
> my upload bandwidth. Go get it again.
>
> Whats your ipv4 addy?, if fixed I'll put it in my hosts.allow.
>
> 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)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] [Emc-users] web site error

[Sam Sokolik]

Thanks Chris - I know how hard it is to figure this stuff out when it has
been years...

sam

On Sun, May 5, 2019 at 4:01 PM Chris Radek  wrote:

> With Stephen's help I finally got access to the machine and then was
> able to patch it up.  There were several confounding problems due to
> upgrades at the hosting site, one of which was that my ssh key was
> in an old format that has been deprecated.
>
> I don't know who gets those webmaster emails either...
>
> Chris
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Simultaneous 4 axis + new TP

[Sam Sokolik]

The new to falls back to 1 segment look ahead if rotary axis motion is
used.  Simultaneous motion works...  just not n lookahead...

On Wed, Mar 13, 2019, 12:51 PM Curtis Dutton  wrote:

>  I posted a while ago about adding software laser rastering to linuxcnc.
> I'm close to getting the documentation finished so I can get a pull request
> for that.
>
> I've recently begun to implement 4 axis simultaneous laser engraving using
> G93 inverse time feed. I think I remember reading that the NEW TP doesn't
> work when using more than the XYZ axis.
>
> While laser engraving, keeping the speed of the laser as constant as
> possible is important.
>
> When the machine gets to a section with many small moves it slows way
> down.  Even with straight G64 it is too slow.
>
> Does anyone know about plans for getting the new TP to work with > 3 axis?
> I'm not opposed to beginning some of this work if anyone has some pointers?
>
> Thanks,
>Curtis
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Singularity avoidance

[Sam Sokolik]

The motion adaptive feed pin could work..

http://linuxcnc.org/docs/html/man/man9/motion.9.html


On Thu, Feb 14, 2019, 5:52 AM Thắng Lê  "Singularity avoidance has been a developing topic for many years"
> This topic was introduced here:
> https://robohub.org/3-types-of-robot-singularities-and-how-to-avoid-them/
>
> There is a solution was mentioned: reduce velocity when robot goes near
> singlarity.
>
> Because i cant take result of inverse kinematic function (can make this
> function return singularities)  and i dont want to touch linuxcnc-core so i
> have idea create a new hal component to recalculator singulartities.
>
> The last problem: how to reduce velocity when robot is near singularities
> and return old velocity when robot passes it? Is there any hal pin could do
> this?
>
>
> --
> Lê Thắng
> Phone: (+84) 7722443855
> Email: lethang12...@gmail.com
>___ ___ ___
> ( __ ) __ __( _ )
>  \  -  \   _|__|_
>\  -  \ (_/ \_)
>  \  -  \
>__\_ -_\ __
>   [_]
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] New Stuff

[Sam Sokolik]

I have lightly tested RR..  I think it is a great addition..

https://youtu.be/u9QqVx3_RgA

On Tue, Sep 18, 2018, 7:40 AM andy pugh  wrote:

> On Tue, 18 Sep 2018 at 13:29, Rene Hopf via Emc-developers
>  wrote:
>
> > Yes, good idea. This is a good way of checking if there are any issues
> with existing behaviour.
> > reverse run is also useful to get drills and stuff out of holes on multi
> axis machines.
> > who is maintaining those branches? will you merge them?
>
> External Offsets is Dewey.
> Dewey: Is two votes enough to encourage you to push the merge?
> I have tested External Offsets extensively, my lathe has been running
> that branch for a long time, with no deliterious effects on
> conventional operation.
>
> Reverse Run is Rob Ellenberg
> Rob: Same question (and do you think it is ready to run?)
>
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] INI edit from inside gui

[sam sokolik]

There is already an example of this in the 'machine calibration' gui 
within axis.  It is used primarily for PID tuning.  It then allows you 
to save the parameters back to the ini.


sam

On 11/2/2017 7:42 AM, Marius Liebenberg wrote:
I do a lot of upgrades to Chinese routers from their controller to 
Mach3. I have been using an Atom type mother board for the last five 
years together with a detuned Windows XP installation. It is always a 
parallel port driver installation.
I am finding it more and more difficult to get motherboards that will 
support XP and today my supplier warned me that the motherboards of 
the future will not install XP at all.


The reason that I install Mach3 with a parallel breakout is purely 
because it is so easy to do and my customers do not need to learn linux.
Now I am thinking that the time has maybe come to do a Mach 
replacement controller that will be just as easy but running linuxcnc. 
If I use Gmoccapy for instance and add a page or two that can edit a 
configuration similar to what one does in Mach, then there might be 
less resistance to using linuxcnc.


So I would imagine that there will be a matrix of pins and signals 
that could be configured from within the gui and a standard INI file 
with parameters for calibration of motor parameters and others.


Will it be possible to reload or restart linuxcnc from inside the gui 
and more so, what do the gurus think of such and idea? Is it at all 
feasible?



-
Regards / Groete

Marius D. Liebenberg
+27 82 698 3251
+27 12 743 6064


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


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] A tweak to Touchy?

[sam sokolik]

On the Matsuura - I found this out also (counts not resetting between 
launches of linuxcnc).  (the encoder counters on the 7i73)

I think I got around it by applying the reset pulse to the encoder 
counter in hal as linuxcnc booted.  (I think peter had a better solution 
but I don't remember what it was)

sam

On 4/17/2017 9:48 AM, andy pugh wrote:
> My lathe is set up with the Touchy interface. However I am not using
> the touchy jog-counts input as I have 4 separate wheels for jogging  X
> and Z and for spindle and feed override. (I don't currently have a way
> to alter maxv or to move the restart point, but I haven't felt the
> need yet)
>
> I was having a problem with my lathe booting up with feed and spindle
> overrides set very low[1] and was finally prompted to try to get
> Touchy to report the current override value in the case where it was
> set from another source.
>
> I added a couple of lines around line 798 in touchy.py
>
>   + self.fo_val = s.feedrate * 100
>   + self.so_val = s.spindlerate * 100
>  set_label(self.wTree.get_widget("fo").child, "FO:
> %d%%" % self.fo_val)
>  set_label(self.wTree.get_widget("so").child, "SO:
> %d%%" % self.so_val)
>  set_label(self.wTree.get_widget("mv").child, "MV: %d"
> % self.mv_val)
>
> Experiment shows that with this change Touchy displays over-rides
> sourced from halui as well as internally. (ie, both Touchy and halui
> count pins can change the setting, and Touchy reports both)
>
> I think this is better, but I am cautious of pushing it as a
> modification in case it is a bad idea in a way that I can't see.
>
>
> [1] Fixed by setting the halui.xxx-override.count-enable pin false
> then to true only in in the postgui, the Mesa card jogwheel counts on
> smart-serial boards don't reset between startups so the system can see
> a large delta at time.
>


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G33 linear motion limits exceeded error

[sam sokolik]

quick testing - I don't get the error until I actually try to create a 
thread that is faster than the axis limit (for a given rpm) awesome!
(and it doesn't seem to pause at the end when there is an error)

Here is with the gain set to 1 (default)
http://electronicsam.com/images/KandT/testing/robthreading/roblatestthreading.png

and set to .5
http://electronicsam.com/images/KandT/testing/robthreading/roblatestthreadinggain.5.png

Great work!
sam

On 01/26/2017 09:44 PM, Robert Ellenberg wrote:
> For anyone interested in trying this out, I have fixes / improvements in
> this branch now:
>
> https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-overhaul-2.7-rebase
>
> - Less intrusive warning messages if the spindle is too fast
> - Spindle RPM limit calculation should work properly now
> - Improved (again) algorithm for position tracking that should have even
> less acceleration ripple.
>
> Best,
> Rob
>
> On Thu, Jan 26, 2017 at 3:10 AM John Morris  wrote:
>
>> On 01/23/2017 12:05 PM, John Kasunich wrote:
>>> If you run a program with G33 moves in it and the spindle isn't
>>> turning, the program will silently hang waiting for index.
>> Additionally, a G33 move will wait for the spindle-at-speed pin.  (See
>> below)
>>
>>> The run-time check sould of course use the actual spindle speed from
>>> the encoder. If you don't have an encoder you can't do G33 anyway.
>>> [...]
>>>
>>> On Mon, Jan 23, 2017, at 12:18 PM, Robert Ellenberg wrote:
 Is there an INI or HAL setting to tell LinuxCNC that the spindle
 ismanually controlled?
>>> Not that I'm aware of.
>> Of course an INI setting could be added to specify whether the spindle
>> is under LCNC control, but even without this, Rob's spindle-scaling
>> scheme should still work.  If a fixed-speed spindle runs at 2000 RPM but
>> axis constraints limit max spindle speed to 1000 RPM, the program should
>> pause indefinitely waiting for the spindle-at-speed pin.
>>
>> This behavior could be puzzling:  the spindle is turning, but axes never
>> move, why?  This might be addressed with a "spindle not coming to speed"
>> warning following some timeout.
>>
>> If that makes sense, then here's one way to specify the checks:
>>
>> - Preview-time check:
>> - Input:  S value
>> - Applicability:  any machine
>>   - Fixed-speed spindles:  operator must program S to benefit fm check
>> - Failure action:  raise warning
>>
>> - Run-time check:
>> - Input:  spindle encoder output
>> - Applicability:  any machine with spindle encoder
>>   - No spindle encoder:  hang waiting for index; see next
>> - Failure action:  scale spindle speed
>>   - After timeout on index/spindle-at-speed pins, raise warning
>>
>>  John
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Torch Height Control

[sam sokolik]

why not just use the pid component that is already in linuxcnc?

On 1/24/2017 7:49 AM, EBo wrote:
> On Jan 24 2017 6:29 AM, andy pugh wrote:
>> On 24 January 2017 at 00:06, John Thornton  wrote:
>>>  if(enable){
>>>  float min_velocity = requested_vel
>>> -(requested_vel*(1/velocity_tol));
>>>  if(current_vel > 0 && current_vel >=
>>> min_velocity){vel_status = 1;}
>>>  else {vel_status = 0;}
>>>
>>>  if(torch_on && arc_ok && vel_status){ // allow correction
>>>  //if(volts_requested - volts > volts_limit){
>>>  //volts = volts_requested - volts_limit;
>>>  //}
>>>  //else if(volts_requested + volts > volts_limit){
>>>  //   volts = volts_requested +volts_limit;
>>>  //}
>>>  if (abs(volts_requested - volts) > voltage_tol) {
>>>  offset += (volts_requested - volts) * p_gain;
>>>  }
>>>  last_z_in = 0;
>>>  }
>>
>> The code for an actual PID is pretty simple.
>>
>> static double olderror, iterm
>>  if(torch_on && arc_ok && vel_status){ // allow correction
>>  error = (volts_requested - volts)
>>  dterm = (error - olderrer) * Dgain
>>  olderror = error
>>  iterm += error * Igain
>>  pterm = error * Pgain
>>  if (absf(error) > deadband){
>>   offset += pterm + iterm + dterm
>>  }
>>
>> Is close. You probably need to initialise olderror intelligently, to
>> avoid a single-cycle crazy value.
> I am not completely convinced that the offset calculation in case of
> "absf(error) > deadband" is sufficient.  The various terms might still
> give you an unreasonable offset.  Might need to clamp that as well, but
> I am not fully sure what that would imply.
>
> EBo --
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] backplot/dro contents on the pi/arm version of lcnc.

[sam sokolik]

in the 'view' menu - uncheck 'show offsets'

With the coordinate offsets (tlo and such) shown - the velocity disappears.

sam

On 1/16/2017 9:01 AM, Gene Heskett wrote:
> Greetings all;
>
> I am making some progress, and I'm hopeing the ferrite stuff will help.
>
> Progress enough that I want to complain about the dro stuff overlaid on
> the backplot screen.
>
> Nothing I can exert in the view menu will bring up a velocity readout,
> nor turn off a boatload of info that is more visual noise than helpfull
> to me while I am trying to bring it to life.
>
> Its an extremely busy screen, covering and distracting the backplot.
>
> The X86 version can be configured to show what I want, but not on the pi
> version.
>
> Can this be addressed in due time?
>
> I did get it to cut a lathe pawn (in air, spindle vfd wasn't powered up)
> last evening, I had a dial sitting on the saddle watching X motion, and
> put it in the range where it was at zero on the outer end when it had
> run to completion and parked itself. Then I ran it again, and at the end
> of the 2nd run, it was parked 0.041" inward from where it was parked the
> first time.  This difference does not show in the dro display.
>
> Both motor cable shields are grounded as they go by the common ground
> bolt, and a separate ground strap, a 5/16" wide flat braid is attached
> about 1" away from the drivers - terminal, and to this bolt. About 7"
> longer than the similar braid lash-up of the Z drive.  And I can hear
> more "roughness" in the x drive than in the Z drive.  So its getting
> more noise from x than z.
>
> Cheers, Gene Heskett


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Max velocity slider and pure rotary motion

[sam sokolik]

I love the MV slider - use it all the time.  I need to know that 
feedrate because a lot of the time I am capping the velocity to the feed 
rate for testing (or just above)  I don't know the solution (as of right 
now I don't need to cap rotary only motion)  But the scaling of actual 
feed rate is a must for me.

sam

On 01/07/2017 04:16 AM, Niemand Sonst wrote:
> Hallo John,
>
> I agree with you, that the actual behavior is not what a user expect.
> Just changing max_vel to "%-Slider" is unfortunately not enough, as also
> the GUI must be changed to support the new feature.
>
> I from my side can tell that for gmoccapy the amount of work is doable.
> I will be pleased to do that.
>
> Norbert
>
> Am 07.01.2017 um 09:42 schrieb John Morris:
>> I've been asked about some seemingly unintuitive behavior:  the max
>> velocity slider is not applied to rotary-only motion.  You can try this
>> yourself by running the `axis_9axis.ini` config, setting the max
>> velocity slider to zero, and noting rotary axes still move after e.g.
>> `g0 a180 f40`.
>>
>> This can't be trivially fixed by applying the max velocity setting to
>> rotary-only motion.  Back in 2007, Chris explained [1] (referring to a
>> document still available from NIST [2]) that feed rate in units/minute
>> can be unintuitive for rotary-only motion, since the units are degrees
>> instead of inches or millimeters.
>>
>> Ok, so damned if we do, and damned if we don't; then what are the other
>> options?  Axis has a couple of instructive examples:
>>
>> - The rapid override slider reads on a percentage scale, and the same
>> slider does what one would expect, both for linear and rotary-only motion.
>>
>> - The jog speed slider reads in linear units/minute, and when a rotary
>> axis is configured a second slider reading in degrees/minute appears.
>>
>> Right now, I'm leaning toward recommending the max velocity slider be
>> changed to a percentage scale and applied to both, similar to rapid
>> override.  I'd love to hear other opinions.  Thanks-
>>
>>  John
>>
>> [1]: https://sourceforge.net/p/emc/mailman/message/13618943/
>> [2]: http://ws680.nist.gov/publication/get_pdf.cfm?pub_id=823374
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[sam sokolik]

oh - what - did you mention you get exact stop when it is trying to 
change the spindle speed?  Is that why it is happening on this system?

sam

On 12/14/2016 05:56 PM, sam sokolik wrote:
> Here is a plot with motion.spindle-speed-in
>
> http://electronicsam.com/images/KandT/testing/robthreading/latest/robnewandspindlein.png
>
> sam
>
>
>
> On 12/11/2016 03:52 PM, Robert Ellenberg wrote:
>> Sam, one last thing, is it possible to put the spindle-speed-in pin on a
>> halscope channel? I'd like to see what the spindle velocity is when it
>> transitions out of accel sync.
>>
>> On Sun, Dec 11, 2016 at 4:44 PM Robert Ellenberg <rwe...@gmail.com> wrote:
>>
>>> Thanks for giving it a spin!
>>>
>>> I am still getting the error about the spindle going too fast..  You can
>>> see the threading is happening at 19.12 ipm and the axis max vel is
>>> 30ipm.  I tried a similar config and got the same result (could be both
>>> configs have some odd issue we have not figured out.)
>>>
>>> http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix2Error.png
>>>
>>>
>>> There's definitely an edge case there I didn't account for. I'll keep
>>> working on it and see if I can isolate a test case to reproduce.
>>>
>>> Current 2.7 behavior with the blip at the beginning (again - didn't see
>>> this with your latest push)
>>>
>>> http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png
>>>
>>>
>>> Another thing I'm noticing is that my modified position-error calculation
>>> seems to perform worse with the stock-like velocity estimate (in terms of
>>> steady-state error). I'll play with a few approaches and see if I can get
>>> something better than stock.
>>>
>>> Sam, do you do any kind of filtering / averaging in your spindle-speed
>>> input?  It would be interesting to see the effect if so. I suspect that the
>>> velocity signal could be filtered significantly without impacting the
>>> position tracking performance.
>>>
>>> Best,
>>> Rob
>>>
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[sam sokolik]

also - am I seeing an exact stop at the pull out?

2.7 doesn't seem to do that.  (I am positive we want blending on pull out)

http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png

sam

On 12/14/2016 05:56 PM, sam sokolik wrote:
> Here is a plot with motion.spindle-speed-in
>
> http://electronicsam.com/images/KandT/testing/robthreading/latest/robnewandspindlein.png
>
> sam
>
>
>
> On 12/11/2016 03:52 PM, Robert Ellenberg wrote:
>> Sam, one last thing, is it possible to put the spindle-speed-in pin on a
>> halscope channel? I'd like to see what the spindle velocity is when it
>> transitions out of accel sync.
>>
>> On Sun, Dec 11, 2016 at 4:44 PM Robert Ellenberg <rwe...@gmail.com> wrote:
>>
>>> Thanks for giving it a spin!
>>>
>>> I am still getting the error about the spindle going too fast..  You can
>>> see the threading is happening at 19.12 ipm and the axis max vel is
>>> 30ipm.  I tried a similar config and got the same result (could be both
>>> configs have some odd issue we have not figured out.)
>>>
>>> http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix2Error.png
>>>
>>>
>>> There's definitely an edge case there I didn't account for. I'll keep
>>> working on it and see if I can isolate a test case to reproduce.
>>>
>>> Current 2.7 behavior with the blip at the beginning (again - didn't see
>>> this with your latest push)
>>>
>>> http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png
>>>
>>>
>>> Another thing I'm noticing is that my modified position-error calculation
>>> seems to perform worse with the stock-like velocity estimate (in terms of
>>> steady-state error). I'll play with a few approaches and see if I can get
>>> something better than stock.
>>>
>>> Sam, do you do any kind of filtering / averaging in your spindle-speed
>>> input?  It would be interesting to see the effect if so. I suspect that the
>>> velocity signal could be filtered significantly without impacting the
>>> position tracking performance.
>>>
>>> Best,
>>> Rob
>>>
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[sam sokolik]

Here is a plot with motion.spindle-speed-in

http://electronicsam.com/images/KandT/testing/robthreading/latest/robnewandspindlein.png

sam



On 12/11/2016 03:52 PM, Robert Ellenberg wrote:
> Sam, one last thing, is it possible to put the spindle-speed-in pin on a
> halscope channel? I'd like to see what the spindle velocity is when it
> transitions out of accel sync.
>
> On Sun, Dec 11, 2016 at 4:44 PM Robert Ellenberg  wrote:
>
>> Thanks for giving it a spin!
>>
>> I am still getting the error about the spindle going too fast..  You can
>> see the threading is happening at 19.12 ipm and the axis max vel is
>> 30ipm.  I tried a similar config and got the same result (could be both
>> configs have some odd issue we have not figured out.)
>>
>> http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix2Error.png
>>
>>
>> There's definitely an edge case there I didn't account for. I'll keep
>> working on it and see if I can isolate a test case to reproduce.
>>
>> Current 2.7 behavior with the blip at the beginning (again - didn't see
>> this with your latest push)
>>
>> http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png
>>
>>
>> Another thing I'm noticing is that my modified position-error calculation
>> seems to perform worse with the stock-like velocity estimate (in terms of
>> steady-state error). I'll play with a few approaches and see if I can get
>> something better than stock.
>>
>> Sam, do you do any kind of filtering / averaging in your spindle-speed
>> input?  It would be interesting to see the effect if so. I suspect that the
>> velocity signal could be filtered significantly without impacting the
>> position tracking performance.
>>
>> Best,
>> Rob
>>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[sam sokolik]

There is no filtering.  Here is the complete config

net spindle-vel encoder.0.velocity motion.spindle-speed-in

http://electronicsam.com/images/KandT/testing/robthreading/latest/Emco_HalfFull_Morph.tar.gz

I can scope more pins but it will have to wait a few days.

sam

On 12/11/2016 03:44 PM, Robert Ellenberg wrote:
> Thanks for giving it a spin!
>
> I am still getting the error about the spindle going too fast..  You can
> see the threading is happening at 19.12 ipm and the axis max vel is
> 30ipm.  I tried a similar config and got the same result (could be both
> configs have some odd issue we have not figured out.)
> http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix2Error.png
>
>
> There's definitely an edge case there I didn't account for. I'll keep
> working on it and see if I can isolate a test case to reproduce.
>
> Current 2.7 behavior with the blip at the beginning (again - didn't see
> this with your latest push)
> http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png
>
>
> Another thing I'm noticing is that my modified position-error calculation
> seems to perform worse with the stock-like velocity estimate (in terms of
> steady-state error). I'll play with a few approaches and see if I can get
> something better than stock.
>
> Sam, do you do any kind of filtering / averaging in your spindle-speed
> input?  It would be interesting to see the effect if so. I suspect that the
> velocity signal could be filtered significantly without impacting the
> position tracking performance.
>
> Best,
> Rob
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Spindle speed signal

[sam sokolik]

Threading air..

The motion seems a lot more consistent - no funny blip the original did. 
run after run looked pretty much identical in halscope.

http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix.png
motion.spindle-tracking-gain set to .5
http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfixmotion.spindle-tracking-gain.5.png

I am still getting the error about the spindle going too fast..  You can 
see the threading is happening at 19.12 ipm and the axis max vel is 
30ipm.  I tried a similar config and got the same result (could be both 
configs have some odd issue we have not figured out.)
http://electronicsam.com/images/KandT/testing/robthreading/latest/newthreadingfix2Error.png

Current 2.7 behavior with the blip at the beginning (again - didn't see 
this with your latest push)
http://electronicsam.com/images/KandT/testing/robthreading/latest/current2.png

Again - great work!
sam

On 12/11/2016 08:17 AM, Robert Ellenberg wrote:
> Ahh, that would have been smart to include before:
>
> - sim_spindle_encoder's position signal is now quantized based on
> encoder resolution.
> - Use motion.spindle-speed-in as the velocity reference for spindle
> position tracking (falls back to old velocity calculation if this pin is
> unconnected)
> - Tweak position error correction math to reduce acceleration jitter
> - Add a HAL pin, motion.spindle-tracking-gain (range 0.0 to 1.0) to
> control how aggressive position tracking is. 1.0 is stock behavior, 0.0 is
> no position tracking.
> - Fix "sync_accel" phase of position tracking for low-count encoders.
> - Experimental fix for issue 167
>  by popping an error
> message to the user and reducing spindle speed (if possible)
> - Fix for issue 68  by
> disabling blending at start of G33 (to be consistent w/ 2.6.x)
>
> Backend changes:
>
> - Group some spindle status variables into struct:
>- Motion spindle command outputs are in a struct called "spindle_cmd"
>in emcStatus
>- motion spindle inputs are now in a struct called "spindle_fb"
> - Math tweaks to rigid tapping / position tracking to prevent
> discontinuities due to sign changes.
>
> -Rob
>
> On Sun, Dec 11, 2016 at 8:20 AM andy pugh  wrote:
>
> On 11 December 2016 at 06:30, Robert Ellenberg  wrote:
>> For anyone interested in testing, my latest branch based on Peter's
>> suggestion, and a bunch of other spindle tracking fixes is here:
> Can you explain what is changed and improved?
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G71

[sam sokolik]

so far so good..  Great job!!

http://electronicsam.com/images/KandT/testing/Screenshot-33.png

sam

On 11/30/2016 08:27 PM, andy pugh wrote:
> On 29 November 2016 at 22:01, andy pugh  wrote:
>> It is nearly ready for requests to attempt to break it.
> I think that it now is ready for attempts to break it.
>
> I would be interested in screen-shots and sample files that the
> algorithm copes badly with.
>
> No documentation yet, but, roughly speaking
>
>  P  # Block Number of contour beginning (uses N word in beginning block)
>  D # Roughing Depth per cut
>  R # Retraction from each cut
>  J  # Overthickness before finishing X (diameter)   (U on other 
> controllers)
>  L  # Overthickness before finishing Z  (W on other 
> controllers)
>  I   # Thickness for finishing at X
>  K  # Thickness for finishing at Z
>  F  # Feedrate override between P and Q blocks
>  S   # Spindle speed override between P and Q blocks
>  T   # Tool for cycle
>
> F, S, T are not active in the Python remap version. Nor are I and K as
> it doesn't do the semi-finish pass. P should refer to an O NNN SUB / O
> NNN ENDSUB block.
>


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[sam sokolik]

it is actually 10in/s^2 but correct on .5in/s velocity

On 11/26/2016 01:26 PM, Robert Ellenberg wrote:
> Sam, what are the max velocity and acceleration on the Z axis? It looks
> like 0.5 in / sec and 20 in/sec^2 from the plots. I want to match my sim
> configuration to yours.
>
> On Sat, Nov 26, 2016, 2:03 PM Robert Ellenberg <rwe...@gmail.com> wrote:
>
>> Ahh, I'll take another look at the math, clearly it's not calculating the
>> max RPM correctly.
>>
>> On Sat, Nov 26, 2016 at 12:39 PM sam sokolik <sa...@empirescreen.com>
>> wrote:
>>
>> ok.. Here is some oddness..
>>
>> If I use the original pitch of P.059055 I get the error saying the
>> spindle should be running at 237rpm (the error I always get).
>>
>> pitch of .05 I don't get the error .06 I don't get the error .07 I
>> do get the error (but it threads at 19ish ipm) same error saying spindle
>> should be running at 237
>>
>> sam
>>
>> On 11/26/2016 11:19 AM, sam sokolik wrote:
>>> Here are 2 screenshots showing the threading at 15ipm and the shuttle at
>> 30.
>>> http://electronicsam.com/images/KandT/testing/robthreading/threading.png
>>> http://electronicsam.com/images/KandT/testing/robthreading/shuttle.png
>>>
>>> So I am not understanding why the threading would think that 237 is the
>>> maximum feed.
>>>
>>> Side note - this is running rt_preempt and uspace.  A base thread of
>>> 50us seems to work fine with the printer port.
>>>
>>> sam
>>>
>>>
>>> On 11/25/2016 09:24 PM, sam sokolik wrote:
>>>> that is odd because the threading is done at about 16ipm - and the max
>>>> velocity of the axis is 30ipm...  (you can see the z velocity goes
>>>> higher than 16ipm in the plots)
>>>>
>>>> If there is anything else that would help to plot - let me know
>>>>
>>>> sam
>>>>
>>>> On 11/25/2016 08:25 PM, Robert Ellenberg wrote:
>>>>> Nice work! The message you're getting in axis is a new feature I
>> added. It
>>>>> warns you if the combination of spindle speed and thread pitch would
>>>>> require more than 90% of your maximum axis velocity. If so, it slows
>> the
>>>>> spindle down to a safe maximum speed before starting the thread (in
>> this
>>>>> case 230RPM). The 90% value is arbitrary, I just wanted to have some
>> safety
>>>>> factor in there.
>>>>>
>>>>> Comparing the two acceleration plots, it seems like the acceleration
>> during
>>>>> the start of the thread is higher in stock 2.7 than with my branch/ The
>>>>> high initial acceleration is good, though, since it settles in about
>> 120ms,
>>>>> whereas the new branch takes about 200ms. I'll run the same program in
>>>>> simulation tomorrow and see if I can reproduce the effect. It may be
>> worth
>>>>> trying the same comparison in G61 (in case blending is causing it).
>>>>>
>>>>> Best,
>>>>> Rob
>>>>>
>>>>> On Fri, Nov 25, 2016 at 8:37 PM sam sokolik <sa...@empirescreen.com>
>> wrote:
>>>>>> ok - I finally did some testing on the emco using this branch..
>>>>>>
>>>>>>
>>>>>>
>> https://github.com/robEllenberg/linuxcnc-mirror/commits/feature/nominal-vel-during-sync
>>>>>> This is a thread using this program
>>>>>> http://electronicsam.com/images/KandT/testing/robthreading/test.ngc
>>>>>>
>>>>>> This is the current 2.7 behavior
>>>>>>
>> http://electronicsam.com/images/KandT/testing/robthreading/current.png
>>>>>> This is with robs fixes
>>>>>>
>> http://electronicsam.com/images/KandT/testing/robthreading/robnew1.png
>>>>>> It looks like the acceleration spike are defiantly smaller.
>>>>>>
>>>>>> I did find an oddity on both branches - quite often it seemed to
>>>>>> overshoot initially and then slow back down.  I don't know if it is an
>>>>>> artifact of my config (100 line single channel encoder + index. never
>>>>>> seemed to effect the threading I have done.
>>>>>>
>>>>>>
>> http://electronicsam.com/images/KandT/testing/robthreading/current1.png
>>>>>> http://electronicsam.com/images/KandT/testing/robthreading/robnew

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[sam sokolik]

Here are 2 screenshots showing the threading at 15ipm and the shuttle at 30.

http://electronicsam.com/images/KandT/testing/robthreading/threading.png
http://electronicsam.com/images/KandT/testing/robthreading/shuttle.png

So I am not understanding why the threading would think that 237 is the 
maximum feed.

Side note - this is running rt_preempt and uspace.  A base thread of 
50us seems to work fine with the printer port.

sam


On 11/25/2016 09:24 PM, sam sokolik wrote:
> that is odd because the threading is done at about 16ipm - and the max
> velocity of the axis is 30ipm...  (you can see the z velocity goes
> higher than 16ipm in the plots)
>
> If there is anything else that would help to plot - let me know
>
> sam
>
> On 11/25/2016 08:25 PM, Robert Ellenberg wrote:
>> Nice work! The message you're getting in axis is a new feature I added. It
>> warns you if the combination of spindle speed and thread pitch would
>> require more than 90% of your maximum axis velocity. If so, it slows the
>> spindle down to a safe maximum speed before starting the thread (in this
>> case 230RPM). The 90% value is arbitrary, I just wanted to have some safety
>> factor in there.
>>
>> Comparing the two acceleration plots, it seems like the acceleration during
>> the start of the thread is higher in stock 2.7 than with my branch/ The
>> high initial acceleration is good, though, since it settles in about 120ms,
>> whereas the new branch takes about 200ms. I'll run the same program in
>> simulation tomorrow and see if I can reproduce the effect. It may be worth
>> trying the same comparison in G61 (in case blending is causing it).
>>
>> Best,
>> Rob
>>
>> On Fri, Nov 25, 2016 at 8:37 PM sam sokolik <sa...@empirescreen.com> wrote:
>>
>>> ok - I finally did some testing on the emco using this branch..
>>>
>>>
>>> https://github.com/robEllenberg/linuxcnc-mirror/commits/feature/nominal-vel-during-sync
>>>
>>> This is a thread using this program
>>> http://electronicsam.com/images/KandT/testing/robthreading/test.ngc
>>>
>>> This is the current 2.7 behavior
>>> http://electronicsam.com/images/KandT/testing/robthreading/current.png
>>>
>>> This is with robs fixes
>>> http://electronicsam.com/images/KandT/testing/robthreading/robnew1.png
>>>
>>> It looks like the acceleration spike are defiantly smaller.
>>>
>>> I did find an oddity on both branches - quite often it seemed to
>>> overshoot initially and then slow back down.  I don't know if it is an
>>> artifact of my config (100 line single channel encoder + index. never
>>> seemed to effect the threading I have done.
>>>
>>> http://electronicsam.com/images/KandT/testing/robthreading/current1.png
>>> http://electronicsam.com/images/KandT/testing/robthreading/robnew.png
>>>
>>> Also - rob - it prints in axis every pass velocity at line 8 is 230rpm
>>> or such.. (paraphrasing..)
>>>
>>> sam
>>>
>>>
>>> On 09/25/2016 07:47 AM, Robert Ellenberg wrote:
>>>> Hi All,
>>>>
>>>> Recently, I found a way to reduce the acceleration / velocity jitter
>>> during
>>>> threading and tapping motions (see this issue on github
>>>> <https://github.com/LinuxCNC/linuxcnc/issues/164> and the
>>>> feature/spindle-sync-jiiter-fix branch
>>>> <
>>> https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-jitter-fix
>>>> ).
>>>> The effect looks significant on the HALscope, but I'm not sure how much
>>> of
>>>> a difference it would make on a real machine. Is anyone interested in
>>> doing
>>>> a before and after test on real hardware?
>>>>
>>>> Thanks!
>>>> Rob
>>>>
>>> --
>>>> ___
>>>> Emc-developers mailing list
>>>> Emc-developers@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>>>
>>>
>>> --
>>> ___
>>> Emc-developers mailing list
>>> Emc-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>>
>> --
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[sam sokolik]

that is odd because the threading is done at about 16ipm - and the max 
velocity of the axis is 30ipm...  (you can see the z velocity goes 
higher than 16ipm in the plots)

If there is anything else that would help to plot - let me know

sam

On 11/25/2016 08:25 PM, Robert Ellenberg wrote:
> Nice work! The message you're getting in axis is a new feature I added. It
> warns you if the combination of spindle speed and thread pitch would
> require more than 90% of your maximum axis velocity. If so, it slows the
> spindle down to a safe maximum speed before starting the thread (in this
> case 230RPM). The 90% value is arbitrary, I just wanted to have some safety
> factor in there.
>
> Comparing the two acceleration plots, it seems like the acceleration during
> the start of the thread is higher in stock 2.7 than with my branch/ The
> high initial acceleration is good, though, since it settles in about 120ms,
> whereas the new branch takes about 200ms. I'll run the same program in
> simulation tomorrow and see if I can reproduce the effect. It may be worth
> trying the same comparison in G61 (in case blending is causing it).
>
> Best,
> Rob
>
> On Fri, Nov 25, 2016 at 8:37 PM sam sokolik <sa...@empirescreen.com> wrote:
>
>> ok - I finally did some testing on the emco using this branch..
>>
>>
>> https://github.com/robEllenberg/linuxcnc-mirror/commits/feature/nominal-vel-during-sync
>>
>> This is a thread using this program
>> http://electronicsam.com/images/KandT/testing/robthreading/test.ngc
>>
>> This is the current 2.7 behavior
>> http://electronicsam.com/images/KandT/testing/robthreading/current.png
>>
>> This is with robs fixes
>> http://electronicsam.com/images/KandT/testing/robthreading/robnew1.png
>>
>> It looks like the acceleration spike are defiantly smaller.
>>
>> I did find an oddity on both branches - quite often it seemed to
>> overshoot initially and then slow back down.  I don't know if it is an
>> artifact of my config (100 line single channel encoder + index. never
>> seemed to effect the threading I have done.
>>
>> http://electronicsam.com/images/KandT/testing/robthreading/current1.png
>> http://electronicsam.com/images/KandT/testing/robthreading/robnew.png
>>
>> Also - rob - it prints in axis every pass velocity at line 8 is 230rpm
>> or such.. (paraphrasing..)
>>
>> sam
>>
>>
>> On 09/25/2016 07:47 AM, Robert Ellenberg wrote:
>>> Hi All,
>>>
>>> Recently, I found a way to reduce the acceleration / velocity jitter
>> during
>>> threading and tapping motions (see this issue on github
>>> <https://github.com/LinuxCNC/linuxcnc/issues/164> and the
>>> feature/spindle-sync-jiiter-fix branch
>>> <
>> https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-jitter-fix
>>> ).
>>> The effect looks significant on the HALscope, but I'm not sure how much
>> of
>>> a difference it would make on a real machine. Is anyone interested in
>> doing
>>> a before and after test on real hardware?
>>>
>>> Thanks!
>>> Rob
>>>
>> --
>>> ___
>>> Emc-developers mailing list
>>> Emc-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>>
>>
>>
>> --
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

[sam sokolik]

ok - I finally did some testing on the emco using this branch..

https://github.com/robEllenberg/linuxcnc-mirror/commits/feature/nominal-vel-during-sync

This is a thread using this program
http://electronicsam.com/images/KandT/testing/robthreading/test.ngc

This is the current 2.7 behavior
http://electronicsam.com/images/KandT/testing/robthreading/current.png

This is with robs fixes
http://electronicsam.com/images/KandT/testing/robthreading/robnew1.png

It looks like the acceleration spike are defiantly smaller.

I did find an oddity on both branches - quite often it seemed to 
overshoot initially and then slow back down.  I don't know if it is an 
artifact of my config (100 line single channel encoder + index. never 
seemed to effect the threading I have done.

http://electronicsam.com/images/KandT/testing/robthreading/current1.png
http://electronicsam.com/images/KandT/testing/robthreading/robnew.png

Also - rob - it prints in axis every pass velocity at line 8 is 230rpm 
or such.. (paraphrasing..)

sam


On 09/25/2016 07:47 AM, Robert Ellenberg wrote:
> Hi All,
>
> Recently, I found a way to reduce the acceleration / velocity jitter during
> threading and tapping motions (see this issue on github
>  and the
> feature/spindle-sync-jiiter-fix branch
> ).
> The effect looks significant on the HALscope, but I'm not sure how much of
> a difference it would make on a real machine. Is anyone interested in doing
> a before and after test on real hardware?
>
> Thanks!
> Rob
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


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

Re: [Emc-developers] Distributing remaps

[sam sokolik]

My thought would be to add a config to /sim/axis/remap

then people can use it as they please.

sam

On 11/14/2016 9:20 AM, dragon wrote:
> That was exactly my plan as well. Use a sub to make it more in line with
> the way that linuxCNC already does things.
>
> There have been a few attempts at g71 in the past, but they were all
> half-baked from what I could find. None that I found implemented g70.
> They were also very 'hacky' in the way that they tried to use line
> numbers. I personally feel that the fix for that is to use an o-sub.
>
> The big question is, if it is done as a remap will it get distributed?
>
> It would be great to work together with others on this.
>
> -Todd
>
> On 11/14/2016 09:01 AM, andy pugh wrote:
>> On 14 November 2016 at 14:20, dragon  wrote:
>>> I am working towards implementing lathe roughing cycles g71/g72. There
>>> was some discussion in Wichita as to using remap or integrating this
>>> into interp. I am trying to get a feel for what the devs would prefer.
>> Interesting, I was seriously considering doing this myself.
>>
>> What I was thinking of doing was doing it Python first to check the
>> logic, then converting to C++ to move it to interp_cycles.cc
>>
>> What started me looking at it was that there is a moderately simple
>> way to tell G71 where to find the code without considerably altering
>> the way that LinuxCNC works with line numbers.
>>
>> All you need to do is define the profile in a numbered O-sub block.
>>
>> O100 SUB
>> G0
>> G1
>> G2
>> G3
>> G1
>> O100 ENDSUB
>>
>> G71 P100 
>>
>> This way the profile will be automatically skipped by the interpreter.
>>
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Tool Number limit

[sam sokolik]

I thought Andy had a good start at this at the Wichita fest a few years 
ago...

it is in the linuxcnc git

andypugh/tooltable

http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/andypugh/tooltable

sam

On 10/26/2016 12:26 PM, James Waples wrote:
> The tool count should be limited by how much RAM your machine has ;).
>
> We should start with a well designed, minimal reimplementation of the tool
> table in it's current incarnation (minus warts) and add features as they
> are needed/wanted. Everyone could talk about things forever without
> anything being implemented. As long as the right decisions are made new
> features can be added quite easily, both to LinuxCNC and this library
> module.
>
> I'd like to suggest Rust as the language of choice for this. The tool
> library is a somewhat standalone component and would be a good experiment
> for using Rust in a wider capacity in LCNC. It's also pretty good at
> binding with C code so integration shouldn't be too difficult. That said,
> it's quite a new language and mindshare is somewhat limited currently so
> this might not be the most practical solution.
>
> On Wed, 26 Oct 2016 at 18:11 Niemand Sonst  wrote:
>
>> Hallo,
>>
>> I followed till now with big interest. Most opinions and wishes are
>> clearly understandable, but shouldn't we begin with other questions?
>>
>> - How hard will it be to get the tool storage out of real-time? IMHO it
>> does not belong there.
>> - What information are needed for linuxCNC itself (iocontrol,
>> interpreter, etc)
>> - What informations are needed by the GUI or what are the requirements
>> of the user?
>> - etc.
>>
>> Without knowing all that, it is not possible to discuss about the
>> storage way (text, Database or XML, etc.)
>>
>> If I am allowed to dream:
>>
>> Tool table is a graphical tool editor, with images to show the user a
>> drawing with the information required.
>> "No" Tool number limit (I have no company, but one of my machine has
>> about 150 SK30 tool holders, I was lucky getting them for some boxes of
>> beer ;-)
>> It contains (for a mill)
>> - Tool Number
>> - Poket Number (actually not handled correct in remap)
>> - Tool diameter
>> - Tool wear in diameter
>> - Tool length
>> - Tool length wear
>> - length of the cutting flute (and linuxCNC will look in future if the
>> tool is suited ;-)
>> - Form of the tool (V or ballnose or flat (Future preview will show that
>> style, because it will cut from a solid)
>> - How long has the tool been used
>> - How many times has it been mounted
>> - Number of teeth (Cam may need that)
>> - what is the recommended cutdepth / teeth (Cam may need that)
>> - What speed to use (Cam may need that)
>> - Power limit (If the tool needs more power, the machine will go in stop
>> to avoid damage on the machine, like a aluminum milling closing the flutes)
>>
>> I am sure there will be more wishes, so please add them to the list. And
>> who begins with a lathe list? IMHO the tool storage could be different.
>>
>> I am a python fan, so that is my preferred language to code the Tool
>> editor. I am willing to do that, but I am not able to change the
>> iocontrol, interpreter code :-( Who help with that?
>>
>> Norbert
>>
>>
>>
>> --
>> The Command Line: Reinvented for Modern Developers
>> Did the resurgence of CLI tooling catch you by surprise?
>> Reconnect with the command line and become more productive.
>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>> http://sdm.link/telerik
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] NOTICE: Feature freeze pending in view of a new release

[sam sokolik]

I think the reverse run branch should get merged after the freeze.

On 6/28/2016 11:08 AM, Chris Radek wrote:
> On Tue, Jun 28, 2016 at 11:36:40AM -0400, John Kasunich wrote:
>> It is only monotonically increasing if you interpret it as two integers
>> separated by a dot.  Humans can interpret it any way they want, but
>> how do programs interpret it?
> for debian packages this is really well defined, but also very
> complicated, so dpkg has a way you can ask:
>
> % dpkg --compare-versions 2.9 lt 2.10 && echo yep it is
> yep it is
>
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] MPG Jogging Off of a Limit

[sam sokolik]

our over travel limits actually kill power to the drives...  (same as 
the estop loop)

sam

On 5/24/2016 10:03 AM, Jeff Johnson wrote:
> Yes with the MPG...just went out and did it to make sure.
>
> Jeff Johnson
> john...@superiorroll.com
> Superior Roll & Turning
> 734-279-1831
>
> -Original Message-
> From: andy pugh [mailto:bodge...@gmail.com]
> Sent: Tuesday, May 24, 2016 9:25 AM
> To: EMC developers 
> Subject: Re: [Emc-developers] MPG Jogging Off of a Limit
>
> On 24 May 2016 at 13:55, johnson  wrote:
>> We use ignore limits and we can jog off.
> With an MPG?
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is designed for 
> the especial use of mechanical geniuses, daredevils and lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
> --
> Mobile security can be enabling, not merely restricting. Employees who bring 
> their own devices (BYOD) to work are irked by the imposition of MDM 
> restrictions. Mobile Device Manager Plus allows you to control only the apps 
> on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] MPG Jogging Off of a Limit

[sam sokolik]

Wow - that is pretty..  Love the MPG's in the apron.   Can't wait for a 
video showing them working!

The K is a pain to get off of the over travel limits - but it has only 
happened once when I forgot to home and jogged it into the limit.  The 
matsuura is even harder.  You would have to remove access panels to get 
the machine off the limits.  I was planning on just putting a switch - 
maybe momentary push button that disabled the over travel limits - 
allowing to jog off.  (we have done this already when I ran it into the 
over travel when homing wasn't quite right yet - we used a jumper.. :)

sam

On 5/24/2016 8:27 AM, andy pugh wrote:
> On 24 May 2016 at 14:09, Gene Heskett  wrote:
>> Double shaft motors would help. :-}
> The motors have resolvers on the shaft extension, and then the whole
> motor lives in a casting.
>
> No visible motor shafts in this set-up:
> https://picasaweb.google.com/108164504656404380542/Holbrook#6281710819317309698
>


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] axis alignment jumping

[sam sokolik]

as far as I know - the component time is in clock cycles - not us...

sam

On 05/15/2016 06:54 PM, Jon Elson wrote:
> I've been having small jumps in position for a long time on
> my Bridgeport with my PPMC boards.  Couldn't quite be sure
> it wasn't operator error, but it seemed to be getting more
> frequent.  Today I had more of it, and I was really sure I
> didn't hit any wrong buttons or anything.
>
> I've just replaced the encoder counter card in the PPMC, and
> so far it is always returning to the same coordinate.
> I'll have to keep checking for a while to make sure it
> continues to position reliably.
>
> Anyway, I had a really weird thing happen.  I just swapped
> the card and started LinuxCNC, and when I was jogging, I
> noticed the jog continued after I released the keyboard jog
> key.  Trying a few other things, I noticed the GUI was
> really sluggish, too.  So, then I checked the show hal
> config parameters, to see if any tasks were running long.
> The hal_ppmc component was running vastly long, overrunning
> the whole servo thread.  It was running a very steady 1.3 ms
> for that component only!  I thought if the real time tasks
> overran their period, you'd get a warning, at the least!
> But, I didn't see a thing.  (Hmm, I wonder if a thread
> overrun could foul up the GUI so badly that it lost the
> message that there was an overrun?  Is that possible?)
>
> I couldn't find anything wrong with the board, put it back
> in, and the ppmc run time was back to normal.  Must have
> been a dirty contact in motherboard.
>
> I'm running2.5.4 with Axis.
>
> This coordinate jumping can be really hard to find.  I'd
> think if it happened all at once, I'd get a prompt following
> error.  So, it must be happening a little at a time,
> although when I notice it, it seems to have happened all at
> once.
> It appears to have happened on all axes, and maybe happens
> to two axes at about the same time.
>
> Well, any comments would be welcome.
>
> Jon
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] More than 8 stepgen

[sam sokolik]

And to answer the question - stepgen was created before the uvw axis 
were added to linuxcnc.

sam

On 5/2/2016 7:44 AM, Len Shelton wrote:
> So I am curious... what is the reason why LinuxCNC is a 9 axis machine
> controller, but stepgen is limited to 8 instances?
>
>> Len
> --
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] More than 8 stepgen

[sam sokolik]

Where are you seeing 8 stepgens?  The manpage and docs say 16.

On 5/2/2016 7:44 AM, Len Shelton wrote:
> So I am curious... what is the reason why LinuxCNC is a 9 axis machine
> controller, but stepgen is limited to 8 instances?
>
>> Len
> --
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] More than 8 stepgen

[sam sokolik]

I think (if my git foo is strong) JT increased it to 16 in 2013

http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=61ebd8221eedad3d22b9e679c7857574b10c57d4

sam

On 5/2/2016 7:44 AM, Len Shelton wrote:
> So I am curious... what is the reason why LinuxCNC is a 9 axis machine
> controller, but stepgen is limited to 8 instances?
>
>> Len
> --
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Reverse Run

[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

On 9/8/2015 7:51 PM, Robert Ellenberg wrote:
> 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
>
> On Tue, Sep 8, 2015 at 12:25 PM, Jon Elson  wrote:
>
>> On 09/08/2015 07:43 AM, Kenneth Lerman wrote:
>>> 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
>>
>>
>>
> --
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
> --
> Kenneth Lerman
> 55 Main Street
> Newtown, CT 06470
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> 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=/4140
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> 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=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Reverse Run

[sam sokolik]

https://youtu.be/3aYaHxT6ZnQ

On 9/8/2015 7:43 AM, Kenneth Lerman wrote:
> 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
>
> On Mon, Sep 7, 2015 at 9:53 PM, sam sokolik <sa...@empirescreen.com> wrote:
>
>> 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
>>
>> On 04/09/2015 06:32 AM, sam sokolik wrote:
>>> 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
>>>
>>> On 4/8/2015 10:29 PM, Robert Ellenberg wrote:
>>>> On Apr 8, 2015 10:06 PM, "sam sokolik" <sa...@empirescreen.com> wrote:
>>>>> 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.
>>>>> -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.
>>>>
>>>>> sam
>>>>>
>>>>>
>>>>> On 04/08/2015 07:25 PM, Robert Ellenberg wrote:
>>>>>> 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

Re: [Emc-developers] Reverse Run

[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

On 04/09/2015 06:32 AM, sam sokolik wrote:
> 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
>
> On 4/8/2015 10:29 PM, Robert Ellenberg wrote:
>> On Apr 8, 2015 10:06 PM, "sam sokolik" <sa...@empirescreen.com> wrote:
>>> 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.
>>> -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.
>>
>>> sam
>>>
>>>
>>> On 04/08/2015 07:25 PM, Robert Ellenberg wrote:
>>>> 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
>>>>
>> --
>>>> 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-i

Re: [Emc-developers] Moving backlash comp to HAL module

[sam sokolik]

I also use hal to do temp compensation using the offset component.

https://www.youtube.com/watch?v=h-CdFd2Zakc

sam

On 7/27/2015 9:34 AM, Sebastian Kuzminsky wrote:
 On 07/26/2015 09:31 PM, Brian wrote:
 I have had an idea lingering in my head for quite some time now.  How about 
 moving the screw/backlash comp out of motion and implement it with a HAL 
 module.  The purpose would be for two goals.  One it would make it more 
 logical to implement more sophisticated joint compensation, such as thermal 
 expansion, deflection, and belt stretch.  Second, it would set the stage to 
 be more friendly for dual scale/motor feedback, because it would give 
 control over where the compensation is added in the feedback loop.
 I agree with Andy, backlash compensation belongs in Motion, since that's
 where the trajectory is planned.

 Motion can insert a backlash compensation move when a joint changes
 direction, and compensate for the time that the backlash move takes by
 not moving the other joints (except that possible backlash moves on
 other joints may happen at the same time).

 An external hal component that tried to do that would have to capture
 and buffer all the joint waypoints that Motion was generating during the
 backlash move, then when the backlash move is finished either try to
 catch up to Motion (which would violate the accel  vel that Motion had
 planned), or stay behind Motion from then on out (which would introduce
 lag on things that immediately affect the trajectory, like Feed Override).

 While backlash compensation surely belongs in Motion, slow,
 small-magnitude, long-term offset changes like thermal compensation can
 probably be implemented safely as a HAL modification to the waypoints
 commanded by Motion.  See Dewey's moveoff demo for an example of how
 this can be implemented (sim/axis/moveoff), with some video here:

  https://www.youtube.com/watch?v=KY6hx7WBkO8
  https://www.youtube.com/watch?v=XGDq6620fPQ




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

Re: [Emc-developers] LCNC-V2.6.7-saga

[sam sokolik]

does it still crash without any external device powered up?  (I too have
been running linuxcnc up to 2.6.7 without issue)

sam

On 05/17/2015 04:35 PM, Gene Heskett wrote:
 On Sunday 17 May 2015 17:25:07 andy pugh wrote:
 On 17 May 2015 at 22:19, Gene Heskett ghesk...@wdtv.com wrote:
 Since I am software stepping, when I next reboot
 it, I will raise the base_thread to 30 u-secs just for SG's.  I
 believe it was 27 the last time I checked.
 Have a look at Machine-Show Hal Config and at the bottom of the list
 is threads

 Make sure that the base-thread time is less than the base-thread
 period by some margin.
 Also, make sure that only functions that need to be in the base thread
 are in the base thread. That is probably only parport.write,
 stepconf.make-steps and encoder.count
 Printed for on site checking, thanks Andy.

 Cheers, Gene Heskett


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Reverse Run

[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

On 4/9/2015 11:37 AM, Robert Ellenberg wrote:
 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
 On Apr 9, 2015 12:18 PM, Gene Heskett ghesk...@wdtv.com wrote:

 On Thursday 09 April 2015 12:10:41 andy pugh wrote:
 On 9 April 2015 at 17:02, Gene Heskett ghesk...@wdtv.com wrote:
 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


 --
 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_15utm_medium=emailutm_campaign=VA_SF
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 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_15utm_medium=emailutm_campaign=VA_SF
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 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_15utm_medium=emailutm_campaign=VA_SF
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Reverse Run

[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

On 4/8/2015 10:29 PM, Robert Ellenberg wrote:
 On Apr 8, 2015 10:06 PM, sam sokolik sa...@empirescreen.com wrote:
 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.
 -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.

 sam


 On 04/08/2015 07:25 PM, Robert Ellenberg wrote:
 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

 --
 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_15utm_medium=emailutm_campaign=VA_SF
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 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_15utm_medium=emailutm_campaign=VA_SF
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 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_15utm_medium=emailutm_campaign=VA_SF
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 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_15utm_medium=emailutm_campaign=VA_SF

Re: [Emc-developers] Reverse Run

[sam sokolik]

oh - better yet...

sam

On 4/9/2015 6:41 AM, andy pugh wrote:
 On 9 April 2015 at 12:32, sam sokolik sa...@empirescreen.com wrote:
 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_15utm_medium=emailutm_campaign=VA_SF
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Reverse Run

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


On 04/08/2015 07:25 PM, Robert Ellenberg wrote:
 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
 --
 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_15utm_medium=emailutm_campaign=VA_SF
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 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_15utm_medium=emailutm_campaign=VA_SF
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G18 arcs bug in 2.7+

[sam sokolik]

Chris figured it out.  Now the plane issue I was seeing was totally my
fault.  When I changed planes to G18 - I just switched Y to Z.  Well
this makes the arcs the wrong way.  Changing them to G3 fixes it.  Oops.
I fail at the right hand rule I guess.

Sorry Rob if you started looking at that..  (Chris also figured that out)
(this example) 
http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-03-09%2010:14:18.png

sam

On 03/10/2015 02:33 AM, Andrew wrote:
 Fixed, thanks!

 2015-03-09 19:01 GMT+02:00 Andrew:

 I still think there's a bug.
 Indeed, inch lathe config works well.
 But when I change inch to mm and increase the values accordingly - it
 behaves exactly as described in my first message.
 So this is rather inch-mm bug somewhere.


 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the 
 conversation now. http://goparallel.sourceforge.net/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers




--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G18 arcs bug in 2.7+

[sam sokolik]

in sim lathe - I get about 5.5ipm...  which seems right - feed/rev of 
.14mm = 1000rpm*(.14*.03937)=5.5ipm.  Feed override seems to work 
also...  (and changing the spindle rpm changes feed)

sam

On 3/9/2015 8:34 AM, Andrew wrote:
 Sure, I attached the code.

 Thanks!

 2015-03-09 15:26 GMT+02:00 sam sokolik sa...@empirescreen.com:

 Do you have a gcode snippet that would show this?

 thanks
 sam

 On 3/9/2015 8:12 AM, Andrew wrote:
 Hello,

 I found this bug a couple of months back and it hasn't disappeared since.
 Sim-lathe slows down on G2 G3 arcs. Say, the feed is 140mm/min, it moves
 140 on the lines and it's limited to 60 on arcs. Exactly 60 mm/min. Feed
 override is ignored on arcs, but works for lines.
 G94, G95, G96, G97 doesn't change anything.
 Both new and old TP.
 It works normal in 2.6.7, but fails in 2.7 and master.
 G18 is active, might be the key?



 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/


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

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G18 arcs bug in 2.7+

[sam sokolik]

Do you have a gcode snippet that would show this?

thanks
sam

On 3/9/2015 8:12 AM, Andrew wrote:
 Hello,

 I found this bug a couple of months back and it hasn't disappeared since.
 Sim-lathe slows down on G2 G3 arcs. Say, the feed is 140mm/min, it moves
 140 on the lines and it's limited to 60 on arcs. Exactly 60 mm/min. Feed
 override is ignored on arcs, but works for lines.
 G94, G95, G96, G97 doesn't change anything.
 Both new and old TP.
 It works normal in 2.6.7, but fails in 2.7 and master.
 G18 is active, might be the key?



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G18 arcs bug in 2.7+

[sam sokolik]

this program does show difference between planes..

G17 vs g18..

G18 peaks at about 320ipm vs G17 peaks at about 540ipm..

I don't see an issue with feed override.

sam


On 03/09/2015 08:26 AM, sam sokolik wrote:
 Do you have a gcode snippet that would show this?

 thanks
 sam

 On 3/9/2015 8:12 AM, Andrew wrote:
 Hello,

 I found this bug a couple of months back and it hasn't disappeared since.
 Sim-lathe slows down on G2 G3 arcs. Say, the feed is 140mm/min, it moves
 140 on the lines and it's limited to 60 on arcs. Exactly 60 mm/min. Feed
 override is ignored on arcs, but works for lines.
 G94, G95, G96, G97 doesn't change anything.
 Both new and old TP.
 It works normal in 2.6.7, but fails in 2.7 and master.
 G18 is active, might be the key?


 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the 
 conversation now. http://goparallel.sourceforge.net/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers


g20 g64
s3400 m3
g0z1
g0x0y0z1
g0 x1.724638 z-1.012731
g1z-.1f999
g1 x1.724638 z-1.012731
g18
g2 r1.997999 x1.613302 z-1.178668
r1.996000 x1.486083 z-1.332506
r1.994000 x1.344282 z-1.472733
r1.992000 x1.189344 z-1.597975
r1.99 x1.022843 z-1.707013
r1.988000 x0.846464 z-1.798789
r1.986000 x0.661990 z-1.872422
r1.984000 x0.471277 z-1.927214
r1.982000 x0.276244 z-1.962655
r1.98 x0.078845 z-1.978430
r1.978000 x-0.118942 z-1.974421
r1.976000 x-0.315142 z-1.950708
r1.974000 x-0.507799 z-1.907568
r1.972000 x-0.694996 z-1.845471
r1.97 x-0.874875 z-1.765076
r1.968000 x-1.045656 z-1.667222
r1.966000 x-1.205650 z-1.552921
r1.964000 x-1.353282 z-1.423350
r1.962000 x-1.487103 z-1.279832
r1.96 x-1.605805 z-1.123828
r1.958000 x-1.708233 z-0.956924
r1.956001 x-1.793399 z-0.780806
r1.954000 x-1.860485 z-0.597253
r1.952000 x-1.908861 z-0.408112
r1.95 x-1.938080 z-0.215284
r1.948000 x-1.947890 z-0.020702
r1.946000 x-1.938233 z0.173687
r1.944000 x-1.909246 z0.365943
r1.942000 x-1.861258 z0.554151
r1.94 x-1.794786 z0.736439
r1.938000 x-1.710533 z0.910999
r1.936000 x-1.609377 z1.076105
r1.934000 x-1.492362 z1.230126
r1.932000 x-1.360690 z1.371549
r1.93 x-1.215706 z1.498986
r1.928000 x-1.058886 z1.611194
r1.926000 x-0.891819 z1.707084
r1.924000 x-0.716195 z1.785733
r1.922000 x-0.533785 z1.846390
r1.91 x-0.346426 z1.888488
r1.918000 x-0.155999 z1.911645
r1.916000 x0.035589 z1.915669
r1.914000 x0.226423 z1.900560
r1.912000 x0.414597 z1.866508
r1.91 x0.598240 z1.813893
r1.908000 x0.775525 z1.743280
r1.906000 x0.944697 z1.655410
r1.904000 x1.104083 z1.551198
r1.902000 x1.252112 z1.431719
r1.90 x1.387330 z1.298197
r1.898000 x1.508413 z1.151996
r1.896000 x1.614182 z0.994602
r1.893999 x1.703613 z0.827609
r1.892000 x1.775848 z0.652707
r1.89 x1.830202 z0.471658
r1.888000 x1.866169 z0.286284
r1.886000 x1.883429 z0.098443
r1.884000 x1.881850 z-0.089983
r1.882000 x1.861487 z-0.277110
r1.88 x1.822584 z-0.461074
r1.877999 x1.765567 z-0.640043
r1.876000 x1.691046 z-0.812243
r1.874000 x1.599802 z-0.975966
r1.872000 x1.492781 z-1.129597
r1.87 x1.371085 z-1.271623
r1.868000 x1.235962 z-1.400651
r1.866000 x1.088788 z-1.515420
r1.864000 x0.931060 z-1.614814
r1.861999 x0.764375 z-1.697873
r1.86 x0.590417 z-1.763805
r1.858000 x0.410939 z-1.811986
r1.856000 x0.227744 z-1.841974
r1.854000 x0.042669 z-1.853509
r1.852000 x-0.142432 z-1.846515
r1.85 x-0.325712 z-1.821102
r1.848000 x-0.505345 z-1.777563
r1.846000 x-0.679544 z-1.716373
r1.844000 x-0.846583 z-1.638180
r1.841999 x-1.004807 z-1.543802
r1.84 x-1.152658 z-1.434218
r1.838000 x-1.288680 z-1.310553
r1.836000 x-1.411541 z-1.174073
r1.834000 x-1.520043 z-1.026170
r1.832000 x-1.613134 z-0.868344
r1.83 x-1.689918 z-0.702194
r1.828000 x-1.749664 z-0.529396
r1.826000 x-1.791812 z-0.351691
r1.824000 x-1.815979 z-0.170864
r1.822000 x-1.821965 z0.011273
r1.82 x-1.809749 z0.192897
r1.818000 x-1.779492 z0.372198
r1.816000 x-1.731538 z0.547388
r1.814000 x-1.666402 z0.716728
r1.812000 x-1.584774 z0.878541
r1.81 x-1.487506 z1.031226
r1.808000 x-1.375602 z1.173279
r1.806000 x-1.250213 z1.303305
r1.804000 x-1.112620 z1.420033
r1.802000 x-0.964225 z1.522325
r1.80 x-0.806533 z1.609194
r1.798000 x-0.641139 z1.679805
r1.796000 x-0.469712 z1.733490
r1.794000 x-0.293977 z1.769750
r1.792000 x-0.115699 z1.788261
r1.79 x0.063336 z1.788879
r1.788000 x0.241340 z1.771637
r1.786000 x0.416536 z1.736748
r1.784000 x0.587182 z1.684599
r1.782000 x0.751585 z1.615749
r1.78 x0.908115 z1.530924
r1.778000 x1.055229 z1.431005
r1.776000 x1.191477 z1.317026
r1.774000 x1.315525 z1.190155

Re: [Emc-developers] G18 arcs bug in 2.7+

[sam sokolik]

100% feedrate override   (I set linuxcnc to display metric.)
http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-03-09%2009:09:59.png

50% feedrate override
http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-03-09%2009:10:26.png

sam

On 03/09/2015 08:56 AM, sam sokolik wrote:
 in sim lathe - I get about 5.5ipm...  which seems right - feed/rev of 
 .14mm = 1000rpm*(.14*.03937)=5.5ipm.  Feed override seems to work 
 also...  (and changing the spindle rpm changes feed)

 sam

 On 3/9/2015 8:34 AM, Andrew wrote:
 Sure, I attached the code.

 Thanks!

 2015-03-09 15:26 GMT+02:00 sam sokolik sa...@empirescreen.com:

 Do you have a gcode snippet that would show this?

 thanks
 sam

 On 3/9/2015 8:12 AM, Andrew wrote:
 Hello,

 I found this bug a couple of months back and it hasn't disappeared since.
 Sim-lathe slows down on G2 G3 arcs. Say, the feed is 140mm/min, it moves
 140 on the lines and it's limited to 60 on arcs. Exactly 60 mm/min. Feed
 override is ignored on arcs, but works for lines.
 G94, G95, G96, G97 doesn't change anything.
 Both new and old TP.
 It works normal in 2.6.7, but fails in 2.7 and master.
 G18 is active, might be the key?


 --
 Dive into the World of Parallel Programming The Go Parallel Website, 
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for 
 all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/


 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers
 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the 
 conversation now. http://goparallel.sourceforge.net/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G18 arcs bug in 2.7+

[sam sokolik]

Yes - I think I am seeing it too.  20in/s^2 inch config works great but 
a 500mm/s^2 metric config doesn't..

sam

On 3/9/2015 12:01 PM, Andrew wrote:
 I still think there's a bug.
 Indeed, inch lathe config works well.
 But when I change inch to mm and increase the values accordingly - it
 behaves exactly as described in my first message.
 So this is rather inch-mm bug somewhere.

 2015-03-09 16:13 GMT+02:00 sam sokolik sa...@empirescreen.com:

 100% feedrate override   (I set linuxcnc to display metric.)

 http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-03-09%2009:09:59.png

 50% feedrate override

 http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-03-09%2009:10:26.png

 sam

 On 03/09/2015 08:56 AM, sam sokolik wrote:
 in sim lathe - I get about 5.5ipm...  which seems right - feed/rev of
 .14mm = 1000rpm*(.14*.03937)=5.5ipm.  Feed override seems to work
 also...  (and changing the spindle rpm changes feed)

 sam

 On 3/9/2015 8:34 AM, Andrew wrote:
 Sure, I attached the code.

 Thanks!

 2015-03-09 15:26 GMT+02:00 sam sokolik sa...@empirescreen.com:

 Do you have a gcode snippet that would show this?

 thanks
 sam

 On 3/9/2015 8:12 AM, Andrew wrote:
 Hello,

 I found this bug a couple of months back and it hasn't disappeared
 since.
 Sim-lathe slows down on G2 G3 arcs. Say, the feed is 140mm/min, it
 moves
 140 on the lines and it's limited to 60 on arcs. Exactly 60 mm/min.
 Feed
 override is ignored on arcs, but works for lines.
 G94, G95, G96, G97 doesn't change anything.
 Both new and old TP.
 It works normal in 2.6.7, but fails in 2.7 and master.
 G18 is active, might be the key?


 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub
 for all
 things parallel software development, from weekly thought leadership
 blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/


 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers
 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub
 for all
 things parallel software development, from weekly thought leadership
 blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers



 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers





--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] New TP bugs?

[sam sokolik]

2 screen shots arc/line...  G64P.1

http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-03-08%2017:49:49.png

http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-03-08%2017:45:24.png

sam
On 03/08/2015 05:20 PM, sam sokolik wrote:
 is this correct?
 x 100mm/s 25mm/s^2
 y 100mm/s 25mm/s^2
 z 100mm/s 250mm/s^2

 Lines
 enabled 3:04
 disabled 4:50

 arcs
 enabled 3:27
 disabled 5:03

 there is a fix now in 2.7 - rob when you get a chance - look it over.

 sam





 On 03/08/2015 02:40 PM, Andrew wrote:
 Hello,

 Today I ran into a comparison of hobby CNC software on a russian forum. The
 guy made a test trajectory and run it on a few CNC's. Here's the results:
 KMotionCNC - 2:59
 NCStudio v5.5.60 - 3:12
 EdingCNC - 3:47
 Mach3 - 5:25
 PlanetCNC - 11:24
 LinuxCNC was not tested.

 So I installed a fresh 2.7.0~pre4 from git, edited axis_mm config to
 100mm/s and 25mm/s2 for XY and 250mm/s2 for Z (by the test conditions). I
 also set G64 P0.1.
 The results were pretty unpredictable:
 5:05 for arc segments and 4.50 for line segments with ARC_BLEND_ENABLE = 0
 5:23 for arc segments and 6.50 for line segments with ARC_BLEND_ENABLE = 1
 Looks like ARC_BLEND_ENABLE switch is inverted.
 The way how it follows the trajectory confirms that too.

 Also, 2.7 often shows an arbitrary non-zero velocity on preview when the
 actual velocity is 0.

 --
 Andrew

 PS: I attached the test files, in case someone wants to try.


 --
 Dive into the World of Parallel Programming The Go Parallel Website, 
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for 
 all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the 
 conversation now. http://goparallel.sourceforge.net/


 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers
 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the 
 conversation now. http://goparallel.sourceforge.net/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] New TP bugs?

[sam sokolik]

is this correct?
x 100mm/s 25mm/s^2
y 100mm/s 25mm/s^2
z 100mm/s 250mm/s^2

Lines
enabled 3:04
disabled 4:50

arcs
enabled 3:27
disabled 5:03

there is a fix now in 2.7 - rob when you get a chance - look it over.

sam





On 03/08/2015 02:40 PM, Andrew wrote:
 Hello,

 Today I ran into a comparison of hobby CNC software on a russian forum. The
 guy made a test trajectory and run it on a few CNC's. Here's the results:
 KMotionCNC - 2:59
 NCStudio v5.5.60 - 3:12
 EdingCNC - 3:47
 Mach3 - 5:25
 PlanetCNC - 11:24
 LinuxCNC was not tested.

 So I installed a fresh 2.7.0~pre4 from git, edited axis_mm config to
 100mm/s and 25mm/s2 for XY and 250mm/s2 for Z (by the test conditions). I
 also set G64 P0.1.
 The results were pretty unpredictable:
 5:05 for arc segments and 4.50 for line segments with ARC_BLEND_ENABLE = 0
 5:23 for arc segments and 6.50 for line segments with ARC_BLEND_ENABLE = 1
 Looks like ARC_BLEND_ENABLE switch is inverted.
 The way how it follows the trajectory confirms that too.

 Also, 2.7 often shows an arbitrary non-zero velocity on preview when the
 actual velocity is 0.

 --
 Andrew

 PS: I attached the test files, in case someone wants to try.


 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the 
 conversation now. http://goparallel.sourceforge.net/


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

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] New TP bugs?

[sam sokolik]

I have played with mach's trajectory planner when rob started working on
the new TP.  I actually used  linuxcnc to show what mach was doing.  I
used the step/dir output from mach - mesa 7i80 encoder input -
linuxcnc.  Not only was there acceleration constraint violations - its
path following shows similar issues.

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NewTrajectoryControl

It gets worse the faster you go it seems.

I am also surprised that mach didn't perform better.  In most test I
have done mach ran a bit faster.  (because of its acceleration violation
/  path tolerance.)  I believe that CV Dist Tolerance_Unit is the
distance from the end of the line that it is cutting to where the arc
starts rounding.

It is awesome that we can check the trajectory planning within linuxcnc
using hal. 

sam


On 03/08/2015 06:37 PM, Andrew wrote:
 2015-03-09 1:11 GMT+02:00 Robert Ellenberg rwe...@gmail.com:

 Nice catch, Sam! those variables definitely should have been doubles, not
 ints. I'm not sure whether the comparison numbers Andrew posted were for
 the lines or arcs example, but it looks like 2.7 is at least competitive.
 3:04 is second place on that list!

 3:04 is for P0.1
 But they had 4 units in Mach3, not sure what it actually means

 Mach3 performs even worse on the arcs he says.
 Here's the link for the topic, google translate will help with russian
 http://www.cnc-club.ru/forum/viewtopic.php?f=41t=2558
 And I can ask the author something if nesessary.

 It surprises me a little that Mach3 isn't higher on that list. I wonder
 what lookahead setting they were using?

 He says Mach3 best performs with these settings
 http://www.cnc-club.ru/forum/download/file.php?id=38185mode=view

 Talking about Mach3... interesting trajectory screenshots
 http://www.cnc-club.ru/forum/download/file.php?id=44822mode=view
 http://www.cnc-club.ru/forum/download/file.php?id=44823mode=view
 http://www.cnc-club.ru/forum/download/file.php?id=44824mode=view
 This is for acceleration 100, 500 and 1500 mm/s2 respectively
 Settings http://www.cnc-club.ru/forum/download/file.php?id=44825mode=view

 And voila, the machining results for the same GCode
 Mach3
 http://www.cnc-club.ru/forum/download/file.php?id=44782mode=viewmt=1
 and NCStudio
 http://www.cnc-club.ru/forum/download/file.php?id=44781mode=viewmt=1

 Mach3 is seriously broken according to this...


 @Andrew, I'm taking a look at the current velocity display issue, I think
 it will be a simple fix.

 Great, thanks!




--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] [Emc-commit] 2.7: tp: fix for climbing behavior in rigid tapping

[sam sokolik]

that is how tapping is implemented.  (it isn't seeing that the spindle 
is reversed - it is syncing past the starting point of the cycle - then 
turning the spindle off / reversing  - waiting for the spindle to stop 
(still synced) and then moving to the initial starting point of the 
tapping cycle.

http://linuxcnc.org/docs/2.7/html/gcode/gcode.html#sec:G33_1-Rigid-Tapping

You can see it here...  (my spindle has really slow accelleration..)

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

sam

On 3/3/2015 10:38 AM, Jon Elson wrote:
 On 03/03/2015 08:37 AM, Robert W. Ellenberg wrote:
 tp: fix for climbing behavior in rigid tapping

 It turns out we were always setting the tp goalPos to be the endpoint of
 the most recently added segment. Unfortunately, this assumption breaks
 on rigid tapping, where the end point is somewhere past the start
 point (but motion stops early once the spindle isn't synced).
 Hmm, I've noticed at the end of a G33.1 cycle, as the
 spindle reverts to
 forward rotation, the Z axis remains synched to the spindle
 for a moment,
 and starts toward the workpiece again.  This probably lasts
 50 - 100 ms,
 which seems awfully long before it recognizes that the
 spindle has reversed
 at the end of the withdrawal from the thread.

 Is this the behavior you are describing above?

 Jon

 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers




--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Thoughts on pause-retract and related issues.

[sam sokolik]

I like the sound of that...   would then the preview show actual tool
location? 

sam
On 11/26/2014 04:28 AM, andy pugh wrote:
 I have been thinking for quite a while that a set of offset pins in
 HAL to apply external offsets in World space would be very useful.

 These would be perfect for Mark's squiffy bevel sawing machine, and
 would probably be a better solution to the problem that is almost but
 not quite solved by probekins.

 Offsets as HAL pins into motion would have the advantage of working in
 XYZ space rather than joint space, and hopefully it would also be
 possible to keep things inside soft-limits and velocity/accel limits.
 (or maybe not if those limits are computed prior to the switch to
 realtime)

 The mah jwp patch that I tried the other day was similar to what I
 envisage, except the offsets were definitively tied to pause-mode
 motion, whereas what I am proposing could be activated at any time
 when an activate pin was enabled.

 This would also provide a very convenient place for Dewey's new
 retract component to hook in, while not excluding the possibility of a
 proper jog-while-paused hooked into normal jog-while-not-paused
 jogging later. (the pins would be more generally applicable).

 One interesting application for such pins would be to allow
 world-space motion from arbitrary HAL components driven by sources
 other than G-code. There are probably many potential uses for this in
 special purpose machines. In this scenario motmod would handle homing,
 kinematics and kinematical limits, but the HAL component would
 generate the moves.



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Found a new constraint violation...

[sam sokolik]

Playing around with dxf2gcode.. (cool program btw..)  It generated this 
file  (running in master)

http://electronicsam.com/images/KandT/testing/SPACOUT1.ngc

it violates the negative y acceleration on line 18,23,37 and so on.

http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-10-20%2014:21:17.png
 


it seems to be switching to parabolic blending maybe at that point? (you 
can see the strait g64 tolerance is doing what I have seen in parabolic 
blending..

actually really not quite sure what it is doing..

sam

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Found a new constraint violation...

[sam sokolik]

ok - as you can see from my screen shot I was actually running 2.6.3

So - I actaully ran master and - it runs as expected...   One of the 
many small bugs fixed..  Yay Rob!!

http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-10-20%2015:02:29.png

sam





On 10/20/2014 02:37 PM, sam sokolik wrote:
 Playing around with dxf2gcode.. (cool program btw..)  It generated this
 file  (running in master)

 http://electronicsam.com/images/KandT/testing/SPACOUT1.ngc

 it violates the negative y acceleration on line 18,23,37 and so on.

 http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-10-20%2014:21:17.png


 it seems to be switching to parabolic blending maybe at that point? (you
 can see the strait g64 tolerance is doing what I have seen in parabolic
 blending..

 actually really not quite sure what it is doing..

 sam

 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://p.sf.net/sfu/Zoho
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers



--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Tool Table and Wear offset Table

[sam sokolik]

are you saying have a g41.1 on
On 10/2/2014 10:07 AM, Dave Cole wrote:
 On 10/2/2014 10:46 AM, andy pugh wrote:
 On 2 October 2014 15:40, Dave Cole linuxcncro...@gmail.com wrote:
 They would like to be able to adjust the jet size (think tool diameter)
 on the fly
 This is probably most easily done with G42.1 and G41.1, though the
 G-code would have to actually stop and look for new values  from an
 input source.

 Any change of tool diameter would require a recalculation of the
 motion queue, so I don't think that there is any way to do it
 completely live.
 As an initial step job-by-job, however, it would be relatively easy.
 So perhaps if I had the tool/jet diameter in a hal float pin, I could
 use that along with the analog input function in Gcode to grab the hal
 value and then assign it via an invocation of G42.1 or G41.1 ?

 Does that sound possible/reasonable?

 So in this respect the tool table becomes a non issue?   Does this sound
 correct?

 Thanks,

 Dave

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


 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers




--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Tool Table and Wear offset Table

[sam sokolik]

wow - didn't mean to send that..

well to finish my thought - would you put g41.1 at the begining of every 
part/shape?  I could see that working very well.

sam


On 10/2/2014 10:26 AM, sam sokolik wrote:
 are you saying have a g41.1 on
 On 10/2/2014 10:07 AM, Dave Cole wrote:
 On 10/2/2014 10:46 AM, andy pugh wrote:
 On 2 October 2014 15:40, Dave Cole linuxcncro...@gmail.com wrote:
 They would like to be able to adjust the jet size (think tool diameter)
 on the fly
 This is probably most easily done with G42.1 and G41.1, though the
 G-code would have to actually stop and look for new values  from an
 input source.

 Any change of tool diameter would require a recalculation of the
 motion queue, so I don't think that there is any way to do it
 completely live.
 As an initial step job-by-job, however, it would be relatively easy.
 So perhaps if I had the tool/jet diameter in a hal float pin, I could
 use that along with the analog input function in Gcode to grab the hal
 value and then assign it via an invocation of G42.1 or G41.1 ?

 Does that sound possible/reasonable?

 So in this respect the tool table becomes a non issue?   Does this sound
 correct?

 Thanks,

 Dave

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


 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers



 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers




--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] automatic

[sam sokolik]

for even more ideas.  (this is pretty specific to the KT gearbox...) 
but might give ideas..  (maybe on what not to do.. ;) )

http://electronicsam.com/images/KandT/conversion/testing/config/gearshift16.comp

I obviously am not the greatest programmer but the comp has never given 
us problems.

https://www.youtube.com/watch?v=22dWg3GbywElist=UUHk52YjGT8HryRYmJKSl-lg

just shifting though all the gears.  (you can see the shift rails 
(ssr's) , 4 bits, count up)

sam


On 09/25/2014 05:21 AM, andy pugh wrote:
 On 25 September 2014 11:12, David Armstrong cncbas...@gmail.com wrote:

 the error i have is that the the 5i20.scale does not exist
 The encoder scale is listed as an r/w pin, rather than a parameter.
 (assuming you mean 5i20.0.enoder.00.scale? )
 I am not sure if you would really want to change the encoder scale in
 mid-stream though, you will get a huge position jump.
 It might be better to do you own calculations in the comp based on
 rawcounts (which only ever counts up or down)



--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] HAL driver 7i80 not in master

[sam sokolik]

it is the hm2_eth.c

sam
On 9/11/2014 7:42 AM, Marius Liebenberg wrote:
 I am looking for the hm2_7i80.c driver code but cannot find it in
 master. Anybody know where to find it please?



--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hostmot2 ethernet support now in master branch (was Re: feedback on jepler/hm2-eth-v2)

[sam sokolik]

This is master running on debian wheezy and rt_preemt.  It has been up 
for 9 days so far.  It is running the splash screen in an infinite loop. 
The stepgens in the 7i80 are in velocity mode and running with pid.

http://electronicsam.com/images/KandT/testing/weekplus.png

sam

On 7/26/2014 11:18 AM, Jeff Epler wrote:
 Thanks to everyone who tested and did code review, and thanks in
 particular to Michael Geszkiewicz who wrote the original code, the
 hostmot2 driver has now been merged to the LinuxCNC master branch.

 This is the first hardware driver that functions exclusively with
 userspace POSIX realtime, aka uspace.  To use it, you have to use a
 PREEMPT-RT kernel such as linux linux-image-3.2.0-4-rt-686-pae on Debian
 7, configure your linuxcnc with
  --enable-realtime=uspace
 and sudo make setuid so that linuxcnc can run with realtime priority.

 For more information on uspace realtime,
  http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Uspace

 Jeff

 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers




--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Jeff's wheezy live cd

[sam sokolik]

Can you explain the steps that brought you to needing those 2 files?

(I have been running the new livecd for the past couple weeks with both 
the 7i80, 5i20 and rtai/rt-preempt with no issues.)

sam

On 8/5/2014 8:17 AM, David Armstrong wrote:
 Then why did i have to install the 2 files referenced to allow Linuxcnc to
 run
 i am NOT using Machinekit

 Dave


 On 5 August 2014 13:58, Jeff Epler jep...@unpythonic.net wrote:

 On Mon, Aug 04, 2014 at 07:05:21PM +0100, David Armstrong wrote:
 Guy's
 just for information , jeff's boot image as per the wiki
 http://article.gmane.org/gmane.linux.distributions.emc.user/52401
 The LinuxCNC image you refer to is built by Chris Radek, not by any Jeff.

 and found that

 /etc/security/limits.d/linuxcnc.conf
 /etc/udev/rules.d/50-LINUXCNC-shmdrv.rules

 were not included
 These may be files that are shipped by the MachineKit project.  LinuxCNC
 is not MachineKit and does not ship these files.  shmdrv is
 machinekit-specific, and in current versions of LinuxCNC we increase the
 locked memory limit by appending lines to /etc/security/limits.conf;
 this was done because at the time we added this, limits.d did not exist
 yet.  Patches to change our packaging to use limits.d instead would be
 welcome.

 Jeff


 --
 Infragistics Professional
 Build stunning WinForms apps today!
 Reboot your WinForms applications with our WinForms controls.
 Build a bridge from your legacy apps to the future.

 http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

 --
 Infragistics Professional
 Build stunning WinForms apps today!
 Reboot your WinForms applications with our WinForms controls.
 Build a bridge from your legacy apps to the future.
 http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers




--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Mach4 is for sale!

[sam sokolik]

Sorry - this was supposed to be on the users list.

sam
On 8/1/2014 10:22 AM, sam sokolik wrote:
 If anyone is interested...

 https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/145043

 http://www.machsupport.com/forum/index.php/topic,27747.0.html

 http://www.machsupport.com/software/mach4/

 sam

 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers




--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Mach4 is for sale!

[sam sokolik]

If anyone is interested...

https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/145043

http://www.machsupport.com/forum/index.php/topic,27747.0.html

http://www.machsupport.com/software/mach4/

sam

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Help me understand Ethernet motion control

[sam sokolik]

I will take a stab...

The short answer is linuxcnc Ethernet motion is no different than any of 
the other interface card solution..

The longer (as I understand it) answer is...

Remember that linuxcnc doesn't use motion devices like smoothstepper or 
galil.  (these are buffering devices that move motion off of the 
computer.)  These have advantages that the computer that is sending the 
data doesn't have to be realtime (or the link between the computer and 
the device doesn't need to be realtime).  From my perspective - they 
have too many disadvantages.  (but I am biased..)

In linuxcnc - most interfaces are 'just' hardware step generators and or 
pwm generators and or i/o and or encoder counters and or other things I 
can't think of at the moment.  (ie mesa, pico, vital...) This moves the 
heavy lifting off of the computer.  So on a normal system running one of 
these interfaces the computer accesses the card every servo period. 
(maybe 1 to 10khz).   This reads encoder positions,  updates stepgens, 
pwm, i/o and so on.  The link between the interface card and the 
computer is realtime be it pci, parallel port, ethernet  So 
initially the realtime Ethernet interface was rt-net on xenomai.  This 
worked but was a pain that a) you needed rtnet and b) There was only a 
few network interfaces supported...  Now the Ethernet interface uses 
rt-preempt which is a lot less work to setup - expecially now that jeff 
has added support to master.  (on wheezy you can use the rt_preempt 
kernel from synaptic)

Overall - pretty exciting stuff!

sam





On 7/28/2014 7:11 AM, Marius Liebenberg wrote:
 I am wondering about how Ethernet motion control works together with
 linuxcnc. How is the synchronized motion achieved over the link? Or what
 kind of information is passed over the link to the controller?



--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] jepler/rtos-uspace: a new POSIX realtime branch

[sam sokolik]

I have been testing the Ethernet branch.   (mesa 7i80)  no issues what 
so ever.

Some of the hardware I have been testing is the

GIGABYTE GA-J1800N-D2H  rt-preempt latency 36us
http://electronicsam.com/images/KandT/testing/j1800.png

GIGABYTE GA-J1900N-D3V rt-preempt latency 66us
http://electronicsam.com/images/KandT/testing/j1900.png

All these latency tests have been done with idle=poll in the kernel line.

(these motherboards have one major issue - The usb's don't seem to work 
with any of the normal RTAI kernels...)  They seem to have decent 
latency with rtai - just no usb..  This may or may not be figured out in 
the future.

The J1900 is cool because it has dual nics - great for Ethernet 
solutions.. (also 1 normal pci slot as an option)
http://electronicsam.com/images/KandT/testing/IMG_20140717_110054_019.jpg

I have been tickling the stepgens on the 7i80 for days with no issues.

Great work!!
sam




On 7/17/2014 4:46 PM, Jeff Epler wrote:
 Not a lot has changed since my last report.  the rtos-uspace branch has
 been rebased a few additional times.

 In the absence of any concerns raised about this branch before July 20
 (Sunday), I plan to merge my work to the linuxcnc master branch.

 So if you want to raise any issues or just offer review comments, please
 feel free to do so in this thread.

 Jeff

 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers




--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers