Re: [Emc-users] Programmer for a serial EEPROM?

[Philipp Burch]

Hi Greg,

I would assume that this naming difference does not matter, as it seems
to only affect the package. You could give this datasheet a try:

http://datasheet.datasheetarchive.com/originals/library/Datasheets-SW21/DSASW00417843.pdf

or

http://www.farnell.com/datasheets/1918295.pdf

On page 74 or 71, respectively, 25Q80BVAIG is listed as top side marking
for the W25Q80BVDAIG, i.e. PDIP, industrial temp, green package.

Regards,
Philipp

On 05.06.2017 23:00, Gregg Eshelman wrote:
> I need to reprogram a Winbond 25Q80BVAIG serial EEPROM. It's an 8 pin
> DIP. I've found some cheap ($5 or less) Chinese programmers on eBay with
> a ZIF socket and USB. Dunno if they'll work for this chip.
> 
> Been trying to find a datasheet but Google and friends insist I cannot
> read the characters off the chip and will only give me results for a
> 25Q80BVSIG, or other strings of characters in varying degress of not
> what I entered.
> 
> It IS a 25Q80BVAIG, I've found plenty of clear images of chips with that
> and it's turned up in lists on sites offering them for sale. Dunno why
> the search engines have to be so idiotically "helpful".
> 
> --
> 
> 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



signature.asc
Description: OpenPGP digital signature
--
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] Programmer for a serial EEPROM?

[Gregg Eshelman]

I need to reprogram a Winbond 25Q80BVAIG serial EEPROM. It's an 8 pin 
DIP. I've found some cheap ($5 or less) Chinese programmers on eBay with 
a ZIF socket and USB. Dunno if they'll work for this chip.


Been trying to find a datasheet but Google and friends insist I cannot 
read the characters off the chip and will only give me results for a 
25Q80BVSIG, or other strings of characters in varying degress of not 
what I entered.


It IS a 25Q80BVAIG, I've found plenty of clear images of chips with that 
and it's turned up in lists on sites offering them for sale. Dunno why 
the search engines have to be so idiotically "helpful".


--
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] won't start on line 310 (run from here)

[Stuart Stevenson]

Gentlemen,

Debian Wheezy
latest linuxcnc release - installed today - but the last release did the
same thing
Axis interface
Kasuga 3 axis mill

when starting (run from here) on line 310 I get the error "length of cutter
compensation entry move is not greater than the tool radius"

This only happens when I 'run from here'.
When running through the program the machine runs this code just fine. I
cannot run through the program as I must change tools in the holder - set
the tool length - and - start by picking 'run from here' (right click on
the mouse).

status window shows G40 prior to initiating 'run from here'
after initiating 'run from here' the error shows and the status window
shows G41
mdi g40 resets the status window
reinitiation of 'run from here' shows the error and sets the status window
to G41

Editing the G41 and G40 out of the program allows 'run from here' to start
the machine and run the tool.

snippet of code from the program

N288X.1684Y-.6104
N289G01Z.105F100.0
N290G41X.0024F4.0
N291Y-1.428
N292G40
N293X.1024
N294G00Z1.115
N295M05
N296M09
N297G91G28Z.0
N298(MSG)
N299(MSG TOOL T4. IS)
N300(MSG DIA0.5000)
N301(MSG CRAD   0.)
N302(MSG FLTLEN 0.2500)
N303(MSG STKOUT 0.5000)
N304(MSG)
N305(MSG 1/2 SPOT DRILL.)
N306(MSG)
N307(MSG SPOT DRILL HOLE)
N308(MSG)
N309(MSG)
N310G91G49G28Z.0
N311T04M06
N312G64P.001
N313G90G00G43
N314S1400M08
N315X1.375Y-3.0M03
N316Z1.115
N317X-.3Y-.1
N318G81X-.2Y-.2Z.075R.275F2.0
N319G80M05
N320M09
N321G91G28Z.0

thanks
Stuart




-- 
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.
--
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] RPI saga continues - SPI probably solved

[Peter C. Wallace]

On Mon, 5 Jun 2017, Bertho Stultiens wrote:


Date: Mon, 5 Jun 2017 16:20:03 +0200
From: Bertho Stultiens 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] RPI saga continues - SPI probably solved

On 06/04/2017 06:15 AM, john mcintyre wrote:

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


Isn't this what you call a challenge?


Anyway, I've fixed a couple of things, like endianness, which I did
wrong in the previous versions. This implementation is hard-coded to use
the RPI hardware peripherals. Also, you can now attach to SPI0 or SPI1
ports on the 40-pin header and you may choose any CE line you wish
(updated man page also attached).

My tests so far have seen stable results, timing wise, although I cannot
test functionally on a real system (lacking a 7i90 in my inventory).
Though, the timing has improved with respect to the original version.

Read and write SPI clock frequencies may be different now. This will
help to overcome the SPI round-trip delay while reading (just lower the
read frequency setting), or when you want buffers on the SPI lines.

So, if anybody wants to have a go and test this, please do so and tell
me how it goes. In the meantime... need to get my hands on a 7i90 (and
upgrade the mill at the local hackerspace).

--
Greetings Bertho

(disclaimers are disclaimed)



Thank you for working on this! The ability to set the clock speed should be 
especially valuable. It means I can make a Async SPI interface version of the 
firmware (as opposed to the current hardware clocked version), that 
oversamples/digital filters the input data and clock for better noise 
resistance. This will probably require lowering the SPI clock to say 16 MHz

to accomodate the increased turnaround delays from the digital filtering.

Peter Wallace
Mesa Electronics


--
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] Axis Bug in Master?

[Todd Zuercher]

I was playing with Master some more. 
I think there is a bug in how Axis handles jogging a 4th axis when it is not 
homed when that axis is not an "A" axis, and using identity kins. (not a 
problem in joint mode) 
After it is homed it behaves fine, but when it is not homed trying to jog the 
4th axis, no matter what letter B-W axis has been assigned to it, trying to jog 
using the onscreen buttons in Axis gives this message to the terminal window. 
Exception in Tkinter callback 
Traceback (most recent call last): 
File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1437, in __call__ 
return self.func(*args) 
File "/usr/bin/axis", line 2493, in jog_plus 
speed = get_jog_speed(a) 
File "/usr/bin/axis", line 1733, in get_jog_speed 
if joint_type[a] == 'LINEAR': 
IndexError: list index out of range 

I get the same results with my own machine configs, and the simplest sim.axis 
config modified for 4 axis. 
-- 

 

Todd Zuercher 
mailto:zuerc...@embarqmail.com 

 
--
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] RPI saga continues - SPI probably solved

[Bertho Stultiens]

On 06/04/2017 06:15 AM, john mcintyre wrote:
> Your saga continues, you must be related to a bulldog ,once locked
> on  it cannot let go.

Isn't this what you call a challenge?


Anyway, I've fixed a couple of things, like endianness, which I did
wrong in the previous versions. This implementation is hard-coded to use
the RPI hardware peripherals. Also, you can now attach to SPI0 or SPI1
ports on the 40-pin header and you may choose any CE line you wish
(updated man page also attached).

My tests so far have seen stable results, timing wise, although I cannot
test functionally on a real system (lacking a 7i90 in my inventory).
Though, the timing has improved with respect to the original version.

Read and write SPI clock frequencies may be different now. This will
help to overcome the SPI round-trip delay while reading (just lower the
read frequency setting), or when you want buffers on the SPI lines.

So, if anybody wants to have a go and test this, please do so and tell
me how it goes. In the meantime... need to get my hands on a 7i90 (and
upgrade the mill at the local hackerspace).

-- 
Greetings Bertho

(disclaimers are disclaimed)
/*This is a component for RaspberryPi to hostmot2 over SPI for linuxcnc.
 *Copyright 2016 Matsche 
 *Copyright 2017 B.Stultiens 
 *
 *This program is free software; you can redistribute it and/or modify
 *it under the terms of the GNU General Public License as published by
 *the Free Software Foundation; either version 2 of the License, or
 *(at your option) any later version.
 *
 *This program is distributed in the hope that it will be useful,
 *but WITHOUT ANY WARRANTY; without even the implied warranty of
 *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *GNU General Public License for more details.
 *
 *You should have received a copy of the GNU General Public License
 *along with this program; if not, write to the Free Software
 *Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */

/* Without Source Tree */
#undef WOST

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include "hal.h"
#include "rtapi.h"
#include "rtapi_app.h"

#include "rtapi_stdint.h"
#include "rtapi_bool.h"
#include "rtapi_gfp.h"
#include "rtapi_slab.h"

#include "rtapi_bool.h"

#if defined (WOST)
#include "include/hostmot2-lowlevel.h"
#include "include/hostmot2.h"
#else
#include "hostmot2-lowlevel.h"
#include "hostmot2.h"
#endif

#include "spi_common_rpspi.h"

//#define RPSPI_DEBUG		1	// Uncomment for debugging
#define RPSPI_DEBUG_WRITE	1	// Debug write command before cookie probe

#if defined(RPSPI_DEBUG)
#define RPSPI_DEBUG_PIN		23	// Debug timing on GPIO 23
#endif

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Matsche");
MODULE_DESCRIPTION("Driver for HostMot2 devices connected via SPI to RaspberryPi");
MODULE_SUPPORTED_DEVICE("Mesa-AnythingIO-7i90");

#define MAX_BOARDS	5
#define MAX_MSG		512		// FIXME: The 7i90 docs say that the max. burstlen == 127 (i.e. cmd+message <= 1+127)

// GPIO pin definitions
#define SPI0_PIN_CE_1	7
#define SPI0_PIN_CE_0	8
#define SPI0_PIN_MISO	9
#define SPI0_PIN_MOSI	10
#define SPI0_PIN_SCLK	11
#define SPI1_PIN_CE_2	16		// AUX SPI0 in docs
#define SPI1_PIN_CE_1	17
#define SPI1_PIN_CE_0	18
#define SPI1_PIN_MISO	19
#define SPI1_PIN_MOSI	20
#define SPI1_PIN_SCLK	21

typedef struct hm2_rpspi_struct {
	hm2_lowlevel_io_t llio;		// Upstream container
	int		nr;		// Board number
	uint32_t	spiclkratew;	// SPI write clock for divider calculation
	uint32_t	spiclkrater;	// SPI read clock for divider calculation
	uint32_t	spiclkbase;	// SPI base clock for divider calculation
	uint32_t	spice;		// Chip enable mask for this board
	int		spidevid;	// The SPI device id [01]
	int		spiceid;	// The SPI CE id [012]
} hm2_rpspi_t;

typedef enum {
	RPI_UNSUPPORTED,
	RPI_1,		// Version 1
	RPI_2		// Version 2 and 3
} platform_t;

static uint32_t *peripheralmem = (uint32_t *)MAP_FAILED;	// mmap'ed peripheral memory
static size_t peripheralsize;	// Size of the mmap'ed block
static bcm2835_gpio_t *gpio;	// GPIO peripheral structure in mmap'ed address space
static bcm2835_spi_t *spi;	// SPI peripheral structure in mmap'ed address space
static bcm2835_aux_t *aux;	// AUX peripheral structure in mmap'ed address space
static uint32_t aux_enables;	// Previous state of SPI1 enable
static platform_t platform;	// The RPI version

static hm2_rpspi_t boards[MAX_BOARDS];	// Connected boards
static int comp_id;			// Upstream assigned component ID

/*
 * Configuration parameters
 */
static char *config[MAX_BOARDS];
RTAPI_MP_ARRAY_STRING(config, MAX_BOARDS, "config string for the AnyIO boards (see hostmot2(9) manpage)")

/*
 * RPI3 NOTE:
 * The SPI frequency is wildly variable when the ondemand cpufreq governor is
 * active. This may result in changing SPI frequencies depending on the system

Re: [Emc-users] Question on thread geometry

[tom-emc]

My numbers are similar (not exactly the same):

Major Dia: 0.3678
Minor Dia: 0.3239
Thread Depth:  0.2555

I am measuring with thread wires (0.029 dia) and am trying to get a pitch dia 
of between 0.3468 and .3430 (class 2A or better).

-Tom


> On Jun 5, 2017, at 5:30 AM, andy pugh  wrote:
> 
> On 5 June 2017 at 02:22,  wrote:
> 
>> Currently I do that by cutting a diameter with the threading tool.  I
>> measure that with a micrometer and I enter the DRO value in the tool touch
>> off for that tool (I have a routine that leaves the tool at the diameter
>> after cutting so this works).  But I am wondering, I don’t have a DIAMETER
>> value in the tool table for the tool.  Should I?  Is a zero (or
>> non-existant) radius value causing Linuxcnc to think the tool is longer
>> than it really is when cutting?
> 
> 
> How do your numbers compare with line 502 of this spreadsheet?
> https://docs.google.com/spreadsheets/d/1m5zkO9-SbQaYWbTPlQXJ2VA73Ys8WgWDrPk_rEukHc0/edit?ts=57064122#gid=0
> 
> (This is a version of the table I complied 20 years or so ago, but modified
> to include the effects of crest and root flattening/rounding)
> 
> The DXF file of the inserts shows a 0.05mm radius, whereas as the web-page
> table shows 0.06mm. In either case the tip is rounded, not flat.
> 
> You might consider drawing the thread in CAD, with the exact profile for
> the thread and grade required, and then fit an exact drawing of the insert
> into it. That might answer the question of how to touch-off and what to.
> 
> It is an interesting puzzle, and I am another who will admit to "creeping
> up" on one-off threads.
> 
> -- 
> 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

[Gene Heskett]

On Monday 05 June 2017 05:30:10 andy pugh wrote:

> On 5 June 2017 at 02:22,  wrote:
> > Currently I do that by cutting a diameter with the threading tool. 
> > I measure that with a micrometer and I enter the DRO value in the
> > tool touch off for that tool (I have a routine that leaves the tool
> > at the diameter after cutting so this works).  But I am wondering, I
> > don’t have a DIAMETER value in the tool table for the tool.  Should
> > I?  Is a zero (or non-existant) radius value causing Linuxcnc to
> > think the tool is longer than it really is when cutting?
>
> How do your numbers compare with line 502 of this spreadsheet?
> https://docs.google.com/spreadsheets/d/1m5zkO9-SbQaYWbTPlQXJ2VA73Ys8Wg
>WDrPk_rEukHc0/edit?ts=57064122#gid=0
>
> (This is a version of the table I complied 20 years or so ago, but
> modified to include the effects of crest and root flattening/rounding)
>
> The DXF file of the inserts shows a 0.05mm radius, whereas as the
> web-page table shows 0.06mm. In either case the tip is rounded, not
> flat.
>
> You might consider drawing the thread in CAD, with the exact profile
> for the thread and grade required, and then fit an exact drawing of
> the insert into it. That might answer the question of how to touch-off
> and what to.
>
> It is an interesting puzzle, and I am another who will admit to
> "creeping up" on one-off threads.

Even the "creep up" can lead to fit problems. I cannot buy an insert 
truely suitable for cutting a 50 TPI thread, all are tip profiled for 
much coarser threads, and rarely is the tip profile correct for a thread 
3x finer than a 16 to 20 TPI thread.  So the nuts I might make for a 50 
TPI thread, I expect to have to drive with spanners, well lubed, as 
they'll need to round off the sharper tips of each the first time 
assembled.  Yet 3 trips later, they'll need some thread-locker magic to 
stay put.  Neither actually has a full bodied width of tooth. Whats 
needed is an HSS insert with a sharp tip that might be flattened about 
half a red one on a wet rouge stone. Cheap enough to bin when its dull 
w/o shedding a tear because the carbide version is so outragiously 
priced.  The insert makers are not serving the market with what the 
market needs.

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

[andy pugh]

On 5 June 2017 at 02:22,  wrote:

> Currently I do that by cutting a diameter with the threading tool.  I
> measure that with a micrometer and I enter the DRO value in the tool touch
> off for that tool (I have a routine that leaves the tool at the diameter
> after cutting so this works).  But I am wondering, I don’t have a DIAMETER
> value in the tool table for the tool.  Should I?  Is a zero (or
> non-existant) radius value causing Linuxcnc to think the tool is longer
> than it really is when cutting?


How do your numbers compare with line 502 of this spreadsheet?
https://docs.google.com/spreadsheets/d/1m5zkO9-SbQaYWbTPlQXJ2VA73Ys8WgWDrPk_rEukHc0/edit?ts=57064122#gid=0

(This is a version of the table I complied 20 years or so ago, but modified
to include the effects of crest and root flattening/rounding)

The DXF file of the inserts shows a 0.05mm radius, whereas as the web-page
table shows 0.06mm. In either case the tip is rounded, not flat.

You might consider drawing the thread in CAD, with the exact profile for
the thread and grade required, and then fit an exact drawing of the insert
into it. That might answer the question of how to touch-off and what to.

It is an interesting puzzle, and I am another who will admit to "creeping
up" on one-off threads.

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

Re: [Emc-users] Lubrication system

[andy pugh]

On 5 June 2017 at 02:52, Jon Elson  wrote:

> If this is truly designed for grease, then I really don't know anything
> about it.


Central greasing systems are sometimes seen on lorry chassis.
http://www.herglube.com/html/content/products/application/products_10/2014/1222/81.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, 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