Re: [Emc-users] RPI saga continues - SPI probably solved

2017-06-03 Thread john mcintyre 
Good day Gene ,

Your saga continues, you must be related to a bulldog ,once locked on  it 
cannot let go.

All the best john



From: Gene Heskett 
Sent: Sunday, 4 June 2017 9:47 AM
To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] RPI saga continues - SPI probably solved

On Friday 02 June 2017 21:50:13 Bertho Stultiens wrote:

> On 06/03/2017 03:36 AM, Gene Heskett wrote:
> >> Has anybody done an implementation of affinity in linuxcnc already?
> >> If yes, how is it setup?
> >
> > On the x86 stuff, in years past, we used "isolcpus"=3 (or whatever
> > was the last core) as a kernel argument at kernel load time.
> >
> > On x86 stuff the cpu you have isolated is found and used
> > automatically, however the use cannot be detected by the various cpu
> > monitoring utilities such as htop.  I had originally set that up to
> > reserve core 3, on the 4 core pi, and on core 3 of the athlons I
> > don't know who corrected me, but it was said that was no longer a
> > useful item, so I took it back out of /boot/cmdline.txt and out of
> > some of the x86 machines too, but I see its still in as an =1 on the
> > two atom boards out in the shop.  The one I removed it from hasn't
> > indicated any unhappiness with that turn of events.
> >
> > Perhaps Sebastian or someone more familiar with it can shine a light
> > on us here? As in has it been deprecated on all arches. I still have
> > 2 D525MW's with it in effect. And htop cannot see any usage of cpu-1
> > on either of those 2 boxes.
>
> Yes, isolcpus=X is the way to do that. However, doing so means that
> the kernel never schedules anything on the core automatically. You
> must set the thread/process affinity in the running code, using a
> syscall, to move a specific thread/process onto that isolated core.
> Otherwise, it will be idle all the time.

When I awoke about sunup, I had a message from amanda. I gad left lcnc
running when I came in for the and the pi apparently crashed very
quickly when amanda tried to access it.

So when I ran down at restoring it today, with 8 wires yet to hook up
verify I have them right, and I'll be at the same place I was,
everything running nicely, the morning of May 2, but I shut lcnc down
before hitting the light switch and closing the garage door for the
night. On my feet a good share of the day, I'll pay for it in the night
with leg cramps. I'll take an extra big b12 pill, which sometimes helps
because metformin flushes b12 out into a big white bowl. :)

I did write the new image to a card, but have not had the time to go into
it, setting hostnames, hosts etc, yadda, yadda yet.  And killing
anything that can over-write /etc/resolv.conf thereby keeping my local
network running on the pi like it runs on everything else.

I did plug in that terabyte HD and had mc update the linuxcnc tree
already on that drive from a couple weeks ago, and its still plugged in.

And I'm bushed, but progress has been made.  Curious, before I quit, I
fired up the scope and looked at everything I had hooked up the last 3
days, and was amazed!  Whereas the old lashup was attacking the 7i90
with switching noises up in the 90+ mhz range, at peak voltages of 30+
volts before it hit any wire by wire filtering I'd been building, if
there is any noise there now, its well under 50 millivolts and I can't
see it on the analog scope at all. This was with the vfd up and running,
spinning the chuck at about 225 rpms.  And yet every cable I am hooking
up is coming into the bottom of the motor drivers box, thru it just as
before. The cpu/controller box is insulated from the power box, and only
connected to the single point ground by one braided strap, which I had
to cover with shrink tubing because it was touching the spinx1 which I'd
remounted on the inside of the door.  Didn't blow anything but the vfd
was going crazy when I moved the boxes door, which now has the pi &
controller box on the outside of the door.

Thanks Bertho, a lot.

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/pix/EasterSundayCropped2004-1.jpg]

Gene's Web pages
geneslinuxbox.net
Welcome to Gene's web pages. Here you will find some of the things that make me 
tick, and that help keep me out of the bars. That is me & the missus, Dee 
(Elladene) I ...




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

Re: [Emc-users] RPI saga continues - SPI probably solved

2017-06-03 Thread Gene Heskett 
On Friday 02 June 2017 21:50:13 Bertho Stultiens wrote:

> On 06/03/2017 03:36 AM, Gene Heskett wrote:
> >> Has anybody done an implementation of affinity in linuxcnc already?
> >> If yes, how is it setup?
> >
> > On the x86 stuff, in years past, we used "isolcpus"=3 (or whatever
> > was the last core) as a kernel argument at kernel load time.
> >
> > On x86 stuff the cpu you have isolated is found and used
> > automatically, however the use cannot be detected by the various cpu
> > monitoring utilities such as htop.  I had originally set that up to
> > reserve core 3, on the 4 core pi, and on core 3 of the athlons I
> > don't know who corrected me, but it was said that was no longer a
> > useful item, so I took it back out of /boot/cmdline.txt and out of
> > some of the x86 machines too, but I see its still in as an =1 on the
> > two atom boards out in the shop.  The one I removed it from hasn't
> > indicated any unhappiness with that turn of events.
> >
> > Perhaps Sebastian or someone more familiar with it can shine a light
> > on us here? As in has it been deprecated on all arches. I still have
> > 2 D525MW's with it in effect. And htop cannot see any usage of cpu-1
> > on either of those 2 boxes.
>
> Yes, isolcpus=X is the way to do that. However, doing so means that
> the kernel never schedules anything on the core automatically. You
> must set the thread/process affinity in the running code, using a
> syscall, to move a specific thread/process onto that isolated core.
> Otherwise, it will be idle all the time.

When I awoke about sunup, I had a message from amanda. I gad left lcnc 
running when I came in for the and the pi apparently crashed very 
quickly when amanda tried to access it.

So when I ran down at restoring it today, with 8 wires yet to hook up 
verify I have them right, and I'll be at the same place I was, 
everything running nicely, the morning of May 2, but I shut lcnc down 
before hitting the light switch and closing the garage door for the 
night. On my feet a good share of the day, I'll pay for it in the night 
with leg cramps. I'll take an extra big b12 pill, which sometimes helps 
because metformin flushes b12 out into a big white bowl. :)

I did write the new image to a card, but have not had the time to go into 
it, setting hostnames, hosts etc, yadda, yadda yet.  And killing 
anything that can over-write /etc/resolv.conf thereby keeping my local 
network running on the pi like it runs on everything else.

I did plug in that terabyte HD and had mc update the linuxcnc tree 
already on that drive from a couple weeks ago, and its still plugged in.

And I'm bushed, but progress has been made.  Curious, before I quit, I 
fired up the scope and looked at everything I had hooked up the last 3 
days, and was amazed!  Whereas the old lashup was attacking the 7i90 
with switching noises up in the 90+ mhz range, at peak voltages of 30+ 
volts before it hit any wire by wire filtering I'd been building, if 
there is any noise there now, its well under 50 millivolts and I can't 
see it on the analog scope at all. This was with the vfd up and running, 
spinning the chuck at about 225 rpms.  And yet every cable I am hooking 
up is coming into the bottom of the motor drivers box, thru it just as 
before. The cpu/controller box is insulated from the power box, and only 
connected to the single point ground by one braided strap, which I had 
to cover with shrink tubing because it was touching the spinx1 which I'd 
remounted on the inside of the door.  Didn't blow anything but the vfd 
was going crazy when I moved the boxes door, which now has the pi & 
controller box on the outside of the door.

Thanks Bertho, a lot.

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 

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

[Emc-users] LinuxCNC 2.7.9 released

2017-06-03 Thread Sebastian Kuzminsky 

LinuxCNC 2.7.9 is released.  This release fixes some obscure bugs and
adds a couple of new features:

* A driver for Mitsubishi VFDs.
* Support for "auxiliary applications", such as NativeCam, that are
  distributed separately from LinuxCNC.
* Add a "Integrator's Manual", a work in progress with helpful
  information on how to build your own CNC machine.


Special shout out to *two* first-time committers in this release (we
hope to see more of you in the future!):

* Alexander Brock
* Joe Hildreth


And as always, thanks to our awesome community of helpers and
bug-reporters, and to the usual list of long-time committers:

* Andy Pugh
* Chris Morley
* Chris Radek
* Dewey Garrett
* Jeff Epler
* John Thornton
* Jon Elson
* Norbert Schechner
* Sebastian Kuzminsky


The full changelog:

  * support "auxiliary apps", distributed separately from LinuxCNC

  * docs: add a bit more info to position feedback ini setting
  * docs: sort board list in hm2_eth manpage
  * docs: fix pyvcp multi label description
  * docs: fix pyvcp example so it runs
  * docs: clarify return value in hal_pin_new(3) manpage
  * docs: add missing var section to index header
  * docs: add machine building info to integrator document
  * docs: add manpage for hal_parport realtime component
  * docs: add units info to halui max-velocity pins in manpage
  * docs: flesh out max-velocity pins in halui manpage
  * docs: fix incorrect info for stat.motion_type and stat.motion_mode
  * docs: code notes: a pose has 9 coordinates, not 6
  * docs: add hal_manualtoolchange manpage
  * docs: add info about remap debug messages
  * docs: fix paraport/parport typos
  * docs: fix pin names in thcud manpage example HAL config
  * docs: clean up the note about T0 handling
  * docs: add some info for the hal python module
  * docs: clarify an ambiguity about siggen in the HAL documentation
  * docs: add information about addf command in the HAL documentation
  * docs: add details on epp_dir command line parameter of hal_ppmc
  * docs: remove a footnote about the behavior of emc2 v2.4
  * docs: add or2 example
  * docs: fix description of USER_DEFINED_FUNCTION_MAX_DIRS in
ini-config
  * docs: clarify g28/30 description
  * docs: add link to G54-G59.3 User Coordinates section
  * docs: clean up Machine Coordinate System section
  * docs: remove M6 from modal group description
  * docs: add links to machine origin from several places
  * docs: fix typos and markup problems all over
  * docs: add more information about the addf command
  * docs: sorted gmoccapy video links with headlines
  * docs: add a known problem with macros to gmoccapy docs
  * docs: fix cut-n-paste bug in mb2hal manpage
  * docs: expand on different ways of starting LinuxCNC
  * docs: document some features of the Axis GUI
  * docs: add info about the basic directory structure
  * docs: correct misleading descriptions of named parameters
  * docs: update info about 'save' command in halcmd manpage & help

  * Axis GUI: avoid unbounded memory growth in text widgets on stretch
  * Axis GUI: make tool info display widget larger
  * Axis GUI: remove unused .info.offset widget
  * Axis GUI: shorten tool touch off widget title text
  * gmoccapy GUI: removed unused code
  * gmoccapy GUI: added get_joints_amount() for compatibility 2.7 and
master
  * gmoccapy GUI: new hal pin gmoccapy.ignore-limits
  * gmoccapy GUI: bug if no macros in ini file
  * gmoccapy GUI: bug in macro button handling
  * gmoccapy GUI: G96 bug solved
  * gscreen GUI: fix missing .themes folder error
  * halui: fix halui.program.run

  * gladeVCP: make CombiDRO compatible for both 2.7 and master
  * gladeVCP: fix delta scale pin not updating if wheel scroll used
  * gladeVCP: add missing icon image for hal_dial

  * pncconf: fix spindle command using wrong signal name
  * pncconf: fix sserial mode setting in HAL file

  * hal_ppmc: add command line arg to turn on/off port direction change

  * mitsub_vfd: add a driver for Mitsubishi VFDs

  * classicladder: fix sequential variable access
  * classicladder: fix whitespace errors

  * ilowpass: round the output instead of truncating

  * halcmd: waitusr: avoid race condition

  * hm2: better error message on unexpected pin descriptors
  * hm2_eth: don't segfault on interfaces without addresses

  * linuxcnc python module: add doc string for stat.motion_mode
  * linuxcnc python module: add doc string for stat.motion_type
  * linuxcnc python module: add a doc string for
stat.queued_mdi_commands
  * linuxcnc python module: add EMC_MOTION_TYPE_* constants

  * hal python module: better doc strings for connect() and new_sig()

  * Interp: fix a typo in a cutter-comp error message
  * Task: set the stat struct member queuedMDIcommands

  * example g-code: fix Z value reported by rectangle_probe.ngc
  * example configs: fix hal pin names in gmoccapy_plasma
  * example configs: limit led without off color in gmoccapy_plasma
  * example configs: xhc-hb04.tcl: if prior

Re: [Emc-users] Question on thread geometry

2017-06-03 Thread Gene Heskett 
On Saturday 03 June 2017 10:08:47 tom-...@bgp.nu wrote:

> > On Jun 3, 2017, at 7:16 AM, Gene Heskett 
> > wrote:
> >
> >
> > What then is the effect of g7/g8 on g76?
>
> Gene,
>
> According to the G76 man page:
>
> "Note:
> When G7 Lathe Diameter Mode is in force the values for I, J and K are
> diameter measurements. When G8 Lathe Radius Mode is in force the
> values for I, J and K are radius measurements."
>
> Also, according to that page it claims that it is an error if the
> active plane is not the ZX plane.  As I mentioned in a previous email,
> I set G18 in the script we are running but Linuxcnc/G76 seem hell bent
> on putting the machine in G17.
>
> -Tom

IIRC g17 is xy, perhaps since the joints merge conversion you have a 
ghost joint in the configuration?  The interactions can be "strange", 
although I'll plead to using more "colorfull" words to describe it when 
it hits.

TLM is now behaving itself but I did have adjust a few things in that 
dept after the joints merge.  From its present .ini file: 

varname section HEADER:
.ini:JOG_AXES   =   ZX  [DISPLAY]
.ini:GEOMETRY   =   XZ  [DISPLAY]
.ini:COORDINATES=   XZ  [TRAJ]
.ini:KINEMATICS =   trivkins "coordinates=XZ"   [KINS]

And:
[RS274NGC]
PARAMETER_FILE = linuxcnc.var
RS274NGC_STARTUP_CODE=G8 G18 G21 G40 G49 G64 P.005 Q.005 G80 G90 G94 G97

best read with a monospaced font.

The reversed order in the first line above "JOG_AXES" is so the jogging 
works from the correct keyboard keys both BEFORE and after being homed.

Does this help?

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 

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

Re: [Emc-users] Question on thread geometry

2017-06-03 Thread tom-emc 

> On Jun 3, 2017, at 7:16 AM, Gene Heskett  wrote:
> 
> 
> What then is the effect of g7/g8 on g76?

Gene,

According to the G76 man page:

"Note:
When G7 Lathe Diameter Mode is in force the values for I, J and K are diameter 
measurements. When G8 Lathe Radius Mode is in force the values for I, J and K 
are radius measurements."

Also, according to that page it claims that it is an error if the active plane 
is not the ZX plane.  As I mentioned in a previous email, I set G18 in the 
script we are running but Linuxcnc/G76 seem hell bent on putting the machine in 
G17.

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

Re: [Emc-users] Question on thread geometry

2017-06-03 Thread tom-emc 

> On Jun 3, 2017, at 5:17 AM, andy pugh  wrote:
> 
> On 3 June 2017 at 01:11,   wrote:
>> However, what we were seeing (and have seen multiple times now but cannot 
>> yet re-create at will) is that even though our routine is commanding say, a 
>> diameter of .324, the DRO in Axis is showing the cutter down below that.  
>> Meaning there is a disconnect between the commanded position and where the 
>> machine is really is.
> 
> Are you displaying commanded or actual position? ie, is the axis not
> where LinuxCNC commands it to be, or is LinuxCNC not commanding the
> numbers from your G76 command?

The DRO is showing the actual position.  I am pretty sure the commanded 
position from G76 is being sent correctly, at least when this problem is NOT 
happening it works fine.  I am going to try cutting some more today and will 
see if I encounter this issue again, though I am not sure what I should look at 
when it is happening?
> 
> The G76 code is here:
> https://github.com/LinuxCNC/linuxcnc/blob/9e4641a816ab8fe4f6a09a48fac550cc8aef1dee/src/emc/rs274ngc/interp_convert.cc#L4590
> 
> That seems quite explicit:
> double end_depth = fabs(k_number) + fabs(i_number);
> 
> And the last moves are cut at start_x - end_depth

We were talking about looking at the G76 code to see what it was doing, thanks 
for the pointer to it.

-Tom

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


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

Re: [Emc-users] Question on thread geometry

2017-06-03 Thread Gene Heskett 
On Saturday 03 June 2017 05:17:43 andy pugh wrote:

> On 3 June 2017 at 01:11,   wrote:
> > However, what we were seeing (and have seen multiple times now but
> > cannot yet re-create at will) is that even though our routine is
> > commanding say, a diameter of .324, the DRO in Axis is showing the
> > cutter down below that.  Meaning there is a disconnect between the
> > commanded position and where the machine is really is.
>
> Are you displaying commanded or actual position? ie, is the axis not
> where LinuxCNC commands it to be, or is LinuxCNC not commanding the
> numbers from your G76 command?
>
> The G76 code is here:
> https://github.com/LinuxCNC/linuxcnc/blob/9e4641a816ab8fe4f6a09a48fac5
>50cc8aef1dee/src/emc/rs274ngc/interp_convert.cc#L4590
>
> That seems quite explicit:
> double end_depth = fabs(k_number) + fabs(i_number);
>
> And the last moves are cut at start_x - end_depth

I've used g76 in odd ways and while the operation was going faster than 
the screen DRO updates could track, I haven't been able to touch off at 
a known diameter, and cut thread based on the pure math entered. And 
sitting here waiting for my coffee to goto work, I am wondering if there 
is a g7/g8 interaction thats messing with me?  So I commonly start big, 
and for externals touch off by small increments until the fit is usable.
That was obviously by small, about 2 thou increments when I was doing the 
50 tpi threads in the x drive for the sheldon. 50 tpi because the walls 
were thin & I didn't want to weaken it by using a coarser, deeper  
thread. It also allowed bearing zero clearance much easier to adjust. 
That seems to be holding well as I set it to zero by feel, and the dial 
says the backlash is a hair over a thou. I can live with that.

And it sure as tooting beat the nominally 90 thou I started with.  The 
screw was good, but the nut was a cobbled up mess, had a helicoil insert 
in it, running on a square thread screw.  And the helicoil was less than 
5 thou from being worn and stripped again. I am assuming, never having 
asked John Knox if the nuts were available, that one would have to make 
his own replacements.  Since I had a small ball screw & nut, that was 
the obvious choice. I found some oversized balls on ebay, and restuffed 
the nuts for nearly zero lash.

What then is the effect of g7/g8 on g76?

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 

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

Re: [Emc-users] Question on thread geometry

2017-06-03 Thread andy pugh 
On 3 June 2017 at 01:11,   wrote:
> However, what we were seeing (and have seen multiple times now but cannot yet 
> re-create at will) is that even though our routine is commanding say, a 
> diameter of .324, the DRO in Axis is showing the cutter down below that.  
> Meaning there is a disconnect between the commanded position and where the 
> machine is really is.

Are you displaying commanded or actual position? ie, is the axis not
where LinuxCNC commands it to be, or is LinuxCNC not commanding the
numbers from your G76 command?

The G76 code is here:
https://github.com/LinuxCNC/linuxcnc/blob/9e4641a816ab8fe4f6a09a48fac550cc8aef1dee/src/emc/rs274ngc/interp_convert.cc#L4590

That seems quite explicit:
double end_depth = fabs(k_number) + fabs(i_number);

And the last moves are cut at start_x - end_depth

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

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