Re: [Emc-users] jerk control

[David Berndt]

I don't have a great need for it with my machines, or the time/brains to  
implement it. It just seems like a feature we really should have.


 I'd be willing to participate monetarily in some sort of system to  
incentivize the inclusion of jerk control. Perhaps an open-source feature  
bounty? Does the community want to consider that sort of thing?


-Dave

On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck   
wrote:



hey guys

I am sitting here watching my cnc mill atm its shaking quite a bit
acceleration is 600mm/sec2  which is not that high i think.  compared to
every other cnc mill i have used with a commercial controller.  they have
jerk control and work much better.  so looking forward to when we get  
jerk

control here on linuxcnc!

but in the mean time i need a poor mans jerk control and thinking of a
limit on the pid output to chop down the initial acceleration for the  
first

moment in time just so little moves don't shake it to death

andy mentioned that I could maybe use a limit component to limit the
initial acceleration for the first tiny moment in time to cut down on the
vibrations.

how do you guys think that could work?

Regards

Andrew

___
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] Probe recommendations.

[David Berndt]

I'm not going to say it's in the same cost range, but what about the  
Hallmark impact tolerant touch probe. ITTP?   
https://hallmarkdesign.co.nz/probe





On Sun, 14 Mar 2021 17:13:17 -0400,  wrote:


Watch https://youtu.be/kwLydF4osc4 for an approach that I'm currently
playing with to reduce probe breakage .

-Original Message-
From: Gerrit Visser 
Sent: March 14, 2021 4:33 PM
To: 'Enhanced Machine Controller (EMC)' 
Subject: Re: [Emc-users] Probe recommendations.

I am still at the 'tooling breakage' stage of cnc. So far only 1  
Aliexpress

tip broken (CA$12 cost). I have some more on the way because I expect it
won't be the last broken one.
I have 2 Renishaw TP2's, they are surviving my inexperience so far. M2
threads.
Renishaw makes a sacrificial breakaway adapter, essentially a short  
piece of

material with a groove. Male and female M4 threads at opposite ends. It
however costs more than you were spending on just the probe.

Ken, this might be an option to try?
https://www.aliexpress.com/item/1005001421085958.html . If you make the
breakaway adapter then the more plentiful choices of M2 and M2.5 threaded
ones can come into play as well.

gerrit


-Original Message-
From: ken.stra...@gmail.com 
Sent: March 14, 2021 3:37 PM
To: 'Enhanced Machine Controller (EMC)' 
Subject: Re: [Emc-users] Probe recommendations.

Yes, I use standard 4mm screw probes. Perhaps us$50 is "reasonable" but  
I'm
just a hobbyist/retiree and I find that breakage due to stupidity  
annoying.

I'd rather spend a similar amount on a decent bottle of wine!





___
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] Dealing with Servo Faults

[David Berndt]

No experience on commercial systems. But I agree, a servo fault throwing  
e-stop wouldn't be the best. The behaviour that seems standard on fault is  
that the machine goes to power off which removes enable from all the other  
axis and spindle is effective and limits the chaos to a reasonable level  
and makes recovery possible.


That would be especially important for servo drives that don't have  
separate control and power inputs where in an e-stop you'd be forced to  
kill all drive power, encoder counting probably stops happening, position  
info is lost and you're stuck re-homing or whatever else is required to  
check your offsets.



-Dave


On Wed, 10 Feb 2021 00:08:41 -0500, John Dammeyer   
wrote:



Quick question.

There's a multi-axis operation in progress.  For whatever reason one of  
the servos throws out a fault and of course stops.


Should just the enables to the other servo drives be removed or should  
power be cut to all drives.


I'm not really in favour of dropping out power because that would mean  
you also lose the ability to easily recover.  The other drives and  
spindle were working so you really just want them stopped and things  
like coolant shut off.


This isn't the same as an ESTOP which does remove all power that could  
result in motion.  Low voltage control and PC are left running.


For my PMDX-126 BoB my faults are consolidated and brings the PMDX  
/FAULT input low.  That disables the ChargePump which in turn disables  
all outputs including the enable to all the drive.  And the orange  
button beside the red one on the user screen goes greyed out.


After 4 seconds the /FAULT input is once again brought high (inactive)  
and now the orange ENABLE button on the screen (or F2) can be clicked  
which then asserts the ENABLE output to the drives and allows hardware  
to be controlled again.


For my servos taking the ENABLE signal FALSE and then TRUE resets the  
FAULT condition.   If the fault is still there then the /FAULT is  
brought low again. Etc...


What do other systems (including commercial) do when a drive faults on  
one axis.


John




___
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] 4th axis engraving

[David Berndt]

Are you going to be able to use the "wrap" feature of 2d tool paths in  
fusion to get this done? Or are you a licensed/paying user? Autodesk has  
really gutted the 4/5th axis cad from the free version.


I did some more complex milling a few months back and ended up buying a  
4th license. If you're doing anymore more than wrapping you'll need to  
consider inverse time feed rates. There's a post processor posted by the  
guy that runs the metalmusings youtube channel that seems ok if you need  
that. Give his vids a watch as well for some explanations.



-Dave

On Wed, 06 Jan 2021 17:02:38 -0500, andrew beck   
wrote:



Hey everyone

I have a job to do engraving the od of a wheel.   I currently have a 4th
axis but haven't bolted a motor on it.  I can suss this part though.   
And I

use fusion360 for cam.

I have never done 4th axis work before.  And don't even know if anyone  
has

a linuxcnc post processor set up.

If anyone out there has done this I would love to hear from you.  I have
about a week to get this working.

Regards

Andrew

___
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] I wonder if I can fix it?

[David Berndt]

This is easily repaired by throwing it in the nearest round bin and buying  
a more robust Spinea cycloidal reducer and servo from ebay



On Tue, 05 Jan 2021 12:25:42 -0500, andy pugh  wrote:


I bought an FHA-17C actuator from eBay. It was cheaper than normal,
for parts or not working.
It clearly had the cables cut off, so I decided to gamble.

It turns out that things were worse than I hoped.

https://photos.app.goo.gl/p3SL2Bwv2b9yd5XJ9

I am seriously considering trying to make a new flexspline. I mean,
how hard can it be?



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

Re: [Emc-users] Chinese VFDs with good reputations

[David Berndt]

Hi John,

You've got me a bit interested in these drives. I'm currently looking for  
the biggest single phase servo I can easily find, looks like the Bergerda  
1.8 or maybe even 2.6kw might be it. But it's always a bit hard to tell  
with the lower quality documentation these companies provide. Can you  
confirm/deny that the 1.8kw can run on single phase?  What drive model  
number are you using?


Anyone else have any experience with the 2.6kw Bergeda? Looks like the  
LiChaun A4 series might also be of interest?




Thanks,

-Dave


On Sat, 26 Dec 2020 13:48:29 -0500, John Dammeyer   
wrote:


I looked at prices for a 2HP 3phase and a VFD (like Hitatchi  
Vectorless?) and found without shipping the price was approaching $600.   
For less than that I ended up with Bergerda.


I'm using a Bergerda AC Servo 110SM series (1.8kW, 6NM)  on my spindle,  
currently with a cheap PWM module until I wire up a second BoB for  
step/dir control.  With PWM I get 100RPM to 3000RPM without a belt  
change.  With stepper I can have it move very very slowly.


I also swapped in, for testing, a smaller 60SM series 1.27NM Bergerda  
onto the X axis.  Once I read the manual correctly I got step and  
direction working well.  The drive isn't overly large but is a bit  
bigger than the HP_UHU which runs the brushed servo motors also 1.2 NM.
This video shows it now working.  I can get 180ipm on the X axis just  
like the much bigger DC Servo.

https://youtu.be/43liAVILgHY

The Gecko Stepper G213V driver on the knee has now failed for the second  
time melting the connector again.  Absolutely no response from Gecko so  
it's being scrapped and FedEx tracking says my new Bergerda AC 80SM  
series servo (3.5NM) will arrive on Wednesday along with 2 more of the  
small 60SM units.


They aren't cheap compared to stepper motors.  In my case I get to  
remove a complete Toroidal power supply that runs only the stepper but  
is big enough for the entire mill with 60VDC motor drivers.


The DC Servos and Harmonic drive (controlled with STMBL) run on a 105DC  
Toroidal power supply.  I could remove this and run the Harmonic off  
110VAC to DC with a smaller isolation transformer.  Then I'd have room  
for the Bergerda drives.
This is the MACH3 Road Runner with the much bigger DC Servos and the  
1200 oz-in (drops to 3.5NM at 300RPM) on the knee.

https://youtu.be/OUQzyp-3WXY

I've found support and price excellent, shipping horrendous.   For  
example I found that when the spindle stopped it would sometimes sit  
with a bit of a squeal.  A quick email to Bergerda and discussion and we  
figured out which parameters to tweak.  Now it's dead quiet.  And much  
smaller than the single phase 1.5kW 2HP motor.

http://www.autoartisans.com/mill/NewPulleys-1.jpg

John Dammeyer


-Original Message-
From: Dave Cole [mailto:linuxcncro...@gmail.com]
Sent: December-26-20 9:44 AM
To: emc-users@lists.sourceforge.net
Subject: [Emc-users] Chinese VFDs with good reputations

What low cost Chinese drives have you guys used with great success?

I'm talking mostly single phase input drives.

There are a lot of look a likes on Ebay.�� Some are dirt cheap. Others
not so much.

Some specify that they are specifically for water cooled spindles, etc.

Others say almost nothing.

Dave



___
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] G64 - view current setting

[David Berndt]

Thanks Andy.

As a follow up. Maybe I'm being a bit lazy here as I haven't really dug  
deep on this one yet.
But does G64 Px operate in machine native units? or should it be reset  
when changing between g20 and g21?


-Dave

On Wed, 18 Nov 2020 16:55:48 -0500, andy pugh  wrote:


On Tue, 17 Nov 2020 at 03:38, David Berndt  wrote:


Is there any way to See the P or P and Q values of G64? A pin or param
somewhere? Some other method?


I have had a look, and I don't see anything.

The python interface has a "get motion mode" but that does not seem to
get the tolerance.

If you are prepared to recompile, then I think you could edit here to
get tp->tolerance or tc->tolerance out to a HAL pin:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/control.c#L1941



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

[Emc-users] G64 - view current setting

[David Berndt]

Is there any way to See the P or P and Q values of G64? A pin or param  
somewhere? Some other method?


-Dave


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

Re: [Emc-users] Peristaltic Pump

[David Berndt]

I'm not sure I participated in the previous discussion but it is something  
I've been doing for about the last 6 months now. I replaced my old setup  
which was air combined with mist via pressurizing the mist tank and  
carefully regulating each stream via pnuematic regulator and a quite small  
flow control valve on the coolant line. That never really worked very well  
as the cheap regulators seemed to drift and the flow control valve  
occasionally died due to small amounts of solids in the coolant.


I'm using one of the little 12v pumps, 1*3 tubing, the smaller the tubing  
the less it flows, and I find I want to run the smallest possible size to  
get reasonable mist usage.


For reference, here's an example.
https://www.ebay.ca/itm/DC12V-24V-Peristaltic-Dosing-pump-For-Aquarium-Lab-Chemical-Analysis-1PC/352574372597

I drive this via a motor driver circuit and arduino using PWM to control  
motor speed and also I built sort of an coolant flow if you will into HAL  
that will run the pump only a percentage of the time, I find even with the  
smallest tubing the pump at full speed moves a ton of coolant for a mist  
system doing the kind of fairly small aluminum work I mostly do. A stepper  
motor for proper low speed control would be better if you're willing to  
spend the coin.


The tubing connectors are a bit of a weak point, they tend to blow off  
around 40psi in my experience. I generally run my mist at more like 10 but  
accidents happen...


These units are definitely throw away, put yours where you can service it  
and replace it easily. I'm still on the same motor but I had to replace a  
pump head due to wear on the rollers and tubing after maybe 200 hours of  
actual on time? At some point the pump head stalled but the motor kept  
spinning and it sort of flat spots the plastic rollers.


Overall I'm pleased with the peristaltic pump idea and won't be going back  
to manually balancing mist flow with flow control and regulators.


-Dave



On Mon, 09 Nov 2020 16:31:24 -0500,  wrote:

Some time ago there was a little discussion about using a peristaltic  
pump to supply coolant to a mister. Was this successful? Which pump was  
used? Is silicone tubing resistant to coolant?




___
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] G93 minimum value/behaviour

[David Berndt]

It's an interesting idea but I can't afford that level of potential  
downtime currently. Getting the machine to where it's at has taken a long  
time and re-doing any of it for fixing a G93 issue isn't in the cards.  
Maybe over xmas break or something.



I'd be interested in any other internals I can plumb/halscope to find the  
cause. But as per above, realistically unless it's a very simple fix that  
doesn't involve recompiling something I'm not fixing it anytime soon. G93  
feeds of less than 1 really don't matter to me that much currently. I only  
really reported it as I thought it was a universal issue, clearly it's not  
and I can reasonably expect it to be fixed the next time I upgrade  
software.



-Dave


On Sun, 13 Sep 2020 15:21:58 -0400, andy pugh  wrote:


On Sun, 13 Sep 2020 at 17:13, David Berndt  wrote:


2.7.8


The first thing to try is an update to 2.7.14 (latest 2.7 version)



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

Re: [Emc-users] G93 minimum value/behaviour

[David Berndt]

2.7.8

On Sun, 13 Sep 2020 06:54:09 -0400, andy pugh  wrote:


On Sun, 13 Sep 2020 at 09:57, David Berndt  wrote:


F10   - 60 deg/s
F5- 30 deg/s
F2.5  - 15 deg/s
F1- 6 deg/s
F.5   - 6 deg/s
F.1   - 6 deg/s


That seems strange. Which version of LinuxCNC are you using?



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

Re: [Emc-users] G93 minimum value/behaviour

[David Berndt]

Ok, I wasn't around yesterday to read the replies and do more testing.

My previous g-code example had some artistic license applied as I was not  
at the console to copy the code and was a bit lazy, plus I hoped it would  
be reasonably clear. Lets ignore the fast rotary axis, that's really not  
what anyone cares about here. Also yes I forgot the G1 in the example, but  
as I was getting different results for various values of F then it seems  
to me there would have bene no way I was testing without the G1, a G0  
would always run at the maximum speed. I'm short a time machine to go back  
and look at my initial testing instructions.



Here's an actual real world test I just ran. I manually transcribed this  
as annoyingly you can't seem to copy out of the MDI history window when  
the machine is in e-stop. So there's my get out of typo jail free card  
again.


G0 Z-6 A0
G93 G1 Z-6.1 A360 F10
G93 G1 Z-6.2 A720 F5
G93 G1 Z-6.3 A1080 F2.5
G93 G1 Z-6.4 A1440 F1
G93 G1 Z-6.5 A1800 F.5
G93 G1 Z-6.6 A2160 F.1

Expected speeds of the A axis as per the axis.N.joint-vel-cmd and move  
time:

F10  - 60 deg/s- 6 seconds
F5   - 30 deg/s- 12 seconds
F2.5 - 15 deg/s- 24 seconds
F1   - 6 deg/s - 60 seconds
F.5  - 3 deg/s - 120 seconds
F.1  - 0.6 deg/s   - 600 seconds

Hopefully we're agreed on the theory?

My results:

F10   - 60 deg/s
F5- 30 deg/s
F2.5  - 15 deg/s
F1- 6 deg/s
F.5   - 6 deg/s
F.1   - 6 deg/s


-Dave



On Sat, 12 Sep 2020 10:43:30 -0400, Gene Heskett   
wrote:



On Saturday 12 September 2020 07:46:05 andy pugh wrote:


On Sat, 12 Sep 2020 at 05:19, David Berndt  wrote:
> 2) Is there a minimum value for G93 feed rates.

Not as far as I know. I just tried a test move of G93 G0 X100 F0.01
and it moved 1mm in 1 minute.

> rotating A axis with something like G93 A45000 Z-1 F.2.

I tried this G-code in the axis-9axis sim. It complained that there
was no movement mode active. Putting in a G1 I got approximately the
expected result, in that Z moved 0.5mm in 4.5 minutes. So I assume
that the A axis was maxed out in the simulator.
Bumping up the A axis max speed from 90 to 360 gave me a system that
did 25 revolutions in 1 minute.

Had you done a G0 move?

G0 X0 Y0
G93 A45000 Z-1 F.2

Moves very fast. As G0 is modal. This ought to be an error, I think.
(G0 X0 Y0 F10 is accepted. It is valid G-code but probably isn't what
anyone intends. It says "set the feed rate to 10 and then perform a
rapid move")

G93 with G0 active, however, clearly makes no sense and appears to
cause confusion.

From this Doc quote:

• G93 - is Inverse Time Mode. In inverse time feed rate mode, an F word
means the move should be completed in [one divided
by the F number] minutes. For example, if the F number is 2.0, the move
should be completed in half a minute.
When the inverse time feed rate mode is active, an F word must appear on
every line which has a G1, G2, or G3 motion, and
an F word on a line that does not have G1, G2, or G3 is ignored. Being in
inverse time feed rate mode does not affect G0 (rapid
move) motions.

I think it should throw an error for a G0 on that same or previous line
hat updates the modal to a G0.

And a "G93 A45000 Z-1 F.2" won't run on the G0704 whose A axis is a slow
worm drive, throwing an instant f error but, it appears to run as
expected on the 6040 whose A axis is belt driven and capable of several
rps.

Wall time for that command is exactly 5 minutes, but I preceded it with a
g1f20x0y0. Rehomed, and xy zeroed with a g0 is not an error but the
reported z velocity is not .2, but 1.92, crazy fast. I think it would be
helpfull to issue an "educational" error as its not really a valid
command for the G0 mode.  As it will quite likely break the tool, it
shouldn't be allowed to run IMO.

My $0.02.

Cheers, Gene Heskett



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

[Emc-users] G93 minimum value/behaviour

[David Berndt]

I've recently started playing more with a 4th axis and have Fusion  
spitting out some reasonably decent G93'd code.


Two things have come up now that I'm running a part or two.

1) Am I correct in assuming that the G64 P/q settings have limited/no  
effect when using the a rotary axis and linear simultaneously? I can't see  
a different in speed when I play with reasonable values for P.


2) Is there a minimum value for G93 feed rates. It would have been  
convenient at one point today to plunge an endmill into a continuously  
rotating A axis with something like G93 A45000 Z-1 F.2. Which I'd expect  
to create an inverse time of 1/.2 = 5 minutes to plunge the endmill 1"  
over (45000/360)=125 rotations @ 25rpm. A shallow cut in a narrow slot  
with a smallish endmill. But the feed rate that I got was much higher than  
expected, nothing below an F of .5 really seems to give me an output that  
I'd expect. Am I missing something? Is there a minimum/maximum value for F  
in G93?


Thanks
-Dave


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

Re: [Emc-users] OT: Anyone tried these auto lube units?

[David Berndt]

I have had two of similar design in service for about 3 years now and both  
seem to work just fine. Filling them is the only real nuisance as I  
mounted mine in the base of the machine. Keep them very accessible if you  
can.



On Tue, 18 Aug 2020 19:05:41 -0400, Leonardo Marsaglia  
 wrote:



Hello guys,

I'm about to purchase some automatic lube units for a copying lathe I'm
retrofitting with LCNC and for the router project (which is alive again
finally).

I'm planning to use an auto lube unit like this:

https://www.ebay.com/itm/CNC-Electromagnetic-Lubricant-Pump-Automatic-Lubricating-Oil-Pump-220V-HTS02-2L/184283971779?hash=item2ae82e40c3:g:TCMAAOSwiI1eYgJZ


Do you have any experience with these? Should I try something a little  
more

expensive just to play it safe?

Thanks as always!

___
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] Cheaper than normal FHA-25B

[David Berndt]

When reasonably sized harmonic drives with servo motors inbuilt are 250$  
on ebay, they are COTS.  So the answer is yes. Just buy one of those and  
move on to solving a more interesting problem or making whatever the  
machine is supposed to make.


-Dave



On Sat, 16 May 2020 02:49:55 -0400, John Dammeyer   
wrote:



Hi Dave,
I think the question being raised is whether it's possible to create a  
zero backlash 4th or 5th axis with COTS hardware for less money than a  
harmonic drive or the cycloidal gearboxes.


John



-Original Message-
From: David Berndt [mailto:ber...@uberwin.com]
Sent: May-15-20 11:19 PM
To: Enhanced Machine Controller (EMC); Roland Jollivet
Subject: Re: [Emc-users] Cheaper than normal FHA-25B

Why are you particularly worried about that? Cyclodial gear boxes and
harmonic drives are both basically 0 backlash, with potentially some  
lost

motion. Most are repeatable well under 1 arc minute, which compared to a
lot of rotary tables already out there. And that's something like a  
.0017"
displacement on a 12" radius. Angular transmission accuracy would seem  
to

be almost as big an issue that you'd have to start to think about if
you're concerned about those levels of backlash. Also overall mechanical
stiffness.

-Dave


On Sat, 16 May 2020 01:49:58 -0400, Roland Jollivet
 wrote:

> I've been thinking about 4th axes;
> While motorised reduction drives are readily available, the issue is
> obviously backlash.
>
> One way to make a zero backlash drive is to use two identical
> gearbox/drives. Place them at opposite ends of the axis, and pit them
> against each other by a few encoder counts.
> So they will track and retain the zero-backlash.
>
> Of course, the total power available is now less than one drive motor,
> but
> it is an option to use almost any pair of reduction drives that can be
> got.
> But there is also the cost of the second servo amp.
>
>
> On Fri, 15 May 2020 at 14:11, andy pugh  wrote:
>
>> The normally appear on eBay at up to 6x this price.
>> https://www.ebay.co.uk/itm/233587431605
>>
>> The B versions have conventional incremental encoders and hall
>> sensors, so are easy to integrate. Lots of torque, zero backlash and  
a

>> very strong and fancy big crossed-roller bearing make them an
>> almost-complete 4th or 5th axis just needing a bracket and a drive.
>>
>> I have no connection with the vendor, if you order one and receive
>> dolls-house furniture instead don't blame me.
>>
>> --
>> 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-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




___
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] Cheaper than normal FHA-25B

[David Berndt]

Why are you particularly worried about that? Cyclodial gear boxes and  
harmonic drives are both basically 0 backlash, with potentially some lost  
motion. Most are repeatable well under 1 arc minute, which compared to a  
lot of rotary tables already out there. And that's something like a .0017"  
displacement on a 12" radius. Angular transmission accuracy would seem to  
be almost as big an issue that you'd have to start to think about if  
you're concerned about those levels of backlash. Also overall mechanical  
stiffness.


-Dave


On Sat, 16 May 2020 01:49:58 -0400, Roland Jollivet  
 wrote:



I've been thinking about 4th axes;
While motorised reduction drives are readily available, the issue is
obviously backlash.

One way to make a zero backlash drive is to use two identical
gearbox/drives. Place them at opposite ends of the axis, and pit them
against each other by a few encoder counts.
So they will track and retain the zero-backlash.

Of course, the total power available is now less than one drive motor,  
but
it is an option to use almost any pair of reduction drives that can be  
got.

But there is also the cost of the second servo amp.


On Fri, 15 May 2020 at 14:11, andy pugh  wrote:


The normally appear on eBay at up to 6x this price.
https://www.ebay.co.uk/itm/233587431605

The B versions have conventional incremental encoders and hall
sensors, so are easy to integrate. Lots of torque, zero backlash and a
very strong and fancy big crossed-roller bearing make them an
almost-complete 4th or 5th axis just needing a bracket and a drive.

I have no connection with the vendor, if you order one and receive
dolls-house furniture instead don't blame me.

--
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-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] Hal file naming conventions

[David Berndt]

I guess my biggest issue is I don't name the components themselves. Then  
when I try to describe what a signal is connecting it's connecting some  
terribly named thing, with another terribly named thing, so my signals end  
up not being very usefully named thing like SigNot2And27 or whatever  
nonsense occurs to me at the time. I guess I should start with my  
components and maybe the the rest might fall more into place.




On Thu, 14 May 2020 07:57:55 -0400, andy pugh  wrote:


On Thu, 14 May 2020 at 05:42, David Berndt  wrote:

Wondering if anyone cares to share with me a useful naming convention  
for
your signals? Do you also use the name parameters to name your  
components

or do you just stick with and2.0 thru and2.x?


I like to give them names that include what they are and what they do.

and.sp_intrlk for the spindle interlock, that sort of idea.
I think it is important to leave some clue what the component function  
is.



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

[Emc-users] Hal file naming conventions

[David Berndt]

Wondering if anyone cares to share with me a useful naming convention for  
your signals? Do you also use the name parameters to name your components  
or do you just stick with and2.0 thru and2.x?


My hal config works fine, but I worry about anyone that might have to look  
at it after me, or even if I have to look at it again after a year or two.


Apologies if this has come up before, I did a bit of light googling and  
didn't find much on the topic.


-Dave





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

Re: [Emc-users] custom_G42 rs274

[David Berndt]

Is this for lathe or? What's the use case?

-Dave


On Sun, 26 Apr 2020 16:42:03 -0400, andy pugh  wrote:


On Sun, 26 Apr 2020 at 20:56, nkp  wrote:


I want the interpreter to handle the compensation path, like this:

https://imgur.com/xs9e3BJ


So you want it to over-cut in slots where the tool won't fit?



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

Re: [Emc-users] Encoder reset on homing to index

[David Berndt]

Actually, this got me thinking a bit, the table is hard to yank around and  
get real results. But we can actually measure the spring in the system, if  
we have something rigid enough to push against. Stick a spring of known  
lb/in between your table and the frame or some other ill advised and  
unsafe practice. Then just compress it and compare the f-error of the  
rotary with the linear encoder.


Here's what happened when I stuck a 400lb/in spring in there and gave it a  
go.


Column-1 displacement/spring compression - inches
Column 2- f-error rotary (aka "spring" in the complete axis drive  
system)	- inches

Colump 3 - Theoretical Spring force - lbs
0   0   0
0.250.002   100
0.5 0.0025  200
0.750.003   300
1   0.0033  400
1.250.0037  500
1.5 0.004   600
1.750.0042  700
2   0.0047  800

I pulled the backlash out of the system and put a very light preload on  
the spring to hold it in place. Then I put on my face shield and hid  
behind the control cabinet and did the test.


-Dave

On Sun, 26 Apr 2020 15:49:16 -0400, David Berndt   
wrote:


There's about .0015-.002" of backlash and an .0005" spring in the system  
at reasonably force levels at the highest points of stiction on the  
ways. I'm sure I could get more spring out of the system if I run an  
endmill into the vise, but we're not really testing that here.


Ballscrews, precision Apex gearboxes, big metal couplings (whatever they  
brand is called) and reasonable ballscrew bearings, no belts, on a  
5000lb universal mill. It's stiffer than the average 6040 router.


Rotary scale works out to 254000/inch, Linear is 50800/inch. Running  
drives with +/-10v in torque mode.


I tuned the system to work with the linear scales only. It sucks in  
terms of following error compared to what I've achieved with the rotary.  
Getting the acceleration errors out is a challenge with the linear scale  
(probably because those acceleration errors are actually real as opposed  
to the rotary that has no idea what table position really is). Still  
~.001 following error isn't terrible.


I then took the tuned linear and turned the sum2'ing with the rotary  
back on, so both loops are running, then I crank up the I term on the  
linear pid and let that run. It seems to give good results. I can run  
with the linear scale as the feedback into axis.1.motor-pos-fb. But I've  
given up on homing to index. It's not something I need that badly and I  
can't justify any more machine downtime for it really.


I may consider instead of adding more I to the linear PID that perhaps I  
should play with the gain on the sum'ing of the two PID outputs. But I'm  
not sure that's useful. I also tried inserting the Linear PID result  
into the rotary BIAS, and although that worked it didn't do anything  
better than where I was at before.


Currently If I g2 a 2"dia circle at 20IPM (a normal feed rate for me)  
the follow error at reversal peaks at ~.0006" as the backlash is pulled  
out. It's an improvement for sure. My time now would be better spent on  
finding a new ballscrew.



-Dave


On Sun, 26 Apr 2020 13:34:14 -0400, Roland Jollivet  
 wrote:



No-one has mentioned the mechanics of the system.. (or have they?)

What is the mechanical coupling like between the stepper and the linear
scale. Obviously it's most susceptible to backlash and belt stretch.
If the stepper is holding fast, how much linear deviation can you get if
you try move the carriage to and fro?  (stiffness)
Also, how many steps/linear increment?



On Sun, 26 Apr 2020 at 16:47, dave engvall  wrote:


Not that I know much about this but: It is my understanding that the
rotary because it has less quantatization error does a better job on
control but unless your machine is very tight a poorer job on position.
Early on I tried my machine with a 5 um linear glass scale. It was very
difficult to tune. Later on tuning with a rotary encoder was a cinch by
comparison. I've not tried both scales yet but that is where I'm  
headed.
Conversation with Stu and the group that did the installation might  
shed

some light. Does the information  coming off the sensors need to be
reallocated. Just thinking(?) out loud.

On my machine, a well worn BP size, using I has never given me better
following error. I get by with P, FF1, FF2, zero or very small D and  
no I.


just my tuppence!

Dave

On 4/25/20 10:56 PM, David Berndt wrote:
> The rotary loop works fine by itself.
>
> The linear loop, as it's just an I term is pretty useless/non
> functional by itself. Maybe you could argue it's ok for really small
> values of I, but then the settling time when using both PID loops
> combined is terrible. I was under the impression that was as
> designed/expected based on the
>
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Combining_Two_Feedback_Devices_On_One_Axis
>
> Side question. When doing touchoff/tool touchoff is commanded  

Re: [Emc-users] Encoder reset on homing to index

[David Berndt]

There's about .0015-.002" of backlash and an .0005" spring in the system  
at reasonably force levels at the highest points of stiction on the ways.  
I'm sure I could get more spring out of the system if I run an endmill  
into the vise, but we're not really testing that here.


Ballscrews, precision Apex gearboxes, big metal couplings (whatever they  
brand is called) and reasonable ballscrew bearings, no belts, on a 5000lb  
universal mill. It's stiffer than the average 6040 router.


Rotary scale works out to 254000/inch, Linear is 50800/inch. Running  
drives with +/-10v in torque mode.


I tuned the system to work with the linear scales only. It sucks in terms  
of following error compared to what I've achieved with the rotary. Getting  
the acceleration errors out is a challenge with the linear scale (probably  
because those acceleration errors are actually real as opposed to the  
rotary that has no idea what table position really is). Still ~.001  
following error isn't terrible.


I then took the tuned linear and turned the sum2'ing with the rotary back  
on, so both loops are running, then I crank up the I term on the linear  
pid and let that run. It seems to give good results. I can run with the  
linear scale as the feedback into axis.1.motor-pos-fb. But I've given up  
on homing to index. It's not something I need that badly and I can't  
justify any more machine downtime for it really.


I may consider instead of adding more I to the linear PID that perhaps I  
should play with the gain on the sum'ing of the two PID outputs. But I'm  
not sure that's useful. I also tried inserting the Linear PID result into  
the rotary BIAS, and although that worked it didn't do anything better  
than where I was at before.


Currently If I g2 a 2"dia circle at 20IPM (a normal feed rate for me) the  
follow error at reversal peaks at ~.0006" as the backlash is pulled out.  
It's an improvement for sure. My time now would be better spent on finding  
a new ballscrew.



-Dave


On Sun, 26 Apr 2020 13:34:14 -0400, Roland Jollivet  
 wrote:



No-one has mentioned the mechanics of the system.. (or have they?)

What is the mechanical coupling like between the stepper and the linear
scale. Obviously it's most susceptible to backlash and belt stretch.
If the stepper is holding fast, how much linear deviation can you get if
you try move the carriage to and fro?  (stiffness)
Also, how many steps/linear increment?



On Sun, 26 Apr 2020 at 16:47, dave engvall  wrote:


Not that I know much about this but: It is my understanding that the
rotary because it has less quantatization error does a better job on
control but unless your machine is very tight a poorer job on position.
Early on I tried my machine with a 5 um linear glass scale. It was very
difficult to tune. Later on tuning with a rotary encoder was a cinch by
comparison. I've not tried both scales yet but that is where I'm headed.
Conversation with Stu and the group that did the installation might shed
some light. Does the information  coming off the sensors need to be
reallocated. Just thinking(?) out loud.

On my machine, a well worn BP size, using I has never given me better
following error. I get by with P, FF1, FF2, zero or very small D and no  
I.


just my tuppence!

Dave

On 4/25/20 10:56 PM, David Berndt wrote:
> The rotary loop works fine by itself.
>
> The linear loop, as it's just an I term is pretty useless/non
> functional by itself. Maybe you could argue it's ok for really small
> values of I, but then the settling time when using both PID loops
> combined is terrible. I was under the impression that was as
> designed/expected based on the
>
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Combining_Two_Feedback_Devices_On_One_Axis
>
> Side question. When doing touchoff/tool touchoff is commanded position
> or actual position used?
>
>
>
> Maybe I'll look at a different PID strategy. Perhaps I could add the
> pid.y2.error value from the linear encoder to the pid.Y.command then
> the servo encoder will really have its thumb in the tuning pie. The
> linear encoder won't have to run any actual gain, just spit out the
> current error vs commanded.
>
> -Dave
>
>
> On Sat, 25 Apr 2020 23:44:46 -0400, Peter C. Wallace 
> wrote:
>
>> On Sat, 25 Apr 2020, David Berndt wrote:
>>
>>> Date: Sat, 25 Apr 2020 23:13:59 -0400
>>> From: David Berndt 
>>> To: Peter C. Wallace 
>>> Cc: "Enhanced Machine Controller (EMC)"
>>> 
>>> Subject: Re: [Emc-users] Encoder reset on homing to index
>>> Resent-Date: Sat, 25 Apr 2020 23:39:11 -0400
>>> Resent-From: "David Berndt" 
>>> Resent-To: "emc-users@lists.sourceforge.net"
>>> 
>>> Resent-cc: "Peter C. Wallace" 
>>>  Trying this again for the second time, no more attachmen

Re: [Emc-users] Encoder reset on homing to index

[David Berndt]

The rotary loop works fine by itself.

The linear loop, as it's just an I term is pretty useless/non functional  
by itself. Maybe you could argue it's ok for really small values of I, but  
then the settling time when using both PID loops combined is terrible. I  
was under the impression that was as designed/expected based on the  
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Combining_Two_Feedback_Devices_On_One_Axis


Side question. When doing touchoff/tool touchoff is commanded position or  
actual position used?




Maybe I'll look at a different PID strategy. Perhaps I could add the  
pid.y2.error value from the linear encoder to the pid.Y.command then the  
servo encoder will really have its thumb in the tuning pie. The linear  
encoder won't have to run any actual gain, just spit out the current error  
vs commanded.


-Dave


On Sat, 25 Apr 2020 23:44:46 -0400, Peter C. Wallace   
wrote:



On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 23:13:59 -0400
From: David Berndt 
To: Peter C. Wallace 
Cc: "Enhanced Machine Controller (EMC)"  


Subject: Re: [Emc-users] Encoder reset on homing to index
Resent-Date: Sat, 25 Apr 2020 23:39:11 -0400
Resent-From: "David Berndt" 
Resent-To: "emc-users@lists.sourceforge.net"  


Resent-cc: "Peter C. Wallace" 
 Trying this again for the second time, no more attachments, only a  
google photos link. I really mean it this time.

https://photos.app.goo.gl/xMK4Ep69i1SpznC58

Here are some halscope screenshots. Would saving the halscope data and
distributing that be better/prefered? Not sure what the policy is here.


This isn't really revealing much to me. All the index-enables fire,
commands go to zero, feedback goes to 0 and then the PID.y.output takes
off, PID.y2(linear).output eventually catches on and doesn't do anything
to help, seems to add fuel to the fire instead of acting in an opposite
direction it should.

Please see screenshots, any thoughts are appreciated.

-Dave



The runaway almost suggests you have one PID loop with negative feedback  
and one with positive feedback. Have you tried each loop individually?





On Sat, 25 Apr 2020 14:44:54 -0400, Peter C. Wallace 
wrote:


On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 14:21:45 -0400
From: David Berndt 
To: "Enhanced Machine Controller (EMC)"  
,

   Peter C. Wallace 
Subject: Re: [Emc-users] Encoder reset on homing to index
Thanks for the feedback Peter.
 I took the time to re-order my hal file (it's a bit of a disaster  
with all the other non motion going-ons in there).

 Here is the relevant start of m addf's
  addf hm2_5i25.0.read  servo-thread
addf motion-command-handler   servo-thread
addf motion-controllerservo-thread
addf pid.x.do-pid-calcs   servo-thread
addf pid.y.do-pid-calcs   servo-thread #rotary
addf pid.y2.do-pid-calcs  servo-thread #linear
addf pid.z.do-pid-calcs   servo-thread
addf pid.a.do-pid-calcs   servo-thread
addf pid.s.do-pid-calcs   servo-thread
 addf sum2.3   servo-thread#pid.y.output  
+pid.y2.output -> 'y-output' -> hm2_5i25.0.7i77.0.1.analogout1

 addf hm2_5i25.0.write servo-thread
  I excluded all the stuff below which is are things like servo amp  
ready, amp fault, coolant, spindle speed, spindle amp draw, f-error  
tracking, stuff that happens in servo-thread but isn't exciting or  
relevant to motion in a realtime way.
 Yes, PID.y.index-enable, pid.y2.index-enable,  
hm2encoder.03.index-enable, and hm2...encoder.01.index-enable are  
all plumbed up and I show them going TRUE during homing.
 When I went out to the cold mill this AM and started fooling around  
I noticed I was getting some following errors even in my previously  
configured "acceptable" config which was driving axis.1.motor-pos-fb  
from the rotary encoder still. Some hal-scoping around shows that  
maybe with the change I need some re-tuning at higher speeds.
 The need for retuning made me think that perhaps if the tuning was  
questionable and that lead to a bit of runaway condition at higher  
speeds then perhaps if I just decreased the max speed and tried  
assigning the linear encoder pos fb to axis pos fb I might see an  
improvement.
 So I did that, and it did. I'm now jogging back and forth at half  
the old max speed and doing some basic G-code tests with the linear  
axis being axis.1.motor-pos-fb. Which is nice because the GUI  
displays more enjoyable numbers.
 I'm not sure which change contributed to what, HAL reorder/cleanup,  
or tuning.
  My homing situation hasn't really changed. I still have to home  
twice to get a completed homing cycle. I once got persistent runaway  
after homing (caught quickly by f-error), but it wasn't self  
correcting, turning the machine on again (f2) just led to another  
immediate runaway. Restarted linuxcnc to try again and all was well.  
Interesting problems.
  So as it stan

Re: [Emc-users] Encoder reset on homing to index

[David Berndt]

Trying this again for the second time, no more attachments, only a google  
photos link. I really mean it this time.

https://photos.app.goo.gl/xMK4Ep69i1SpznC58

Here are some halscope screenshots. Would saving the halscope data and
distributing that be better/prefered? Not sure what the policy is here.


This isn't really revealing much to me. All the index-enables fire,
commands go to zero, feedback goes to 0 and then the PID.y.output takes
off, PID.y2(linear).output eventually catches on and doesn't do anything
to help, seems to add fuel to the fire instead of acting in an opposite
direction it should.

Please see screenshots, any thoughts are appreciated.

-Dave



On Sat, 25 Apr 2020 14:44:54 -0400, Peter C. Wallace 
wrote:


On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 14:21:45 -0400
From: David Berndt 
To: "Enhanced Machine Controller (EMC)"  
,

Peter C. Wallace 
Subject: Re: [Emc-users] Encoder reset on homing to index
 Thanks for the feedback Peter.

I took the time to re-order my hal file (it's a bit of a disaster with  
all the other non motion going-ons in there).


Here is the relevant start of m addf's


addf hm2_5i25.0.read  servo-thread
addf motion-command-handler   servo-thread
addf motion-controllerservo-thread
addf pid.x.do-pid-calcs   servo-thread
addf pid.y.do-pid-calcs   servo-thread #rotary
addf pid.y2.do-pid-calcs  servo-thread #linear
addf pid.z.do-pid-calcs   servo-thread
addf pid.a.do-pid-calcs   servo-thread
addf pid.s.do-pid-calcs   servo-thread

addf sum2.3   servo-thread#pid.y.output  
+pid.y2.output -> 'y-output' -> hm2_5i25.0.7i77.0.1.analogout1


addf hm2_5i25.0.write servo-thread


I excluded all the stuff below which is are things like servo amp  
ready, amp fault, coolant, spindle speed, spindle amp draw, f-error  
tracking, stuff that happens in servo-thread but isn't exciting or  
relevant to motion in a realtime way.


Yes, PID.y.index-enable, pid.y2.index-enable,  
hm2encoder.03.index-enable, and hm2...encoder.01.index-enable are  
all plumbed up and I show them going TRUE during homing.


When I went out to the cold mill this AM and started fooling around I  
noticed I was getting some following errors even in my previously  
configured "acceptable" config which was driving axis.1.motor-pos-fb  
from the rotary encoder still. Some hal-scoping around shows that maybe  
with the change I need some re-tuning at higher speeds.


The need for retuning made me think that perhaps if the tuning was  
questionable and that lead to a bit of runaway condition at higher  
speeds then perhaps if I just decreased the max speed and tried  
assigning the linear encoder pos fb to axis pos fb I might see an  
improvement.


So I did that, and it did. I'm now jogging back and forth at half the  
old max speed and doing some basic G-code tests with the linear axis  
being axis.1.motor-pos-fb. Which is nice because the GUI displays more  
enjoyable numbers.


I'm not sure which change contributed to what, HAL reorder/cleanup, or  
tuning.



My homing situation hasn't really changed. I still have to home twice  
to get a completed homing cycle. I once got persistent runaway after  
homing (caught quickly by f-error), but it wasn't self correcting,  
turning the machine on again (f2) just led to another immediate  
runaway. Restarted linuxcnc to try again and all was well. Interesting  
problems.



So as it stands now, homing (i have no idea what to actually  
try/change, it's broken but also kind of fine...) , and more tuning  
(assuming it's not a fools errand to change tuning with the addition of  
a linear scale...) are my next steps.




-Dave



I suspect you will have to track down whats going on with halscope  
(triggered by index-enable going low) and monitor the commanded  
position, feedback position

and PID output



On Sat, 25 Apr 2020 09:44:14 -0400, Peter C. Wallace   
wrote:



On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 03:23:20 -0400
From: David Berndt 
Reply-To: "Enhanced Machine Controller (EMC)"
   
To: "Enhanced Machine Controller (EMC)"  


Subject: Re: [Emc-users] Encoder reset on homing to index
After a few more hours tonight putzing around with this thing. Here's  
where I'm at.
 I've wired up the shared index. It completes both the encoder's  
index-enable cycles. encoder.NRotary.position and  
encoder.nLinear.position both reset to ~0. Home is also at 0 as is  
homeoffset, so once index is found there should be no need for the  
axis to move. However it takes off and gets caught by a fairly strict  
ferror.
 If I then home it again the result seems to be close enough that the  
small post-index-enable completion jump is within f-error. The axis  
moves a few .001" and settles. I'm not sure what's causing this jump  
in the first/second homing. Because of the ferror the first homing  

Re: [Emc-users] Encoder reset on homing to index

[David Berndt]

Thanks for the feedback Peter.

I took the time to re-order my hal file (it's a bit of a disaster with all  
the other non motion going-ons in there).


Here is the relevant start of m addf's


addf hm2_5i25.0.read  servo-thread
addf motion-command-handler   servo-thread
addf motion-controllerservo-thread
addf pid.x.do-pid-calcs   servo-thread
addf pid.y.do-pid-calcs   servo-thread #rotary
addf pid.y2.do-pid-calcs  servo-thread #linear
addf pid.z.do-pid-calcs   servo-thread
addf pid.a.do-pid-calcs   servo-thread
addf pid.s.do-pid-calcs   servo-thread

addf sum2.3   servo-thread#pid.y.output +pid.y2.output  
-> 'y-output' -> hm2_5i25.0.7i77.0.1.analogout1


addf hm2_5i25.0.write servo-thread


I excluded all the stuff below which is are things like servo amp ready,  
amp fault, coolant, spindle speed, spindle amp draw, f-error tracking,  
stuff that happens in servo-thread but isn't exciting or relevant to  
motion in a realtime way.


Yes, PID.y.index-enable, pid.y2.index-enable,  
hm2encoder.03.index-enable, and hm2...encoder.01.index-enable are all  
plumbed up and I show them going TRUE during homing.


When I went out to the cold mill this AM and started fooling around I  
noticed I was getting some following errors even in my previously  
configured "acceptable" config which was driving axis.1.motor-pos-fb from  
the rotary encoder still. Some hal-scoping around shows that maybe with  
the change I need some re-tuning at higher speeds.


The need for retuning made me think that perhaps if the tuning was  
questionable and that lead to a bit of runaway condition at higher speeds  
then perhaps if I just decreased the max speed and tried assigning the  
linear encoder pos fb to axis pos fb I might see an improvement.


So I did that, and it did. I'm now jogging back and forth at half the old  
max speed and doing some basic G-code tests with the linear axis being  
axis.1.motor-pos-fb. Which is nice because the GUI displays more enjoyable  
numbers.


I'm not sure which change contributed to what, HAL reorder/cleanup, or  
tuning.



My homing situation hasn't really changed. I still have to home twice to  
get a completed homing cycle. I once got persistent runaway after homing  
(caught quickly by f-error), but it wasn't self correcting, turning the  
machine on again (f2) just led to another immediate runaway. Restarted  
linuxcnc to try again and all was well. Interesting problems.



So as it stands now, homing (i have no idea what to actually try/change,  
it's broken but also kind of fine...) , and more tuning (assuming it's not  
a fools errand to change tuning with the addition of a linear scale...)  
are my next steps.




-Dave


On Sat, 25 Apr 2020 09:44:14 -0400, Peter C. Wallace   
wrote:



On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 03:23:20 -0400
From: David Berndt 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)"  


Subject: Re: [Emc-users] Encoder reset on homing to index
 After a few more hours tonight putzing around with this thing. Here's  
where I'm at.


I've wired up the shared index. It completes both the encoder's  
index-enable cycles. encoder.NRotary.position and  
encoder.nLinear.position both reset to ~0. Home is also at 0 as is  
homeoffset, so once index is found there should be no need for the axis  
to move. However it takes off and gets caught by a fairly strict ferror.


If I then home it again the result seems to be close enough that the  
small post-index-enable completion jump is within f-error. The axis  
moves a few .001" and settles. I'm not sure what's causing this jump in  
the first/second homing. Because of the ferror the first homing attempt  
does not actually complete the homing cycle, ishomed is not set.


For the homing thing, I may setup a mux to turn off the  
pid.yLinear.output. Maybe leave it off until everythings homed, or  
everythings homed + some time, or some other benchmark. My machine  
spends very little of it's time in an unhomed state and the control  
tends to stay on 99% of the time so homing/rehoming isn't really much  
of a priority. Or maybe abandon indexed homing.



It would also be nice to be able to feed pid.yLinear.feedback into  
axis.1.motor-pos-fb. But that's a recipe for the axis taking  
off/tripping ferror instantly. I'm not sure why, I can watch the  
pid.yRotary.feedback and pidyLinear.feedback and they're quite close to  
each other. I think this works fine pre-homed and breaks after homing  
but I'd have to re-run that experiment to be sure. Seeing the machine  
@actual position being off a few thou is really disconcerting. I can  
always press the @ to switch to machine commanded, which is (hopefully,  
if the linear is more accurate) much closer to reality.



-Dave


Is the index enable signal wired to both PID components in hal?

Re: [Emc-users] Encoder reset on homing to index

[David Berndt]

After a few more hours tonight putzing around with this thing. Here's  
where I'm at.


I've wired up the shared index. It completes both the encoder's  
index-enable cycles. encoder.NRotary.position and encoder.nLinear.position  
both reset to ~0. Home is also at 0 as is homeoffset, so once index is  
found there should be no need for the axis to move. However it takes off  
and gets caught by a fairly strict ferror.


If I then home it again the result seems to be close enough that the small  
post-index-enable completion jump is within f-error. The axis moves a few  
.001" and settles. I'm not sure what's causing this jump in the  
first/second homing. Because of the ferror the first homing attempt does  
not actually complete the homing cycle, ishomed is not set.


For the homing thing, I may setup a mux to turn off the  
pid.yLinear.output. Maybe leave it off until everythings homed, or  
everythings homed + some time, or some other benchmark. My machine spends  
very little of it's time in an unhomed state and the control tends to stay  
on 99% of the time so homing/rehoming isn't really much of a priority. Or  
maybe abandon indexed homing.



It would also be nice to be able to feed pid.yLinear.feedback into  
axis.1.motor-pos-fb. But that's a recipe for the axis taking off/tripping  
ferror instantly. I'm not sure why, I can watch the pid.yRotary.feedback  
and pidyLinear.feedback and they're quite close to each other. I think  
this works fine pre-homed and breaks after homing but I'd have to re-run  
that experiment to be sure. Seeing the machine @actual position being off  
a few thou is really disconcerting. I can always press the @ to switch to  
machine commanded, which is (hopefully, if the linear is more accurate)  
much closer to reality.



-Dave


On Fri, 24 Apr 2020 20:01:26 -0400, David Berndt   
wrote:


The rotary encoder is supplying it's own power (+5v) as it's the encoder  
relay/output from an amplifier and not directly from the rotary encoder.  
The linear encoder is using the inbuilt 7i77 5v. Common ground, at least  
I assume all the encoder inputs have a common ground... So I guess  
jumpering the index over shouldn't be a big deal.


Feels a bit unsatisfying though. I understand the timing issues (though  
I'm not sure with a slow homing cycle I should care) but not solving  
this in a reasonably elegant way in software seems like a fail to me.  
Maybe that's just the Covid Crankiness talking.


-Dave



On Fri, 24 Apr 2020 19:23:18 -0400, Peter C. Wallace   
wrote:



On Fri, 24 Apr 2020, David Berndt wrote:


Date: Fri, 24 Apr 2020 19:02:54 -0400
From: David Berndt 
To: "Enhanced Machine Controller (EMC)"  
,

Peter C. Wallace 
Subject: Re: [Emc-users] Encoder reset on homing to index
 If I understand you correctly that would be the goal. But how do I  
tie them together?


As I understand it now I'll need to detect when index-enable changes  
state to false, as an indication of the preferred index signal being  
detected. Then fire a oneshot to encoder.LinearNumber.reset



I was suggesting that you wire the preferred physical index signal
to both encoder inputs, Then connect motions index-enable pin to both
encoder index enables in hal, no one-shots or resets involved.

In general you would not want to do a physical encoder counter reset
in hal (at least when in motion) because:

1. Its not synchronized with the actual index signal so it will cause a  
somewhat random count error proportional to velocity (random because
the time of index occurance is random compared to the counter reset at  
the servo-thread write time)


2. Resetting the counter will corrupt the velocity calculation



-Dave



On Fri, 24 Apr 2020 18:20:07 -0400, Peter C. Wallace   
wrote:



On Fri, 24 Apr 2020, David Berndt wrote:


Date: Fri, 24 Apr 2020 17:19:10 -0400
From: David Berndt 
Reply-To: "Enhanced Machine Controller (EMC)"
   
To: emc-users@lists.sourceforge.net
Subject: [Emc-users] Encoder reset on homing to index
Can anyone enlighten me as to how hm2_5i25.0.encoder.N.position  
seems to get reset during homing to index? I assume somethnig is  
triggering hm2_5i25.0.encoder.N.reset? But I don't see that plumbed  
up anywhere in my HAL.
 I'm adding a linear encoder to a servo axis and am retaining my  
servo homing, but when it homes I need to zero the linear encoder as  
well if the rotary is going to zero to avoid huge f-errors and other  
issues...

 Thanks,
-Dave


 Why dont you use the preferred index signal to zero both encoders?


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

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


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy 

Re: [Emc-users] Encoder reset on homing to index

[David Berndt]

The rotary encoder is supplying it's own power (+5v) as it's the encoder  
relay/output from an amplifier and not directly from the rotary encoder.  
The linear encoder is using the inbuilt 7i77 5v. Common ground, at least I  
assume all the encoder inputs have a common ground... So I guess jumpering  
the index over shouldn't be a big deal.


Feels a bit unsatisfying though. I understand the timing issues (though  
I'm not sure with a slow homing cycle I should care) but not solving this  
in a reasonably elegant way in software seems like a fail to me. Maybe  
that's just the Covid Crankiness talking.


-Dave



On Fri, 24 Apr 2020 19:23:18 -0400, Peter C. Wallace   
wrote:



On Fri, 24 Apr 2020, David Berndt wrote:


Date: Fri, 24 Apr 2020 19:02:54 -0400
From: David Berndt 
To: "Enhanced Machine Controller (EMC)"  
,

Peter C. Wallace 
Subject: Re: [Emc-users] Encoder reset on homing to index
 If I understand you correctly that would be the goal. But how do I tie  
them together?


As I understand it now I'll need to detect when index-enable changes  
state to false, as an indication of the preferred index signal being  
detected. Then fire a oneshot to encoder.LinearNumber.reset



I was suggesting that you wire the preferred physical index signal
to both encoder inputs, Then connect motions index-enable pin to both
encoder index enables in hal, no one-shots or resets involved.

In general you would not want to do a physical encoder counter reset
in hal (at least when in motion) because:

1. Its not synchronized with the actual index signal so it will cause a  
somewhat random count error proportional to velocity (random because
the time of index occurance is random compared to the counter reset at  
the servo-thread write time)


2. Resetting the counter will corrupt the velocity calculation



-Dave



On Fri, 24 Apr 2020 18:20:07 -0400, Peter C. Wallace   
wrote:



On Fri, 24 Apr 2020, David Berndt wrote:


Date: Fri, 24 Apr 2020 17:19:10 -0400
From: David Berndt 
Reply-To: "Enhanced Machine Controller (EMC)"
   
To: emc-users@lists.sourceforge.net
Subject: [Emc-users] Encoder reset on homing to index
Can anyone enlighten me as to how hm2_5i25.0.encoder.N.position seems  
to get reset during homing to index? I assume somethnig is triggering  
hm2_5i25.0.encoder.N.reset? But I don't see that plumbed up anywhere  
in my HAL.
 I'm adding a linear encoder to a servo axis and am retaining my  
servo homing, but when it homes I need to zero the linear encoder as  
well if the rotary is going to zero to avoid huge f-errors and other  
issues...

 Thanks,
-Dave


 Why dont you use the preferred index signal to zero both encoders?


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

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


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-users] Encoder reset on homing to index

[David Berndt]

If I understand you correctly that would be the goal. But how do I tie  
them together?


As I understand it now I'll need to detect when index-enable changes state  
to false, as an indication of the preferred index signal being detected.  
Then fire a oneshot to encoder.LinearNumber.reset


-Dave



On Fri, 24 Apr 2020 18:20:07 -0400, Peter C. Wallace   
wrote:



On Fri, 24 Apr 2020, David Berndt wrote:


Date: Fri, 24 Apr 2020 17:19:10 -0400
From: David Berndt 
Reply-To: "Enhanced Machine Controller (EMC)"

To: emc-users@lists.sourceforge.net
Subject: [Emc-users] Encoder reset on homing to index
 Can anyone enlighten me as to how hm2_5i25.0.encoder.N.position seems  
to get reset during homing to index? I assume somethnig is triggering  
hm2_5i25.0.encoder.N.reset? But I don't see that plumbed up anywhere in  
my HAL.


I'm adding a linear encoder to a servo axis and am retaining my servo  
homing, but when it homes I need to zero the linear encoder as well if  
the rotary is going to zero to avoid huge f-errors and other issues...


Thanks,
-Dave



Why dont you use the preferred index signal to zero both encoders?




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


Peter Wallace
Mesa Electronics


___
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] Encoder reset on homing to index

[David Berndt]

Just a plain KA300 chinese linear encoder.


On Fri, 24 Apr 2020 17:39:51 -0400, Leonardo Marsaglia  
 wrote:



Just because I'm curious,

Is this an absolute linear encoder or an incremental one (or may be it  
can

work in both ways)?

El vie., 24 abr. 2020 a las 18:28, andy pugh ()
escribió:


On Fri, 24 Apr 2020 at 22:21, David Berndt  wrote:
>
> Can anyone enlighten me as to how hm2_5i25.0.encoder.N.position seems  
to

> get reset during homing to index? I assume somethnig is triggering
> hm2_5i25.0.encoder.N.reset?

The encoder counts reset when encoder.N.index-enable is true and an
index is seen.
You can detect this as the index-enable goes false a the same time.

--
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-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] Encoder reset on homing to index

[David Berndt]

Index-enable enable is true when index-enable is false? Who designed this?  
Politicians?


I don't even know what to say as I try to wrap my mind around this one...  
Isn't there some sane/simple way to just tie the index-enable out bit from  
the one encoder to the index-enable in bit on the second encoder?


If I have to setup a whole bunch of oneshot shenanigans for this I'm going  
to be very disappointed.


-Dave

On Fri, 24 Apr 2020 17:25:00 -0400, andy pugh  wrote:


On Fri, 24 Apr 2020 at 22:21, David Berndt  wrote:


Can anyone enlighten me as to how hm2_5i25.0.encoder.N.position seems to
get reset during homing to index? I assume somethnig is triggering
hm2_5i25.0.encoder.N.reset?


The encoder counts reset when encoder.N.index-enable is true and an
index is seen.
You can detect this as the index-enable goes false a the same time.



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

[Emc-users] Encoder reset on homing to index

[David Berndt]

Can anyone enlighten me as to how hm2_5i25.0.encoder.N.position seems to  
get reset during homing to index? I assume somethnig is triggering  
hm2_5i25.0.encoder.N.reset? But I don't see that plumbed up anywhere in my  
HAL.


I'm adding a linear encoder to a servo axis and am retaining my servo  
homing, but when it homes I need to zero the linear encoder as well if the  
rotary is going to zero to avoid huge f-errors and other issues...


Thanks,
-Dave


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

Re: [Emc-users] best diy 4th axis

[David Berndt]

Heres a picture of the not very exciting square box I made that bolts  
together and holds the spinea unit in the horizontal plane. Some of the  
joints got scraped in and then the bottom was scraped for squareness with  
the spinea flange. You can see my overhung fixture bar is already attached.


https://photos.app.goo.gl/uPyBioiBrsJNtiVg6

Note the key use of gorilla tape on the outside of the ts200 and the last  
round of notes from measurement/scraping still on the unit. Regular  
duct-tape is not approved for cycloidal use.


Here's what happens when you drive your drill chuck into that pipe fixture  
from the side.


https://photos.app.goo.gl/zHxXurYgmY22msqb9


-Dave


On Wed, 01 Apr 2020 03:05:52 -0400, John Dammeyer   
wrote:



From: David Berndt [mailto:ber...@uberwin.com]
Alright, maybe i'm shooting myself in the foot here by inducing demand  
and

I won't be able to get any cheap ebay units in future, but here goes...

I bought a used spinea ts200 about a year ago and put a 750w servo on  
the

back of it, built an enclosure and use it primarily as a fixturing
positioner. It's awesome for my needs. 169:1 ratio. Position holding  
under

light milling (think 5hp or less is my experience, I don't have a 40hp
beast to test with)


Any pictures?



___
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] best diy 4th axis

[David Berndt]

Alright, maybe i'm shooting myself in the foot here by inducing demand and  
I won't be able to get any cheap ebay units in future, but here goes...


I bought a used spinea ts200 about a year ago and put a 750w servo on the  
back of it, built an enclosure and use it primarily as a fixturing  
positioner. It's awesome for my needs. 169:1 ratio. Position holding under  
light milling (think 5hp or less is my experience, I don't have a 40hp  
beast to test with)


I will say, from my limited 1 unit experience, the efficiency isn't great  
if you want to get anywhere near top speed you'll have to swap the grease,  
or heat the unit, or just put a honking big servo on there. I have trouble  
getting over 10RPM without the servo running beyond it's continuous duty  
zone. Maybe mine was filled with some sort of alternative grease in a past  
life, never opened it up to investigate. For positioning 10RPM is lots.


I'm impressed with the milling stiffness. I've overhung a heavy walled 5"  
square tube  about 20" from the face of ths TS200 and use it as a 4 sided  
fixture with no far end support and it still mills like a champ. I'm only  
doing 2hp or less cuts in aluminum on that fixture, and I'm sure it'd be  
better with a tailstock, but it's run for hundreds of hours making parts  
without so far. The cross roller bearings in those units are quite  
something.


I haven't hooked up a brake of any sort, doesn't seem needed it for my use  
cases.


One thing to maybe look out for if you care a lot about positioning is the  
these units have an angular transmission accuracy error/window that looks  
something like +/- 17 arc seconds, differs for exact units, get specs from  
spinea for your model if you like.  So if you care about resolutions below  
that, or lost motion then another solution, or a high resolution encoder  
mounted on the output flange would be the way to go. I believe the strain  
gauge units have a similar but different accuracy issue, perhaps software  
compensation would even be possible?


I'm also of the impression that the tilting stiffness and torsional  
stiffness are significantly superior to the harmonic drives, but I could  
be totally off there.


-Dave


On Tue, 31 Mar 2020 23:03:11 -0400, andrew beck   
wrote:



Hey guys.

I have been thinking about my 4th axis I am going to make.

I have my cnc mill working now though there is still a bunch of work to  
get
done.  But I have been thinking about how I can make the best 4th axis  
and

after that 5th axis.

I have narrowed it down to either harmonic drives or Hypocycloidal gear
boxes.

I am thinking the hypocyloidal type looks the most rigid and best to make
as it looks like the it would be very easy to make on a cnc mill and a
harmonic drive relies on a thin strain wave gear that is not the
strongest.  I actually have a rather large one which I have been thinking
about using but I would like to go with a the hypocycloidal design  
instead.


all you guys out there with awesome cncs sitting in your sheds have you
ever built one of these?  I don't want to reinvent the wheel if I don't
have to.  And I am on the track to making my cnc a 5th axis when I get to
it.  First I will make the 4th axis and pump a bit of work through it and
make some money lol.  But 5 axis looks pretty fun and cool and I think it
is finally doable for the pro diy person.

I have all the toys like a surface grinder and lathes etc and of course  
the

cnc mill.

also don't mind spending money if needed as it is a business.

here are some links to get the ideas flowing

videos

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

fuson 360 scripts to generate the gear profile.


https://github.com/mawildoer/cycloidal_generator/blob/master/README.md
https://github.com/tapnair/Fusion360HypocycloidGear


and just to show that it has been done before I say that the new Hass
umc500 has cycloidal gearboxes in it so the design must be pretty good.

https://www.haascnc.com/machines/vertical-mills/universal-machine/models/umc-500.html


regards

Andrew

___
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] Open source CNC architecture

[David Berndt]

On Sat, 15 Feb 2020 01:56:44 -0500, Rafael Skodlar   
wrote:



On 2020-02-11 01:04, Chris Albertson wrote:
   I said people *want* to use CNC like a laser printer. Most  
setups are
not that good.  It is a goal and if designing a new system.  It is good  
to
set the bar high and try to do what can't be done today.What I  
really

meant was that with a printer, all the critical timing happens in the
printer.  There are no servo-loops on the PC and you don't need a  
real-time

OS to print to paper. I think people want CNC to work this way.



That's how some CNC machines work. I came across a small woodwork  
business owner with very nicely garage that was converted into workshop.  
Win PC in the corner for designing parts in CAD, large Axiom CNC machine  
with a pendant to control it. Tiny LCD is all that's needed to select  
the job, i.e. file from a USB stick.


The owner did not know what's inside the CNC machine itself and he  
doesn't care. That's what you say Chris I think and I agree with.


I don't know if there's an option for connecting that CNC machine to  
LAN. I would not use wireless connections for such as it's security  
issue due to hacking possibility in the neighborhood. Another  
possibility is noise on WhyFy frequencies from appliances, bad power  
lines, etc.


In any case, that CNC machine does not have or need a PC computer with  
modern GUI interface connected directly to run it. That's why I started  
this discussion. X-windows is waste of resources, it's another thing  
that needs to be maintained and updated in some instances. Too many  
things to go bad in what's supposed to be a relatively simple embedded  
system.


The tiniest user interface would be possible using extended ASCII  
characters as in old DOS. We used to play with that in old email  
signatures. My fun with ASCII art in the 1990s:




How did we get to the point where we decided that the goal is a  
"relatively simple embedded system"? I for one am not looking to trade off  
the current gui and it's features for what you describe.


It seems like a lot of this thread seems to steer itself in the machinekit  
direction in terms of apparent goals/ideals, so I guess I'd ask, why not  
start there?





 . ..   .  . . . . o o o o O o
   ___   ___   _  O
  |  Rafael Skodlar| |   LINUX   |   ]OO|_n_n__][.
  | ra...@mydomain.com |=|  Support  |=||=[]_|__|)<
   oo~~oo~   ~~oo~~~oo~~  oooo  'oo -| oo\_
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Add colors, lines, and block characters and ... you see the picture  
that's taking extremely little memory by today standards.
Simple ASCII DRO + G-code scroll window and 4x4 keypad would be enough  
for most work. No need for keyboard, mouse and X-windows on large  
monitor.



On Mon, Feb 10, 2020 at 3:06 PM Bari  wrote:

A laser printer is a good example of how people really want a CNC  
mill to
work.  You design you document on the computer then press "print" and  
the
printer creates it.   After the last of the data is moved to the  
printer

you can turn the PC off it you like.



Why it's not that simple:


https://www.machinedesign.com/3d-printing-cad/article/21122653/top-11-myths-of-cnc-machining


the article states:
Myth #4: G/M Code is a Thing of the Past

That's true too. It amazes me that the industry did not go away from  
primitive code by today standards. G-code was only modified or updated  
by some CNC machines manufacturers as far as I know but most of G-code  
is still the same. Compare that to computer/software advancements since  
1980s. Perl, php, python, Go, html, etc.


Using G-code is like writing computer programs in assembly language! It  
time to upgrade it to something like HP-GL with addition for Z and other  
axis obviously. Such a language would make it much easier for human(e)  
use. 4 to 6 letter long abbreviations for tool manipulation would still  
make code terse enough to fit on smaller LCD displays and we could  
remember the commands for small jobs after a while.


For start, HP-GL commands would need to be modified to accommodate  
relative or absolute CNC tool movement.


Magazine Digital Machinist has some very cool CNC related articles but  
you need to wait long for the next quarterly issue to follow them. None  
of the advertisers mention LCNC ;-(



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

Re: [Emc-users] question about glue

[David Berndt]

Not directly glue advise. But gear tooth sensor advise. Don't let the  
heads of those things rip off and go through my gear head mill's bevel  
gear teeth. Not pretty. No teeth broke but there is a surprising amount of  
quite hard metal in the middle of something like an Allegro ATS675 it  
seems. The gears were nowhere near silent before, but they're louder now  
for the experience.



-Dave

On Tue, 11 Feb 2020 13:27:48 -0500, Gene Heskett   
wrote:



Greetings all;

I went tp play with the lathe after reboot the rpi4 with cpu_freq raised
to 800 megs.

All of a sudden the spindle tach got noisy, then quit. removeing the
heads lid, I could see a good coat of the 5w20 I've been useing for
spindle oil had flung out of the side face of the bronze bearing and
given my encoder assembly a good coat of it.

Removeing it for a better look I found 2 of the 667's loose with signs of
the bull gear touching them, with one having vibrated enough to break
its wraping wire connections. They were glued into pockets machined in
the mounting bracket which if the glue worked had them spaced about 5
thou away from the bull gear in a curved alu bracket made of of 7075
scrap. I've made a wooden c clamp with a #6 wood screw which is
currently sitting with the point of the screw in the middle of the face
of the loose index generating 667 after the alu was well washed by
acetone and then filling its pocket in the bracket with shoe goop, same
stuff as go-2.  And tomorrow I'll do the same with the other.

Cleaned up with acetone of course.

Previous attempts to glue then in place with super glue were very short
lived, loose in a week.  Ditto with gelled super glue.

The go-2 lasted about 2 years.

What sort of glue can I use that can withstand an oily environment of
light 00w20 for many years?

Thanks all.

Cheers, Gene Heskett



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

[Emc-users] Backlash comp monitoring

[David Berndt]

Hello All,

I'm having a bit of an issue with some geometry not coming out as  
expected. I suspect it's related to backlash and cutting forces moving the  
table a bit but I don't have linear scales to monitor/correct for that  
sort of thing so I'm left wondering a bit. I was hoping that being able to  
see what backlash comp is doing on screen as my toolpaths run might  
enlighten me some. Is there any pin or ?? that can be monitored to give me  
more insight?



Thanks,
-Dave


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

Re: [Emc-users] Ebay Servo Drive

[David Berndt]

I'm confused by these sorts of drives. I guess for a 3060 or something...

But why don't people just spend the time and read up on older mitsubishi,  
sigma, automation direct (probably delta made?), delta, drives or their  
alibaba knockoffs then get those, there are tons around on ebay,  
aliexpress, etc. They're not significantly more expensive, sometimes  
cheaper even. They take straight mains voltage and they have more  
professional level features (step and direction, +/-10v, torque and speed  
modes, encoder count outputting, electronic gearing, often some sort of  
rs232 programming, about a billion settings to play with, a ton of IO  
usually 7 or 8 digital ins and another 7 or 8 digital outs, safety  
features, seperation of control circuitry from high power circuitry so you  
can count steps even when the high power is off for example if the machine  
is in e-stop. You get a lot more bang for your buck imo, and you save  
having get some sort of fairly large DC power supply.





On Tue, 12 Nov 2019 15:28:50 -0500, Marshland Engineering  
 wrote:



Just ordered one of these to try. Looks very promising.

https://www.ebay.com/itm/322460600468

Downloaded the software and that looks quite professional.

Anyone tried them before ? 80 volt 20 amps

or more power (Tim the tool man !!! )

150 volt 20 amps

https://www.ebay.com/itm/322460615556

and the Holy Grail !!!

https://www.ebay.com/itm/322393653446

Means that I can run from the parallel port !!!

Cheers Wallace.



___
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] Machine For Conversion?

[David Berndt]

Retrofit and keep all the fanuc hardware/motors?

Production shop or hobby?

What's your tolerance for a working machine vs a project?

Three Phase available?


I think the hardware looks snazzy, I'd dubious about it actually being  
bt35, guessing more like a 40 taper. For myself I'd strip the  
control/drives/motor and repower it with single phase capable more modern  
servos systems, but that's a very home-garage specific view of it.


Dave

On Wed, 06 Nov 2019 11:28:53 -0500, Todd Zuercher   
wrote:



How good of a candidate for conversion would an old YCI SuperMax 60A be.
We are considering buying this.
https://akroncanton.craigslist.org/bfs/d/cnc-vertical-machining-center-supermax/7010042462.html

Todd Zuercher
P. Graham Dunn Inc.
630 Henry Street
Dalton, Ohio 44618
Phone:  (330)828-2105ext. 2031


___
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] Detecting ESTOP and Machine ON/OFF in Axis user interface

[David Berndt]

iocontrol.0.user−enable−out

(Bit, Out) FALSE when an internal estop condition exists

iocontrol.0.user−request−enable

(Bit, Out) TRUE when the user has requested that estop be cleared


and

halui.machine.is−on bit out

pin for machine is On/Off


are what I've used in past I believe.





On Fri, 01 Nov 2019 00:20:23 -0400, John Dammeyer   
wrote:


OK.  So I grabbed the linuxcnc_master and unzipped it.  In the python  
section I've found the code that deals with the two buttons.

The class linuxcnc is reached through the
import linuxcnc
However, I can't find any code that defines
class linuxcnc:
def estop_clicked(event=None):
s.poll()
if s.task_state == linuxcnc.STATE_ESTOP:
c.state(linuxcnc.STATE_ESTOP_RESET)
else:
c.state(linuxcnc.STATE_ESTOP)
def onoff_clicked(event=None):
s.poll()
if s.task_state == linuxcnc.STATE_ESTOP_RESET:
c.state(linuxcnc.STATE_ON)
else:
c.state(linuxcnc.STATE_OFF)


I'm trying to find out what to put in the hal file that responds to the  
button press.  None of the pins appear to change when I click on it and  
hold it down.  Ie.  Nothing appears to change to TRUE from FALSE. Or the  
other way around.

Suggestions?
Thanks
John
"ELS! Nothing else works as well for your Lathe"
Automation Artisans Inc.
www dot autoartisans dot com

___
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] ESTOP and Machine Enable.

[David Berndt]

My take is E-stop is E-stop. It should remove high voltage to your  
drives/spindles. In some setups it might be a fairly unpleasant button to  
press, will your Z axis fall a little before the brake kicks in? Will your  
VFD hate you for suddenly disconnecting it from the mains and preventing  
it from doing whatever braking tricks it might normally do to slow down  
your spindle? Will all your drives lose position counting? etc.


When the system is out of estop but not Machine Power, all drives should  
have high voltage applied but their enable inputs should not be driven  
high. The machine cannot move. Things like amplifier error states need not  
really be dealt with here.


When power is turned on servo enable pins should be driven to true,  
whatever logic direction that is.


You may need to add some troubleshooting steps to when power-on goes true  
as some drives have errors that will need clearing, or other fun stuff. Do  
it all here when the power-on goes high. It's a safe time to do it, it  
makes sense for the drives to have a bit a few seconds of getting their  
crap together if necessary at power-on. There is no requirement that the  
machine go from power on to moving at 5m/s instantaneously. Once the  
machine is in the power-on state, the state of your amp-ready signals will  
start to be be taken into account by linuxcnc, so if an amp is in error,  
you won't be moving anyways...



If you're setup this way, you can hit power-off/F2 (Escape is not quite  
the same, canceled current event but does not go into power off) in the  
event of some bad code, chips in your keyboard, or whatever else and all  
your drive enables should drop and all motion stops, things become pretty  
safe, but electrically everything still connected. You haven't lost  
position/index counting, you haven't made anything unhappy by suddenly  
disconnecting it from HV mains in the way E-stop might. And you can save  
that big red E-stop button for the times you really need it, like in the  
event of potential injury.




That's my 2 cents.
-Dave


On Sun, 27 Oct 2019 15:43:04 -0400, John Dammeyer   
wrote:


What exactly is the difference in LinuxCNC with the red ESTOP button and  
the orange Machine ENABLE button?


MACH3 has only the RESET button which flashes when an ESTOP event like  
limit switch or other error and results in power removed from the  
drives.  Spindle should stop.  There's really no separate enable.


My feeling is the LinuxCNC Machine ENABLE button is separate from the  
ESTOP button. Clicking the orange ENABLE button only prevents CNC motion  
commands but isn't expected to remove Drive or System Power. That's  
reserved for the ESTOP which also disables the Charge Pump.


Clicking the ESTOP button would then switch off the high voltage to  
motors etc. and at the same time is also clears (switches off the  
ENABLE).   An ESTOP input would do the same.  While ESTOP is active the  
ENABLE button remains grey'd out and cannot be pressed to re-enable the  
system .  The ESTOP condition must first be removed.


But if all I do is click on the ENABLE button so it goes OFF then power  
should remain on the system?


Have I got that right?

Thanks
John Dammeyer






___
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] ESTOP Power Control

[David Berndt]

Maybe I'm lost... But do you need this? Control side of the drives is up  
and encoders are counting right? So why do the drives need to be ready to  
actually move just because you're going to send disable estop?


The machine still isn't in the "machine on" state, so drive enables aren't  
driven high yet anyways so why does it need to be ready to move when the  
ESTOP comes off?



Regards,
Dave


On Wed, 23 Oct 2019 20:16:39 -0400, John Dammeyer   
wrote:


I've added back the safety aspect of an ESTOP event shutting down all  
high voltages.  The low voltage 24V stays on as does the PC/Monitor and  
the AC to the PMDX-126 BoB.  Ie. I have two 220VAC circuits.  One for  
all the Motor power and one for the Control power.  Only the Motor Power  
is removed.
Now click on the little orange icon to re-enable the system, ENABLE goes  
active and the AC Motor Power Relay switches  ON.

Interlocks prevent this while:
1.  An ESTOP is still pressed
2.  Spindle Motor Switch is in ON position,
3.  Limit Switches are not in override if they were the cause of the  
ESTOP in the first place and are still activated.
The ENABLE from the PC goes through the BoB and out to the various  
drives.  This happens faster than the high voltage power supplies for  
the drives.

Is there a way to delay the ENABLE out?
Or will I be forced to build a circuit that makes sure the high voltages  
are within range and use the output of that to gate the ENABLE?

What's everyone else doing?
Thanks
John
"ELS! Nothing else works as well for your Lathe"
Automation Artisans Inc.
www dot autoartisans dot com

___
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] PROGRAM_PREFIX with spaces

[David Berndt]

Just wanted to drop a note to the to the group so that other's don't have  
to troubleshoot this maybe as much as I have.


Turns out it might not be a great idea to put spaces in the directories  
that will go in your program path. It prevents custom M Codes from running  
from that directory and they seem to fail silently.  Or if they don't fail  
silently, there doesn't seem to be any warning about it that I could find.


Removed the space from my "NC Files" directory to NCFiles and updated  
PROGRAM_PREFIX and now my custom m-codes work.


Everything else seems to work regarding that program prefix, I could open  
files, etc. Should I have escaped that space in the config file? If so  
what are the escape characters valid for the ini file?


-Dave



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

Re: [Emc-users] G54.1?

[David Berndt]

I'm not motivated enough to try to put this feature in myself, but would  
certainly make use of it. I have enough WCS's to survive as is, but feel a  
bit cramped...


I'm not really sure how this works for the linuxcnc project, but along the  
lines of bug bounties, I'd throw in 40$ CAD (a virtual case of beer if you  
will) to whomever makes this happen, especially if it could be patched  
into 2.7.8 or some other easy upgrade path (I have a stable machine and  
the idea of going to master scares me...). If this is some sort of faux  
paus then please ignore/pretend I'm not so ignorant.


Dave


On Wed, 02 Oct 2019 16:57:36 -0400, Todd Zuercher   
wrote:


I work with a lot of Fanuc machines and I was curious if there was any  
interest in the Linuxcnc community for having more work coordinate  
systems available similar to how Fanuc controls have their G54.1 option.
It works by adding a P code to a G54 command.  In the Fanuc system there  
are the usual G54-G59 then continues on with G54P1, G54P2... up to some  
large number (the limit depends on how much you paid for.)


I know Linuxcnc can sort of work around this by using axis offsets in  
the tool table like work coordinate system offsets, but it seems a  
little hacky.


Todd Zuercher
P. Graham Dunn Inc.
630 Henry Street
Dalton, Ohio 44618
Phone:  (330)828-2105ext. 2031


___
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] Methods of Homeing a rotary?

[David Berndt]

I'm just finishing up a rotary built with a 750w servo and Spinea TS 200  
and I plan to run a trunion style setup, so when that is level wrt to the  
Y axis, that's "home" imo.


I've be pondering this a bit as well. I'm thinking a Fadal style homing  
system might be best (I have no real fadal experience, but I saw one on  
the internet...).  If the plate was manually jogged to within a degree or  
so of level, lining up marks on the platen/body perhaps then a homing  
sequence could be started to find the next index mark. It seems to me that  
if you did the work to set the home offset fairly accurately once in the  
ini file, this sort of homing should be quite repeatable.


I'm not really sure how to figure out homing without a home switch though.  
I guess the home switch could just be virtual in a pyvcp panel or  
something and could be pressed when the alignment marks are close. But I'm  
open to other suggestions.





On Wed, 13 Mar 2019 18:55:15 -0400, andy pugh  wrote:


On Wed, 13 Mar 2019 at 22:29, Gene Heskett  wrote:


Since I've never put a home switch on a rotary,


Neither have I. It isn't often necessary. If I had something  without
rotational symmetry I would probably use a spirit level on the part...

When I have considered doing it I have thought in terms of a
semi-circular track and an opto-sensor. (so it never takes more than
180 degrees to home)



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

Re: [Emc-users] CNC Press Brake at TXRX Labs

[David Berndt]

Pretty interesting. But I know nothing about press brakes... Is the code  
run by some sort of step through procedure?


Presumably a press like this is much more versatile than a manual machine  
as messing with the back-gauges becomes unnecessary. Any other big  
advantages?


Do you have position feedback on the rams? Or just feedback on hydraulic  
valve position?


What would make the UI press-brake friendly?


Dave


On Mon, 04 Feb 2019 22:47:25 -0500, Chris Kelley   
wrote:



I've been working on retrofitting a CNC press brake at TXRX Labs in
Houston, TX.

It is current;y far enough along to make some parts, so I formed about  
200

aluminum box-like things that are used in pairs as covers for light pole
base plates.

Here's a video of forming a few of them:
https://www.youtube.com/watch?v=VHk05MQhoPU

The machine uses regular servo-motors for the 2-axis back-gauge and
servo-hydraulic valves for the two sides of the bending ram.  Most of the
ram motion is controlled by ClassicLadder and a mess of HAL components.

A new press-brake friendly UI is in progress.

For what it's worth, the parts being bent were cut on a CNC plasma table
(that I built) that also runs LinuxCNC.

___
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] Done with that panel code, with one exception

[David Berndt]

I could write a big email about this, and I will if you want to, just let  
me know. But I'll jump in here and agree with Chris. You're missing out  
not having a cad/cam package. You're not able to use your tools, or your  
time to optimum effect, and you're not getting the best end result that  
you could possibly get in most cases. Modern CAM software outputs some  
awesome tool paths and is worth having/using. Especially for a hobbyist  
imo.



Regards,
Dave


On Wed, 19 Dec 2018 01:01:39 -0500, Gene Heskett   
wrote:



On Tuesday 18 December 2018 20:51:43 Chris Albertson wrote:


On Tue, Dec 18, 2018 at 2:50 PM Gene Heskett 

wrote:

> On Tuesday 18 December 2018 12:57:07 Chris Albertson wrote:
> > Gene,
> >
> > You should learn to use CAM software.
>
> I've made several passes at learning one pkg or another, but after
> half an hour without making any real progress, I'm back to measuring
> and defining points and writing gcode by hand.

30 minutes is unrealistic.


No, whats unrealistic is that in 30 minutes I wasn't able to get 2 lines
to come together and be coupled so I could move the joint and begin to
approach what I wanted to with a realstic chance of actually getting the
trapezoid I was looking for. Doing that in gcode is extremely simple
because you can lay out the trapezoid in 3 or 4 minutes, its
automatically a straight line from point a to b, b to c, c to d, and d
to a, insert a small ramp down in the a to b run and stay there till
leaving the a again.. Check your measurements and do the tool_rad comp
in your code, but by using some weird air moves, it demanded 3x what the
docs say to even get it to load the code without yelling at me. G42,
once its working will automatically round the corners. Fiddling with the
lower run length gets me the trapezoid needed since I lay that stuff out
so one end is x.5750 and the other end is -.5750 so it automaticaly
symmetrical. I had lots more trouble getting lcnc to accept the g42 than
anything else. The time killer is fixing the typu's cause I can't see
near as well as I could with the cataracts, and instrumenting it to
verify I didn't forget to turn on the spindle while I'm doing motor
power off runs of nearly an hour each just to watch the backplot get
screwed because of a typu. If I run it all the way thru. Every such
mistake is of course another broken mill. It needs spindle rpm it
doesn't have when tops is 2500. For something like this 10k is more
usable and that would cut the execution time to 1/4 what it is now. 2500
just buries the tool in swarf.

I bought another z casting 3 or 4 years back, thinking of machining it to
clamp a 24k revs 1 horse motor in place of its gearbox and spindle, but
then I've not been able to find a truly concentric means of mounting a
1/8" collet and mill in its 1/4" spindle. I'll probably trip over
exactly what I need, someday, if I have sense enough left to recognize
it when I see it.

If I don't fall over first... So far I'm beating the odds, I've outlived
all the jerks I might have killed had it been legal at the time they
needed it. Most of that was 60 years ago. :) First wife's 1st husband. A
problem if there ever was one.


Takes about a week to learn to use
something like that.   But it's been 4 days now to make a simle "D"
cut out. If yousave a few days on every parts the payback is quick.
Plus you be able to make very complex, lofted parts with compound
curves.


Loft is not a problem even on that toy, z is the fastest axis by a factor
of at least 2, and I can with the drive mods I've made, use the full
height of an 18" post. And with doubled bronze z nuts, backlash might be
2 thou. Ditto for the ball screws for xy as I've restuffed those nuts
with oversized balls.


> > As an exercise I tried this,
> > took about 6 minutes.  Four steps Draw trapezoid, filet the
> > corners, select tool, generate g-code for tool path.  The
> > trapezoid is parametric so I can change the length by editing one
> > number.
>
> I'm about halfway there, and should be able to switch it to a db9/15
> size by throwing a software switch. But I'm also up to around 310
> LOC now. With the CAM program unrolling all the loops, this code
> would be 100K+ of build it from scratch to fix a typu in the cam
> drawings.






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

Re: [Emc-users] Spindle Encoder AEDR-8300 Encoder Ring

[David Berndt]

Ok, thanks guys. I'll go with a seperate encoder to pickup a once per  
rotation count. Are there any requirements about on/off span in relation  
to A/B. The "centering"  of the index pulse sounds like it could be a bit  
fiddly, and getting the pulse perfect would probably be difficult as well,  
presumably linuxcnc won't be comparing A/B to index for any reason, just  
needs that index pulse  (+A/B count scaled at 1RPS).



The gears certainly aren't going to change, that is the gear combo that  
drives from the gearbox to the spindle on my universal mill. They two sets  
of 35 degree spiral miter gears that are rigidly fixed, such that  
centerline isn't adjustable between the gears, so changing them to a set  
that would result in a 1:1 ratio would be quite the challenge and likely  
cost more than this old mill is worth. Gear pairings are 48/40 and 34/33.


Dave

On Thu, 29 Nov 2018 04:11:56 -0500, Peter Blodow  wrote:


Hello David,
how did this funny gear ratio come to be? Assuming it's tooth gears or a  
belt drive, can't you change it to 55/55 or 68/68 or some other 1/1  
ratio, which would solve this problem? Years ago, I made drawers full of  
gears for cases like this, letting my little mill make gears for itself,  
the large mill  and the lathe with MS Excel and a home made stepper  
program.

Peter


Am 29.11.2018 um 06:52 schrieb David Berndt:

Alright, Dragging this back up.

A knockoff Omron encoder showed up in the mail, well I assume It's a  
knockoff at this price. Mounted it, wired it up. But it's on the back  
of the mill and geared 68/55 to the actual spindle output.


So now the question is, what do I setup scaling to? Set scaling so that  
X pulses = one rotation? That seems to be the correct thing based on my  
reading. What if anything do I do with my index pulse then? It fires  
every 2000 counts, which is useful for keeping track of lost counts  
perhaps but not much else, as it doesn't repeat based on physical  
location on the spindle every rotation. Disconnect it and run a real  
once per rotation index? Contrive some sort of index scaling using  
oneshot or something crazy like that?


Regards,

Dave


On Thu, 01 Nov 2018 06:30:19 -0400, andy pugh   
wrote:



On Thu, 1 Nov 2018 at 03:31, David Berndt  wrote:

That doesn't sound particularly hopeful for me and my plans. I guess  
maybe

a more traditional/proven approach of a through-beam sensor with
interrupting disk and much much lower resolution encoder ring with
drilled/milled holes might be the way to go.


I think that the AEDR _ought_ to work. They are a commercial product,
after all.

Part of my problem was that I had no adjustment for sensor-to-target
spacing, and to make matters worse I had a sensor and a target on both
sides of the PCB (The PCB was sandwiched between two encoders, because
of the wacky idea I was experimenting with).

I mainly gave up because my (scratch built) motor turned out to be
rather too weak.



___
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] Spindle Encoder AEDR-8300 Encoder Ring

[David Berndt]

Alright, Dragging this back up.

A knockoff Omron encoder showed up in the mail, well I assume It's a  
knockoff at this price. Mounted it, wired it up. But it's on the back of  
the mill and geared 68/55 to the actual spindle output.


So now the question is, what do I setup scaling to? Set scaling so that X  
pulses = one rotation? That seems to be the correct thing based on my  
reading. What if anything do I do with my index pulse then? It fires every  
2000 counts, which is useful for keeping track of lost counts perhaps but  
not much else, as it doesn't repeat based on physical location on the  
spindle every rotation. Disconnect it and run a real once per rotation  
index? Contrive some sort of index scaling using oneshot or something  
crazy like that?


Regards,

Dave


On Thu, 01 Nov 2018 06:30:19 -0400, andy pugh  wrote:


On Thu, 1 Nov 2018 at 03:31, David Berndt  wrote:

That doesn't sound particularly hopeful for me and my plans. I guess  
maybe

a more traditional/proven approach of a through-beam sensor with
interrupting disk and much much lower resolution encoder ring with
drilled/milled holes might be the way to go.


I think that the AEDR _ought_ to work. They are a commercial product,
after all.

Part of my problem was that I had no adjustment for sensor-to-target
spacing, and to make matters worse I had a sensor and a target on both
sides of the PCB (The PCB was sandwiched between two encoders, because
of the wacky idea I was experimenting with).

I mainly gave up because my (scratch built) motor turned out to be
rather too weak.



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

Re: [Emc-users] Spindle Encoder AEDR-8300 Encoder Ring

[David Berndt]

I actually tried this technique previously using the ats675s but I  
couldn't get a satisfactory quadrature output, my gear teeth produced more  
like a 25-30% on time and 70% off, so clocking the two sensors for real  
quadrature was problematic and didn't really provide the result I was  
looking for, plus it put my sensors inside a pretty greasy/oily gearbox  
which didn't make adjusting things appealing or convenient. A single  
ATS601 was used with a small dimple in the gear face to pickup an index  
pulse, that did work pretty well.


I'm not trying to mount at the top of the spindle but need to leave room  
for drawbar equipment. I  guess I could mount a small toothed pulley/belt  
and bring something out the side to a traditional rotary encoder, but  
theres not a lot of mounting area, seems inconvnient, ugly, etc. With  
something lower profile like the AEDR lineup it might be do-able directly  
under the drawbar equipment.


Another alternative I do have is to pick up off a shaft stub that comes  
out the back of the Z column with a traditional rotary encoder, some lathe  
work and a mounting bracket. But that shaft is 2 gear pairs away from the  
spindle so there seems to be about a degree or so of backlash in the  
interface between it in the spindle, I haven't measured an exact amount  
yet. My guess is this won't be the worlds biggest issue, but doesn't sound  
ideal. I don't plan on doing much rigid tapping, but I can imagine some  
scenarios where having better spindle position information would be useful.


Dave

On Thu, 01 Nov 2018 12:36:04 -0400, Jon Elson   
wrote:



On 11/01/2018 03:09 AM, Chris Albertson wrote:
You don't want to block the hole in the spindle so you are looking for  
an

encoder with a large hole though it?Is that right?

If the spindle is belt or gear driven you could place the sensor on the
gear or pulley that drives the spindle.   You could also place a timing
belt puley on the spindle then drive the encoder with a 1:1 belt drive.
1:1 drive would allow using a 3 channel encoder


Yes, see :
http://pico-systems.com/bridge_spindle.html
I did this a number of years ago on my Bridgeport mill, but it could be  
done on a lathe as well.
These sensors are ideal for this purpose, as they have logic to detect  
the PASSING of the gear tooth, not just the presence/absence of a tooth.


Jon


___
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] Spindle Encoder AEDR-8300 Encoder Ring

[David Berndt]

Thanks Andy,

That doesn't sound particularly hopeful for me and my plans. I guess maybe  
a more traditional/proven approach of a through-beam sensor with  
interrupting disk and much much lower resolution encoder ring with  
drilled/milled holes might be the way to go.


But to make sure this AEDR thing is really dead. Any reason to believe the  
AEDR-831X single channel units, which are the only way the 36tpi units  
seem to be available, have the same actual reoslution restriction? If  
there is only one channel then are they really looking for a fixed line  
width? There would be no offset second sensor at a fixed pitch to require  
that. I have the space to mount two single channel units, build in a  
little adjustability in their mounting to get them "clocked" correctly to  
get a quadrature signal.


Anyone have any idea what an AEDR-8311 is? The data sheets I can find only  
detail 8xx0, no idea what the last 1 is for.


Any other options I should be looking at? I didn't see anything super  
compelling when I spent 3 hours of my life reading through the datasheets  
from the digikey optical sensors - reflective section. I'm working with a  
~2" ID mounting for my encoder ring, so options for adapting an off the  
shelf encoder ring seem low as not many are that large.


Dave


On Wed, 31 Oct 2018 16:48:46 -0400, andy pugh  wrote:


On Wed, 31 Oct 2018 at 19:00, David Berndt  wrote:


if so was it with one of the one channel output units
instead of 2 channels or how did you handle creating such a fine  
pattern?
Any other details about how it was done and how well or not well it  
works


I used a 2 channel. I ended up having a target laser-cut by a company
who specialise in PCB stencils.

This might currently be pretty inexpensive from China, for example:
https://www.seeedstudio.com/stencil.html

It never worked all that well, though. I rather struggled with
soldering the devices, as at the time I had no hot-air or reflow oven.



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

[Emc-users] Spindle Encoder AEDR-8300 Encoder Ring

[David Berndt]

Hi EMC folks and more specifically Andy Pugh,

I was hoping you could let me know which of the AEDR line you used and how  
fine a pattern you put on your encoder wheel on one of your lathes. It  
seems the reasonable options are the 36 LPI or 75LPI models, but I suspect  
you did less? if so was it with one of the one channel output units  
instead of 2 channels or how did you handle creating such a fine pattern?  
Any other details about how it was done and how well or not well it works  
would be appreciated.



Thanks,
Dave


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

[Emc-users] Newall DRO integration

[David Berndt]

Anyone have any experience integrating a Newall DRO into linuxcnc? I  
happened up a scale/read head for quite cheap with no display. It might be  
a useful tool for roughly calibrating axis, or doing whatever other random  
tasks in future. I don't necessarily need it to be part of a control loop  
at this point, I'm mostly just curious if it's practical to cook up  
reading circuitry and get the data in via some sort of Mesa card?


It's a Newaall Spherosyn.


Thanks,

Dave

--
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] Large servo selection

[David Berndt]

Hmm. Belting is a pretty interesting idea. Though for my application, the  
reverse motion of a crank/slider isn't a big negative.


I've also been toying with combining a few servos smaller servos to get  
the work done. I've got no great idea on that yet mechanically or  
electrically. But taking advantage of the maximum torque vs rated torque  
on a 750w drive times 2 or 3 would seem to get me into the appropriate  
numbers and the smaller drives are much easier to find in single phase.


Dave


On Wed, 11 Apr 2018 22:19:24 -0400, Dave Cole <linuxcncro...@gmail.com>  
wrote:


Consider using a timing belt drive. Not exactly a timing belt, but a  
cogged tooth belt.  They make cogged tooth belting specifically for  
linear actuators.
You can buy it several inches wide so 6 hp would not be a problem.   I  
did a servo drive setup to propel a machine carriage with such a belt.   
I think the belt was about 2 inches wide.  I think we used a 2 kw servo  
motor with a  gearbox.   It could produce about a thousand of pounds of  
pull.You can buy the belting by the meter or foot.  I think it is  
"AT" belting that is generally used for linear drives.   Belts tend to  
be a bit elastic when pulled hard so you may need a 3+ inch wide belt.
But it can certainly move quickly.   The cost for the belting is quite  
reasonable.



On 4/11/2018 3:21 PM, John Kasunich wrote:


On Wed, Apr 11, 2018, at 3:08 PM, John Kasunich wrote:


On Wed, Apr 11, 2018, at 10:30 AM, David Berndt wrote:

I'm looking to output about 1000lbf in a linear direction via a
crank/slider or ballscrew

You don't mention the stroke length.  Are you moving a few inches in a
fraction of a second, or several meters over several seconds?

On further thought...

Ballscrew requires unreasonably high RPM.

Crank is very non-linear, and has major problems as stroke exceeds a  
couple inches - longer stroke means longer crank which means more and  
more torque is required.  You never use more than a half-revolution of  
the crank, so some serious reduction will be needed between motor and  
crank.


Have you considered roller chain?  Keep the sprocket size small so the  
torque doesn't get crazy high, but you can use multiple revolutions of  
the sprocket to cover an unlimited stroke.  Still going to require a  
gearbox; for a 1000 lbf load you will need a few thousand in-lbs  (few  
hundred ft-lbs) of torque, which is a LOT for any motor.


Interesting engineering problem to be sure.



--
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] Large servo selection

[David Berndt]

I'd like this to be reasonably low effort. My biggest concern is single  
phase input. Control/response requirements are about as low as it gets.


I'm looking to output about 1000lbf in a linear direction via a  
crank/slider or ballscrew with peak speed of about 1m/s. So that's a real  
5hp of energy. Duty cycle will be low, and external active cooling can be  
provided if required. So things like steppers are out, I've never seen a  
stepper that outputs nearly that much, and I don't particular want to  
create a 4kw 80v dc power supply...


re: Control requirements, I really only need to start running at a  
particular speed and be able to return the system to a somewhat close stop  
position, which can be as simple/bad as a vfd with a switch and timed jog.  
Any extra control over the system that I can get would add capabilities  
though.


The goal here is to see if there are any industrial drives out there that  
might periodically pop up on ebay which are higher KW and single phase  
capable.I see units like the Parker Gemini GV/GV6-U12/H20 which claim  
single phase at 3.5kw and 5.9kw.


Dave


On Wed, 11 Apr 2018 09:24:32 -0400, Dave Cole <linuxcncro...@gmail.com>  
wrote:



How much time/work do you want to put into this motor/drive setup?
There are no really cheap large servo motor solutions unless you stumble  
into a deal on Ebay or a surplus marketplace.
Larger servos generally mean 3 phase inputs.   So that becomes an  
immediate issue.


If you can live with a VFD, your life will be much simpler to simply get  
a single phase input VFD and a suitable motor.
You can find 3 phase gearbox equipped motors on Ebay that can get you  
500 rpm max.


Dave



On 4/11/2018 2:01 AM, David Berndt wrote:
Wondering if anyone had any preference/experience/advise to share with  
single phase capable larger servos. I'm looking at an application for a  
3 to 5hp motor with a vfd, but if I could just get a servo to fill in  
that'd be nice. Gear reduction will be required, but something with  
more torque, needing less reduction will make things easier.Say ~500rpm  
as a goal maximum output.


I see things like Fanuc red cap servos (ai series? pulsecoder encoder)  
2.5kw kicking around ebay. Driving something like that would seem to be  
the challenge?


Thoughts? Suggestions? Previous experience?

Dave

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


--
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] Large servo selection

[David Berndt]

Wondering if anyone had any preference/experience/advise to share with  
single phase capable larger servos. I'm looking at an application for a 3  
to 5hp motor with a vfd, but if I could just get a servo to fill in that'd  
be nice. Gear reduction will be required, but something with more torque,  
needing less reduction will make things easier.Say ~500rpm as a goal  
maximum output.


I see things like Fanuc red cap servos (ai series? pulsecoder encoder)  
2.5kw kicking around ebay. Driving something like that would seem to be  
the challenge?


Thoughts? Suggestions? Previous experience?

Dave

--
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] TSC, grrrrr.

[David Berndt]

What? What exactly is the pitch/sizing on a USS bolt? Google doesn't  
really return much for a USS thread chart... UNS? 7/16-18? TSC was formed  
in 1938, perhaps you got their last piece of original stock?



On Mon, 02 Apr 2018 19:35:27 -0400, Gene Heskett   
wrote:



I rigged the 5C to ER-40 to the mills table, then found I needed a draw
bolt about 4" long to keep the R8 from rotating in the ER40 collet.  So
I saddled up and ran out to TSC, where I found the 7/16 bolts they had
were only grade 5.  So I got one and some washers to adjust the length
with, came back and found the bolt was USS while the butt end of the R8
was SAE.  So I'll have to round up some 1/2" A2 and put it all back in
the lathe to apply a g76 and make some SAE threads.

I also found I'll  need a better way to clamp it to the table, probably
by making a big v-block and a thick steel bar to clamp it into the V.

Some days I swear its not worth gnawing thru the straps to get up and pee
in the mornings. :(


--
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] ATS-667 again

[David Berndt]

Just a quick note to say the ATS601 seems to work quite well on inital  
testing. It can detect a small drilled hole in a shaft (think a full width  
peck from a 1/8" drill) without much trouble. If you're sensing  
something(s) that isn't a gear tooth and doesn't have to reject objects  
that aren't gear-tooth-like this may be the way to go.




On Sat, 27 Jan 2018 21:37:38 -0500, Gene Heskett <ghesk...@shentel.net>  
wrote:



On Saturday 27 January 2018 19:09:07 David Berndt wrote:

A new name, I'll say welcome in case no one else does.


I'll jump in here and be slightly off topic. I've recently been
setting up some ATS688s for spindle encoding on a big straight bevel
gear. Works great. Wish the duty cycle was a bit higher so I wouldn't
have to skew the A/B phases off 90 degrees. But the gear teeth aren't
square like the reference 60-0 target from the data sheet, so this was
pretty much as expected.

I also tried to use a ats668 to detect a drill hole on the gear shaft.
Forget it. Unless you're target really looks like a gear tooth an
ats668 is not what you want. Ordered some ats601s and 675s to try
instead for the index pulse.


I used ats-667's on the 60 tooth bull gear in my Sheldon lathe, used a
piece of 8-32 screw gooped to the side of the gear in line with a tooth
for an index generator. I gooped them into slots carved in the inside
face of a 1/2" thick alu plate carved to match the OD of the gear. So
they essentially can't move. They have worked well but no feedback to
the spindle, its a vfd drive.


Also keep the ats668 (and most others in the line I assume) mounted
fairly rigidly with short leads. I found when my mill head reversed
directions that some sort of magnetic coupling happens with the gear
teeth causing the sensor to vibrate and moved enough to hit the gear
briefly. I spent a couple hours trying to figure out if the torque
from reversal was moving that gear around, bad bearing, etc, until I
figured out it was the sensor moving. It's not super obvious when
you're staring deep into a mill-head head with a flashlight what's
going on.


Been there, done that, my sympathies.


On Sat, 27 Jan 2018 15:35:54 -0500, John Alexander Stewart

<ivatt...@gmail.com> wrote:
> Hi all;
>
> I am restarting an older CNC lathe conversion - an Emco Compact-8,
> fwiw.
>
> I have the 5i25 and 7i76, and 6 ats-667 sensors for spindle. (6,
> because if
> I only ordered 3, I'd end up breaking one, and shipping is
> expensive...)
>
> Any wiring issues I should be aware of?  Field voltage is about 8v;
> well within the range of the ATS-667. I have some small relays for
> driving the VFD for the spindle, also driven off of field power.
>
> The Emco spindle has a 40 tooth gear, and the aluminium pulley has a
> set screw, so I should be ok with that - 40 teeth should be more
> than enough, right?
>

Depends on how much stability and stiffness you want at the lower speeds,
and the "bandwidth" of the control circuit. I had an opto-interrupter
based rig under the cover where I wasn't able to machine more that 64
slots in the wheel, with a long one for index. The noise and such from
such a low slot count made it impossible to run much Pgain, around 3.5
IIRC. Because the pwm-servo is FAST, it and the motor responded to all
that noise, hammering the gear teeth in the 2 speed head something
awfull.

So here about 3 months ago, I ordered a 1000 line omron encoder from
fleabay for a $21 bill, and drilled into the rear shaft of the motor to
mount an an extension to drive this encoder, but found I had a
differential encoder whose signal levels weren't TTL. That was solved by
a couple of the dollar ea. rs485 transceivers, which had zero problems
at the motors wide open speed making TTL outputs to feed a 5i25. I had
to write a hal paragraph to determine the gears ratios in the 2 speed
spindle in order to scale it. Then because it has two speeds, cut a dent
in the rim of the gear shift knob and put 2 microswitches on it to tell
lcnc which gear it was in, and took advantage of those switches to add a
small offset to the otherwise zero between gears speed, so that between
gears the motor is turning about 20 rpm. With one of Jon's Pico systems
pwm-servo amps, which is a full 4 quadrant controller, I can be turning
1000 rpms, reach up and grab the knob and turn it, and by the time its
moved 5 degrees, the motor is down to 20 revs, the knob continues to
turn until the gears are touching again, and the knob might resist 50
milliseconds while the gears mesh and slide into position, and the motor
speed is restored to the same spindle rpms in a few milliseconds once
the knob is fully homed in the other gear. So I no longer have to stop
the spindle, manually grab and turn the spindle for gear mesh. Doesn't
yet work if the spindle isn't running.  I need to fix that...

I still use the opto kit on the spindle for its index pulse, but all the
two speed l

Re: [Emc-users] ATS-667 again

[David Berndt]

I'll jump in here and be slightly off topic. I've recently been setting up  
some ATS688s for spindle encoding on a big straight bevel gear. Works  
great. Wish the duty cycle was a bit higher so I wouldn't have to skew the  
A/B phases off 90 degrees. But the gear teeth aren't square like the  
reference 60-0 target from the data sheet, so this was pretty much as  
expected.


I also tried to use a ats668 to detect a drill hole on the gear shaft.  
Forget it. Unless you're target really looks like a gear tooth an ats668  
is not what you want. Ordered some ats601s and 675s to try instead for the  
index pulse.


Also keep the ats668 (and most others in the line I assume) mounted fairly  
rigidly with short leads. I found when my mill head reversed directions  
that some sort of magnetic coupling happens with the gear teeth causing  
the sensor to vibrate and moved enough to hit the gear briefly. I spent a  
couple hours trying to figure out if the torque from reversal was moving  
that gear around, bad bearing, etc, until I figured out it was the sensor  
moving. It's not super obvious when you're staring deep into a mill-head  
head with a flashlight what's going on.



On Sat, 27 Jan 2018 15:35:54 -0500, John Alexander Stewart  
 wrote:



Hi all;

I am restarting an older CNC lathe conversion - an Emco Compact-8, fwiw.

I have the 5i25 and 7i76, and 6 ats-667 sensors for spindle. (6, because  
if

I only ordered 3, I'd end up breaking one, and shipping is expensive...)

Any wiring issues I should be aware of?  Field voltage is about 8v; well
within the range of the ATS-667. I have some small relays for driving the
VFD for the spindle, also driven off of field power.

The Emco spindle has a 40 tooth gear, and the aluminium pulley has a set
screw, so I should be ok with that - 40 teeth should be more than enough,
right?

Thanks for any advice/war stories you are willing to give.

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

[Emc-users] Linuxcnc.var reset causes?

[David Berndt]

I recently restarted my machine after about a months uptime. Everything  
was working quite well until the window manager died (not really  
linuxcnc's problem). When I brought linuxcnc baack up all my work offsets,  
54,55,56,57 were used, were all 0. Super annoying I reset g56 and  
tested again and then restarted linuxcnc, again my work offsets weren't  
saved. I tried the same experiment again and it seems to have stuck this  
time.


So I guess my question is what the heck is going on...? I'm glad the tool  
table is in a different file because losing all that as well would be  
really annoyhing. Is there some step I need to be taking to save the work  
offsets? Should I not expect them to save forever and ever? Is there  
something that causes the linuxcnc.var file to be ignored? overwritten?  
explode?



Unrelated, sort of... I'm getting really tired of setting work offsets for  
offsets I'm not in and ruining other setups all the time. I'm running  
axis, not sure if this is handled differently in other gui's... Why if I'm  
in g56 when I hit touch off why is the default in the dropdown box for the  
WCS G54 and not the currently active WCS? Is there any way to change this?


--
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] Backlash compensation speed

[David Berndt]

I was having a backlash issue yesterday that lead me to wondering. How is  
backlash taken up? At rapid speed? At max acceleration? More? Less? What  
governs how the motion to backlash comp is taken up?


Kind of a moot point because it turned out my backlash problem was some  
loose bolts in a super inaccessible spot under the saddle... Good times.  
But still curious about the software side of things.


--
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] MDI edit/UI question

[David Berndt]

I jumped through the hoops of fire. It works.

Thanks for the patch and support.

Dave

On Thu, 24 Aug 2017 15:30:03 -0400, David Berndt <ber...@uberwin.com>  
wrote:



Sigh.

No.

It's a python file. I'm not a python expert, but that totally sounds  
like the kind of thing that'll just get realtime interpreted. Why would  
anyone want to rebuild... Now I have to remember back 4 months ago to  
when I built initially, figure out how the heck to rebuild, any what if  
any special configurations/switches/whatever are required.


Sigh.

Thanks for the help though.

Dave

On Thu, 24 Aug 2017 04:37:39 -0400, suavesteve <suavest...@hotmail.com>  
wrote:




Just a follow-up, showing it working on my SIM v2.7.8 machine,

https://youtu.be/TGBxozl6aIg

Philip


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







--
Using Opera's mail client: http://www.opera.com/mail/

--
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] MDI edit/UI question

[David Berndt]

Sigh.

No.

It's a python file. I'm not a python expert, but that totally sounds like  
the kind of thing that'll just get realtime interpreted. Why would anyone  
want to rebuild... Now I have to remember back 4 months ago to when I  
built initially, figure out how the heck to rebuild, any what if any  
special configurations/switches/whatever are required.


Sigh.

Thanks for the help though.

Dave

On Thu, 24 Aug 2017 04:37:39 -0400, suavesteve   
wrote:




Just a follow-up, showing it working on my SIM v2.7.8 machine,

https://youtu.be/TGBxozl6aIg

Philip


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




--
Using Opera's mail client: http://www.opera.com/mail/

--
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] MDI edit/UI question

[David Berndt]

I got no joy on this one, or I don't understand the expected result of the  
patch.


In 2.7.8 that I pulled/built a few months back. Changes appear to apply  
just fine, but when scrolling through the history list I can't press home,  
left, right, end, etc to begin edittng.


Turns out insert works, which I didn't know previously. I restored the  
pre-patch axis.py and tested again, insert works there as well, so no  
actual change. But having any key that lets me get into edit mode is all I  
really needed. The choice of insert seems a little dubious to me.


On Tue, 22 Aug 2017 05:10:18 -0400, suavesteve   
wrote:



I've ran into this problem, too; best as I could see, it wasn't possible
to use the keys with that particular entry box, so I made a few
modifications to the axis.py script to give me left + right, home and
end keys. It seems to have worked fine for me, for > 6 months.

Philip


--
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] MDI edit/UI question

[David Berndt]

Maybe this is an easy one, maybe not.

When using axis in standard config, on the mdi screen, if you've selected  
the "MDI Command" text box, you can use the up/down arrows to scroll  
through the history, enter to run the currently selected history command,  
and if you use the mouse to click on a history command/the MDI Command box  
when a history command is selected you can edit the history command and  
then run it.


What is currently driving me bananas is.. How do you get into the  
"edit" mode when selecting a history command without using the mouse? In  
my experience, simply pressing end key might do it, or f2, maybe f6, right  
arrow, anything? Nothing I seem to press does it short of getting out the  
mouse. As my current mouse setup is to leave the mouse hanging off the  
back of the control cabinet, and occasionally stepping on it or kicking it  
across the garage it's not the most convenient thing, I try to avoid it...


Help..? I'm sure the answer is obvious to some other folks.

--
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] Huanyang vfd reverse

[David Berndt]

On Sun, 20 Aug 2017 18:09:20 -0400, Gene Heskett <ghesk...@shentel.net>  
wrote:



On Sunday 20 August 2017 03:40:56 David Berndt wrote:


I'm having some issues commissioning my HY VFD. 4kw unit driving a 5hp
3450rpm motor at 30hz max frequency (temporary 2 pole motor, 4 pole
motor is in the mail). Works great in "forward", but when it accels in
reverse it trips out and throws an E.OC.N error. Which appears to be
an over current error.

I've flipped 2 leads to the motor, reversing the physical rotation and
it still works great in vfd "forward", proving that the motor and
mechanical aspects work in both directions. But the VFD does not.
Accel times are quite conservative/slow. Problem happens about 1
second into acceleration. No clue There don't seem to be any
relevant settings. Problem happens regardless of control method,
modbus or operator panel.

Unrelated, but wow, at low speeds this VFD seems to throw off a ton of
interference. The symptom I've noticed is that my usb mouse connected
to the PC in the control cabinet that also houses the VFD basically
gives up on life if the motor is running below 15hz. USB dongle modbus
was fairly impacted as well until I grounded the cable shield to the
pc case.


I had noise worse than the coaches megaphone, so I put a 20 amp rated
Corcom brick wall in the AC line feed.  Works a treat.


Any particular series you picked? Does it really matter? I assume some  
filtering, even one of the corcom filters rated as general purpose would  
be better in front of the vfd than nothing at all?





Just to make this slighlty more on topic. Is there a config somewhere
for maximum spindle RPM? With the drive configured correctly it won't
overspeed the motor, but it would be nice if the software was aware of
a top end for spindle speed as well.


What are you using for an interface between the pwm (or pdm) gen, I am
assuming the pwmgen is in a mesa interface card?.



It's just a usb to modbus dongle. So the hy_vfd user componenet.  I  
realize there are ways to solve this in HAL but none of them seem to  
enforce the same way softlimits do, or I'm doing something wrong. I'm  
looking for something that will throw an error and power off the machine  
g-code sets and S command too high, or the manual control screen is used  
to set the rpm too high (ideally the interface would just stop increasing  
the spindle speed once it hits the max...).





I had been assured by the ebay critter that sold me the 1.5 hp vfd,
hooked to a 1 horse 3 phase motor from a 30 yo compressor, that the
analog input filtering was good and that I could feed the analog input
(0 <-> 5 volt range, it has both 5 volt and 10 volt inputs) directly
from the pwm generator, but I was unable to get good smooth control.

My motor is a 4 pole, and at light load it has been spun north of 7K
rpms.  No damage if the internal fans don't throw blades, but because of
motor winding inductance, current draw is well under an amp/phase so
usable torque is an oxymoron, there isn't much. Practical limit for my
setup is about 140hz. From 8hz to 140hz doesn't make me switch drive
belts from 1st gear, no backgear.


I don't plan to run a great range of motor speeds, but getting it up to  
90hz to pickup some spindle speed would be nice if the gearing and spindle  
will take it. On the low end, if something like 20-30hz would be usable  
I'd probably be satisfied, just enough to limit trips ot the back of the  
machine to throw gear select levers.




I had a mesa spinx-1 I had taken out of TLM because I was putting in a 40
lb supply and one of Jon's (Pico Systems pwm-servo amplifiers, great
device BTW), so I pulled it out and hooked it up.  Works Perfect.  With
a bit of tuning in the vfd, I can even do rigid tapping on the old grey
Sheldon up to around 200-250 spindle rpms. Above that and the overshoot
at reversal exceeds a full turn of the chuck.

The spinx-1 needs separate fwd and rev signals, not a problem to hack
that in your .hal file, but yell if you need some snippets of hal code,
I might be able to help.


Thanks,
Dave



Cheers, Gene Heskett



--
Using Opera's mail client: http://www.opera.com/mail/

--
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] Huanyang vfd reverse

[David Berndt]

Yes, That's my second reset.

On Sun, 20 Aug 2017 14:50:47 -0400, Eric Keller <eekel...@psu.edu> wrote:

Had you done that before?  Resetting the drive is the first step in all  
the

directions that I have seen.
I'm happy with mine, but I wish I could add an external braking resistor.

On Sun, Aug 20, 2017 at 10:45 AM, David Berndt <ber...@uberwin.com>  
wrote:



Sigh, resetting the drive to defaults cured the reverse issue. No idea
what setting could have been set to cause some sort of a reverse bias  
or ??

issue.


On Sun, 20 Aug 2017 03:40:56 -0400, David Berndt <ber...@uberwin.com>
wrote:

I'm having some issues commissioning my HY VFD. 4kw unit driving a 5hp
3450rpm motor at 30hz max frequency (temporary 2 pole motor, 4 pole  
motor
is in the mail). Works great in "forward", but when it accels in  
reverse it
trips out and throws an E.OC.N error. Which appears to be an over  
current

error.

I've flipped 2 leads to the motor, reversing the physical rotation and  
it
still works great in vfd "forward", proving that the motor and  
mechanical

aspects work in both directions. But the VFD does not. Accel times are
quite conservative/slow. Problem happens about 1 second into  
acceleration.
No clue There don't seem to be any relevant settings. Problem  
happens

regardless of control method, modbus or operator panel.

Unrelated, but wow, at low speeds this VFD seems to throw off a ton of
interference. The symptom I've noticed is that my usb mouse connected  
to
the PC in the control cabinet that also houses the VFD basically gives  
up
on life if the motor is running below 15hz. USB dongle modbus was  
fairly

impacted as well until I grounded the cable shield to the pc case.

Just to make this slighlty more on topic. Is there a config somewhere  
for
maximum spindle RPM? With the drive configured correctly it won't  
overspeed
the motor, but it would be nice if the software was aware of a top end  
for

spindle speed as well.


Thanks,
Dave


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




--
Using Opera's mail client: http://www.opera.com/mail/



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




--
Using Opera's mail client: http://www.opera.com/mail/

--
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] Huanyang vfd reverse

[David Berndt]

Sigh, resetting the drive to defaults cured the reverse issue. No idea  
what setting could have been set to cause some sort of a reverse bias or  
?? issue.


On Sun, 20 Aug 2017 03:40:56 -0400, David Berndt <ber...@uberwin.com>  
wrote:


I'm having some issues commissioning my HY VFD. 4kw unit driving a 5hp  
3450rpm motor at 30hz max frequency (temporary 2 pole motor, 4 pole  
motor is in the mail). Works great in "forward", but when it accels in  
reverse it trips out and throws an E.OC.N error. Which appears to be an  
over current error.


I've flipped 2 leads to the motor, reversing the physical rotation and  
it still works great in vfd "forward", proving that the motor and  
mechanical aspects work in both directions. But the VFD does not. Accel  
times are quite conservative/slow. Problem happens about 1 second into  
acceleration. No clue There don't seem to be any relevant settings.  
Problem happens regardless of control method, modbus or operator panel.


Unrelated, but wow, at low speeds this VFD seems to throw off a ton of  
interference. The symptom I've noticed is that my usb mouse connected to  
the PC in the control cabinet that also houses the VFD basically gives  
up on life if the motor is running below 15hz. USB dongle modbus was  
fairly impacted as well until I grounded the cable shield to the pc case.


Just to make this slighlty more on topic. Is there a config somewhere  
for maximum spindle RPM? With the drive configured correctly it won't  
overspeed the motor, but it would be nice if the software was aware of a  
top end for spindle speed as well.



Thanks,
Dave

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




--
Using Opera's mail client: http://www.opera.com/mail/

--
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] Huanyang vfd reverse

[David Berndt]

I'm having some issues commissioning my HY VFD. 4kw unit driving a 5hp  
3450rpm motor at 30hz max frequency (temporary 2 pole motor, 4 pole motor  
is in the mail). Works great in "forward", but when it accels in reverse  
it trips out and throws an E.OC.N error. Which appears to be an over  
current error.


I've flipped 2 leads to the motor, reversing the physical rotation and it  
still works great in vfd "forward", proving that the motor and mechanical  
aspects work in both directions. But the VFD does not. Accel times are  
quite conservative/slow. Problem happens about 1 second into acceleration.  
No clue There don't seem to be any relevant settings. Problem happens  
regardless of control method, modbus or operator panel.


Unrelated, but wow, at low speeds this VFD seems to throw off a ton of  
interference. The symptom I've noticed is that my usb mouse connected to  
the PC in the control cabinet that also houses the VFD basically gives up  
on life if the motor is running below 15hz. USB dongle modbus was fairly  
impacted as well until I grounded the cable shield to the pc case.


Just to make this slighlty more on topic. Is there a config somewhere for  
maximum spindle RPM? With the drive configured correctly it won't  
overspeed the motor, but it would be nice if the software was aware of a  
top end for spindle speed as well.



Thanks,
Dave

--
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] How to add additional condition for enabling machine

[David Berndt]

If the air pressure is related to movement of an axis (or you want to say  
it is...) you can use axis.N.amp-fault-in as a place to input an your  
error condition. The machine won't be forced to e-stop, but will not allow  
the power button to be pressed/stay on.


Same thing should be possible with motion.enable in bit.

For the spindle, maybe motion.spindle-inhibit in bit is what you're  
looking for.


If you want the machine to be totally useless then perhaps wiring it into  
the e-stop circuit is the way to go. Personally I'm not on board with  
that. But about half of the standard conventions in linuxcnc seem to rub  
me the wrong way, so it might be just fine with you.



Dave

On Sat, 29 Jul 2017 12:10:31 -0400, Tomaz T.  wrote:

I have air pressure switch to control if there is enough air pressure.  
Now I would like that this is also condition for enabling machine to run.


I would need a little help how to correctly add this to hal.
--
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




--
Using Opera's mail client: http://www.opera.com/mail/

--
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] Multi-meter recommendations

[David Berndt]

Apologies, this might be slightly OT, but I imagine we all use a  
Multi-meter a few times a month in our EMC related work.


It seems my Micronta 22-174b has given up on life, or has suffered a brain  
injury at the very least. After not using the meter for about 3 weeks I  
dusted it off and was double checking some wiring for a 24v servo brake,  
everything went fine, there was no funny event, no smoke, no fire, not  
even any brimstone,  but the meter didn't read 24v on the 24v line, more  
like 19v, and I notice the ohm mode reads 32ohms all the time, even when  
it should be displaying open circuit.


Nothing internally seems amiss, no obviously blown traces, componenents,  
no burnt smell. Board says 1992, I guess 25 years is enough, maybe it's  
time to consider a new unit.


S... Anyone have any recommendations for a hobbyist level meter.


Dave

--
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] EMC traffic

[David Berndt]

Everyone gave up and moved to machinekit...


On Mon, 19 Jun 2017 17:42:24 -0400, hubert  wrote:

Just checking, It seems unusual not to have any posts in this long a  
period.  My last received post was 6/17/17, 12:27 PM


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




--
Using Opera's mail client: http://www.opera.com/mail/

--
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] HAL - Delay before machine power

[David Berndt]

Update: I changed the order of the loadrt, addf, and any lines to do with  
the reset related oneshot to be at the top of the HAL file and it seems to  
"work" now. More testing maybe required. It's unclear to me which of these  
items (or all?) are important in terms of order and how order of all  
things in HAL is determined.

Still doesn't give enough time between the servo reset and checking servo  
status, but just pressing machine on again does the trick.


On Tue, 09 May 2017 02:59:54 -0400, David Berndt <ber...@uberwin.com>  
wrote:

> Hello all,
>
> Sorry to disturb the email list with this, normally I'd post to the  
> forum but it seems to be pretty unreliable lately.
>
> I'm pretty new to this, so the solution to this might be obvious. But at  
> this time it isn't to me. Any help would be appreciated.
>
> My current situation is I'm trying to get me e-stop/motion stop/etc  
> stuff sorted out and I've found that one of my servo drives throws a bit  
> of a fit when power is removed from the motor power side of the drive,  
> and then restored some time later such that the internal caps have had  
> time to leak down. Once power is restored the drive should be good to  
> go, it throws no visible errors/alarms/warnings but fails to put it's  
> Servo on/Servo Ready output back to on.
>
> My HAL is and2'ing the Servo Ready and the Servo warning (limit  
> switches, etc) from the drive together and inputting that into the  
> axis.N.amp-fault. Which is working great in all cases except this  
> particular one.
>
> I've fiddled with the drive settings quite a bit and it seems it's  
> simply working as designed/implemented and there is no  
> setting/switch/magic beans to change this behaviour on the drive side.
>
> So what I'd like to do is to send an alarm reset signal to the servo  
> drive before machine power on (F2) does anything like check for enabled  
> amps, so that the drive could clear it's alarm and go Servo Ready.
>
> I've tried to attach a oneshot to halui.machine.is-on, but in this error  
> case according to halscope it never fires, possibly because the machine  
> is never in the is-on state long enough (or at all) when there is a  
> servo fault. It's not clear to me how I could arrange the oneshot to  
> happen much earlier? or to intercept the power-on command and do some  
> stuff then, then allow it to resume, or whatever the process might be?  
> Note that the oneshot code is likely correct/functional as I can see it  
> firing in all the other cases (for instance when there is no servo  
> error, but the machine is transitioning to the is-on state), it's just  
> likely not dispatched in the order it needs to be.
>
> Perhaps another solution would be to run somewhere, possibly in a new  
> loop, a check to see if the machine is off, and if so send an alarm  
> reset to the drive, every 5 seconds or something would be fine. It's  
> pretty unlikely that an operator could get from enabling the drives via  
> e-stop/motion stop switches to pressing machine on in the gui/keyboard  
> in less than a few seconds. This sounds less ideal and I'm still not  
> really sure how to implement that either...
>
> Regards,
> Dave

--
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] HAL - Delay before machine power

[David Berndt]

Hello all,

Sorry to disturb the email list with this, normally I'd post to the forum  
but it seems to be pretty unreliable lately.

I'm pretty new to this, so the solution to this might be obvious. But at  
this time it isn't to me. Any help would be appreciated.

My current situation is I'm trying to get me e-stop/motion stop/etc stuff  
sorted out and I've found that one of my servo drives throws a bit of a  
fit when power is removed from the motor power side of the drive, and then  
restored some time later such that the internal caps have had time to leak  
down. Once power is restored the drive should be good to go, it throws no  
visible errors/alarms/warnings but fails to put it's Servo on/Servo Ready  
output back to on.

My HAL is and2'ing the Servo Ready and the Servo warning (limit switches,  
etc) from the drive together and inputting that into the axis.N.amp-fault.  
Which is working great in all cases except this particular one.

I've fiddled with the drive settings quite a bit and it seems it's simply  
working as designed/implemented and there is no setting/switch/magic beans  
to change this behaviour on the drive side.

So what I'd like to do is to send an alarm reset signal to the servo drive  
before machine power on (F2) does anything like check for enabled amps, so  
that the drive could clear it's alarm and go Servo Ready.

I've tried to attach a oneshot to halui.machine.is-on, but in this error  
case according to halscope it never fires, possibly because the machine is  
never in the is-on state long enough (or at all) when there is a servo  
fault. It's not clear to me how I could arrange the oneshot to happen much  
earlier? or to intercept the power-on command and do some stuff then, then  
allow it to resume, or whatever the process might be? Note that the  
oneshot code is likely correct/functional as I can see it firing in all  
the other cases (for instance when there is no servo error, but the  
machine is transitioning to the is-on state), it's just likely not  
dispatched in the order it needs to be.

Perhaps another solution would be to run somewhere, possibly in a new  
loop, a check to see if the machine is off, and if so send an alarm reset  
to the drive, every 5 seconds or something would be fine. It's pretty  
unlikely that an operator could get from enabling the drives via  
e-stop/motion stop switches to pressing machine on in the gui/keyboard in  
less than a few seconds. This sounds less ideal and I'm still not really  
sure how to implement that either...

Regards,
Dave

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