Re: [Emc-users] chinese vfd is driving me bonkers.

[jrmitchellj]

I have an Eheim aquarium pump that has been running continuously for over
25 years!  It is a canister model.


--J. Ray Mitchell Jr.
jrmitche...@gmail.com
(818)324-7573


"Good enough is the enemy of excellence"author unknown


On Wed, Mar 27, 2019 at 7:01 PM Chris Albertson 
wrote:

> Yes,  I've used aquarium pumps.  the submersible pumps are good because
> they eliminate a problem if there is a leak. All of them are magnetic drive
> and water lubricated.  The best pumps, I think are made by Eheim.  Eheim is
> a German company and you might expect one of their pumps to run continosly
> 24x7 for 10 years or more.  These pumps are nearly selent.  It is hard to
> know it is is running unless you check the flow rate.  "There "universal"
> is the one to get.  They come in sizes to 3,400 liters per hour but you
> need the smallest size.  They have US pipe threads and can be disassembled
> by hand with no tools for cleaning.   They sell replacment parts.
>
> Quality is about what you would expect from a preiumum brand German made
> pump.  I am pretty surethey are all made in Germany, all of mine are.
>
> https://www.eheim.com/en_GB/products/technology/pumps/universal
>
> --
>
> Chris Albertson
> Redondo Beach, California
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

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

Re: [Emc-users] chinese vfd is driving me bonkers.

[MC Cason via Emc-users]

Gene,


  My local Lowes has fountain pumps from $20.00, to over $200.00.  Most 
of them are submersible, and run from 80gph, to over 800gph.



  Back in the day, when overclocking computers started becoming a 
thing, I've seen Little Giant submersible pumps used as coolant pumps.  
They worked well, but they are a bit on the pricey side.



---Mark

On 3/27/19 8:08 PM, Gene Heskett wrote:

On Wednesday 27 March 2019 16:39:10 Gene Heskett wrote:


While trying to get a reverse control over this POS, I noted that the
default was reversed, so I traded the 2 U & V wires to the motor to
make it run fwd.

This is toward the end of March, but as of this afternoon its default,
can't change it w/o moving UV again, is now its running bass ackwards
again.

Then, I note after I had unplugged the hoses from the pump in order to
re-route them thru the new cable chains, that the pump wasn't.  Power
is being switched on queue..

Pull pump out of water, note its slightly warm. Made sure power was
off and popped the end covers, discover its a PM armature with pretty
strong cogging. Put front cover back on as its also the front bearing.
  Apply power, and 8 or 10 pokes at turning it, It takes off again. Its
not stiff or dragging. Stop AC to it, stops, start it, runs. Several
times. So obviously it can't be trusted.

I've a mind to just order another pump and a vfd.  I am plumb sick of
screwing with this documentless piece of Chinese shit vfd. I want to
actually USE it before I fall over...


I found a 110 volt 3hp vfd on fleabay for a good price, but ATM there is
NOT a single 110 volt submersible spindle coolant pump listed.

Everything they show has 220 on its makers label, but the only label on
this one says 110 volts & looks like it came from a brother labelmaker.
The instant you mention 110 volt, fleabay thinks its looking at 500 hp
Western Roller irrigation pumps or the like.  Only weigh a ton or so.
Water a square mile of irrigated land from a 36" hole into the Morrison
Acquifier, now damned near dry and 700+ feet down. 300 could reach it in
the early 70's.

Damn I wish fleabay actually had a search engine.

Cheers, Gene Heskett


Cheers, Gene Heskett




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

Re: [Emc-users] chinese vfd is driving me bonkers.

[Chris Albertson]

Yes,  I've used aquarium pumps.  the submersible pumps are good because
they eliminate a problem if there is a leak. All of them are magnetic drive
and water lubricated.  The best pumps, I think are made by Eheim.  Eheim is
a German company and you might expect one of their pumps to run continosly
24x7 for 10 years or more.  These pumps are nearly selent.  It is hard to
know it is is running unless you check the flow rate.  "There "universal"
is the one to get.  They come in sizes to 3,400 liters per hour but you
need the smallest size.  They have US pipe threads and can be disassembled
by hand with no tools for cleaning.   They sell replacment parts.

Quality is about what you would expect from a preiumum brand German made
pump.  I am pretty surethey are all made in Germany, all of mine are.

https://www.eheim.com/en_GB/products/technology/pumps/universal

-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] SPI comms for linuxcnc (was Re: Rock64 pre-orders on Banggood.)

[TJoseph Powderly]

Hello Gene

I always forget some context...

In my use of the RPi and SPI and stacking connectors ( there, that's the 
context )

I have SPI devices connected thru the 40pin stacking header
so my paths are very short and solid.

Theres topological problems with the stacking connectors
but SPI routes are very short.
( some one list referred to the 'sandwich' problem of these 
microcontrollers )


I have the RPi3B and two protoboards with MCP23s17's stacked,
then short jumpers to the PICnc stepgen.
I use the 'extender' style 40pin headers, gold plated.

I dont know how tall the stack can grow before signals degrade.

re: the topology
I tried to invert the 40 pin connector
that is, to move it to bottom of RPi
so the heatsinks and fan on top side didnt bother the stacking
It was a mess, too hard to remove it :-(

I considered a board to just breakout just the spi pins.
But for the RPi's , a generic SPI driver is needed ( talks _to_ many/any 
devices).
And for the LinuxCNC community, a generic SPI driver that talks _from_ 
many hosts is needed.


Thats another problem, can a comp have its own modules?
Like, can a generic SPI host comp have specific client sub-comps?
How to talk to different devices with same protocol?

I cant right now, I'm attempting python calls to use the MCP23s17 i/o,
its slow and non-realtime if I cant swing it, but for buttons, relays 
and lights, thats ok.


BTW: Theres 2 spi buses on the rpi3b
one SPI0 has 2 chip selects the other has 3 SPI1.

tomp

On 03/28/2019 02:49 AM, Gene Heskett wrote:

On Wednesday 27 March 2019 14:03:33 Nicklas Karlsson wrote:


On Wed, 27 Mar 2019 19:12:48 +0700

TJoseph Powderly  wrote:

( list apology, I seem to have replied to posters rather than to the
list, and several times :-(

re SPI comms Linuxcnc SBC microcontrollers ...

it has been said on this mail list,
that SPI is a good candidate for a bus technology to work _with_
realtime.

Maybe not as a bus but chip select between devices over a short
distance work. Isolation is possible but delay may cause problem at
high speed. If drivers are kept close together and there are not to
many of them which likely to be the case it is a good candidate.

CANopen is available for ordinary CAN networks and over Ethercat. SDO
protovol may be a very good candidate for configuration to get a more
or less standard format, *.eds files may be used as a standard
dictionary format, expedited transfer of up to 32 bit at a time is
relatively simple to implement, to add a sequence number might be a
good idea so that severel messages could be on the the they thru the
system but for configuration to wait a short while is OK since there
usually only is a need for a few numbers. I have som code is somenone
need it. PDOs are simple if harcoded, mapping and communication
parameters are harder but may not be needed for a working system.

SPI is very common on Micro controllers, cheap and fast but only over
very short distances, there certainly are limitations.


Qualify very short distance to include up to 8" long although it wasn't
as bulletproof at a lower speed as I was using 8" pin to pin jumpers and
no termintors.  Now my cable is a legit ribbon and about an inch. And
Jon E's little terminator board adds a little under an inch to that. At
that distance, its bulletproof.


heres some work in that vein (maybe overlooked)

yeltrow's work:
a generic spi hal module so you can use other SPI devices ( rpi,
arduino, mcp23s17, ENC28J60, theres a lot of spi stuff to hang onto
such a bus )
https://www.forum.linuxcnc.org/24-hal-components/28851-spi-bus-gener
ic-driver-and-st-l6480

the files are on the forum for members
linuxcnc-upload-2015-12-03.tar

erste's work:
for ethernet circumventing usb ( via spi
interesting as spi and ethernet seem to be future avenues
http://erste.de/ethraw/README

theres other efforts but less coupled to the spi grail

tomp


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


Cheers, Gene Heskett




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

Re: [Emc-users] SPI comms for linuxcnc (was Re: Rock64 pre-orders on Banggood.)

[andy pugh]

On Thu, 28 Mar 2019 at 01:07, TJoseph Powderly  wrote:

> My RIP source tree is DGarr's external offset branch.
>
> I dont have raspi.kp either.
>
> Where are these files?

He means hm2_rpspi

-- 
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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] chinese vfd is driving me bonkers.

[Gene Heskett]

On Wednesday 27 March 2019 16:39:10 Gene Heskett wrote:

> While trying to get a reverse control over this POS, I noted that the
> default was reversed, so I traded the 2 U & V wires to the motor to
> make it run fwd.
>
> This is toward the end of March, but as of this afternoon its default,
> can't change it w/o moving UV again, is now its running bass ackwards
> again.
>
> Then, I note after I had unplugged the hoses from the pump in order to
> re-route them thru the new cable chains, that the pump wasn't.  Power
> is being switched on queue..
>
> Pull pump out of water, note its slightly warm. Made sure power was
> off and popped the end covers, discover its a PM armature with pretty
> strong cogging. Put front cover back on as its also the front bearing.
>  Apply power, and 8 or 10 pokes at turning it, It takes off again. Its
> not stiff or dragging. Stop AC to it, stops, start it, runs. Several
> times. So obviously it can't be trusted.
>
> I've a mind to just order another pump and a vfd.  I am plumb sick of
> screwing with this documentless piece of Chinese shit vfd. I want to
> actually USE it before I fall over...
>
I found a 110 volt 3hp vfd on fleabay for a good price, but ATM there is 
NOT a single 110 volt submersible spindle coolant pump listed.

Everything they show has 220 on its makers label, but the only label on 
this one says 110 volts & looks like it came from a brother labelmaker. 
The instant you mention 110 volt, fleabay thinks its looking at 500 hp 
Western Roller irrigation pumps or the like.  Only weigh a ton or so.  
Water a square mile of irrigated land from a 36" hole into the Morrison 
Acquifier, now damned near dry and 700+ feet down. 300 could reach it in 
the early 70's.

Damn I wish fleabay actually had a search engine.
>
> Cheers, Gene Heskett


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



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

Re: [Emc-users] SPI comms for linuxcnc (was Re: Rock64 pre-orders on Banggood.)

[TJoseph Powderly]

Gene hello



On 03/27/2019 08:13 PM, Gene Heskett wrote:

On Wednesday 27 March 2019 08:12:48 TJoseph Powderly wrote:


( list apology, I seem to have replied to posters rather than to the
list, and several times :-(

re SPI comms Linuxcnc SBC microcontrollers ...

it has been said on this mail list,
that SPI is a good candidate for a bus technology to work _with_
realtime.

heres some work in that vein (maybe overlooked)

yeltrow's work:
a generic spi hal module so you can use other SPI devices ( rpi,
arduino, mcp23s17, ENC28J60, theres a lot of spi stuff to hang onto
such a bus )
https://www.forum.linuxcnc.org/24-hal-components/28851-spi-bus-generic
-driver-and-st-l6480


Interesting driver for the big stuffs. However, I wonder if yeltrow is
aware of rpspi.ko, now part of LCNC.  Not parport based but gpio,
written specificly for the rpi3b.  And I'm using it, writing to a Mesa
7i90 at 42 megabaud, and reading back from the 7i90 at 25 megabaud
useing only 4 gpio pins for 2 or 3  target devices.

I dont find source rpspi.c in my sources.
cant google it except to find messages from you.

My RIP source tree is DGarr's external offset branch.

I dont have raspi.kp either.

Where are these files?

The files I was speaking of were generic spi utilities,
not RPi to Mesa communication modules,
They were attempts to make SPI available on any hardware platform to any 
SPI device.
They are attempts only ( one uses a parport but i guess that could be 
altered to gpio )

But from the parport, the author connects to many different SPI devices.

What file builds rpspi.ko ?

Maybe its private/unpublished work from Matsche ?

I cant find it on https://github.com/LinuxCNC/linuxcnc either.

Plz lemmeno
TomP

Perusal of that code might be of help to yeltrow. gpio seems to be about
10x faster than trying to simulate SPI over a parport.  The 7i90 has
both modes depending on the firmware loaded.


the files are on the forum for members linuxcnc-upload-2015-12-03.tar

So this work handily predates rpspi.ko. Still, theres obviously things to
be learned from the rpi version.


erste's work:
for ethernet circumventing usb ( via spi
interesting as spi and ethernet seem to be future avenues
http://erste.de/ethraw/README

theres other efforts but less coupled to the spi grail

tomp


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

Cheers, Gene Heskett




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

Re: [Emc-users] Rock64 pre-orders on Banggood.

[Stuart Stevenson]

Rather than offload all the good stuff why isn't the kernel patching made
easier. There was a BDI at one time. It wasn't a bdi. It took professional
tweaking to make it run. Maybe a truly BDP for the kernel?

On Wed, Mar 27, 2019, 6:35 PM Alan Condit  wrote:

> I pulled the trigger on a RockPro64 4gb this morning. The RockPro64 has
> the Mali
> T860 gpu (supports OpenGL 3.2).
>
> I have a Pine64 A64+ 2gb. Just a couple of days ago, I built a preempt_rt
> kernel
> for it running on armbian Stretch.
>
> I cloned the raspberrypi/linux repository (it had the latest good arm
> sources).
> I downloaded the source for 4.19.25, I downloaded the patches 4.19.25 from
> kernel.org .
> At that time the latest patches for 4.19.y was 4.19.27. and applied the
> corresponding
> preempt_rt patch for it. I used the make menuconfig option.
> Now just a few days later the latest patches are for 4.19.31. They are
> working very hard
> to integrate preempt_rt into mainstream.
>
> Pine64’s A64+, Rock64 and RockPro64 are hardware options in the
> menuconfig. So far,
> I have had no problems that I can trace to the kernel.
>
> When my RockPro64 arrives I will try to build the preempt_rt kernel for it.
>
> Alan
>
> > From: TJoseph Powderly 
> > Subject: Re: [Emc-users] Rock64 pre-orders on Banggood.
> > Date: March 27, 2019 at 5:00:55 AM PDT
> > To: "Enhanced Machine Controller (EMC)"  >
> >
> >
> > for those interested because of 2nd ethernet
> >
> > this maybe useful:
> >
> > a pinout of the header used
> > and small discussion of the needed isolation trafo 'magjack'
> >
> > https://forum.pine64.org/showthread.php?tid=4898
> >
> >
> > also, re rt-preempt 64 bit on it...
> >  i see dev 'schooner' has done this
> > " |root@pine64:~# uname -a
> >
> > Linux pine64 4.9.6-rt4-p64-73261-g5fb7565 #2 SMP PREEMPT RT Wed Feb 8
> 07:45:02 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux"
> >
> > see end of thread at
> > https://forum.pine64.org/showthread.php?tid=394=5|
> >
> > hth
> > tomp
> >
> > i find it amusing that the header naming and advertising suggest this is
> pi5 compatible
> >
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

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

Re: [Emc-users] chinese vfd is driving me bonkers.

[Bruce Layne]

I've had reliable operation from Little Giant and Superior Electric
pumps as small coolant pumps.  The small pumps are not expensive so
there is no excuse for skimping on quality in my opinion.  Spindle
coolant is too important to take unnecessary risks on a pump of
questionable quality.  I particularly like the magnetic drive pumps. 
These are the sorts of pumps that people leave in a lily pond all year
long, pumping algae and koi carp crap sludge.

Here are a couple of eBay items you might want to consider.

254049597655
382673181410

The small Superior Electric pumps currently on eBay seemed to be imitations.

The worst part about using one of these small submersible pond or
fountain pumps is the plumbing.  They probably won't have the plastic
fitting you'll need.  You probably need 8mm internal diameter tubing for
the spindle motor and the pump's tube fittings are usually much larger. 
You may need to epoxy a fitting into the pump's outlet or tap one of
their plastic friction fittings.  The good news is, it's a submersible
pump, so it doesn't matter if the fitting leaks.

Sorry that I can't help you with the Chinese VFD.  I have a few similar
Chinese VFDs (two home brew CNC routers and a 3/4 HP CNC'd Clausing
lathe) and they all work well.  I bought them from eBay sellers with
good reputations.  For the two CNC routers, I bought the spindle motor
and VFD as a matched pair and they were perfectly configured from the
factory.  I needed to do a little programming on the lathe VFD, but the
registers were reasonably well documented in the manual and there are
YouTube videos that described how to configure a genuine Huanyang VFD
for an arbitrary sized spindle motor.  It wasn't difficult, but I
probably spent an hour fiddling with it.  It's handy to watch YouTube
videos like this on the LinuxCNC machine that I'm configuring.

It's sad that someone is selling what are essentially cut rate imitation
Huanyang VFDs.

PRO TIP:  The Huanyang VFDs emit a lot of EMI.  Preferably, use HDMI for
video.  If not, use the best shielded VGA cables you can buy.  Use
shielded continuous flex cable between the VFD and spindle motor and
ground the shield in the electrical panel.





On 3/27/19 4:39 PM, Gene Heskett wrote:
> While trying to get a reverse control over this POS, I noted that the 
> default was reversed, so I traded the 2 U & V wires to the motor to make 
> it run fwd.
>
> This is toward the end of March, but as of this afternoon its default, 
> can't change it w/o moving UV again, is now its running bass ackwards 
> again.
>
> Then, I note after I had unplugged the hoses from the pump in order to 
> re-route them thru the new cable chains, that the pump wasn't.  Power is 
> being switched on queue..
>
> Pull pump out of water, note its slightly warm. Made sure power was off 
> and popped the end covers, discover its a PM armature with pretty strong 
> cogging. Put front cover back on as its also the front bearing.  Apply 
> power, and 8 or 10 pokes at turning it, It takes off again. Its not 
> stiff or dragging. Stop AC to it, stops, start it, runs. Several times. 
> So obviously it can't be trusted.
>
> I've a mind to just order another pump and a vfd.  I am plumb sick of 
> screwing with this documentless piece of Chinese shit vfd. I want to 
> actually USE it before I fall over...
>
>
> Cheers, Gene Heskett




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

Re: [Emc-users] Rock64 pre-orders on Banggood.

[Alan Condit]

I pulled the trigger on a RockPro64 4gb this morning. The RockPro64 has the Mali
T860 gpu (supports OpenGL 3.2).

I have a Pine64 A64+ 2gb. Just a couple of days ago, I built a preempt_rt 
kernel 
for it running on armbian Stretch.

I cloned the raspberrypi/linux repository (it had the latest good arm sources).
I downloaded the source for 4.19.25, I downloaded the patches 4.19.25 from 
kernel.org . 
At that time the latest patches for 4.19.y was 4.19.27. and applied the 
corresponding 
preempt_rt patch for it. I used the make menuconfig option. 
Now just a few days later the latest patches are for 4.19.31. They are working 
very hard
to integrate preempt_rt into mainstream.

Pine64’s A64+, Rock64 and RockPro64 are hardware options in the menuconfig. So 
far,
I have had no problems that I can trace to the kernel.

When my RockPro64 arrives I will try to build the preempt_rt kernel for it.

Alan

> From: TJoseph Powderly 
> Subject: Re: [Emc-users] Rock64 pre-orders on Banggood.
> Date: March 27, 2019 at 5:00:55 AM PDT
> To: "Enhanced Machine Controller (EMC)" 
> 
> 
> for those interested because of 2nd ethernet
> 
> this maybe useful:
> 
> a pinout of the header used
> and small discussion of the needed isolation trafo 'magjack'
> 
> https://forum.pine64.org/showthread.php?tid=4898
> 
> 
> also, re rt-preempt 64 bit on it...
>  i see dev 'schooner' has done this
> " |root@pine64:~# uname -a
> 
> Linux pine64 4.9.6-rt4-p64-73261-g5fb7565 #2 SMP PREEMPT RT Wed Feb 8 
> 07:45:02 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux"
> 
> see end of thread at
> https://forum.pine64.org/showthread.php?tid=394=5|
> 
> hth
> tomp
> 
> i find it amusing that the header naming and advertising suggest this is pi5 
> compatible
> 
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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

Re: [Emc-users] SPI comms for linuxcnc (was Re: Rock64 pre-orders on Banggood.)

[Nicklas Karlsson]

On Wed, 27 Mar 2019 11:53:52 -0700
Chris Albertson  wrote:

> I think in this current context we are talking about distances of not much
> more than 10 centimeters. The signal would go from a GPOI header to a
> real-time controller like an FPGA or uP.   In typical use cases, SPI and
> I2C never leave the PCB and don't go over cables, although it could
> especially in one-off prototype work

That's right. Over longer distances something else is most certainly a better 
choice and maybe even if crossing an isolation barrier. Short distance with a 
maximum of a few devices fast and cheap.


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

Re: [Emc-users] SPI comms for linuxcnc (was Re: Rock64 pre-orders on Banggood.) --> protocol?

[Nicklas Karlsson]

> ...
> But if writing software you should not have to decide of lock in a certain
> communications method.   I like whatht ehauthors is ros-serial did, that
> w=said "Use any communications method that has these four fuctions: open,
> close, read, write.  THat pretty much means anything from a network socket
> to an RS232 cable.

It's nice to have some kind of common message format and that's why I am 
looking on CANopen.


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

[Emc-users] chinese vfd is driving me bonkers.

[Gene Heskett]

While trying to get a reverse control over this POS, I noted that the 
default was reversed, so I traded the 2 U & V wires to the motor to make 
it run fwd.

This is toward the end of March, but as of this afternoon its default, 
can't change it w/o moving UV again, is now its running bass ackwards 
again.

Then, I note after I had unplugged the hoses from the pump in order to 
re-route them thru the new cable chains, that the pump wasn't.  Power is 
being switched on queue..

Pull pump out of water, note its slightly warm. Made sure power was off 
and popped the end covers, discover its a PM armature with pretty strong 
cogging. Put front cover back on as its also the front bearing.  Apply 
power, and 8 or 10 pokes at turning it, It takes off again. Its not 
stiff or dragging. Stop AC to it, stops, start it, runs. Several times. 
So obviously it can't be trusted.

I've a mind to just order another pump and a vfd.  I am plumb sick of 
screwing with this documentless piece of Chinese shit vfd. I want to 
actually USE it before I fall over...


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



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

Re: [Emc-users] SPI comms for linuxcnc (was Re: Rock64 pre-orders on Banggood.)

[Gene Heskett]

On Wednesday 27 March 2019 14:03:33 Nicklas Karlsson wrote:

> On Wed, 27 Mar 2019 19:12:48 +0700
>
> TJoseph Powderly  wrote:
> > ( list apology, I seem to have replied to posters rather than to the
> > list, and several times :-(
> >
> > re SPI comms Linuxcnc SBC microcontrollers ...
> >
> > it has been said on this mail list,
> > that SPI is a good candidate for a bus technology to work _with_
> > realtime.
>
> Maybe not as a bus but chip select between devices over a short
> distance work. Isolation is possible but delay may cause problem at
> high speed. If drivers are kept close together and there are not to
> many of them which likely to be the case it is a good candidate.
>
> CANopen is available for ordinary CAN networks and over Ethercat. SDO
> protovol may be a very good candidate for configuration to get a more
> or less standard format, *.eds files may be used as a standard
> dictionary format, expedited transfer of up to 32 bit at a time is
> relatively simple to implement, to add a sequence number might be a
> good idea so that severel messages could be on the the they thru the
> system but for configuration to wait a short while is OK since there
> usually only is a need for a few numbers. I have som code is somenone
> need it. PDOs are simple if harcoded, mapping and communication
> parameters are harder but may not be needed for a working system.
>
> SPI is very common on Micro controllers, cheap and fast but only over
> very short distances, there certainly are limitations.
>
Qualify very short distance to include up to 8" long although it wasn't 
as bulletproof at a lower speed as I was using 8" pin to pin jumpers and 
no termintors.  Now my cable is a legit ribbon and about an inch. And 
Jon E's little terminator board adds a little under an inch to that. At 
that distance, its bulletproof.

> > heres some work in that vein (maybe overlooked)
> >
> > yeltrow's work:
> > a generic spi hal module so you can use other SPI devices ( rpi,
> > arduino, mcp23s17, ENC28J60, theres a lot of spi stuff to hang onto
> > such a bus )
> > https://www.forum.linuxcnc.org/24-hal-components/28851-spi-bus-gener
> >ic-driver-and-st-l6480
> >
> > the files are on the forum for members
> > linuxcnc-upload-2015-12-03.tar
> >
> > erste's work:
> > for ethernet circumventing usb ( via spi
> > interesting as spi and ethernet seem to be future avenues
> > http://erste.de/ethraw/README
> >
> > theres other efforts but less coupled to the spi grail
> >
> > tomp
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



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

Re: [Emc-users] SPI comms for linuxcnc (was Re: Rock64 pre-orders on Banggood.)

[Chris Albertson]

I think in this current context we are talking about distances of not much
more than 10 centimeters. The signal would go from a GPOI header to a
real-time controller like an FPGA or uP.   In typical use cases, SPI and
I2C never leave the PCB and don't go over cables, although it could
especially in one-off prototype work



On Wed, Mar 27, 2019 at 11:42 AM Rafael Skodlar  wrote:

> We are making progress...
>
> On 3/27/19 11:16 AM, Chris Albertson wrote:
> > What makes SPI nice is not it's speed.  On the Pi it can go up to 250
> MHz,
> > so Ethernet beats it for speed and Ethernet cables can be 100 meters
> long.
> >SPI wins because it is fast enough for most things and is very simple,
> > just connect the wires.  But it only works over a short distance.   But
> it
> > is SIMPLE, conceptually no  unlike TTL level serial.
>
> Let's see what one of my former employers, an IC manufacturer has to say
> about SPI:
> https://www.maximintegrated.com/en/app-notes/index.mvp/id/6208
> "The maximum distance of an I2C bus depends on the capacitive loading.
> In typical applications, the length is limited to a few meters in
> standard mode. This is because a system has to be built to accommodate a
> maximum bus capacitance of 400pF to meet rise time requirements listed
> in the I2C bus specification (Rev. 6 – 4 April 2014)."
>
> Still want to use parallel port? ;-)
>
> >
> >Ethernet needs some support hardware, a small transformer at least.
>
> Not necessarily. There is plenty of boxes connected with fiber cable.
> Seen that done that.
>
> >
> > Unlike simply using GPIO pins, SPI does not need much CPU time to send
> data.
> >
> > But if writing software you should not have to decide of lock in a
> certain
> > communications method.   I like whatht ehauthors is ros-serial did, that
> > w=said "Use any communications method that has these four fuctions: open,
> > close, read, write.  THat pretty much means anything from a network
> socket
> > to an RS232 cable.
> >
>
> All protocols have some kind of handshake. If designed properly then
> dedicated circuits to handle interrupts take care of it. That beats
> anything that I've seen years ago in one over 40 years old CNC machine
> where transistors and other discrete components were in such odd shape I
> wasn't sure what they were in most cases.
>
> You could extend SPI connection with optical drivers and fiber optic
> cables also. 1km distance would not be impossible. Granted, this would
> be theoretical more than a practical solution not sensitive to electric
> noise or atmospheric electric discharge that killed a lot of RS-232
> circuits which I ended up replacing with 60mA loops in my career.
>
> --
> Rafael Skodlar
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] SPI comms for linuxcnc (was Re: Rock64 pre-orders on Banggood.)

[Rafael Skodlar]

We are making progress...

On 3/27/19 11:16 AM, Chris Albertson wrote:

What makes SPI nice is not it's speed.  On the Pi it can go up to 250 MHz,
so Ethernet beats it for speed and Ethernet cables can be 100 meters long.
   SPI wins because it is fast enough for most things and is very simple,
just connect the wires.  But it only works over a short distance.   But it
is SIMPLE, conceptually no  unlike TTL level serial.


Let's see what one of my former employers, an IC manufacturer has to say 
about SPI:

https://www.maximintegrated.com/en/app-notes/index.mvp/id/6208
"The maximum distance of an I2C bus depends on the capacitive loading. 
In typical applications, the length is limited to a few meters in 
standard mode. This is because a system has to be built to accommodate a 
maximum bus capacitance of 400pF to meet rise time requirements listed 
in the I2C bus specification (Rev. 6 – 4 April 2014)."


Still want to use parallel port? ;-)



   Ethernet needs some support hardware, a small transformer at least.


Not necessarily. There is plenty of boxes connected with fiber cable. 
Seen that done that.




Unlike simply using GPIO pins, SPI does not need much CPU time to send data.

But if writing software you should not have to decide of lock in a certain
communications method.   I like whatht ehauthors is ros-serial did, that
w=said "Use any communications method that has these four fuctions: open,
close, read, write.  THat pretty much means anything from a network socket
to an RS232 cable.



All protocols have some kind of handshake. If designed properly then 
dedicated circuits to handle interrupts take care of it. That beats 
anything that I've seen years ago in one over 40 years old CNC machine 
where transistors and other discrete components were in such odd shape I 
wasn't sure what they were in most cases.


You could extend SPI connection with optical drivers and fiber optic 
cables also. 1km distance would not be impossible. Granted, this would 
be theoretical more than a practical solution not sensitive to electric 
noise or atmospheric electric discharge that killed a lot of RS-232 
circuits which I ended up replacing with 60mA loops in my career.


--
Rafael Skodlar


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

Re: [Emc-users] SPI comms for linuxcnc (was Re: Rock64 pre-orders on Banggood.)

[Chris Albertson]

What makes SPI nice is not it's speed.  On the Pi it can go up to 250 MHz,
so Ethernet beats it for speed and Ethernet cables can be 100 meters long.
  SPI wins because it is fast enough for most things and is very simple,
just connect the wires.  But it only works over a short distance.   But it
is SIMPLE, conceptually no  unlike TTL level serial.

  Ethernet needs some support hardware, a small transformer at least.

Unlike simply using GPIO pins, SPI does not need much CPU time to send data.

But if writing software you should not have to decide of lock in a certain
communications method.   I like whatht ehauthors is ros-serial did, that
w=said "Use any communications method that has these four fuctions: open,
close, read, write.  THat pretty much means anything from a network socket
to an RS232 cable.

On Wed, Mar 27, 2019 at 6:15 AM Gene Heskett  wrote:

> On Wednesday 27 March 2019 08:12:48 TJoseph Powderly wrote:
>
> > ( list apology, I seem to have replied to posters rather than to the
> > list, and several times :-(
> >
> > re SPI comms Linuxcnc SBC microcontrollers ...
> >
> > it has been said on this mail list,
> > that SPI is a good candidate for a bus technology to work _with_
> > realtime.
> >
> > heres some work in that vein (maybe overlooked)
> >
> > yeltrow's work:
> > a generic spi hal module so you can use other SPI devices ( rpi,
> > arduino, mcp23s17, ENC28J60, theres a lot of spi stuff to hang onto
> > such a bus )
> > https://www.forum.linuxcnc.org/24-hal-components/28851-spi-bus-generic
> >-driver-and-st-l6480
> >
> Interesting driver for the big stuffs. However, I wonder if yeltrow is
> aware of rpspi.ko, now part of LCNC.  Not parport based but gpio,
> written specificly for the rpi3b.  And I'm using it, writing to a Mesa
> 7i90 at 42 megabaud, and reading back from the 7i90 at 25 megabaud
> useing only 4 gpio pins for 2 or 3  target devices.
>
> Perusal of that code might be of help to yeltrow. gpio seems to be about
> 10x faster than trying to simulate SPI over a parport.  The 7i90 has
> both modes depending on the firmware loaded.
>
> > the files are on the forum for members linuxcnc-upload-2015-12-03.tar
>
> So this work handily predates rpspi.ko. Still, theres obviously things to
> be learned from the rpi version.
>
> > erste's work:
> > for ethernet circumventing usb ( via spi
> > interesting as spi and ethernet seem to be future avenues
> > http://erste.de/ethraw/README
> >
> > theres other efforts but less coupled to the spi grail
> >
> > tomp
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] SPI comms for linuxcnc (was Re: Rock64 pre-orders on Banggood.)

[Nicklas Karlsson]

On Wed, 27 Mar 2019 19:12:48 +0700
TJoseph Powderly  wrote:

> ( list apology, I seem to have replied to posters rather than to the 
> list, and several times :-(
> 
> re SPI comms Linuxcnc SBC microcontrollers ...
> 
> it has been said on this mail list,
> that SPI is a good candidate for a bus technology to work _with_ realtime.

Maybe not as a bus but chip select between devices over a short distance work. 
Isolation is possible but delay may cause problem at high speed. If drivers are 
kept close together and there are not to many of them which likely to be the 
case it is a good candidate.

CANopen is available for ordinary CAN networks and over Ethercat. SDO protovol 
may be a very good candidate for configuration to get a more or less standard 
format, *.eds files may be used as a standard dictionary format, expedited 
transfer of up to 32 bit at a time is relatively simple to implement, to add a 
sequence number might be a good idea so that severel messages could be on the 
the they thru the system but for configuration to wait a short while is OK 
since there usually only is a need for a few numbers. I have som code is 
somenone need it. PDOs are simple if harcoded, mapping and communication 
parameters are harder but may not be needed for a working system.

SPI is very common on Micro controllers, cheap and fast but only over very 
short distances, there certainly are limitations.

> heres some work in that vein (maybe overlooked)
> 
> yeltrow's work:
> a generic spi hal module so you can use other SPI devices ( rpi, 
> arduino, mcp23s17, ENC28J60, theres a lot of spi stuff to hang onto such 
> a bus )
> https://www.forum.linuxcnc.org/24-hal-components/28851-spi-bus-generic-driver-and-st-l6480
>  
> 
> the files are on the forum for members linuxcnc-upload-2015-12-03.tar
> 
> erste's work:
> for ethernet circumventing usb ( via spi
> interesting as spi and ethernet seem to be future avenues
> http://erste.de/ethraw/README
> 
> theres other efforts but less coupled to the spi grail
> 
> tomp
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


-- 
Nicklas Karlsson 


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

Re: [Emc-users] SPI comms for linuxcnc (was Re: Rock64 pre-orders on Banggood.)

[Gene Heskett]

On Wednesday 27 March 2019 08:12:48 TJoseph Powderly wrote:

> ( list apology, I seem to have replied to posters rather than to the
> list, and several times :-(
>
> re SPI comms Linuxcnc SBC microcontrollers ...
>
> it has been said on this mail list,
> that SPI is a good candidate for a bus technology to work _with_
> realtime.
>
> heres some work in that vein (maybe overlooked)
>
> yeltrow's work:
> a generic spi hal module so you can use other SPI devices ( rpi,
> arduino, mcp23s17, ENC28J60, theres a lot of spi stuff to hang onto
> such a bus )
> https://www.forum.linuxcnc.org/24-hal-components/28851-spi-bus-generic
>-driver-and-st-l6480
>
Interesting driver for the big stuffs. However, I wonder if yeltrow is 
aware of rpspi.ko, now part of LCNC.  Not parport based but gpio, 
written specificly for the rpi3b.  And I'm using it, writing to a Mesa 
7i90 at 42 megabaud, and reading back from the 7i90 at 25 megabaud 
useing only 4 gpio pins for 2 or 3  target devices.

Perusal of that code might be of help to yeltrow. gpio seems to be about 
10x faster than trying to simulate SPI over a parport.  The 7i90 has 
both modes depending on the firmware loaded.

> the files are on the forum for members linuxcnc-upload-2015-12-03.tar

So this work handily predates rpspi.ko. Still, theres obviously things to 
be learned from the rpi version. 

> erste's work:
> for ethernet circumventing usb ( via spi
> interesting as spi and ethernet seem to be future avenues
> http://erste.de/ethraw/README
>
> theres other efforts but less coupled to the spi grail
>
> tomp
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



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

Re: [Emc-users] SPI comms for linuxcnc (was Re: Rock64 pre-orders on Banggood.)

[andy pugh]

On Wed, 27 Mar 2019 at 12:14, TJoseph Powderly  wrote:
>
> ( list apology, I seem to have replied to posters rather than to the
> list, and several times :-(
>
> re SPI comms Linuxcnc SBC microcontrollers ...
>
> it has been said on this mail list,
> that SPI is a good candidate for a bus technology to work _with_ realtime.

Peter has leaked the imminent release of a couple of new Mesa cards:

"Also the 7C80 and 7C81 which are a mechanical match to the RPI"

Which sound like they would fit the Rock64 too.

-- 
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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] SPI comms for linuxcnc (was Re: Rock64 pre-orders on Banggood.)

[TJoseph Powderly]

( list apology, I seem to have replied to posters rather than to the 
list, and several times :-(


re SPI comms Linuxcnc SBC microcontrollers ...

it has been said on this mail list,
that SPI is a good candidate for a bus technology to work _with_ realtime.

heres some work in that vein (maybe overlooked)

yeltrow's work:
a generic spi hal module so you can use other SPI devices ( rpi, 
arduino, mcp23s17, ENC28J60, theres a lot of spi stuff to hang onto such 
a bus )
https://www.forum.linuxcnc.org/24-hal-components/28851-spi-bus-generic-driver-and-st-l6480 


the files are on the forum for members linuxcnc-upload-2015-12-03.tar

erste's work:
for ethernet circumventing usb ( via spi
interesting as spi and ethernet seem to be future avenues
http://erste.de/ethraw/README

theres other efforts but less coupled to the spi grail

tomp


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

Re: [Emc-users] Rock64 pre-orders on Banggood.

[TJoseph Powderly]

for those interested because of 2nd ethernet

this maybe useful:

a pinout of the header used
and small discussion of the needed isolation trafo 'magjack'

https://forum.pine64.org/showthread.php?tid=4898


also, re rt-preempt 64 bit on it...
 i see dev 'schooner' has done this
" |root@pine64:~# uname -a

Linux pine64 4.9.6-rt4-p64-73261-g5fb7565 #2 SMP PREEMPT RT Wed Feb 8 
07:45:02 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux"


see end of thread at
https://forum.pine64.org/showthread.php?tid=394=5|

hth
tomp

i find it amusing that the header naming and advertising suggest this is 
pi5 compatible


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

Re: [Emc-users] Possible new feature request – a package file.

[andy pugh]

On Wed, 27 Mar 2019 at 09:40, Greg Bentzinger via Emc-users
 wrote:

> One great feature that Ultimax included was that it savedthe part setup 
> offsets, parameter table and all the tool data with each partprogram. The 
> tool data included cutter geometry type, cutter dia., cutter materialtype, 
> SFPM, default RPM and spindle direction, Z height offset, and Coolantmode. I 
> was wondering if there could be a way to generate a “package file” (TAR ? ) 
> That would have the G-code file, Tool table, and variable table allunder the 
> parent g-code file name.

You could probably include all the data as "magic comments" in an
actual G-code file, so this could take the form of an extra menu
option to "add config data to G-code file"
The read-back part could be realized now, simply by defining an input
filter that parses the magic comments, but that would be a per-user
config and suspect that this would be more useful as a built-in (and
_writing_ the data needs to be built-in anyway)

-- 
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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Possible new feature request – a package file.

[Greg Bentzinger via Emc-users]

>https://lists.sourceforge.net/lists/listinfo/emc-users