Re: [Emc-users] Hardware emcmot?

[dannym]

From: "andy pugh" 
To: "Enhanced Machine Controller (EMC)"
Cc: 
Sent: Wednesday April 10 2019 1:46:17PM
Subject: Re: [Emc-users] Hardware emcmot?

On Wed, 10 Apr 2019 at 19:43,  wrote:

 > Actually I *don't* want to run a form of Linux. Since it's
dedicated
 > HW, the tasks can be hardcoded for bare metal

 I wonder if the Mesa "SoftDMC" would do what you want?

-

Hmm maybe so!

Although it is key to modulate beam power at ~5KHz scaled with the
reciprocal of the instantaneous velocity and an accompanying motion
command param. Not the motion command target feedrate but the
instantaneous velocity after acceleration curves are applied. This
prevents burning more energy per inch than specified during accel
periods. 

The vector sum is easy to sum squares, but then you have reciprocal
of the square root to create. You know, it doesn't have to be perfect,
I wonder if a polynomial for reciprocal-of-square-root would suffice?
Much faster esp since multiplying 32 bit numbers could in theory
overflow a 32 bit reg (although the velocity to do that seems
unreasonable).

The same is true of any solution, except the bulk 98% of the base
requirement tasks are already there. No nontrapezoidal accel.

There seems to be a lack of arc blending though, and I've seem the
result of poor trajectory planning on certain laser-cut files. Ones
that have like 1000 linear motion commands per inch (that number might
be hyperbole) and poor path smoothing, I think due to pixellation
causing irrelevant right-angle turns for only a few thousandth of an
inch. It ran *really* slow on something that was actually not a whole
lot of exceptionally high detail. Some of that could be path smoothing
approximated in the CAM stage.

Danny

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

Re: [Emc-users] Hardware emcmot?

[dannym]

From: dan...@austin.rr.com
To: "Les Newell"
Cc: 
Sent: Wednesday April 10 2019 1:33:31PM
Subject: Re: [Emc-users] Hardware emcmot?

From: "Les Newell" 
To: "Danny Miller"
Cc: 
Sent: Wednesday April 10 2019 12:55:14PM
Subject: Re: [Emc-users] Hardware emcmot?

Moving just emcmot is not really practical but moving the whole
realtime 
 side to another processor shouldn't be too hard. If I remember
correctly 
 the CMS/NML communication subsystem already has network
functionality. 
 Of course in that case you'd probably need your external processor to
be 
 running some sort of Linux.

 Les

 On 10/04/2019 17:10, Danny Miller wrote:
 > I have been wondering- can emcmot be separated from the HAl and 
 > emctask and become a true dedicated realtime stage to control the
joints?
 >
 > The shared memory FIFOs could be replaced with like an ethernet
link 
 > to the hardware RAM. You'd probably load a DMA buffer and just let
it 
 > flow, there's some minor latency but there's not a realtime
requirement.
 >
 > There are cheap high freq MCUs with single-cycle hardware double 
 > multiply/add and gobs of memory. It would have to be coded in
non-OOP 
 > C and I greatly prefer hardware interrupt-driven strategies over
RTOS.
 >
 > Danny 

-

Actually I *don't* want to run a form of Linux. Since it's dedicated
HW, the tasks can be hardcoded for bare metal and stored in flash and
directly load the STEP/DIR pins with SPI data which does precise,
synchronized step-outs.. This is leaner, simpler, more reliable and
the latency can be very low and consistent (although LinuxCNC on
Preempt-RT is already all of that for my machine).

This would require somewhat extensive modification of code.
Microcontrollers typically use C and cannot handle C++'s OOP nor
dynamic memory allocation. However, static mem allocation should be
fine and, like I say, faster and lower latency. Converting objects to
non-OOP code is usually pretty straightforward.

Danny



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

Re: [Emc-users] Hardware emcmot?

[dannym]

From: "andy pugh" 
To: "Enhanced Machine Controller (EMC)"
Cc: 
Sent: Wednesday April 10 2019 1:12:04PM
Subject: Re: [Emc-users] Hardware emcmot?

On Wed, 10 Apr 2019 at 18:19, Danny Miller  wrote:

 > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?EMC_Components
 /> >
 > Shows EMCMOT as a discrete module, and emcmot.c and emcmot.h are
 > supposed to be discrete files. The motor PWMs and switch IO is
under
 > the realtime veil, which is easy to integrate into hw.

 Note that that page was last edited 12 years ago, and is based on an
 earlier page describing EMC1.
 The information there actually dates back to before there was a
HAL

 As far as I can tell motion is made up of all the files in the motion
folder.
 motion.c mainly creates hal pins and exports that hal function that
is
 called periodically by realtime:

 But I might be misunderstanding what you want to do. If you want to
 move motion into a different CPU then it probably could be done, by
 making a HAL interface that duplicates the HAL interface of motmod.
 (the pin names would not have to be the same)
 The Mesa and Pico cards already do this. HAL pins are given values,
 and those values are sent to an FPGA, by various methods (PCI, EPP,
 Ethernet, SPI)

 -- 
 atp
 "A motorcycle is a bicycle with a pandemonium attachment and is
 designed for the especial use of mechanical geniuses, daredevils and
 lunatics."
 — George Fitch, Atlanta Constitution Newspaper, 1916

 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net


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

Re: [Emc-users] Fusion360 gcode= "Radius to end arc differs from radius start"

[dannym]

Is adding a #TOLERANCE_INCH and #TOLERANCE_MM to the .ini file
sufficient?
What tolerances are reasonable?

Danny

-From: "Jon Elson" 
To: "Enhanced Machine Controller (EMC)"
Cc: 
Sent: Monday January 14 2019 10:02:44AM
Subject: Re: [Emc-users] Fusion360 gcode= "Radius to end arc differs
from radius start"

On 01/14/2019 12:18 AM, Danny Miller wrote:
 > I'm managing a community shop with the CNC I designed and 
 > built. It's running on LinuxCNC 2.7.4
 >
 > I was told people brought in some Fusion360-generated code 
 > that created an error "Radius to end arc differs from 
 > radius start". Nobody has provided me that gcode, so I 
 > have no further details. Google saysa this was a common 
 > issue after a q4 2018 patch to fusion360
 >
 Yes, a classic problem. LinuxCNC is strict about the start 
 and end radius needing to match to high accuracy. My fix to 
 this is to always use the R word instead of I and J to set 
 the arc radius, then there is never any way it can't match. 
 If fusion360 cannot be set to use the R word for arc radius, 
 then you can try the tolerance adjustment.

 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] Mesa 7i92 card

[dannym]

There's multiple bitfile options which do commit some pins to special functions 
like the actual STEP/DIR.  The special functions can usually be turned off to 
make the pin a GPIO.

Inside the LinuxCNC HAL, you can change which STEP/DIR pair goes to which axis, 
and associate specific GPIO pins with being limit switch inputs and such.

Danny



 "Horváth Csaba"  wrote: 
> Hi Everebody,
> 
> 
> I just bought a 7i92 card.
> It works well but I don't know how can I remap the pin allocation. Right 
> now there is a G540x2D firmware uploaded on the card.
> I would like to remap the pin allocation of the firmware.
> Can you help me?
> 
> Regards,
> 
>   Csaba
> 
> --
> 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] LinuxCNC 2.7.10 is out

[dannym]

I see the 7i93 includes UART functionality.

I have been troubled by the VFD's RS485 Modbus link.  I had to strap a second 
cable solution onto my PC just for that.

RS485 4-wire transceiver control signals out of the card would be great, but a 
UART that just has Rx/Tx with no RS485 protocol would be a great improvement, 
I'd just drive it into a hardware RS232/Rs485 dongle.  This would save the 
cabling problem.

Does 7i93 work that was, and does LinuxCNC 2.7.10 have the capability to drive 
the UART now?

Danny


 Sebastian Kuzminsky  wrote: 
> LinuxCNC 2.7.10 is out.  This one's a relatively boring stable release.
> A few minor bugs have been fixed, but the real highlights are:
> 
>* full support for Debian Stretch (uspace realtime with RT-Preempt)
>* support for Mesa 7i93 Hostmot2 Ethernet board
>* support for Huanyang GT-series VFDs
> 
> 
> Thanks to the folks who contributed patches and fixes for this release:
> 
>* Andy Pugh
>* Jeff Epler
>* John Thornton
>* Norbert Schechner
>* Sebastian Kuzminsky
> 
> 
> And of course, as always, thanks to everyone helping
> out in the forums, mailing list, and on IRC,
> and to everyone who took the time to open
> issues on github.
> 
> 
> The full changelog:
> 
>* docs: document [EMCMOT]COMM_TIMEOUT
>* docs: teach buildsystem to generate manpages from asciidoc source
>* docs: add info about the Touchy radio buttons
>* docs: improve some hm2_bspi manpages
> 
>* gmoccapy: added Num_Pad jogging
>* image-to-gcode: work around gratuitous breakage in PIL
> 
>* GladeVCP: don't exit if CombiDRO fails to poll status
> 
>* hy_vfd: add --motor-poles, to set PD143
>* hy_vfd: add --base-frequency to set PD004 on the VFD
>* hy_vfd: document PD004/base-freq better in the manpage
>* hy_vfd: fix some typos in --help output and comments
> 
>* add a driver for the Huanyang GT series VFD
> 
>* hm2_eth: add support for Mesa 7i93 AnyIO ethernet board
>* hm2_sserial: Fix a bug where the second port would not work if the
>first was disabled
> 
>* gcodemodule: make interp really close part program
>* pluto: use rtapi's fabs() instead of the kernel's abs()
>* steptest: don't change position-cmd when not running
> 
>* uspace: find top online CPU
> 
>* tests: make timeouts simpler & smarter in halui/jogging test
> 
>* build: fix building linuxcnc.1 when docs not requested
>* build: don't fail when requested not to build documentation
>* build: ensure asciidoc manpages are built before checklink is run
>* build: build-depend on asciidoc-dblatex on debian stretch
>* build: on Debian Stretch and newer, depend on gstreamer 1.0
>* build: add debian/configure stanza for debian stretch
>* build: rename the GS2 VFD Makefile variables for clarity
> 
> 
> -- 
> Sebastian Kuzminsky
> 
> --
> 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] Any experience with Leadshine DM series stepper driver

[dannym]

Best thing is the digitally software-programmed ones.  You program in the exact 
current, microstepping, whether it uses the Enable line, whether it enabled the 
automatic stall detection...

And you can hit "auto-tune" on the motor, it takes over for a second and 
stimulates the motor and gets feedback and you can pull up a graph of its 
stability.  

You can set it for a midband self-generated test step sequence and manually 
adjust the midband resonance dampening.  Honestly could not find anything to 
dampen.  Already totally stable.

I use the Leadshine AM882 and A882H (higher voltage). The DM556 just seems to 
be an American-market rebranding of the AM882 with a somewhat higher price tag.

Bottom line, for the AM882 at least, yes, "super nice", "worth it at any 
price", "would never go back".

Danny

 Chris Albertson  wrote: 
> Has anyone used the Leadshine digital stepper drivers?   Do they
> really provide "smoother operation with less heat"?
> 
> I need to buy a stepper motor controller and notice that Leadshine
> offers three series of drivers.  The most common cheap driver for a 4
> amp motor is the M542.   But there is also the EM503 and DM556.  They
> offer a EM, DM and M series of drivers.
> 
> The DM and EM series have a digital DSP controller and they claim a
> mode where the driver tests the connected motor for both DC resistance
> and inductance and then adjusts the current/speed parameters to suit.
> The motor shaft vibrates while the test is underway (likely the
> controller is placing a small AC signal in the motor to measure
> inductance)
> 
> The DM and EM series can also reduce the current going to the motor
> after it has been at zero speed for one second, to reduce heating.
> 
> The DM and EM series have an RS-232 port so the parameters
> (resistance, inductance and idle current reduction) can be set from
> software rather then auto-tuned.
> 
> In addition the EM series driver can detect skipped steps without an
> additional sensor and raise a fault line that (I assume)
> EMC/MachineKit can detect.
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> 
> --
> 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] [SPAM] Re: Anyone done an ATC?

[dannym]

Me, personally, I'm specifically looking at ATCs for routers, very different as 
we have to go to tool holder, release, grab, and work out the new tool length.

Probably more important, the initial ATC spindle selection.  I'm a bit confused 
what all is on the market and "worth it".

Danny


 andy pugh  wrote: 
> On 12 May 2017 at 13:16, Les Newell  wrote:
> The ATC on my lathe is a turret I originally made for a Denford Orac (a
> small education CNC lathe).

There is a specific HAL component for that tool changer, and for a
couple of closely-related ones.

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ContributedComponents#Denford_Orac_Lathe_ATC_toolchanger_component

I believe that the Orac was actually named after:
https://en.wikipedia.org/wiki/Characters_of_Blake%27s_7#Orac

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

Re: [Emc-users] Anyone done an ATC?

[dannym]

Which spindle did you get?  Options that looked appealing to me:

http://www.ebay.com/itm/1-8KW-ATC-Water-Cooled-Automatic-Tool-Change-Spindle-Motor-ISO20-220V-5-4A-CNC-/112396640759?hash=item1a2b5ca1f7:g:5UIAAOSwawpXtUTl

http://www.ebay.com/itm/2HP-1-5kw-24000RPM-ISO20-3-bearings-Automatic-Tool-Changes-ATC-Spindles-/262522320679?hash=item3d1f8cb727:g:9NYAAOSwRJ9Xhg6v

Danny

 hubert  wrote: 
> Jan did one for my Mill.  It uses BT30 tool holders.  I am not familiar 
> with tool holding on the router.  We used the carousel component for 
> storage and presentation of the tool.  We used pneumatic cylinders for 
> draw bar and movement of the tool to and from the spindle.  We also had 
> to make sure the spindle stopped in the right orientation for the tool 
> change.
> 
> Hubert
> 
> 
> On 5/11/17 8:33 AM, Les Newell wrote:
> > I have done a lathe ATC, which was fairly painless. I have a router that
> > is due for a retrofit and it has an ATC. I'll probably be starting on it
> > sometime around July/August.
> >
> > There are various ways to do tool changers. My lathe ATC uses a Python
> > script which I wrote as a quick hack though it works so well I never
> > bothered to turn it into a proper hal module. For the router I'll
> > probably use ClassicLadder.
> >
> > Les
> >
> > On 09/05/2017 21:17, dan...@austin.rr.com wrote:
> >> I'm hoping to do an ATC router (primarily wood) next.  Does anyone have 
> >> experience doing that with LinuxCNC?
> >>
> >> I do see some $2000 spindle options.  Any recommendations?
> >>
> >> Thanks,
> >> Danny
> >>
> >
> > --
> > 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] Anyone done an ATC?

[dannym]

I'm hoping to do an ATC router (primarily wood) next.  Does anyone have 
experience doing that with LinuxCNC?

I do see some $2000 spindle options.  Any recommendations?

Thanks,
Danny


--
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] Cleaning Carbide Bits -plywood gue.

[dannym]

Was gonna say that.  Something's gotta be messed up to get that prob.

Danny


 Todd  Zuercher  wrote: 
> Honestly we hardly ever have to clean our tools, but we don't mill much 
> pitchy wood, mostly hardwoods and MDF.  For us if a tool is getting clogged 
> up, it is because it is too dull and is getting too hot, or the feed rate is 
> way to slow and it got too hot.  Either way it usually ends up in the bin.
> 
> - Original Message -
> From: "craig" 
> To: emc-users@lists.sourceforge.net
> Sent: Thursday, April 13, 2017 12:33:11 PM
> Subject: [Emc-users] Cleaning Carbide Bits -plywood gue.
> 
> What is the best way to clean plywood glues off small carbide router bits?
> 
> I use small carbide bits to work wood and sometimes plywood.  Mostly 
> smaller than 3mm(1/8 in) bits.
> Sometimes plywood glue melts onto the bits.Cleaning them is a 
> problem.  Suggestions?
> 
> Craig
> 
> --
> 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

Re: [Emc-users] 3D Printers

[dannym]

Parts can be quite strong. Although, I've seen plenty of prints with a bad 
layer (can be as simple as the air conditioning kicking in and shrinking the 
plastic suddenly).

You can print out objects that would be difficult to mill, such as things 
requiring 5-axis milling, exotic holddown solutions, or very deep features, 
inaccessible features, or would have bit radius problems, or would require 
excessive stock.  

When set up correctly 3D printing is much more straightforward.  e.g. a child 
can download a Sonic the Hedgehog file and make it without bit selection, 
holddown solutions, or any complicated CAM.

What's crazy is printing fully functional complex 3d machines:

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

Many 3d print heads use 3D printed components like the tractor-gear.  This is a 
difficult shape to machine otherwise.  It's functional for the "long haul", not 
just a prototype that'll break too soon for real use.

Danny




 Chris Albertson  wrote: 
> On Tue, Mar 28, 2017 at 10:17 AM, andy pugh  wrote:
> 
> > On 28 March 2017 at 17:18, Les Newell  wrote:
> > > The prints also aren't that strong. If you
> > > put enough time into it you can get some good results but most of the
> > > stuff I want to make either needs to be strong or dimensionally accurate
> > > (or usually both together).
> 
> 
> The thing about 2D printing is that it does not work well if you are making
> replacement parts for an existing product.   The original parts were likely
> of metal or a stronger kind of plastic but where 3D printing works well is
> for new designs where you design the part knowing the properties of the
> material.For example if printing a design that uses timing belts, you'd
> use a wider belt them if using aluminum pulleys.
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> --
> 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] 3D Printers

[dannym]

I have done relatively little 3D printing myself.  I do run a community 
hackerspace with a number of 3D printers, most of which are broken.
Many, many cheap 3D printers just can't work out of the box.  Badly designed 
linear axes, terrible ratsnest of wiring, extruder designs that do nothing but 
jam, no good way to level the table.  Driver chips that burn out regularly.

The one with a unique reputation of working consistently is Lulzbot.  It's 
notably more expensive, but it does actually work reliably and is very capable. 
 Lulzbot TAZ 6 is a BIG print area and can be had used/refurb for like 
$1800-$2000.

Danny

 andy pugh  wrote: 
> I find myself astonished that I don't have a 3D printer.
I am thinking of buying one.
Longer-term I think I will end up making a large-format delta pritner,
so the one I buy will be more ot a toe-dipping exercise, and I am
looking at:
http://www.ebay.co.uk/itm/182454763977
Any thoughts?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

Re: [Emc-users] VFD recommendations

[dannym]

AFAIK any quality VFD made in the last 5+ yrs will be sensorless vector drive, 
at basically the same cost as earlier VFDs. 

Hitachi WJ200 is a sensorless vector drive.  It's not super-expensive, and it's 
a Hitachi.  Yes it has a Modbus driver for it.

HY has worked ok for people, but I would never consider it, a reliable WJ200 is 
only a bit more $.

Danny

 dragon  wrote: 
> So some more questions about VFDs...
> 
> What are the advantages of a sensorless vector drive and is it worth the
> extra cost?
> 
> Are there any sensorless vector drives that have a supported modbus driver?
> 
> Is there a list of VFDs with linuxCNC modbus support somewhere other than...
> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?VFD_Modbus
> 
> and the HY series of Huanyang drives?
> 
> Thanks again everyone!
> 
> 
> 
> On 02/05/2017 01:55 PM, dragon wrote:
> > So it looks like perhaps only the 7.5kW model is the new GT series. I
> > don't need anything near that big so if I go with the Huanyang I would
> > be getting the model that uses the existing driver.
> > 
> > Looking at the driver docs and code, it looks like there is no way to
> > request the motor load. However since the driver has HAL pins to report
> > most of the parameters would it be possible to calculate the spindle load?
> > 
> > 
> > 
> > On 02/03/2017 10:06 AM, Sebastian Kuzminsky wrote:
> >> On 02/03/2017 07:34 AM, dragon wrote:
> >>> I just re-read this... If modbus is correctly implemented in the GT
> >>> series, could you just use MB2HAL?
> >>
> >> I think the Huanyang GT VFD should talk to any Modbus Master, including 
> >> MB2HAL.
> >>
> >>
> > 
> 


--
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] Using a homing switch as a limit when not homed

[dannym]

I have inductive proximity switches.  Cause I'm that awesome.

Danny

 Nicklas Karlsson  wrote: 
> Electrical switches will eventully fail unless you use special switches which 
> fail in the correct dirction, you could make it run off the screw?
> 
> 
> On Wed, 8 Feb 2017 17:34:17 +
>  wrote:
> 
> > I don't have a physical stop on my Z axis, putting one in would be a PITA.  
> > The drive is exceptionally strong and it would be problematic to stop the 
> > axis that way.  If you're an idiot and jog it that way prior to homing, you 
> > can dismount the axis.
> > 
> > There is a homing switch at Z+.  It sounds desirable to halt + movement 
> > when that switch is tripped, AND not homed, AND not in the actual homing 
> > sequence.  But NOT stop - movement, otherwise you'd jog it upwards, get it 
> > stuck, and no way to jog down.
> > 
> > How difficult would it be to do that?
> > 
> > Danny
> > 
> > 
> > 
> > 
> > --
> > 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] Using a homing switch as a limit when not homed

[dannym]

I don't have a physical stop on my Z axis, putting one in would be a PITA.  The 
drive is exceptionally strong and it would be problematic to stop the axis that 
way.  If you're an idiot and jog it that way prior to homing, you can dismount 
the axis.

There is a homing switch at Z+.  It sounds desirable to halt + movement when 
that switch is tripped, AND not homed, AND not in the actual homing sequence.  
But NOT stop - movement, otherwise you'd jog it upwards, get it stuck, and no 
way to jog down.

How difficult would it be to do that?

Danny




--
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] nema 24 motors.

[dannym]

Don't servos need a lot of reduction to get the torque up?  Gearboxes always 
bring backlash into the system.  Low backlash boxes are lots of $$$.



Danny

 dragon  wrote: 
> I hate to say it but I'm with Ed on this one. I just paid $32 each for
> e661 servos WITH encoders to put on my 10x24 lathe and Jet 626 mill.
> Grab a free thrown out PC and get rid of the noise problems from that
> SPI bus on the rPi. Analog input drives can be had on ebay for $35,
> especially if you run under 80vDC. With my 96v supply I hope to be up
> around 150ipm.
> 
> While 3 phase steppers are MUCH better than two phase for all of the
> reasons that Danny listed, you can spend the same amount or less for a
> servo setup if you don't mind some used components.
> 
> After having worked with both, I knew that I wouldn't be happy with a
> stepper system even for my little home machines.
> 
> Just my opinion...
> 
> On 01/24/2017 08:49 AM, Ed wrote:
> > On 01/23/2017 11:45 PM, Gene Heskett wrote:
> >> Greetings all;
> >>
> >> I see some "Nema 24" motors at quite reasonable prices showing up on
> >> fleabay,
> > 
> > SNIP
> >> Now, I don't believe this is going to help with the resonance stalls I am
> >> getting at about 30 ipm, so I'm thinking of building a viscous damper to
> >> fit on the rear of this puppy.  But unlike the ones on my hf micromill,
> >> which are long steel spools carrying a 2+ inch stack of heavy fender
> >> washers with elastomer sheets between the washers, which are true shock
> >> absorbers as the resonance is killed by the frictional losses as the
> >> washers walk on the talcum covered elastomer, but I don't have room for
> >> a 2+" stack of fender washers in this spot. 5/8" axially at best.
> > 
> > SNIP
> >> Cheers, Gene Heskett
> > 
> > 
> > RANT MODE ON
> > 
> > Why in this day of cheap encoders, small ebay servo motors, and good 
> > inexpensive servo drives does any one even use stepper motors?
> > 
> > Dampers, resonance issues, lost steps, stalls, only 30 IPM? Why?
> > 
> > Gene, don't stay on the dark side! Go to servo's and don't look back, 
> > you will never regret it.
> > 
> > RANT MODE OFF
> > 
> > deflates-
> > 
> > Ed.
> > 
> > 
> > --
> > 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] Noise problem found, but not fixed.

[dannym]

What's this for again?

I have found it preferable to use one of the DC/DC converters off the 24v power 
supply for steppers (or 48v, but that's a different story, that requires an HV 
converter and the ones they sell are all- ALL- fakes, you have to mod it with 
real components).

Danny
 
 Gene Heskett  wrote: 
> On Thursday 29 December 2016 06:25:34 andy pugh wrote:
> 
> > On 29 December 2016 at 04:49, Danny Miller  
> wrote:
> > > They all look pretty much the same, they're not.
> >
> > Meanwell is an interesting example of a Chinese brand that has made
> > enough of a reputation for being not-awful that others have started
> > making fakes.
> > (The same has happened with Fotek SSRs, you can no longer tell if you
> > are getting a real rip-off of a Crydom or a fake of a rip-off device)
> >
> > The real Mean Well chassis supplies on the RS web site have
> > hexagonal-punched covers. That might be a way to tell:
> > http://uk.rs-online.com/web/p/embedded-switch-mode-power-supplies-smps
> >/1065822/
> >
> > Why not try running from a bench PSU or even batteries as an
> > experiment?
> 
> I don't have a bench supply.  But I did find an expired computer psu last 
> night, and extracted the small pcb with most of its input filtering, and 
> when I get my cramping legs to take me out there, plus input a couple 
> cups of caffeine, I'll put it incircuit for effects.  But first call JT, 
> he has a 3 amp for little enough.
> 
> Someone mentioned that the real meanwell's covers have hex holes. This 
> one has round holes.  Sigh.
> 
> Cheers, Gene Heskett
> -- 
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
> 
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
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] Calling MDI from HAL

[dannym]

Well, how's this work overall?

A G-code called via MDI make take 10 sec to run.  If the halui remains true for 
more than one user space cycle, I presume the rule is to just ignore all the 
calls if the machine is already running G-code?

It did occur to me that it would make perfect sense to only allow the X=0.5X to 
be executed once and that latch gets reset by zeroing the X work offset.  
Because I see no way you could ever need to press it again without zeroing.  If 
you were in the wrong place when you hit X=0.5X (whoops, I'm at the right spot 
for Y=0.5Y but hit it for X??), you cannot fix it by hitting X=0.5X again.  You 
need to find work X=0, zero again, move to X max on the stock, and press X=0.5X 
again.  This sounds desirable, it is all too easy to get tired and press X=0.5X 
once, take a sip of coffee, look back, and press it again, screwing up the X 
zero point.  There is no "back arrow" to fix that little typo.

Only prob is, yes I can connect a latch-reset to the MPG's button for (current 
axis)=0, but I don't know any way to do that IF the user does (work axis)=0 
from the keyboard instead of MPG.  It could be done via the control panel or a 
manually entered MDI command.  In that case the latch would not be reset and it 
would refuse to perform X=0.5X later.

Danny

 Todd  Zuercher  wrote: 
> - Original Message -
> From: "andy pugh" 
> To: "Enhanced Machine Controller (EMC)" 
> Sent: Wednesday, December 28, 2016 4:54:02 AM
> Subject: Re: [Emc-users] Calling MDI from HAL
> 
> >On 28 December 2016 at 07:33, Danny Miller  wrote:
> >> Say I want to use a button to call a one-time G-code op via MDI.
> >> Literally once.  Repeat calls will break things.
> >
> >Is it possible to have the G-code subroutine refuse to run twice?
> >Perhaps through use of a parameter that is not saved through restart?
> >
> >This is probably more reliable than single-shotting in HAL, as there
> >is some chance that halui might miss a single-cycle pulse (it runs in
> >user-space not realtime)
> 
> This might be a little bit of a roundabout way to get there but it might work 
> for you.
> 
> create a custom M1xx code to setp the hal pin to call your halui-mdi command 
> that you only want ever called once.  Then setup another halui-mdi command to 
> call that M1xx code and connect that to your button.  Pressing the button 
> multiple times should have no effect because the once the setp for the first 
> command is set true, it will stay that way and multiple presses should have 
> no effect.  And if you should have a need to reset it, you could set up 
> another way to setp it back.
> 
> --
> 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] An observation on digital calipers

[dannym]

I tried to buy a new pair from Harbor Freight awhile back and they were just 
reading wrong.  IIRC jumped around missing large portions of travel.

Went back to exchange and thought to check first- ALL the ones on the shelf 
read wrong.  

Best results, Neiko calipers seem to be of consistent quality, yet cheap. 
Amazon.com

Danny

 andy pugh  wrote: 
> My little digital caliper is playing up. It could just be a low
battery, it has been flashing the LCD for at least a year.
(As an aside, why do they run normally for about a week then flash the
display for about a year?)
Anyway, moving the slider very slowly it goes from 0.3995" straight to
1.200", then acts a bit random until it switches from 1,499 to a
(correct) 0.800"
Which surprised me, I had assumed that the basic units of the scale
were metric.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

Re: [Emc-users] Traj MAX_VELOCITY

[dannym]

Should be a limit on the vector sum on linear axes only, and you're right, it 
may or may not be desirable.  The mechanical limits already give the per-axis 
limits.

If you make it "infinite", then you get a notably faster speed on diagonal 
rapids than ones that only go down one axis.  But that's hardly a problem.

Limiting traj acceleration is more meaningful.  The per-axis give mechanical 
limits, but your whole machine may walk across the floor if you combine accel 
from 2 axes on a diagonal.  

Danny


 "Klemen Živkovič"  wrote: 
> This parameter seems to me so general that I wonder how it can be applied
> to ALL axes also angular when units are different.
> 
> I am thinking to unlimit this (make it infinite) and then limit it per
> particular axis configuration.
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive. 
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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

Re: [Emc-users] LinuxCNC laser cutter?

[dannym]

You'd have to write VHDL code, compile into a bitfile, and then just use the 
mesaflash command-line to upload to the card.

Danny

 Les Newell  wrote: 
> I did wonder how expensive it is to write to the Mesa cards. I would 
> like to have a go at converting one of my lasers one day. However I have 
> a mill and router that need retrofitting before I look at any laser stuff.
> 
> Les
> 
> On 25/10/2016 13:25, Todd Zuercher wrote:
> > About 4-5kHz in a floating point base-thread was about as fast as I was 
> > able to get the read/writes for my Mesa 5i25/7i77 combo to run at.  There 
> > might be tricks to get it a little faster but I doubt there is a lot more 
> > to be gained with that combo.  Smart serial communication seemed to be the 
> > limiting factor.
> >
> > - Original Message -
> > From: "andy pugh" 
> > To: "Enhanced Machine Controller (EMC)" 
> > Sent: Tuesday, October 25, 2016 6:30:00 AM
> > Subject: Re: [Emc-users] LinuxCNC laser cutter?
> >
> > On 25 October 2016 at 09:48, Les Newell  wrote:
> >> Is there any reason why the realtime part of the raster component can't
> >> run in a faster thread, say 10kHz? As long as you have hardware PWM (e.g
> >> Mesa FPGA) you should be able to get pretty good resolution.
> > Generally the Mesa update functions run in the servo thread because
> > there is a fair bit of floating-point maths involved in PWM duty cycle
> > calculations.
> > It is possible to enable floating-point in a base thread, but I
> > suspect that the Mesa update function might be a bit "expensive" to
> > run at 10kHz.
> >
> 
> 
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive. 
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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

Re: [Emc-users] LinuxCNC laser cutter?

[dannym]

So there is another mode I didn't mention.  When accelerating or decelerating, 
you're not at the specified cut speed, and the laser power must be reduced 
proportional to the speed.

For that, it's gonna use the "fast" PWM ~(10-25KHz).  The period will be fixed 
but the duty cycle changes depending on current speed, which should be 
achievable with the 1ms servo-thread tying in current XY vector-sum velocity 
from emcmot into it.  

That one doesn't change rapidly, so it's pretty simple.

Danny

 andy pugh  wrote: 
> On 24 October 2016 at 20:36,   wrote:
> 
> > Seems like it makes sense to handle this on the Mesa.  It'd be a big task 
> > to understand the FPGA and recode it.
> 
> I don't think that there is any need for re-coding. (and I doubt that
> it would be sensible to start sending JPG data to the FPGA).
> The Mesa cards already have a PWM generator and (presumably) it is
> clever enough to do the right thing when the duty-cycle changes.
> 
> So, what is needed then is a realtime HAL component that reads image
> data and a userspace component to feed it that image data (no
> filesystem access for realtime components).
> The link I gave above has files to do part of this, it creates a
> private shared-memory region and loads image data into it where the
> realtime component can "see" it.
> 
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916


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

Re: [Emc-users] LinuxCNC laser cutter?

[dannym]

Well, Mesa was VERY awesome in that they open-sourced their VHDL code for the 
FPGA, the transport format, and their drivers.

Seems like it makes sense to handle this on the Mesa.  It'd be a big task to 
understand the FPGA and recode it.  But it sounds like it'd be of great benefit.

Or, alternately, AND-gate the two PWMs together.  Probably with an S-R latch to 
avoid giving runt pulses from the high speed PWM at the start/end of the 
low-speed PWM period.

Danny


 andy pugh  wrote: 
> On 24 October 2016 at 19:47,   wrote:
> > Pretty darn fast!  Rastering can be 35 inches/sec and 100 dpi or more (more 
> > dpi is questionable, the beam is typically 0.008" dia).  So, KHz changes.
> 
> So, in theory, changing the duty cycle of a 25kHz PWM at 3.5 kHz.
> It is possible, on some hardware, to run a 4kHz servo thread and to
> send the duty cycle to an FPGA card to generate the PWM.
> 
> If 2kHz is acceptable, then it looks a little easier. That would be 60
> dpi, or 100dpi at 20 inches/sec
> 
> > I can imagine handling bitmaps WAY better than what ULS did, but it seems 
> > like it has to happen in the printer drivers.
> 
> How do you fancy a coding project?
> _some_ of the work that needs to be done is already there:
> https://forum.linuxcnc.org/24-hal-components/22572-hal-power-laser#22961
> 
> 
> Note that there is also  Graster,
> wiki.linuxcnc.org/cgi-bin/wiki.pl?Rastering_With_A_Laser , but that
> seems kludgy to me. But has the advantage of working
> 
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916


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

Re: [Emc-users] LinuxCNC laser cutter?

[dannym]

Pretty darn fast!  Rastering can be 35 inches/sec and 100 dpi or more (more dpi 
is questionable, the beam is typically 0.008" dia).  So, KHz changes.

Rastering is done in two modes- one, you're modulating the power to make shades 
or depth.  Two, you're doing dithering and turning the laser on-off for longer 
periods, with "on" being a fixed intensity, with the intent of leaving 
untouched areas and burned areas.

So note this- you can have TWO periods here. e.g. "I want to burn my greyscale 
at 50% power, using dithering".  So like you're modulating power at 25KHz when 
in the "on" phase of dithering, and then 0 when "off", switching on and off the 
25KHz fixed-period 50% PWM at 3.5KHz with variable periods to achieve dithering.

On the Universal Laser Systems, that dithering didn't go so well with the 
periods they chose.
My plan became to convert my graphics to "1-bit" which allowed my photo 
software to use better dithering.  But then the ULS turned around and resampled 
it in its own resolution, leading to very obvious interference patterns.  

So I figured out the ULS's resolution and set the 1-bit conversion resolution 
to be a multiple of that, and got better success.

I can imagine handling bitmaps WAY better than what ULS did, but it seems like 
it has to happen in the printer drivers.

Danny

 andy pugh  wrote: 
> On 24 October 2016 at 19:06,   wrote:
> I like to do fine-detail rastering.  This does require rapidly changing the 
> power level, so it's quite a different task that just turning on the laser 
> with "Z".

Rastering with LinuxCNC doesn't work as well as it could.
Do you have a feel for how frequently the laser power needs to be adjusted?

I think that the best way to do rastering would be with a
special-purpose raster-generator component which also knows where in
an image file it currently is, and has an independent power output to
HAL based on the current pixel value.

I thing that involving G-code at all is a mistake.

I did make a start on making a set of HAL components to do this. But
it was purely an academic excercise, and I got bogged-down in trying
to make a finite-jerk rastering planner. (un-necessary to make it
work).

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

[Emc-users] LinuxCNC laser cutter?

[dannym]

I just acquired a really good CO2 laser tube, and going through building the 
machine around it.

How mature is LinuxCNC for laser cutting?  I see it was used for this several 
years ago, although it seemed like a hack job.

I like to do fine-detail rastering.  This does require rapidly changing the 
power level, so it's quite a different task that just turning on the laser with 
"Z".

I am familiar with Lasersaur.  Formal development stopped a long time ago and I 
heard it only supports rastering with branches, and it's kinda wacky in that 
they have the PC dumping the design to a Raspberry Pi and THEN using a 8-bit 
micro to step out the motion control.  Some of my rastering has been huge, and 
it would bulk up a lot when becoming g-code, which might be pretty massive to 
transfer to a Pi.

I'd like to use that 7i92 FPGA card again and drive direct from PC, LinuxCNC 
sounds like a good plan.

Danny 

--
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] Machinekit? --> LinuxCNC computer

[dannym]

I've used the 4-way tool I linked to with 12 ga to 22-24ga wire and it always 
gave a perfect crimp with no adjustment or finessing.

Danny

 Mark Johnsen  wrote: 
> On Mon, Oct 24, 2016 at 9:27 AM, Chris Albertson 
> wrote:
> 
> > Are you using the correct color terminal for the wire gage?   If so
> > and it is still loose one trick is to fold the wire in half before you
> > push it in the terminal,
> >
> 
> Probably not...  I bought a bunch of ChinoCo ferrules and they're all RED!
> But, I think they're about the right AWG size.  One bad thing about those
> Chinaco ferrules is the smaller, maybe AWG 24 ferrules are really long as
> well, so long they sometimes don't fit in the smaller phoenix contact
> terminal block receptacles.  So, I snip them off...
> 
> But, you're right, I should do the folding trick, that does work well.
> 
> Thanks,
> Mark
> 
> 
> >
> > The adjustment compensates for tool wear, You need to do this after a
> > maybe few thousand terminals  I always end up taking the whole thing
> > apart to see how it works.  Every brand of tool is different
> >
> > On Mon, Oct 24, 2016 at 9:14 AM, Mark Johnsen  wrote:
> > > I have those crimpers and do like them w/ the exception that I don't know
> > > how to turn the 'gear' to make the compression force stronger.  They're a
> > > little 'soft' for smaller dia wires.  I pulled the screw out, but the
> > > geared washer doesn't turn (the one w/ + and -), I suppose I need to
> > > un-attach the spring?  Then try it?  Wondering if anyone else figured out
> > > how they work.
> > >
> > > Mark
> >
> --
> 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] Machinekit? --> LinuxCNC computer

[dannym]

I've used the 4-way tool I linked to with 12 ga to 22-24ga wire and it always 
gave a perfect crimp with no adjustment or finessing.

Danny

 Mark Johnsen  wrote: 
> On Mon, Oct 24, 2016 at 9:27 AM, Chris Albertson 
> wrote:
> 
> > Are you using the correct color terminal for the wire gage?   If so
> > and it is still loose one trick is to fold the wire in half before you
> > push it in the terminal,
> >
> 
> Probably not...  I bought a bunch of ChinoCo ferrules and they're all RED!
> But, I think they're about the right AWG size.  One bad thing about those
> Chinaco ferrules is the smaller, maybe AWG 24 ferrules are really long as
> well, so long they sometimes don't fit in the smaller phoenix contact
> terminal block receptacles.  So, I snip them off...
> 
> But, you're right, I should do the folding trick, that does work well.
> 
> Thanks,
> Mark
> 
> 
> >
> > The adjustment compensates for tool wear, You need to do this after a
> > maybe few thousand terminals  I always end up taking the whole thing
> > apart to see how it works.  Every brand of tool is different
> >
> > On Mon, Oct 24, 2016 at 9:14 AM, Mark Johnsen  wrote:
> > > I have those crimpers and do like them w/ the exception that I don't know
> > > how to turn the 'gear' to make the compression force stronger.  They're a
> > > little 'soft' for smaller dia wires.  I pulled the screw out, but the
> > > geared washer doesn't turn (the one w/ + and -), I suppose I need to
> > > un-attach the spring?  Then try it?  Wondering if anyone else figured out
> > > how they work.
> > >
> > > Mark
> >
> --
> 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] Machinekit? --> LinuxCNC computer

[dannym]

So far I have used that 4-way tool I gave a link for with 12 ga down to like 22 
or 24 ga, it always gave a perfect crimp with no fiddling or adjustment.

Danny


 Chris Albertson  wrote: 
> Are you using the correct color terminal for the wire gage?   If so
> and it is still loose one trick is to fold the wire in half before you
> push it in the terminal,
> 
> The adjustment compensates for tool wear, You need to do this after a
> maybe few thousand terminals  I always end up taking the whole thing
> apart to see how it works.  Every brand of tool is different
> 
> On Mon, Oct 24, 2016 at 9:14 AM, Mark Johnsen  wrote:
> > I have those crimpers and do like them w/ the exception that I don't know
> > how to turn the 'gear' to make the compression force stronger.  They're a
> > little 'soft' for smaller dia wires.  I pulled the screw out, but the
> > geared washer doesn't turn (the one w/ + and -), I suppose I need to
> > un-attach the spring?  Then try it?  Wondering if anyone else figured out
> > how they work.
> >
> > Mark
> >
> > On Mon, Oct 24, 2016 at 4:20 AM, Gene Heskett  wrote:
> >
> >> On Monday 24 October 2016 05:56:53 andy pugh wrote:
> >>
> >> > https://www.amazon.com/Signstek-Adjusting-Ratcheting-Crimping-AWG23-10
> >> >/dp/B00HPRYIL8/ref=sr_1_5?ie=UTF8=1477283614=8-5=ferrul
> >> >e=1
> >>
> >> Looks usefull, bought the pair.
> >>
> >>
> > --
> > 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
> 
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> 
> --
> 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] New stepper-servo --> Phase delay

[dannym]

They put a Cortex M0 on the module that sits on the board, along with the 
stepper driver and encoder.

There's a greater latency inside the Cortex, it will likely have to respond to 
an interrupt thus have ISR latency.  I presume they've got a PLL to prevent 
oscillation within the final step.

It's not a bad case for an FPGA, since with proper coding the latency is 
limited by the response time of the transistors.

Danny


 Nicklas Karlsson  wrote: 
> Best option is probably to generate stepper signal from hardware timer.
> 
> 2016-10-21 8:17 GMT+02:00 Danny Miller :
> 
> > The SPI comm of course has latency within a comm period.
> >
> > However, the pulse output must be super-fast.  It supports up to 14500
> > rpm, so if it's 2000steps/rev the whole step cycle is 2ms, realistically
> > like maybe 1/4 of that for latency?
> >
> > Danny
> >
> > On 10/19/2016 11:34 PM, Nicklas Karlsson wrote:
> > >>> ... The lag also seemed to vary with velocity.
> > >>>
> > >>>
> > >> Most specifically, it was a lag in the encoder's loop to respond to
> > >> acceleration.
> > >> Velocity was fine, but when there is acceleration, the encoder's
> > >> velocity didn't change for a few milliseconds, then it had to produce
> > >> velocity greater than real for position to catch up.
> > >> I thought it was a really severe problem, but it seems it may not be all
> > >> that bad.  But, it can make servo tuning more tricky.
> > >>
> > >> Jon
> > > Delay is called phase in control theory and it is not good at all for
> > fast response.
> > >
> > > 
> > --
> > > 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


--
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] Machinekit?

[dannym]

Is building LinuxCNC for the BB and running Machinekit two different things?

Why wouldn't you just build LinuxCNC for it, and just add a component for the 
IO pins instead of the paraport component?

Danny


 John Kasunich  wrote: 
> 
> 
> On Wed, Oct 19, 2016, at 01:55 PM, andy pugh wrote:
> > On 19 October 2016 at 18:39,   wrote:
> > 
> > > Anybody familiar with this?
> > 
> > Somewhat. Machinekit is a fork of LinuxCNC, so many things are exactly
> > the same. The split was a few years ago now, so there has been some
> > divergence, but they probbaly look very similar indeed to a user.
> > 
> 
> I looked into machinekit because I wanted to use a BeagelBone.  I found the 
> user-level documentation to be disappointing.  Things that are the same in 
> machinekit and LinuxCNC inherited the good LinuxCNC documentation.  I can't 
> say enough good things about what John Thornton (and others) have done for 
> our documentation.  Unfortunately things that are new in machinekit (and thus 
> the reason I wanted to use it) are barely documented at all.  
> 
> Recently Jeff Epler and others have figured out how to build LinuxCNC for 
> beaglebone, so I came back to my roots and am happy.
> 
> -- 
>   John Kasunich
>   jmkasun...@fastmail.fm
> 
> --
> 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] Glitch with XHC driver when running intense G-code

[dannym]

When I run 3D jobs, I keep running into a minor-but-annoying problem where it 
pops up a window saying it's lost contact with the wireless XHB mpg. Like 
several times per min.  It doesn't interfere with the machine running, luckily.

The mpg didn't get moved, and this warning doesn't come up under normal 2D cuts.

My theory is that the XHC driver is a userspace component and, if you demand 
enough intense tiny g-code vectors rapidly on the realtime threads, it gets too 
starved of cycles and times out.

Could this be the case?  Is there a good way to fix it?

Danny


--
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] Machinekit?

[dannym]

http://www.machinekit.io/

Anybody familiar with this?  Got a friend who wants to put it on a BeagleBone 
Black.  LinuxCNC run onboard a Cortex A8 directly and the HDMI monitor, 
keyboard, mouse etc plug straight into that, not just acting as a motion 
controller from a remote PC.

Notable benefit would seem to be that the IO is very low-latency without a 
motion controller card, and the architecture is 100% consistent, as opposed the 
latency lottery that is picking a PC and its MB chipset and seeing how it 
works.  

BBB does have 2x 46 pin IO headers.  I'm not sure if all pins can be assigned 
arbitrary HW functions, but it sounds like plenty anyhow.

He asked me about it and all I can do so far is say "hmm".  The Machinekit 
website is pretty sparse.

Danny

--
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] Hacking a sim runtime mode

[dannym]

 Chris Albertson  wrote: 
> On Thu, Oct 13, 2016 at 9:00 AM, Peter C. Wallace  wrote:
> > On Thu, 13 Oct 2016, dan...@austin.rr.com wrote:
> >
> 
> > I just tried a real time Mesa Ethernet config with maxvel = 12 IPM (2000
> > IPS = 20 MHz step rate at present 1 steps/In scaling) and maxaccel 2
> > IPS/S (52 Gs) with a 1 KHz servo thread, and it works fine (Peak following
> > errors in the 1-2 mill region)
> 
> The problem to be solved is getting an estimate of the time required
> to complete a job.   Does the above do this accurately?

Yeah I want to know this.  I can run a job for real vs "fast sim" and compare.  
One prob is the cycle time only goes down to seconds AFAIK.  If it's 100x then 
that's over a minute and a half it could be wrong, but that's still good enough 
as long as it's not estimating a very short job.

I am skeptical that the mechanisms will time themselves the same way, but I 
don't know enough to say.
 
> The problem is to get the shape of the velocity curves to be the same
> in the sim as the real job.   In a real 3D wood carving job I thing
> the mill never gets to near full speed and is always making think
> movements and accelerating.   Your sim MIGHT accelerate to quickly and
> make some parts of the work run at a constant velocity (your maximum)
> 
> Intuitively (I've not proved it to myself) you need to scale the max
> speed and acceleration by the same constant.   (But what about third
> derivative?)

I was told the MAX_JERK parameter- (third deriv) was not actually used, not in 
the main branch.  

> 
> Time estimation seem to be a missing feature.  It should not require a
> hack   I _think_ that a machine tool that has all orthogonal and
> linear axis where movement time depends only on delta-X and not on X
> (or Y or Z) then you should not require a full simulation to compute
> the job time as you can simply sumo the deltas.Note that there ARE
> many non-linear machines but mostly these are robots.

Time estimation is SUPER important to me.
1. I can tune the machine to trade off one param for another, a lower max speed 
but higher accel.  I need to know if that helps or hurts runtime, and it can 
actually change from job to job.  A large design without sharp features will go 
faster with high max vel and lower accel.
2. Similarly, I can do changes in design with more raster lines vs less, change 
size and/or depth, and need to know what the cost of that change is.  You'd be 
surprised, doubling the design's size (quadruple the area) with a ball twice 
the diameter may actually take LESS time because it's not demanding huge accels 
in and out of small features.
3. I need to plan my day.  A 2 hr carving is a different product than a 6 hr 
carving.  I need to know when it'll be done, do I run this before going out for 
dinner or will it not be done before I need to leave?  And how much to charge 
before actually doing it.  Customers like to be told a price before the work is 
done.

Danny

> -- 
> 
> Chris Albertson
> Redondo Beach, California
> 
> --
> 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] Hacking a sim runtime mode

[dannym]

Are you saying that's why I got a joint following error?  

I also tried dividing the scale by 100x, so it actually doesn't demand more of 
the stepgens.  Didn't help.

Danny

 andy pugh  wrote: 
> On 13 October 2016 at 16:39,   wrote:
> > Anyhow, yes- stepgen max stuff in the ini file also got increased by 100x.
> 
> Yes, but the system knows that it can't make 100x as many steps per
> second, and thinks that it needs to to make the speeds.
> 
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916


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

Re: [Emc-users] Hacking a sim runtime mode

[dannym]

It's not actually a sim profile, it's a standard profile but the motors will be 
disabled.  Ultimately, it's essential to not have to switch to a "sim" for 
practicality.

Anyhow, yes- stepgen max stuff in the ini file also got increased by 100x.

I also thought about the odd effects if the PWM couldn't follow, so I tried 
decreasing DIRHOLD etc by 100x.

Danny

 andy pugh  wrote: 
> On 13 October 2016 at 15:57,   wrote:
> > Well that's what I tried and described in the initial email.  100x the vel 
> > and accel.
> >
> > It ended up with a "Joint Following Error", and I'm not sure why.
> 
> Is the sim running a stepgen?
> 
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916


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

Re: [Emc-users] Hacking a sim runtime mode

[dannym]

Well that's what I tried and described in the initial email.  100x the vel and 
accel.

It ended up with a "Joint Following Error", and I'm not sure why.

Danny

 andy pugh  wrote: 
> On 13 October 2016 at 04:23,   wrote:
> Is there a better way, like

Possibly. You could try settting up one of the sim configs with 100x
your machine limits. (maybe even 1000x)

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

[Emc-users] Hacking a sim runtime mode

[dannym]

I do 3D carving, and it's very important to know the job runtime before 
starting and while tuning, for various reasons.

The Properties time estimator is not useful, it just uses distance/feedrate.  
That doesn't take into account acceleration, which dominates the runtime in my 
case.  The actual runtime can be 3x-20x the time estimated there, depending on 
how deep and detailed it is, so it really says nothing.

I'm used to estimating under Mach3, which gives a 100% accurate time estimate 
which was wonderful.  It may take a few minutes to eval a large file. 100:1 is 
an acceptable eval time (100 min file evaluated inside 1 min).

I did have a thought "what if I give 100x the vel and accel, stepgens,  100x 
the Traj max vel/accel, divide the axis SCALEs by 100x, and use 100x for 
Feedrate Override?"  Then I could just disable the physical stepper drives, 
take the cycle time and mult by 100x. Actually that won't stress the step times 
weirdly because their scales are divided by 100x.

But all I got was "Joint Following Error" and couldn't move anything, even in 
manual jog.  Not sure why, with the scale kicked down 100x, a max velocity 100x 
greater will just run steps out at the same max speed.  But apparently I broke 
something.  I do use a 7i92 card with a PLL so there's that.  I did increase 
MAX_ERROR by 100x but no luck there.

Is this experiment a dead end?  Why did it break, and is there any way to make 
my concept work?

Is there a better way, like disconnecting EMCMOT from the stepgen and having it 
tally the time consumed without actually spending the time to do anything?

Danny







--
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] Overriding the feedfate override

[dannym]

Oh hey that looks exactly like what I need!  Thanks!

Danny

 sam sokolik  wrote: 
> would any of these help?
> http://linuxcnc.org/docs/2.7/html/gcode/m-code.html#mcode:m48-m49
> 
> On 10/12/2016 1:09 PM, dan...@austin.rr.com wrote:
> > As described earlier, I have a probe I used to set the Z after changing 
> > tools.  The Probe Z button calls an MDI which calls a .ngc g-code file 
> > which uses the G38 probe routine.
> >
> > What I realized is the Feedrate Override mucks with the probe cycle.  The 
> > probe cycle needs to operate at a consistent speed, but Feedrate Override 
> > is being used, sometimes resulting in terribly slow or fast probes.
> >
> > What are the options here?  The g-code can't ignore or set the Feedrate 
> > Override, can it?
> >
> > All I could think of was tying the Probe Z button to a HAL which copies FO 
> > to a backup net "FeedOverride_Back" on rising edge, writes FO=1.0, and 
> > copies back on falling edge of is-auto.  This sounds super-convoluted.
> >
> > Also, important question to know overall- how could that work?  If I have a 
> > a rising edge of Probe Z button, and I both copy FO to FeedOverride_Back 
> > AND write FO=1.0 concurrently, is there a way to predict what gets stored 
> > in FeedOverride_Back?  This sounds like it's two separate threads, and you 
> > don't have a guarantee as to which executes first.
> >
> > e.g. Feedrate Override is 0.2.  Does FeedOverride_Back always get 0.2, or 
> > could FO=1.0 execute first so both Feedrate Override and FeedOverride_Back 
> > = 1.0, and the 0.2 value is lost forever?
> >
> > Would it make sense to get sneaky and, inside the G-code for the probe, 
> > divide the desired F-parameter by the current Feedrate Override, e.g. 
> > desire F10, write F10/[some way to get Feedrate Override=0.2] = 50 which 
> > will result in a feedrate of 10 due to the 0.2 multiplier?
> >
> > Danny
> >
> >
> > --
> > 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] Overriding the feedfate override

[dannym]

As described earlier, I have a probe I used to set the Z after changing tools.  
The Probe Z button calls an MDI which calls a .ngc g-code file which uses the 
G38 probe routine.

What I realized is the Feedrate Override mucks with the probe cycle.  The probe 
cycle needs to operate at a consistent speed, but Feedrate Override is being 
used, sometimes resulting in terribly slow or fast probes.

What are the options here?  The g-code can't ignore or set the Feedrate 
Override, can it?

All I could think of was tying the Probe Z button to a HAL which copies FO to a 
backup net "FeedOverride_Back" on rising edge, writes FO=1.0, and copies back 
on falling edge of is-auto.  This sounds super-convoluted.  

Also, important question to know overall- how could that work?  If I have a a 
rising edge of Probe Z button, and I both copy FO to FeedOverride_Back AND 
write FO=1.0 concurrently, is there a way to predict what gets stored in 
FeedOverride_Back?  This sounds like it's two separate threads, and you don't 
have a guarantee as to which executes first.  

e.g. Feedrate Override is 0.2.  Does FeedOverride_Back always get 0.2, or could 
FO=1.0 execute first so both Feedrate Override and FeedOverride_Back = 1.0, and 
the 0.2 value is lost forever?

Would it make sense to get sneaky and, inside the G-code for the probe, divide 
the desired F-parameter by the current Feedrate Override, e.g. desire F10, 
write F10/[some way to get Feedrate Override=0.2] = 50 which will result in a 
feedrate of 10 due to the 0.2 multiplier?

Danny


--
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] Getting current RPM setting?

[dannym]

Alright!  All good to know.

How do I figure out what's accessible?  For example, max number of lines in a 
g-code file (as needed for another new feature) might or might not be 
accessible.  
I can look and try to figure this out but there's 100+ LinuxCNC files.  Which 
file should I be looking at?

Danny

 andy pugh  wrote: 
> On 6 October 2016 at 16:36,   wrote:
> So help me with a bigger picture-
>
> This feature could be exposed to the HAL by Python code alone, so there's no 
> compile stage?

Yes.

> Does this require modifying existing files from LinuxCNC, or just adding new 
> files?

No, just create a new file called "status" containing that text, give
it exec permissions and move it to /usr/bin then you can "loadusr
status" in the HAL file and it will create a commanded-speed HAL pin.
You could do it rather more neatly, I suspect, in GladeVCP. That code
could run in the background and update a display directly without
going through HAL.

> If I make this change in my current LinuxCNC, what would it be like to import 
> those changes into a new version of LinuxCNC?

I think that, as LinuxCNC knows nothing about the component, it will
just leave it untouched.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

Re: [Emc-users] Getting current RPM setting?

[dannym]

So help me with a bigger picture-

This feature could be exposed to the HAL by Python code alone, so there's no 
compile stage?

Does this require modifying existing files from LinuxCNC, or just adding new 
files?

What directory would that go in?

If I make this change in my current LinuxCNC, what would it be like to import 
those changes into a new version of LinuxCNC?

Danny

 andy pugh  wrote: 
> On 6 October 2016 at 01:45, Sebastian Kuzminsky  wrote:

> In python it's in linuxcnc.stat.settings[2].  Maybe not the most
> intuitive name for it...

Indeed not.

This works as a userspace component.

#!/usr/bin/python
import hal, time
import linuxcnc
h = hal.component("status")
h.newpin("spindle-preset", hal.HAL_FLOAT, hal.HAL_OUT)
h.ready()
s = linuxcnc.stat()
try:
while 1:
time.sleep(1)
s.poll()
h['spindle-preset'] = s.settings[2]
except KeyboardInterrupt:
raise SystemExit




-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

Re: [Emc-users] Getting current RPM setting?

[dannym]

How hard would it be to get a number for how many lines are in the g-code?

I saw the HAL has a "current line number".  I need the total, presumably 
determined when it loaded.

Reason being, my prior post- can give an ETA for 3D carving by (time/current 
line number)*(total lines in G-code -  current line number)

e.g. 10 min in, current count is 50k lines, total file is 200k lines, ETA is 30 
min.

Danny

 John Thornton  wrote: 
> I see where it is wonky... let me see if I can finger out what caused 
> that...
> 
> JT
> 
> On 10/5/2016 9:33 AM, andy pugh wrote:
> > On 5 October 2016 at 15:17, Sebastian Kuzminsky  wrote:
> >> But the information *is* available in the Interpreter (in Task), and
> >> shared from there to all other components that want it, via the Status
> >> structure.  The bests place to export it from is probably halui.  So I
> >> change my suggestion from "add a pin to Motion", to "add a pin to halui"
> > Would it be available to a userspace Python component via the
> > linuxcnc.stat structure?
> > http://linuxcnc.org/docs/2.7/html/config/python-interface.html
> > What does that version of spindle_speed show?
> >
> > (I also note that the formatting of that page has gone funny)
> >
> 
> 
> --
> 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] HAL "watchdog" component

[dannym]

 "Peter C. Wallace"  wrote: 
> On Sun, 2 Oct 2016, dan...@austin.rr.com wrote:
> 
> > Date: Sun, 2 Oct 2016 19:59:37 +
> > From: dan...@austin.rr.com
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: emc-users@lists.sourceforge.net
> > Subject: [Emc-users] HAL "watchdog" component
> > 
> > I am trying to put this in to watch the VFD modbus driver's "watchdog" pin, 
> > and tie a pyvcp LED showing VFD is good, as per:
> > http://linuxcnc.org/docs/html/man/man9/watchdog.9.html
> >
> > I used:
> >
> > loadrt watchdog num_inputs=1
> > addf watchdog servo-thread
> >
> > I have 2 issues:
> >
> > One, it generates the following error:
> >
> > HAL: ERROR: function 'watchdog' not found
> > custom_postgui.hal:42: addf failed
> >
> > My first thought was "well, I didn't include which watchdog it was, it 
> > needs to be watchdog.0".  But that just gets "function 'watchdog.0' not 
> > found".  And the line "setp watchdog.timeout-0 1.0" DOES pass,  as does 
> > "net vfdReadyLed watchdog.ok-out => pyvcp.vfd-ready-led".
> >
> > Second, I'm confused.  The man pages only offers "num_inputs" as an option, 
> > and that only creates more fan-in, not multiple components.  There's no 
> > "count" or "names" parameter, and I tried, HAL just errors "unknown 
> > parameter" when it loads.
> >
> > So can there only be one "watchdog" component, ever?  That doesn't seem 
> > right at all, that's not how HAL components work.  But how would you 
> > include more, and refer to different ones?  How does "addf" work?
> >
> > Danny
> 
> In the watchdog manual page you will see the two wtachdog functions
> "process" and "set-timeouts"
> 
> These are the functions tha must be added via addf
> 
> (watchdog.process and watchdog.set-timeouts)
> 
> 
> 
> Peter Wallace
> Mesa Electronics

Huh.. weird, but is there any way to create more than one?

Kinda beside the point, I made a better component with oneshot + rising=TRUE, 
falling=TRUE, retriggerable=TRUE.  Now it stays TRUE as long as it's been 
triggered in the last 1/2 sec.  That's exactly what I want in a watchdog.


Danny


--
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 "watchdog" component

[dannym]

I am trying to put this in to watch the VFD modbus driver's "watchdog" pin, and 
tie a pyvcp LED showing VFD is good, as per:
http://linuxcnc.org/docs/html/man/man9/watchdog.9.html

I used:

loadrt watchdog num_inputs=1
addf watchdog servo-thread

I have 2 issues:

One, it generates the following error:

HAL: ERROR: function 'watchdog' not found
custom_postgui.hal:42: addf failed

My first thought was "well, I didn't include which watchdog it was, it needs to 
be watchdog.0".  But that just gets "function 'watchdog.0' not found".  And the 
line "setp watchdog.timeout-0 1.0" DOES pass,  as does "net vfdReadyLed 
watchdog.ok-out => pyvcp.vfd-ready-led". 

Second, I'm confused.  The man pages only offers "num_inputs" as an option, and 
that only creates more fan-in, not multiple components.  There's no "count" or 
"names" parameter, and I tried, HAL just errors "unknown parameter" when it 
loads.

So can there only be one "watchdog" component, ever?  That doesn't seem right 
at all, that's not how HAL components work.  But how would you include more, 
and refer to different ones?  How does "addf" work?

Danny 

--
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] Estimated time remaining

[dannym]

I am doing 3D carving, where the Properties analysis is regrettably useless for 
coming up with time estimates due to not taking into account the acceleration 
aspect of trajectory planning.

I did install the cycle timer pvcp and it does certainly help.

But one thing I noticed- these carvings are "mostly" consistent in how much 
time they're taking per-line.  It would be accurate enough to be helpful to 
calculate:

Time Remaining=(total # of gcode lines/gcode lines done so far)*cycletime so far

Is there any way to do that?  All I can see is access to "time".  

Danny

--
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] Function of MAX_JERK?

[dannym]

I was doing tuning for my 3D carving profile and started experimenting with the 
per-axis MAX_JERK in the .ini file [AXIS_x] sections.  LinuxCNC 2.7.4.

The value I had initially was 2000, I gave it 20 and 2.

It made no change at all to the runtime, nor did the machine look to jerk 
around any more or less.  

It's a 3D carving file with a LOT of small vectors and takes about 4x longer to 
run than the estimator says.  So acceleration and jerk should have prominent 
effects on runtime.

Is this "MAX_JERK" functionality hooked up to anything?  I didn't see it under 
the man page online, but the url does have "2.6" in it.

Thanks,
Danny


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

Re: [Emc-users] Trouble with TWOPASS and Mesa loadrt

[dannym]

 Dewey Garrett  wrote: 
> 
> > The line in 7i92_AM882_hack.hal was:
> > loadrt [HOSTMOT2](DRIVER) config=[HOSTMOT2](CONFIG)
> 
> For this case you can omit parentheses:
> loadrt [HOSTMOT2]DRIVER config=[HOSTMOT2]CONFIG

OK I made the loadrt as above, it loads ok without TWOPASS, but when I added 
TWOPASS, I get:
twopass: Error in file ./7i92_AM882_hack.hal:
can't read "::HOSTMOT2((BOARD)": no such element in array
twopass: Error in file ./xhc-hb04_hack.hal:
can't read "::HOSTMOT2((BOARD)": no such element in array


So my next thought is I also needed to remove the parenthesis in the 
references, changing
setp hm2_[HOSTMOT2](BOARD).0.watchdog.timeout_ns 2500
net estop_hardswitch  hm2_[HOSTMOT2](BOARD).0.gpio.030.in_not  => and2.6.in0

into this:

setp hm2_[HOSTMOT2]BOARD.0.watchdog.timeout_ns 2500
net estop_hardswitch  hm2_[HOSTMOT2]BOARD.0.gpio.030.in_not  => and2.6.in0

But it won't parse with TWOPASS= on:

can't read "::HOSTMOT2(BOARD.0.watchdog.timeout_ns)": no such element in array
can't read "::HOSTMOT2(BOARD.0.gpio.030.in_not)": no such element in array

Without TWOPASS, I see to have broken parsing anyhow:
Ini variable '[HOSTMOT2]BOARD.0.watchdog.timeout_ns' not found.

?  Is there a harder bug here regarding parsing the parenthesis?  It seems to 
require them in the references, but TWOPASS chokes when trying to parse them.

Danny

> 
> Though I find little documentation, halcmd (halcmd.c) supports
> interpretation of ini variables in two formats:
>[SECTION]VAR
>[SECTION](VAR)
> 
> The form using parentheses is needed in some cases to resolve
> parsing ambiguities.
> 
> The twopass processing has not supported the form using parentheses.
> 
> I will address this omission with a future patch update for 2.7 but your
> case can probably be handled using the form without parentheses.
> 
> 
> -- 
> Dewey Garrett
> 
> 
> --
> ___
> 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] Trouble with TWOPASS and Mesa loadrt

[dannym]

I am trying to add a run timer as per the time man page.

LinuxCNC fails to load.  Initially I think the offending line was "not: already 
exists" in the postgui hal.  Yes it uses loadrt not, and if I comment all the 
"not" stuff out, linuxCNC loads fine.  loadrt is used in another hal.

So, I looked at how this works and see I probably need "TWOPASS= on", so I 
added that to my ini [HAL] section.  
First question: was that the correct thing to do?

Now I get:

twopass: Error in file ./7i92_AM882_hack.hal:
can't read "::HOSTMOT2((DRIVER)": no such element in array
twopass: Error in file ./xhc-hb04.hal:
can't read "::HOSTMOT2((BOARD)": no such element in array

The line in 7i92_AM882_hack.hal was:
loadrt [HOSTMOT2](DRIVER) config=[HOSTMOT2](CONFIG)

xhc-hb04.hal only references some pins, it does not have a loadrt.

So did the syntax of the Mesa loadrt break TWOPASS?
How do I fix it?

Thanks,
Danny


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

Re: [Emc-users] Need unlocked copy of a pdf for a breakout board I just bought two of.

[dannym]

Why the 5i25?

I have the 7i92, I like the ethernet.  It allows me to put the card in the 
control box without a mass of critical cabling between the PC and the drives.  
Ethernet doesn't have much for length limitations.

Danny

 Chris Albertson  wrote: 
> I have not yet bought a 5i25 card.  So my question might be answered in
> whatever documentation comes with it.
> 
> Can this card be used as a general purpose FPGA development card?  Is the
> process well documented some place?   If so then this card can be used for
> almost any purpose, for example I could build a function generator a logic
> analyzer.
> 
> The other question:   So we get the source code VHDL files for the firmware
> inside this card?  This means we could use any FPGA card or even build one
> from a FPGA chip
> 
> 
> 
> On Wed, Sep 7, 2016 at 6:32 AM, Ralph Stirling <
> ralph.stirl...@wallawalla.edu> wrote:
> 
> > The 5i25 is completely flexible, ..  It isn't at all impossible to set
> > up
> > to generate your own bitfiles, but requires careful editing of some vhdl
> > text files.--
> >
> 
> Chris Albertson
> Redondo Beach, California
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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

Re: [Emc-users] Need unlocked copy of a pdf for a breakout board I just bought two of.

[dannym]

Mesaflash allows you to change the IO configuration, but only to a number of 
premade configs, not arbitrary.  The GPIO has few limits but the location of 
special-purpose STEPx/DIRx pairs are fixed. But those locations change based on 
the mesaflash file you use.

Danny
 
 Gene Heskett  wrote: 
> Greetings all;
> 
> Those breakout boards I bought 2 of arrived today, and are apparently pin 
> assigned according to what a mach3 system might use, including the male 
> db25 on the pcb.  It apparently has pre-assigned output pin groups that 
> are about as incompatible with a 5i25 as could be. I never did find 
> where the X axis for my lathe comes out, but the Z is apparently in the 
> B group of 4.  I ran the spindle, expecting to see the analog of the pwm 
> someplace, but if its there, it is routed to the db15 on the other end 
> of the card.  So I go to look at the pdf of the board thats on the mini 
> cd-r, and found it, and a .doc file, both of which are password 
> protected. Its not that much money, and it would cost thru the nose to 
> put a stop payment on it, but I am tempted anyway.  What a maroon!
> 
> The board is this one.
> 
> 
> Anybody recognize it, or has used it?  Better yet, knows how to unlock 
> the pdf?  Nothing I have here, including libreoffice, can touch the pdf 
> or the .doc files for the card.  All sorts of adv stuff for his driver 
> boxes, you can look at them, but nothing on the card itself.
> 
> I'd love to be able to buy about a 6 pack of cnc4pc's old C1G BoB's, as 
> it has an led for state on every pin, a great troubleshooting tool.  But 
> its been disco'd. Even at 80 plus bucks it was a good card.
> 
> Thanks all, for any help on this.
> 
> Cheers, Gene Heskett
> -- 
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
> 
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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

Re: [Emc-users] What does "CNC" really mean?

[dannym]

 Dave Cole  wrote: 
> On 9/2/2016 1:13 PM, John Kasunich wrote:
> >
> > On Fri, Sep 2, 2016, at 07:29 AM, Bruce Layne wrote:
> >>
> >> On 08/31/2016 10:22 PM, Gregg Eshelman wrote:
> >>> Surprising that just for the fun of doing it, someone hasn't built a 
> >>> punched tape reader for a 3D printer.
> >>
> >> Have you SEEN 10MB of paper tape?!?  :-o
> >>
> >> The bits on paper tape are about .1" in diameter.  That's a lot of paper
> >> tape.
> > 15.8 miles of paper actually.
> >
> > The spool would be over 35 inches in diameter and weigh 115 lbs.
> >
> Yet it is hardly a blip on an $8 -  32 gig stick drive.  The old 
> days of 360K floppies and those newfangled hi-capacity 720 K and 1.44 
> meg floppies seem so long ago You could stick a 1.44 meg floppy 
> in your pocket!   That was crazy!  
> 
> Dave

I seem to recall "the Library of Congress" was the measuring stick for data, 
just like "Olympic swimming pool" is for volume.  Of course scanned pages vs 
ASCII vs compressed ASCII make that vary a lot- and the LoC catalog was notably 
smaller in earlier decades.

Danny

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

Re: [Emc-users] Can't figure out homing on gantry

[dannym]

 dan...@austin.rr.com wrote: 
> 
>  Andy Pugh  wrote: 
> > 
> > 
> > > On 1 Sep 2016, at 08:17,   
> > > wrote:
> > > 
> > > Is "2.8 pre" stable enough to consider reliable?  
> > 
> > I would use it myself (and do) but I wouldn't sell a system with it. 
> > 
> > I haven't seen any problems in several years of using various JA flavours. 
> > With the possible exception of an attempt at rigid tapping in the Y 
> > direction (and I don't even know if that is expected to work)
> 
> Well, a lot of people would be using it in the shop.  So something suggestive 
> of "bleeding edge" could be a problem.
> 
> My problem is that under 2.7.4, I THOUGHT the gantry component was doing 
> independent homing of the X1 and X2 motors.  There are homing switches tied 
> in on the joints.  However, a physical check of what was going on showed it 
> wasn't fully aligned and basically it was just jogging both joints in sync 
> until X1's homing switch tripped and then drive both back in sync while 
> watching the X1 homing switch alone.  X2 wasn't being used at all and it 
> couldn't fix gantry racking.  I'm not clear on whether gantry does or does 
> not have the ability to independently home, I thought I was told it does. I 
> just need indep homing.
> 
> I don't have any feelings for "gantry" vs "JA" except that gantry is already 
> set up.  If I don't go with 2.8-pre, what are my options for getting indep 
> homing?  Sounds like I do at least need to upgrade LinuxCNC.
> 
> Danny
> 

Well, wait- just rechecked the gantry man page: "When the system is homing and 
a joint home switch activates, the command value sent to that joint is "frozen" 
and the joint offset value is updated instead"

It unambiguously DOES say it's per-axis homing, but I saw it stop both when 
X1's limit tripped and X2 never went into seek, and if X2 was in front of X1, 
went over the homing switch with no effect until X1 tripped.

Here's what's in my HAL that should be relevant, did I screw something up?

loadrt gantry count=1 personality=2
net switches-x1   <=  hm2_[HOSTMOT2](BOARD).0.gpio.005.in_not
net switches-x2   <=  hm2_[HOSTMOT2](BOARD).0.gpio.003.in_not
net switches-x1   => gantry.0.joint.00.home
net switches-x2   => gantry.0.joint.01.home
net home-x <= gantry.0.home
net home-x  => axis.0.home-sw-in

Danny

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

Re: [Emc-users] Can't figure out homing on gantry

[dannym]

 Andy Pugh  wrote: 
> 
> 
> > On 1 Sep 2016, at 08:17,   
> > wrote:
> > 
> > Is "2.8 pre" stable enough to consider reliable?  
> 
> I would use it myself (and do) but I wouldn't sell a system with it. 
> 
> I haven't seen any problems in several years of using various JA flavours. 
> With the possible exception of an attempt at rigid tapping in the Y direction 
> (and I don't even know if that is expected to work)

Well, a lot of people would be using it in the shop.  So something suggestive 
of "bleeding edge" could be a problem.

My problem is that under 2.7.4, I THOUGHT the gantry component was doing 
independent homing of the X1 and X2 motors.  There are homing switches tied in 
on the joints.  However, a physical check of what was going on showed it wasn't 
fully aligned and basically it was just jogging both joints in sync until X1's 
homing switch tripped and then drive both back in sync while watching the X1 
homing switch alone.  X2 wasn't being used at all and it couldn't fix gantry 
racking.  I'm not clear on whether gantry does or does not have the ability to 
independently home, I thought I was told it does. I just need indep homing.

I don't have any feelings for "gantry" vs "JA" except that gantry is already 
set up.  If I don't go with 2.8-pre, what are my options for getting indep 
homing?  Sounds like I do at least need to upgrade LinuxCNC.

Danny

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

Re: [Emc-users] Can't figure out homing on gantry

[dannym]

 Gene Heskett  wrote: 
> On Wednesday 31 August 2016 20:49:22 dan...@austin.rr.com wrote:
> 
> > I'm using the LinuxCNC 2.7.4 with the realtime support.
> >
> > Does the "2.8 pre" have the same RT support?
> >
> > Danny
> 
> First, please don't top post, and second, yes.
> 
> And the 2.7.4 you are running is quite old.  If you have not updated 
> since the install, please do so before we hear you have been hacked, 
> there is a boatload of security fixes in the repositories.  I just did a 
> fresh install, and despite my having the last respin of the install dvd, 
> there were still 244 updates, most of which were small so it didn't take 
> long, perhaps 20 minutes with a reboot in the middle. 

Is "2.8 pre" stable enough to consider reliable?  Is the any practical way to 
add JA to an existing installation? 

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

Re: [Emc-users] Can't figure out homing on gantry

[dannym]

I'm using the LinuxCNC 2.7.4 with the realtime support.

Does the "2.8 pre" have the same RT support?

Danny


 John Thornton  wrote: 
> Yup
> 
> On 8/30/2016 1:56 AM, dan...@austin.rr.com wrote:
> > So, I have to switch to 2.8-pre for JA?
> >
> > Danny
> >
> >  Charles Steinkuehler  wrote:
> >> On 8/25/2016 11:38 AM, dan...@austin.rr.com wrote:
> >>> So I guess it does do that.  Now if one home was physically
> >>> installed where it trips 0.53" before physical end-of-travel, if
> >>> this were NOT the gantry axis I'd just give its final machine coord
> >>> as 0.53" and its machine coord is correct (0=end-of-travel).  But
> >>> in this one, say one gantry switch is mounted to trip at 0.5" but
> >>> the other trips at 0.65".  If homing acts like non-gantry joints,
> >>> it would physically leave it at 0.5" and 0.65" and leave joint mode
> >>> with it physically out of sync like that.  Which would mean the
> >>> joints are racked by 0.15" and will forever be locked like that
> >>> because future moves are in axis mode, not joint mode.
> >>>
> >>> Does it have the ability to physically move the joints into
> >>> alignment based on .ini parameters saying one switch is 0.15" off,
> >>> or do I just need to keep physically remounting one switch until
> >>> its trip point is "close enough" to the other?
> >> No.  On the machines I wrote the gantry component for, typically there
> >> is a small screw used to adjust the tripping point for each homing switch.
> >>
> >> As Andy mentioned, you may want to just use a version of LinuxCNC that
> >> supports JA.  When I wrote the gantry component that wasn't an option,
> >> and the behavior of LinuxCNC with any non-trivial kinematics (even
> >> something as simple as a gantry) was very painful from a user
> >> perspective (or at least from *THIS* user's perspective).  I haven't
> >> messed with JA, but it's supposedly *MUCH* better at handling these
> >> sorts of machines.
> >>
> >> -- 
> >> Charles Steinkuehler
> >> char...@steinkuehler.net
> >>
> >
> > --
> > ___
> > 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] What does "CNC" really mean?

[dannym]

Got into a bizarre argument... so of course it was initially "Computer Numeric 
Control".  I was noting people breaking it down to explain it to people as 
"which means it's 'computer numeric controlled'" but that seems to add nothing 
to the meaning.  In fact it's confusing.

It's computer-controlled, sure.  I say "computer controlled" for people who 
don't know the term "CNC".  But what is the "numeric" adding?  I presume that 
meant something in like the 80's, but it's not used anymore.  Computers use 
numbers... and bits... and memory... and code... and electricity.  It doesn't 
seem to convey anything now but implies there's some special number thing going 
on, which is why I always just say "CNC" or "computer controlled".

Thing is, people occasionally become confused how a laser cutter or 3D printer 
is NOT "computer numeric control", we never call those CNC.  Well, they ARE all 
computer-controlled, equally so, really.  And numbers are involved.  But the 
term "CNC" seems limited to mills, routers, and plasma.  A waterjet or wire 
EDM, I just hear those without the "CNC" in front, because there's no manual 
waterjets around.  There are handheld plasma cutters through.

It seems like expanding it to "computer NUMERIC control" implies that something 
entirely different in its core concept than laser cutters or 3D printers... or, 
like, a paper printer, and people ask what that is. 

I was arguing the best answer is "CNC just means CNC, and specifically cutters 
and plasma".  

Danny

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

Re: [Emc-users] Can't figure out homing on gantry

[dannym]

So, I have to switch to 2.8-pre for JA?

Danny

 Charles Steinkuehler  wrote: 
> On 8/25/2016 11:38 AM, dan...@austin.rr.com wrote:
> > 
> > So I guess it does do that.  Now if one home was physically
> > installed where it trips 0.53" before physical end-of-travel, if
> > this were NOT the gantry axis I'd just give its final machine coord
> > as 0.53" and its machine coord is correct (0=end-of-travel).  But
> > in this one, say one gantry switch is mounted to trip at 0.5" but
> > the other trips at 0.65".  If homing acts like non-gantry joints,
> > it would physically leave it at 0.5" and 0.65" and leave joint mode
> > with it physically out of sync like that.  Which would mean the
> > joints are racked by 0.15" and will forever be locked like that
> > because future moves are in axis mode, not joint mode.
> > 
> > Does it have the ability to physically move the joints into
> > alignment based on .ini parameters saying one switch is 0.15" off,
> > or do I just need to keep physically remounting one switch until
> > its trip point is "close enough" to the other?
> 
> No.  On the machines I wrote the gantry component for, typically there
> is a small screw used to adjust the tripping point for each homing switch.
> 
> As Andy mentioned, you may want to just use a version of LinuxCNC that
> supports JA.  When I wrote the gantry component that wasn't an option,
> and the behavior of LinuxCNC with any non-trivial kinematics (even
> something as simple as a gantry) was very painful from a user
> perspective (or at least from *THIS* user's perspective).  I haven't
> messed with JA, but it's supposedly *MUCH* better at handling these
> sorts of machines.
> 
> -- 
> Charles Steinkuehler
> char...@steinkuehler.net
> 


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

[Emc-users] Still trouble with XHC-HB04 mpg

[dannym]

I have this "working" in many ways.  The dial basically works, the HAL for the 
buttons work.  The Axis Select knob selects the axis.
But the .ini "options" don't work, specifically the filters, the Z-direction 
(decrement=up??), and the accel variables.  

I'm so confused, I see 5 key user elements to it and something clearly needs 
cleanup.  But while typing all this and taking notes, it seems to come down to 
my primary problem is the item #3 here, the ini section [XHC_HB04_CONFIG], 
doesn't seem to be recognized by the .tcl file lines such as:
if [info exists ::XHC_HB04_CONFIG(mpg_accels)] {
I don't know how to debug .tcl code.  But none of the [XHC_HB04_CONFIG] config 
seems to make it to the tcl.  The only reason I can make it work is when the 
.hal does this:
loadusr -W xhc-hb04 -H -I xhc-hb04-layout2.cfg -s 3
I can pass SOME key command-line params to the .tcl, the critical ones.  But I 
can't pass the others that I need to pass.


1.  An xhc-hb20.hal file I made, linked from my main .ini file.  That's got 
button tie-ins and all and everything I've done in there works for me and makes 
sense.  This file loads the tcl driver:
loadusr -W xhc-hb04 -H -I xhc-hb04-layout2.cfg -s 3
And there, the options being passed on the load line DO work.  If it were up to 
me, I'd forget the element #3 (described below) out of the ini file and set my 
options here, however, apparently only some options can be fed 
2.  Inside my .ini file, I have this section which the .tcl file instructed me 
to add:

[XHC_HB04_BUTTONS]
# use button names according to layout file LIB:xhc-hb04-layout{n}.cfg
# note: "start-pause" is connected for standard behavior
#controlling halui.pause/halui.resume/halui.run
# these are examples, edit as required:

goto-zero   = halui.mdi-command-00
# synthesized per-axis buttons for goto-zero button:
goto-zero-x = ""
goto-zero-y = ""
goto-zero-z = ""
goto-zero-a = ""

start-pause = std_start_pause
rewind  = halui.program.step

This section makes NO sense to me.  See, inside xhc-hb02.hal, I already have 
"net rewind  halui.mdi-command-04  xhc-hb04.button-rewind ", and my .ini has 
"MDI_COMMAND=M2"

Should I not have ANY of this section because I use a .hal, or what?  Are they 
doing both, does one override the other... I just left it be, up till this 
point.

Then there's:
3. Again in my main .ini file as instructed by the .tcl, this section which 
DOES NOT SEEM TO WORK.  Whether or not it's commented out, these params had no 
effect.
[XHC_HB04_CONFIG]
threadname = servo-thread 
#(optional, default: servo-thread)
layout = 2   
# (optional, 1: 16 buttons | 2: 18 buttons, default: 2)
coords = x y z 
#(optional, 4 max, default: xnum_joints y z a)
coefs  = 1 1 1 1 
# (optional, filter coefs 0 < coef < 1, default: 1 1 1 1)
#mpg_accels = 1 2 2 200   
mpg_accels = 1 2 100 
# (optional: reduced accelerations for all manual mode jogging)
  #(in machine_units/sec/sec like 
[AXIS_n]MAX_ACCELERATION)
   #   (this option requires: [APPLICATIONS]APP = 
xhc-hb04-accels)
scales = 1 1 1
#  (optional, plus/minus factors, default: 1 1 1 1)
require_pendant = no
#(optional, yes | no, default: yes)
inch_or_mm = in 
#  (optional, in | mm for display icon, default: mm)
jogmode= normal 
#  (optional, normal | vnormal | plus-minus, default: normal)
#sequence=2
#  (optional, 1 | 2 | 3 | 4 | 5, default: 1)
#   1: 0.001,0.010,0.100,1.000 (typ for mm machine)
#   2: 0.001,0.005,0.010,0.020 (typ for inch machine)
#   3: 0.001,0.010,0.100
#   4: 0.001,0.005,0.010,0.020,0.050,0.100
#   5: 0.001,0.010,0.050,0.100,1.000


4.  An .ini section: 
[APPLICATIONS]
APP = xhc-hb04-accels
APP = monitor-xhc-hb04

Which I copied in from elsewhere, and I believe that's in order.

Danny

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

Re: [Emc-users] Zeroing work coord via tool touch-off

[dannym]

So is there any way to signal from the .ngc back to the HAL?  I did resolve the 
issue with G38.2 Z-target being work coords not machine, and got a nice 
effective probing cycle going, just no deadmanning.

I am not "into" GUIs yet.  I have whatever stock LinuxCNC panel it came with.  
The Probe button does nothing special on the screen.  

Lemme see, is there a NEED for the .ngc to talk back?  Can HAL logic alone 
launch the .ngc and reliably implement this without anything back?

I'm wondering, if I made the MPG home-all button deadman, what would that rely 
on?  First thought it "if someone accidentally presses this while it's running 
their gcode, it'll see "mode.is-auto" and think it's homing even though it 
failed to start homing, and releasing will .abort their run".  I can, and 
should, do an .is-manual check before setting an isHoming net, but I'm not sure 
what all may be able to block a homing command (left in joint mode?).  Is there 
anything like a mode.is-homing indicator, something which definitively 
indicates the LinuxCNC mode?  Or a #parameter?  I couldn't find one.

How do I make a latch in HAL?  Is that just the flipflop logic component?

Danny

 andy pugh  wrote: 
> On 25 August 2016 at 18:29,   wrote:
> 
> > Can we have a combination of HAL and .ngc be set to this:
> > Logic #1:
> >  if (button & !isProbing), then set isProbing=TRUE, execute myProbe.ngc, 
> > and set isProbing=FALSE when it returns
> > and Logic #2:
> > if(!button & isProbing), then issue a STOP (same as pressing the STOP 
> > button), and isProbing=FALSE
> 
> That is basically what I was suggesting, but the "isProbing" input to
> HAL is a digital output from G-code.
> 
> Which GUI are you using? With Touchy there is a pin "touchy.abort"
> which is ideal for what you are wanting. I have also spotted
> "halui.abort" which should also work to stop the running .ngc program.
> 
> It should be possible to use a latch component, set by the button and
> cleared on completion of the probe routine (mode.is-auto goes to
> false?) or on halui.abort going true.
> 
> And yes, one button can drive both an MDI-command and a HAL input pin.
> But writing the isProbing pin from inside the .ngc stops the situation
> where the realtime code sees the button press but the userspace code
> (mdi_command) doesn't.
> 
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916


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

Re: [Emc-users] LinuxCNC officially rocks

[dannym]

No offense but Mach3 is pretty straightforward to set up, mostly.  The basic 
stuff.  

Installing Linux and LinuxCNC is not really turnkey tech, not even close.  Then 
once you go to a Mesa card, the stepconfig wizard isn't an option, and figuring 
out how to do it from scratch is FANTASTICALLY difficult.  You need to know a 
lot, although that knowledge comes in handy in a million ways later.

No offense but I've noted this.  Not only is there not a lot of clear, 
straightforward examples, even the experts have given me buggy code that won't 
work as-is until you learn how it works anyways and figure out why it's not 
doing it.  Not complaining, it's free help, but that's the situation.

Danny

 John Alexander Stewart  wrote: 
> Agree that LinuxCNC is fantastic.
> 
> What gets me is the number of Mach3 users - why don't they switch? Is it
> that they are (essentially) computer illiterate, and know only Windows
> (barely), or is it just momentum in the home hobbyist field??
> 
> (I'm lucky in that I was "into" wire-wrapping computers as a teenager (RCA
> 1802, Intel 8085...) but I do understand that many of my age group have a
> different relationship with computers, so when I ask the first question,
> above, it's not meant as a slight against them - it's just - how do we get
> more people to use and improve 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] LinuxCNC officially rocks

[dannym]

I started in Mach3, thought LinuxCNC was a bit beta (was like 2005).  Invested 
a tremendous amount of time in it.

Since then I've initially been excited for Mach3 Smoothstepper motion 
controllers, then disillusioned when I found how irreparably buggy it was with 
Mach3, and found the XHC mpg was similarly disappointing on Mach3.  Mach4 was 
vaporware which appeared like it was gonna be wholly disappointing.  

Since then Linux when to a realtime kernel, a LinuxCNC RTK was created, and the 
Mesa 7i92 cards came out, and Mach3 became a joke by comparison.  

As much frustration as I have getting LinuxCNC to do what I need, I still 
absolutely love it.

Danny

 Jon Elson  wrote: 
> On 08/27/2016 04:42 PM, Andrew wrote:
> > Interesting data
> > http://blog.cnccookbook.com/2016/08/26/outstanding-satisfaction-loved-cnc-controls-2016/
> >
> >
> Oh, they have the share data if you click the link for the 
> whole survey.  VERY impressive numbers for LinuxCNC!
> 
> 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] G38.2 probing in machine coord system?

[dannym]

Yeah like I say, to zero out the Zwork coords at present location would be 
confusing, and doesn't actually resolve much.

I'm not familiar with the internally defined parameters.  So #[5203 + [10 * 
#5220] is how you get the work offset of the current coord system?  Wacky... 
there's no "offset of present coord system"?  That's a strangely convoluted way 
to access the single most straightforward parameter there is, used by almost 
all moves.

Danny


 andy pugh  wrote: 
> On 26 August 2016 at 05:27,   wrote:

> I tried to prefix the G38.2 with G53 (machine coord operation), but I get an 
> error that G53 only works on G0/G1.
> Am I looking at the problem right?  How can I make this "probe to a fixed 
> machine coord point"?

That's annoying :-) (and G53 was going to be my first suggestion).

One way that comes to mind (and it is very likely that someone else
has a better idea) would be to zero out the Z offset, do the probe,
then put it back.

; Get the current Z offset,  it's lucky that #params can be computed
#1 = #[5203 + [10 * #5220]
G10 L2 P0 Z0
G38.2 F10 Z-200
G38.3 F10 Z0
G10 L2 P0 Z#1

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

Re: [Emc-users] G38.2 probing in machine coord system?

[dannym]

Yeah the probe input definitely works.  I did get the G38.2 probe to work in 
some controlled circumstances.

Say that machine Zhome=0 is 7" above the bed, and ZMin= -7.0".  In most cases 
this probe will be near the Z min (thin materials).  Z min is not set absurdly 
low (or no limit) to at least guarantee people don't rub the NUT against the 
bed.  The nut stops like 1/2" above the bed.  

The G38.2 is in work coords.  The Z-target must be given, but that's in work 
coords, and it will fail to enter the .ngc call if the Z-target is outside 
machine limits.

So, if you have no work offset, Zmachine and Zwork are the same, and G38.2 
Z-6.5 works.  

But if the user already zeroed on one material, there might be a -5" work 
offset.  Zwork=0 is Zmachine=-5.  It won't matter where your z-axis currently 
is located, the G38.2 Z-6.5 becomes a command to move to machine coord Z= -11.5 
which, as the error says, exceeds joint 2's negative limit.

Someone's example I found online that I was copying started by declaring the 
current Z to be work Z=0.  That's undesirable because if you abort or fail the 
probe cycle, your prior Z offset is still gone.  In any case it won't actually 
do much to fix the z-limit problem.  If you're at Zmachine = -5 and make that 
Zwork =0, your routine can only probe to z=-2 max in that case, but there's no 
way to know what that distance is when coding the .ngc.  It could be -1" or -7".

I guess that does mean that if you have one probe cycle fail to make contact 
with a -1" drop, you would just repeat until it does because the new cycle will 
reset Zwork=0 and G38.2 Z-1 down again.  But that's a bit confusing.  

Danny


 Gene Heskett  wrote: 
> On Friday 26 August 2016 00:27:00 dan...@austin.rr.com wrote:
> 
> > I'm trying the G38.2 z-probe in an ngc call.  I keep getting an error
> > "Probe move on line 6 would exceed joint 2's negative limit".
> >
> > Problem seems to be that G38.2 uses the current coord system.  I've
> > got the Z-home working now, and machine coords knows the furthest it
> > can go, whereas the active coord system Z-value is meaningless for a
> > max probe target.
> >
> > I tried to prefix the G38.2 with G53 (machine coord operation), but I
> > get an error that G53 only works on G0/G1.
> >
> > Am I looking at the problem right?  How can I make this "probe to a
> > fixed machine coord point"?
> >
> > Danny
> >
> Generally, give it a probe distance that would not exceed that limit.  It 
> moves in the current co-ordinate system.  So if your limit is set 1mm 
> above the table, the z-value you give it, shouldn't be lower than 
> 1.001mm at the end of the probe move from where its at at the start.  If 
> the probe contact is not made by then, you get a different error.
> 
> I assume you have verified with a halmeter, watching motion.probe-input, 
> that the probe circuit is working?
> > --
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> 
> Cheers, Gene Heskett
> -- 
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
> 
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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

[Emc-users] G38.2 probing in machine coord system?

[dannym]

I'm trying the G38.2 z-probe in an ngc call.  I keep getting an error "Probe 
move on line 6 would exceed joint 2's negative limit".

Problem seems to be that G38.2 uses the current coord system.  I've got the 
Z-home working now, and machine coords knows the furthest it can go, whereas 
the active coord system Z-value is meaningless for a max probe target.

I tried to prefix the G38.2 with G53 (machine coord operation), but I get an 
error that G53 only works on G0/G1.

Am I looking at the problem right?  How can I make this "probe to a fixed 
machine coord point"?

Danny

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

Re: [Emc-users] Can't figure out homing on gantry

[dannym]

I floundered around with other components while trying to set this up, and was 
told "WTH are you doing just use 'gantry'".  So I went with gantry component, 
and it's worked ok.  But if I need something else, I'm open to it.

I have the RT version of LinuxCNC.  Will that update with this JA stuff but 
remain the RT version?  Or does it already have it?  (that machine's at the 
shop across town, otherwise I'd give the version # and probably just try the 
joint-axes features to see if they exist).

Is there any sort of backup process recommended in case the upgrade breaks 
something, somehow?  

Full disclose, I'm not much of a Linux person (big surprise).  I'm used to 
downloading a file and "run as administrator" in Windows.  Not refusing to 
learn or anything, just fessing the situation.

Danny

 andy pugh  wrote: 
> On 25 August 2016 at 05:25,   wrote:
> I have a gantry router with 2x X motors.  I'm using the "gantry" component.

Have you considered using the Master branch? Gantries are a lot simpler there:
http://linuxcnc.org/docs/devel/html/getting-started/updating-linuxcnc.html#_updating_configuration_files
You don't need the "gantry" component with that LinuxCNC version.

> X2 axis is 3.  axis.3.home-sw-in axis.3.neg-lim-sw-in do not exist to connect 
> to, neither one.

What is the "num_joints" of your "loadrt motmod" line?

> What's the homing situation like on this?

I believe that the home switches connect to the "gantry" component
rather than to the axis.N.home switches.
There is a sample config here:
https://github.com/cdsteinkuehler/linuxcnc/blob/0e0418b362f45d7ad332fa3f211cbf8c2f24efd9/configs/ARM/BeagleBone/Probotix/Comet.hal#L101


-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

Re: [Emc-users] Can't figure out homing on gantry

[dannym]

OK, well the gantry man page says:

"All controlled joints track the commanded position (with a per-joint offset) 
unless in the process of homing. Homing is when the commanded position is 
moving towards the homing switches (as determined by the sign of search-vel) 
and the joint home switches are not all in the same state. When the system is 
homing and a joint home switch activates, the command value sent to that joint 
is "frozen" and the joint offset value is updated instead. Once all home 
switches are active, there are no more adjustments made to the offset values 
and all joints run in lock-step once more."

So I guess it does do that.  Now if one home was physically installed where it 
trips 0.53" before physical end-of-travel, if this were NOT the gantry axis I'd 
just give its final machine coord as 0.53" and its machine coord is correct 
(0=end-of-travel).  But in this one, say one gantry switch is mounted to trip 
at 0.5" but the other trips at 0.65".  If homing acts like non-gantry joints, 
it would physically leave it at 0.5" and 0.65" and leave joint mode with it 
physically out of sync like that.  Which would mean the joints are racked by 
0.15" and will forever be locked like that because future moves are in axis 
mode, not joint mode.  

Does it have the ability to physically move the joints into alignment based on 
.ini parameters saying one switch is 0.15" off, or do I just need to keep 
physically remounting one switch until its trip point is "close enough" to the 
other?

Danny


 dan...@austin.rr.com wrote: 
> What's that mean?  Does it just drive both in tandem until both switches are 
> TRUE, then call it homed?  That wouldn't work, I need independent homing for 
> sure.
> 
> Not sure what the Probotix code is saying but I'll try it out later:
> 
> # join the home switch signals so that both switches have to be closed to 
> trigger a home position
> net switches-y1   => gantry.0.joint.00.home
> net switches-y2 => gantry.0.joint.01.home
> 
> 
> 
> Danny
> 
>  Charles Steinkuehler  wrote: 
> > On 8/24/2016 11:25 PM, dan...@austin.rr.com wrote:
> > > I have a gantry router with 2x X motors.  I'm using the "gantry"
> > > component.
> > > 
> > > Installing homing switches.  Got the Y working right off the bat.
> > > I can see the X1 and X2 switches trigger in HAL Scope so I'm good
> > > to go. This is a wide gantry which can rack somewhat so independent
> > > homing is essential.
> > > 
> > > axis.0.home-sw-in axis.0.neg-lim-sw-in hooked up fine for the X1
> > > side.
> > > 
> > > X2 axis is 3.  axis.3.home-sw-in axis.3.neg-lim-sw-in do not exist
> > > to connect to, neither one.
> > 
> > If you are using the gantry HAL component (and not gantrykins), the
> > motion planner runs as a standard Cartesian machine.  You wire the two
> > homing switches to the gantry component (gantry.N.joint.MM.home),
> > which merges them and generates a single home switch output
> > (gantry.N.home) that you connect to the motion planner.
> > 
> > http://linuxcnc.org/docs/html/man/man9/gantry.9.html
> > 
> > -- 
> > Charles Steinkuehler
> > char...@steinkuehler.net
> > 
> 
> 
> --
> ___
> 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] Zeroing work coord via tool touch-off

[dannym]

Manual toolchanging here.

I have a wireless tool setter already wired in, and an XHC-HB04 wireless 
pendant.  I'd like to press the "Probe-Z" button and have it zero the work 
coords on the touch.

But, just to complicate things, I'd really like to have this deadman, so you 
must hold down the Probe-Z button or it will abort the process immediately and 
fail to set the Z-home.  

There are others using the machine and it's quite easy to forget to put the 
tool probe down or fail to align the tool directly over the probe properly.  
This is the sort of thing people readily say "oh crap!" and promptly forget to 
go looking for the Stop button.  It's a large router and the physical e-stop 
may be some distance away, and if you used that it's gonna unhome the whole 
machine coord system.  I could also reasonably expect some to "fix" it by just 
pausing which actually leaves its move pending.  So there's a big advantage to 
deadmanning that button.

I have coded up other XHC buttons in the HAL to do simple things (home 
button=G0 X0 Y0).  I do see Probe solutions that call a g-code .ngc file but 
that can't deadman AFAIK.  

Is there a reasonably practical way to do this?

Danny

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

Re: [Emc-users] Can't figure out homing on gantry

[dannym]

What's that mean?  Does it just drive both in tandem until both switches are 
TRUE, then call it homed?  That wouldn't work, I need independent homing for 
sure.

Not sure what the Probotix code is saying but I'll try it out later:

# join the home switch signals so that both switches have to be closed to 
trigger a home position
net switches-y1 => gantry.0.joint.00.home
net switches-y2 => gantry.0.joint.01.home



Danny

 Charles Steinkuehler  wrote: 
> On 8/24/2016 11:25 PM, dan...@austin.rr.com wrote:
> > I have a gantry router with 2x X motors.  I'm using the "gantry"
> > component.
> > 
> > Installing homing switches.  Got the Y working right off the bat.
> > I can see the X1 and X2 switches trigger in HAL Scope so I'm good
> > to go. This is a wide gantry which can rack somewhat so independent
> > homing is essential.
> > 
> > axis.0.home-sw-in axis.0.neg-lim-sw-in hooked up fine for the X1
> > side.
> > 
> > X2 axis is 3.  axis.3.home-sw-in axis.3.neg-lim-sw-in do not exist
> > to connect to, neither one.
> 
> If you are using the gantry HAL component (and not gantrykins), the
> motion planner runs as a standard Cartesian machine.  You wire the two
> homing switches to the gantry component (gantry.N.joint.MM.home),
> which merges them and generates a single home switch output
> (gantry.N.home) that you connect to the motion planner.
> 
> http://linuxcnc.org/docs/html/man/man9/gantry.9.html
> 
> -- 
> Charles Steinkuehler
> char...@steinkuehler.net
> 


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

[Emc-users] Can't figure out homing on gantry

[dannym]

I have a gantry router with 2x X motors.  I'm using the "gantry" component.  

Installing homing switches.  Got the Y working right off the bat.  I can see 
the X1 and X2 switches trigger in HAL Scope so I'm good to go. This is a wide 
gantry which can rack somewhat so independent homing is essential.

axis.0.home-sw-in axis.0.neg-lim-sw-in hooked up fine for the X1 side.

X2 axis is 3.  axis.3.home-sw-in axis.3.neg-lim-sw-in do not exist to connect 
to, neither one.  

What's the homing situation like on this?  

Danny

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

Re: [Emc-users] Leadscrew Efficiency?

[dannym]

A 10 TPI would require half the torque, but double the speed.

I would expect a servo to have a reduction gear.  If it had an exceptionally 
high reduction, it may not be able to produce sufficient torque at the higher 
RPM needed.  But that doesn't sound like the case.

Danny

 John Kasunich  wrote: 
> Are they LEADscrews or BALLscrews?
> 
> With ballscrews, the finer pitch screw should indeed provide a much better 
> mechanical advantage.
> 
> With leadscrews, the mechanical advantage almost doesn't matter, because 
> friction is by far the dominant force.  Somewhere between 60% and 95% of the 
> torque required to turn a leadscrew under load is due to the friction between 
> the screw and nut rather than the force actually needed to raise the load.
> 
> I'm not sure why the 10tpi screw would actually be worse - I would expect it 
> to be roughly the same.   However, many factors come into play:
> 
> 1) materials:  are both screws steel?  both nuts bronze? (pr plastic, or 
> whatever)  The materials and lubrication can make a huge difference in the 
> amount of friction.
> 
> 2) surface quality:  a rough screw or nut will have more friction than a 
> polished one
> 
> 3) thread form:  60 degree threads have a lot more friction than Acme due to 
> the wedging action of the 60 degree flanks.  Square threads are best because 
> the flanks are perpendicular to the load, but Acme is almost as good.
> 
> 4) diameter:  if all of the above are equal, the friction FORCE will be the 
> same.  But the TORQUE required depends on the radius of the screw, so a 
> larger diameter screw will require more torque.
> 
> 
> 
> On Thu, Aug 18, 2016, at 10:14 AM, Todd  Zuercher wrote:
> > I have a machine that I converted from step-motors to servos, and I'm 
> > having a little trouble with the Z axis. It has an anti backlash lead screw 
> > with a 5tpi screw. This sort of worked, but the servo was working hard to 
> > move the head, and I wanted a little higher encoder resolution for better 
> > tuning. So I swapped in a nearly identical 10tpi lead screw set I happened 
> > to have on hand (removed from another stepper machine to get better speed 
> > and perfomance). I thought that the 10tpi screw should be easier for the 
> > servo to turn, but I'm finding that the opposite is true and the servo 
> > can't raise the motor without counter balance assistance when it could with 
> > the 5tpi. Does that make sense, or is the problem more likely that the 
> > 10tpi screw and nut are worn out and binding? 
> > 
> > -- 
> > 
> >  
> > 
> > Todd Zuercher 
> > mailto:zuerc...@embarqmail.com 
> > 
> >  
> > --
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> 
> -- 
>   John Kasunich
>   jmkasun...@fastmail.fm
> 
> --
> ___
> 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] Nother Q about these Chinese inverters

[dannym]

A lot of people use them.  They just about throw 'em in for free with a spindle 
on eBay.

I would MUCH rather spend $300 on a high-performance, high-quality, 
well-specified Hitachi VFD.  I need to be able to trust my components.

Look up Hitachi WJ200.  WJ200 is a product LINE though, there are different KW 
and power input types within that so don't just order "a WJ200".  The suffixes 
are critical.

Danny


 Dave Cole  wrote: 
> Just a question to clarify:
> 
> Are the Huanyang inverters known to be quality inverters ??
> Do some of you have those inverters with thousands of hours on them?
> 
> Thanks,  Dave
> 
> On 7/26/2016 2:36 AM, Bruce Layne wrote:
> > Russtuff just uploaded a quick video showing how to program a Huanyang
> > VFD that might be helpful.
> >
> > https://www.youtube.com/watch?v=7OszQS_BQMk
> >
> > He's programming it for RS485 control, which would be nice now that
> > Huanyang VFD support is in LinuxCNC 2.7 and above.  I think many of the
> > Huanyang inverters do not support the com port and it's difficult to
> > tell which do from a visual inspection.  The eBay specs are usually
> > cut-and-paste and are often incorrect.  I've read that even if the
> > Huanyang VFD has the proper chipset to support the com port, it may not
> > have the hardware as a cost saving "feature".  I have a few of these
> > VFDs.  I should connect them to a motor one at a time and see if any of
> > them support RS485, and use that for future CNC projects instead of
> > relays and 0-10V analog control if possible.
> >
> > However, even if you aren't interested in RS485, you might be interested
> > in the part of the video that deals with the parameters for ramp up
> > time, ramp down time, motor current, etc.
> >
> >
> >
> > On 07/25/2016 02:56 AM, Gene Heskett wrote:
>  Greetings to you who are running an inverter driven spindle; I have
>  one of those 1 HP 230 volt 3 phase motors on the table, in this case
>  the one with the noisy bearings but it still rolls dead free. With
>  the inverter set to 90 hertz and its running, pushing the green
>  run/stop to stop it gets a rapid drop to around 75 hz, then its
>  turned loose to coast for quite a spell, 10 secs maybe, at the end
>  of which the DC comes on and its dead in its tracks in less than 1
>  more rev.
> >
> > --
> > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> > patterns at an interface-level. Reveals which users, apps, and protocols are
> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity 
> > planning
> > reports.http://sdm.link/zohodev2dev
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2dev
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Using 7i76 I/O as serial Rx/Tx?

[dannym]

On my X200 VFD I ran into problems with common-mode noise.  RS485's 
differential mode is highly effective at rejecting differential noise UNLESS 
you exceed the differential range of either transceiver's RX side, then it 
stops working, and there was a lot.  So I got an optoisolating RS232-RS485 
converter.

I'm not too happy with having a second cable for the VFD, my computer is 
located away from the control box with all that and I'd rather have one cable.  
That's a minor issue of coarse.  I was fortunate in that I have a PC with a 
true RS232 DB9 on it that can be screwed in.  The USB-serial link would be more 
of a deal-breaker because it doesn't physically lock.

Danny


 andy pugh  wrote: 
> On 8 July 2016 at 07:53, Danny Miller  wrote:
> There's a "UART" listed on the 7i92's features.  Actually since I have a
> hardware RS232/RS485 bridge I could still use that, if the config for it
> has been made.  But I don't know if it has.

It is possible to use the hm2 UART module, and I have done. But it
isn't easy. You currently need to write your own custom HAL component
to encode and decode the byte meanings.

To use hy_vfd it is _far_ easier to just buy a $2 USB-RS485 dongle and use that.
Something like this: http://www.ebay.com/itm/112047282456
Though you may find one closer and faster with searching.

It is possible to desolder the USB plug and fit a motherboard header
so that you can mount it internally, if you want.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

Re: [Emc-users] Spindle control panel breaks LinuxCNC?

[dannym]

Well the VFD does have a minimum speed. It won't run below that because of min 
speed and overheating.  

I did see a freq of 300 (18k rpm) on the HAL while the VFD locked up. 

Also MDI'ed S18000 in while the VFD was locked up.

Looks like the watchdog_out to the VFD is a problem here.

Danny


 Chris Morley  wrote: 
> 
> Iirc Pressing axis spindle buttons sets the rpm to 1 rpm. Maybe this is the 
> problem. Some how that errors the vfd. Depending on what version of lunuxcnc 
> there is an INI switch to change that default rpm.You should be able to test 
> this by setting the rpm to 1 in the MDI window.
> Worth a try.
> 
> Chris M
> 
> - Reply message -
> From: "dan...@austin.rr.com" 
> To: "Enhanced Machine Controller (EMC)" 
> Subject: [Emc-users] Spindle control panel breaks LinuxCNC?
> Date: Wed, Jun 29, 2016 9:12 AM
> 
> 
> 
> It's every single time.  If I use M3, spindle runs 100% reliably.  Or, if I 
> use my XHC wireless mpg, that runs it fine too.
> 
> But on the Manual Control tab, there's a Spindle button with a CW button 
> flanking it on the right and a CCW button on the left and +/- buttons 
> underneath.  Hovering over the CW says "Spindle CW (F9)".  Clicking on that 
> results in no effect from the spindle, and the VFD will not respond to M3, 
> nothing can make it run.  It won't run g-code because spindle-at-speed will 
> never become true and that's required to be true for G1 moves.  That will 
> persist until the VFD power is cycled.  Rebooting LinuxCNC alone will have no 
> effect and it's not necessary to reboot LinuxCNC along with cycling VFD power.
> 
> This is weird.  The VFD is controlled by a complied .c, which has a limited 
> range of communication with the VFD, using a few regs.  LinuxCNC has to have 
> sent something that breaks the VFD communication but I'm not sure what it 
> could even send that would cause that failure that stores IN the VFD's states 
> rather than a state of LinuxCNC's code.  It has to be on the VFD's registers 
> because cycling VFD power is essential to recover, while restarting LinuxCNC 
> is irrelevant to recovery.
> 
> Danny
>  Gene Heskett  wrote:
> > On Wednesday 29 June 2016 01:42:47 Danny Miller wrote:
> >
> > > Well, I recreated it and confirmed cycling VFD power without rebooting
> > > LinuxCNC makes the spindle run again.
> > >
> > > I looked into the HAL after the "Spindle CW" button breaks everything:
> > > enable TRUE
> > > is_alarm FALSE
> > > is_at_speed FALSE
> > > is_ready TRUE
> > > is_running TRUE
> > > reverse FALSE
> > > run TRUE
> > > watchdog_out TRUE
> > >
> > > compared with actually having it running with M3:
> > > is_at_speed becomes TRUE (duh)
> > > watchdog_out is FALSE
> > >
> > > Well, that's odd.  IIRC the watchdog is not getting data back from the
> > > VFD in a timely fashion.  It is somehow locked up so that does seem
> > > consistent with the situation.  But no idea how it's getting locked
> > > up. The x200 VFD code sends a speed, dir, and run command and reads
> > > back the coils.
> > >
> > How often?  This is sounding as it it has some sort of an internal
> > watchdog that is not getting "petted".  This function is normally done
> > by an addf in your .hal file as one of the last addf's, often next in
> > line after the addf that updates the outputs each servo cycle.  That way
> > the watchdog gets petted even if the rest of the system is sitting idle
> > waiting for its slow human to tell it what to do next. :)
> >
> > For an older 5I25 card install, it looked like this in the .hal file:
> > addf   hm2_5i25.0.pet_watchdog   servo-thread# else he bites!
> >
> > Do a "sudo dmesg -c" which will clear dmesgs cache, then start lcnc and
> > stop it. send the next "sudo dmesg >filename 2>&1" and post it here as
> > an insert of that filename.  I also find that printing a copy for future
> > reference is also quite handy as you go about configuring a working
> > system.
> >
> > Point is, that if the setup has a watchdog, it should show up in that
> > dmesg listing, the whole thing is perhaps 60 lines in one of my machines
> > that uses a 5I25 card.  And its now part of the of the output write
> > function now done internal to the card when and output is written by the
> > driver. So it does not show up in my dmesg listing, and that line quoted
> > above now has a #in front of the addf.
> >
> > Check the docs you have on this x200 vfd for any mention of a watchdog.
> > That should define how to "pet" it to keep it from barking.
> >
> > OTOH, I do't have an x200 VFD, and its possible that it does not report
> > its presence when the program is run. In which case see the docs for the
> > x200.
> > >
> > > Danny
> > >
> > > On 6/16/2016 11:04 AM, dan...@austin.rr.com wrote:
> > > > It's modbus, sorry forgot to mention that.
> > > >
> > > > What baffles me is the Spindle buttons on the panel, AFAIK, 

Re: [Emc-users] Spindle control panel breaks LinuxCNC?

[dannym]

Entirely through Modbus, which otherwise works.  I started from the wj200_vfd.c 
code and made some changes to make an x200_vfd.c file.  Just changing a few 
coils.

Modbus starts from the OB RS232 serial port and goes through an isolationg 
RS232-RS485 converter.  Like I say, setup's been good, but this button breaks 
things.

Danny


 John Kasunich  wrote: 
> How is LinuxCNC connected to the VFD?
> 
> Direct hardware control, with an analog speed command and start/stop signals 
> from a parallel port?
> 
> Or serial communications using a HAL driver specific to that brand of VFD?
> 
> Or Modbus using the generic LinuxCNC HAL Modbus driver?
> 
> Or Ethernet using ??? driver?
> 
> That is critical information - I don't recall seeing it anywhere in this 
> email chain, but maybe I missed something in the first message or two.
> 
> The core of LinuxCNC (GUI and motion controller) doesn't communicate with
> the VFD at all.  LinuxCNC reads and writes to HAL pins, and those pins are
> connected to some driver that in turn talks to the drive.
> 
> So there are two things happening here:
> 
> 1) The core of LinuxCNC manipulates the HAL pins differently when you
> use M3 or the MPG compared to when you use the on-screen buttons.
> 
> 2) The driver and/or the VFD itself responds badly to the HAL pin activity
> from the on-screen buttons.
> 
> I think the first step is to figure out item 1.  Set up halscope to observe
> all the spindle-related HAL pins.  Capture and save shots of it working
> correctly when driven by M3 or the MPG.  Then capture it failing when
> driven by the on-screen button.  Study the screen pictures and figure
> out what is different.  Maybe the difference makes sense given the
> context, maybe it is a bug in the core of LinuxCNC.  Post your findings.
> 
> If the difference makes sense, then the problem is in the driver or the
> VFD.  If we know exactly what driver you are using and how it is 
> connected to the drive, and we know exactly what the HAL pins going
> into the driver are doing, maybe we can figure out what is wrong.
> 
> -- 
>   John Kasunich
>   jmkasun...@fastmail.fm
> 
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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

Re: [Emc-users] Spindle control panel breaks LinuxCNC?

[dannym]

It's every single time.  If I use M3, spindle runs 100% reliably.  Or, if I use 
my XHC wireless mpg, that runs it fine too.

But on the Manual Control tab, there's a Spindle button with a CW button 
flanking it on the right and a CCW button on the left and +/- buttons 
underneath.  Hovering over the CW says "Spindle CW (F9)".  Clicking on that 
results in no effect from the spindle, and the VFD will not respond to M3, 
nothing can make it run.  It won't run g-code because spindle-at-speed will 
never become true and that's required to be true for G1 moves.  That will 
persist until the VFD power is cycled.  Rebooting LinuxCNC alone will have no 
effect and it's not necessary to reboot LinuxCNC along with cycling VFD power.

This is weird.  The VFD is controlled by a complied .c, which has a limited 
range of communication with the VFD, using a few regs.  LinuxCNC has to have 
sent something that breaks the VFD communication but I'm not sure what it could 
even send that would cause that failure that stores IN the VFD's states rather 
than a state of LinuxCNC's code.  It has to be on the VFD's registers because 
cycling VFD power is essential to recover, while restarting LinuxCNC is 
irrelevant to recovery.

Danny
 Gene Heskett  wrote: 
> On Wednesday 29 June 2016 01:42:47 Danny Miller wrote:
> 
> > Well, I recreated it and confirmed cycling VFD power without rebooting
> > LinuxCNC makes the spindle run again.
> >
> > I looked into the HAL after the "Spindle CW" button breaks everything:
> > enable TRUE
> > is_alarm FALSE
> > is_at_speed FALSE
> > is_ready TRUE
> > is_running TRUE
> > reverse FALSE
> > run TRUE
> > watchdog_out TRUE
> >
> > compared with actually having it running with M3:
> > is_at_speed becomes TRUE (duh)
> > watchdog_out is FALSE
> >
> > Well, that's odd.  IIRC the watchdog is not getting data back from the
> > VFD in a timely fashion.  It is somehow locked up so that does seem
> > consistent with the situation.  But no idea how it's getting locked
> > up. The x200 VFD code sends a speed, dir, and run command and reads
> > back the coils.
> >
> How often?  This is sounding as it it has some sort of an internal 
> watchdog that is not getting "petted".  This function is normally done 
> by an addf in your .hal file as one of the last addf's, often next in 
> line after the addf that updates the outputs each servo cycle.  That way 
> the watchdog gets petted even if the rest of the system is sitting idle 
> waiting for its slow human to tell it what to do next. :)
> 
> For an older 5I25 card install, it looked like this in the .hal file:
> addf   hm2_5i25.0.pet_watchdog   servo-thread# else he bites!
> 
> Do a "sudo dmesg -c" which will clear dmesgs cache, then start lcnc and 
> stop it. send the next "sudo dmesg >filename 2>&1" and post it here as 
> an insert of that filename.  I also find that printing a copy for future 
> reference is also quite handy as you go about configuring a working 
> system.
> 
> Point is, that if the setup has a watchdog, it should show up in that 
> dmesg listing, the whole thing is perhaps 60 lines in one of my machines 
> that uses a 5I25 card.  And its now part of the of the output write 
> function now done internal to the card when and output is written by the 
> driver. So it does not show up in my dmesg listing, and that line quoted 
> above now has a #in front of the addf.
> 
> Check the docs you have on this x200 vfd for any mention of a watchdog.  
> That should define how to "pet" it to keep it from barking.
> 
> OTOH, I do't have an x200 VFD, and its possible that it does not report 
> its presence when the program is run. In which case see the docs for the 
> x200.
> >
> > Danny
> >
> > On 6/16/2016 11:04 AM, dan...@austin.rr.com wrote:
> > > It's modbus, sorry forgot to mention that.
> > >
> > > What baffles me is the Spindle buttons on the panel, AFAIK, just map
> > > to the same spindle-run in the HAL that M3 goes to.  I remember
> > > looking at the HAL monitor on this weeks ago and IIRC it was
> > > "spindle run true, but spindle-isrunning false".  The spindle isn't
> > > moving at all.  I'll recheck the HAL and take proper notes.
> > >
> > > And like I say, the VFD won't run again even if you reboot LinuxCNC.
> > >  It will run if I cycle power on the VFD.  So, it's like it sent a
> > > toxic command to the VFD that changed a reg to something unusable. 
> > > I did make that x200_vfd.c from the WJ200_vfd.c VFD code, but it
> > > wasn't a major change, and it's simple, there's a run command,
> > > cw/ccw command (I made it so CCW just turns into CW), rpm command,
> > > and reads is-running-at-speed and an error bit.
> > >
> > > It don't see where it could deliver something to de-configure the
> > > VFD, nor why the Spindle panel buttons would do something different
> > > through the HAL than you'd get by MDI M3.
> > >
> > > Danny
> > >
> > >  andy pugh  wrote:
> > >> On 16 June 2016 at 

Re: [Emc-users] Moving axis while paused

[dannym]

I've worked with a number of CNC router users on a bunch of jobs.  I had to 
change my beliefs along the way, based on experience.

Tabs are often a huge liability.  They are a lot of work to cut, leave a finish 
problem where they were cut off, and sometimes tear out the work when you move 
the sheet off the router.  Wood is often warped and the tabs may not render at 
all anyhow.  With some bits and materials, you just don't need tabs, the cut 
piece stays in place.  

Many skilled users don't do them.  Popped pieces can sometimes happen, but they 
can happen WITH tabs too if the sheet lifts and breaks them.  So there's no 
"tabs are the only proper way" rule to it.  There will always be a need to 
pause the machine, fix something which involves a move, and resume.

I'll work on this "moveoff" component then.  

Danny

 andy pugh  wrote: 
> On 27 June 2016 at 15:28, Chris Kelley  wrote:
> I would say that the "proper answer" is to teach the users to properly use
> holding-tabs, hold-downs, etc

That reminds me, I used holding tabs a lot in CamBam, but haven't even
found them in Fusion360 or Inventor HSM. I wonder if they are there to
be found?

However, to say that it is possible to never need to stop a job
part-way through to fix something is, I think, going a bit far. As I
recall the moveoff component was written after a request from a
commercial roll-machining company who wanted to be able to change
chipped or worn tips mid-job.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

Re: [Emc-users] Major lags when zeroing axes

[dannym]

Yeah I don't expect any immediate solution, but this is a significant problem 
which doesn't need to be.  If you've done an X-offset by +2", then the limits 
check and live preview just needs to offset by +2".  They don't need to 
recalculate every line of g-code.

Unless, of course, you use a G10 P0 R1, which rotates the coordinate system.  
For that, you'd have to recalc all the g-code because that geometry is specific 
to the file.

I figured the preview/limits would exist in machine coordinates.  If we're 
calculating to make sure the g-code doesn't exceed machine travel, then work 
coordinates don't make sense.  In that case the work offset gets applied for 
preview & work size display and there's no reason to recalc the machine 
coordinates.  Now if you rehomed the machine coords, I can see why you might 
just recalc the g-code instead of writing special-case code to "fix" the prior 
calc of g-code.  For the most part people would have the machine coords homed 
before loading a g-code design, and only alter work offsets after that, so 
that's a pretty special case to accommodate a change in machine coords on the 
fly.



Danny


 andy pugh  wrote: 
> On 27 June 2016 at 09:16, Danny Miller  wrote:
> When I go to zero the work coordinates, EACH axis results in
> recalculating the entire file, which can take minutes.

The delay is actually probably the toolpath preview (and limits check)
updating. The motion system doesn't need to read the whole file before
starting.

Unfortunately the system still needs to do a point-by-point limits
check with the new starting position.

You can turn off the preview and limits check, but that's not much of
a solution.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

Re: [Emc-users] G0 vs G1-specific functions?

[dannym]

Can the acceleration be changed dynamically through HAL and still work properly?

Because say the traj planner looks 10 moves ahead, and it's 2x G1 followed by 
3x G0 moves then 5x G1.  It forms a plan based on the acceleration rules.  But 
when it hits the 3rd command, the HAL suddenly changes the acceleration rule, 
invalidating the existing plan.  

If the traj planner sticks with the preexisting traj plan and only uses the 
current HAL accel limits to replan the new moves after the current plan is 
executed, that won't work.  There would be G0 moves which have excess accel 
that could stall the motors.

Danny


 Sebastian Kuzminsky  wrote: 
> On 06/27/2016 09:09 AM, dan...@austin.rr.com wrote:
> > Is there any HAL component that can tell if it's running as G0 or G1?
> 
> The pin motion.motion-type, described here:
> 
> http://linuxcnc.org/docs/html/man/man9/motion.9.html
> 
> "traverse" (1) is a G0, "linear feed" (2) is a G1, and "arc feed" (3) is 
> G2/G3.
> 
> 
> -- 
> Sebastian Kuzminsky
> 
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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

Re: [Emc-users] G0 vs G1-specific functions?

[dannym]

Hmm, interesting, but that's only to reduce accel in manual mode, right?

It'd reduce shaking while using the mpg, but the G0 moves in the g-code would 
create motor stalls if used at full speed.  I'm wondering if all G0 and manual 
input could  be a mode of higher speed but more limited in acceleration.

I know a lot of people have noted that the standard trapezoidal accel profile 
doesn't follow the physical properties of the motor (less torque at higher 
speed=more at lower), but nontrapezoidal profiles with variable acceleration 
are exceedingly complicated to build into motion control.  But it seems that 
just separating out G0 and G1 with two separate trapezoidal modes gets you like 
90% of the way there.

Is there any HAL component that can tell if it's running as G0 or G1? 

Would it make sense for HAL to use the current velocity to reduce acceleration, 
thus creating a nontrapezoidal profile?  I think I can see how the HAL could do 
that, but I think it would break the motion control & trajectory planner 
outright.

Danny

 andy pugh  wrote: 
> On 27 June 2016 at 09:41, Danny Miller  wrote:
>
> So, is there a way to have RAPID_ACCELERATION  (for G0 alone) as a
> separate thing from MAX_ACCELERATION for the axes, used for G1 motion?

Possibly.
There are HAL pins to control acceleration. However they are not read
during program execution.

I don't know whether this will work (and can't test it here) but maybe
this is worth an experiment?

loadrt mux2
...
addf mux2.0.servo-thread
...
net accel-sel halui.mode.is-auto => mux2.0.sel
setp mux2.0.in0 100
setp mux2.0.in1 1
net accel-selected mux2.0.out => ini.traj_default_acceleration

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

Re: [Emc-users] Spindle control panel breaks LinuxCNC?

[dannym]

It's modbus, sorry forgot to mention that.

What baffles me is the Spindle buttons on the panel, AFAIK, just map to the 
same spindle-run in the HAL that M3 goes to.  I remember looking at the HAL 
monitor on this weeks ago and IIRC it was "spindle run true, but 
spindle-isrunning false".  The spindle isn't moving at all.  I'll recheck the 
HAL and take proper notes.

And like I say, the VFD won't run again even if you reboot LinuxCNC.  It will 
run if I cycle power on the VFD.  So, it's like it sent a toxic command to the 
VFD that changed a reg to something unusable.  I did make that x200_vfd.c from 
the WJ200_vfd.c VFD code, but it wasn't a major change, and it's simple, 
there's a run command, cw/ccw command (I made it so CCW just turns into CW), 
rpm command, and reads is-running-at-speed and an error bit.  

It don't see where it could deliver something to de-configure the VFD, nor why 
the Spindle panel buttons would do something different through the HAL than 
you'd get by MDI M3.

Danny


 andy pugh  wrote: 
> On 16 June 2016 at 07:57, Danny Miller  wrote:
>  My MPG's "spindle" button works.
>
> On the default panel, ...  Clicking any of that doesn't make the spindle go,
>
> It's not JUST that.  Once you click on any of that, the VFD *will never
> run again* until power is cycled.

How fascinating..
Can we see your HAL files?

Is the spindle controlled by Modbus or DC voltage? What hardware?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] PID tuning 7i92 stepper

[dannym]

So I never did get to tuning the PID for the 7i92, now that other things are 
working sensibly, this is next on my list.

So I tried to follow:
http://gnipsel.com/linuxcnc/tuning/servo.html

Plotted .ferror, .joint-vel-cmd, .motor-pos-fb

I see the .joint-vel-cmd, but .motor-pos-fb never moves from 0, even if the 
scale is tiny.  Axis move just as intended.  .ferror is just noise under 10u.  
Looks like quanitization noise.

Am I missing something?  Is there a different procedure for the unique 7i92 PID 
loops?

1KHz servo thread, and:

# PID tuning params
DEADBAND =  0
P = 1000
I = 0
D = 0
FF0 =   0
FF1 =   1
FF2 =0.00013
BIAS =  0
MAX_OUTPUT =0
MAX_ERROR =0.0005

Danny

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Copying an installation

[dannym]

OK, tried it with a $7 TRENDnet 10/100 card, deleted 70-persistent-net.rules, 
rebooted, and it works!

dmesg says:
[1.727414] 8139too :03:06.0: eth0: RealTek RTL8139 at 0x5000, 
00:14:d1:2e:fc:90, IRQ 10
[1.835906] tg3 :03:08.0: eth1: Tigon3 [partno(BCM95788) rev 3003] 
(PCI:33MHz:32-bit) MAC address 00:16:17:ad:3f:ea
[1.835914] tg3 :03:08.0: eth1: attached PHY is 5705 (10/100/1000Base-T 
Ethernet) (WireSpeed[0], EEE[0])
[1.835918] tg3 :03:08.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] 
TSOcap[1]
[1.835923] tg3 :03:08.0: eth1: dma_rwctrl[763f] dma_mask[32-bit]
[   12.842836] 8139too :03:06.0: eth0: link up, 100Mbps, full-duplex, lpa 
0x45E1

It looks like the new card is a RealTek chip and somehow grabbed eth0, which is 
fine.  I recognize the eth1 as the OB stuff.

Servo Thread 1ms Max Jitter it 57,000 ns
Base Thread 25us Max Jitter was 47,000ns, but I don't think I even have 
anything using Base Thread.

Danny

 "Peter C. Wallace"  wrote: 
> On Sat, 28 May 2016, dan...@austin.rr.com wrote:
> 
> > Date: Sat, 28 May 2016 20:58:59 +
> > From: dan...@austin.rr.com
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: "Enhanced Machine Controller (EMC)" 
> > Subject: Re: [Emc-users] Copying an installation
> > 
> > Hmm, well, interesting, the LEDs are flashing wildly in a 
> >pseudorandomish-looking pattern.  They're all flickering independently, not 
> >all on/all off.  The 4th one (furthest from the ethernet port), that one 
> >looks like it's flickering off VERY briefly then back on once every 2 sec.
> >
> >"setp hm2_7i92.0.led.CR01 TRUE" in the Show HAL Configuration window for all 
> >the CR0x changes nothing, nor does setting FALSE.  They're flickering 
> >unchanged.
> >
> >When I quit LinuxCNC, the LED nearest the ethernet port goes off, the other 
> >3 
> >are solid-on. 
> >
> >Show HAL Configuration->Threads->servo-thread:
> >1  hm2_7i92.0.read
> >10 hm2_7i92.0.write
> >
> >So those are there.
> >
> >Danny
> 
> 
> Default user EEPROM settings make the user LEDs point to RXPKTCount so they 
> are just an activity indicator (this can be changed to HM2 LEDs by writing 0 
> to the LEDMode register in the setup EEPROM)
> 
> if they look ragged though that does suggest communication problems as they 
> should be counting up at a average 3 KHz rate (at 1 KHz servo thread) so the 
> slowest LED should be flickering at around 190 Hz (3 KHz / 16)
> 
> I would try another PC or at leas another NIC (Intel and Realtek are known to 
> work well for real time, Broadcom and Atheros, not so much)
> 
> 
> Peter Wallace
> 
> Mesa Electronics
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Copying an installation

[dannym]

Hmm, well, interesting, the LEDs are flashing wildly in a 
pseudorandomish-looking pattern.  They're all flickering independently, not all 
on/all off.  The 4th one (furthest from the ethernet port), that one looks like 
it's flickering off VERY briefly then back on once every 2 sec.

"setp hm2_7i92.0.led.CR01 TRUE" in the Show HAL Configuration window for all 
the CR0x changes nothing, nor does setting FALSE.  They're flickering unchanged.

When I quit LinuxCNC, the LED nearest the ethernet port goes off, the other 3 
are solid-on.  

Show HAL Configuration->Threads->servo-thread:
1  hm2_7i92.0.read
10 hm2_7i92.0.write

So those are there.

Danny


 andy pugh  wrote: 
> On 28 May 2016 at 05:52, Danny Miller  wrote:
> No, no LinuxCNC axis moves.  If I expand FERROR way out, the display
> says it's moving like 0.5" before erroring- but the physical axis never
> moves.

One way to check if you have Hostmot2 communication would be to try to
light the LEDs on the 7i92 board.
halcmd setp hm2_7i92.0.CR01 1

This situation sounds a lot like what you might get if the hm2_7i92
read/write functions were not added to a thread.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Copying an installation

[dannym]

OK the interfaces file is:
# The loopback network interface
auto lo
iface lo inet loopback
auto eth1
iface eth1 inet static
address 10.10.10.1

BTW that dmesg gave that from grepping "eth" alone.  There is no eth1 there, 
only eth0.

So I changed "eth1" to "eth0" in interfaces and "sudo service networking 
restart".

Now I asked mesaflash and got:
ETH device 7I92 at ip=10.10.10.10

So, GREAT, ran LinuxCNC, but got the same following error upon axis motion.

Rebooted.  LinuxCNC still gives the same following error.

Now dmesg has:
[1.837260] tg3 :03:08.0: eth0: Tigon3 [partno(BCM95788) rev 3003] 
(PCI:33MHz:32-bit) MAC address 00:16:17:ad:3f:ea
[1.837266] tg3 :03:08.0: eth0: attached PHY is 5705 (10/100/1000Base-T 
Ethernet) (WireSpeed[0], EEE[0])
[1.837271] tg3 :03:08.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] 
TSOcap[1]
[1.837275] tg3 :03:08.0: eth0: dma_rwctrl[763f] dma_mask[32-bit]
[   12.808639] ADDRCONF(NETDEV_UP): eth0: link is not ready

But again, mesaflash says it's there at 10.10.10.10.  And if you try to start 
LinuxCNC without the 7i92 powered up, it won't let you start LinuxCNC, not wait 
to move an axis.

Danny


 dan...@austin.rr.com wrote: 
> Alrighty!
> 
> OK, found and renamed that .rules to a .rules.bak file and rebooted.
> 
> Can't see the 7i92 now.  Mesaflash --device 7i92 --addr 10.10.10.10 gives 
> "not found".
> 
> dmesg has no "ifname" in it at all.
> 
> It does have:
> [1.820851] tg3 :03:08.0: eth0: Tigon3 [partno(BCM95788) rev 3003] 
> (PCI:33MHz:32-bit) MAC address 00:16:17:ad:3f:ea
> [1.820858] tg3 :03:08.0: eth0: attached PHY is 5705 
> (10/100/1000Base-T Ethernet) (WireSpeed[0], EEE[0])
> [1.820862] tg3 :03:08.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] 
> ASF[0] TSOcap[1]
> [1.820866] tg3 :03:08.0: eth0: dma_rwctrl[763f] dma_mask[32-bit]
> 
> Danny
> 
> 
>  Gene Heskett  wrote: 
> > On Friday 27 May 2016 12:54:22 dan...@austin.rr.com wrote:
> > 
> > I've sent this message 3 times now.  What black hole is gobbling it up?
> > 
> > > It's a direct dd copy of the drive.  If that wasn't complete, a lot
> > > more would be broken.
> > >
> > > I would not dismantle the (mostly) working system like that.  There's
> > > a risk of something getting stored wrong on the working drive while
> > > it's on the new machine, and I don't see anything to prove by moving
> > > it.
> > >
> > > 99.9% sure it's just something different about the ethernet driver on
> > > the new motherboard.  Something small.  No idea how to fix it, though.
> > 
> > See my reply to Peter, delete /etc/udev/rules.d/70-persistent-net.rules 
> > and reboot.  It will be rebuilt to match the ethernet hardware in finds 
> > as it reboots, and networking will likely be restored.
> > 
> > If not, delete it again, grep ' ifname ' /var/log/dmesg to see what it 
> > did call it, you should get something that resembles this:
> > 
> > gene@coyote:~$ grep ' ifname ' /var/log/dmesg
> > [1.401462] forcedeth :00:08.0: ifname eth0, PHY OUI 0x5043 @ 1, 
> > addr 00:1f:c6:62:fc:bb
> > [1.929064] forcedeth :00:09.0: ifname eth1, PHY OUI 0x5043 @ 1, 
> > addr 00:1f:c6:63:07:97
> > (word wrapped, darn it, what you want is the string after the first 
> > ifname. in this example eth0)
> > 
> > then use an editor as root to look at the /etc/networking/interfaces 
> > file, and rename the stanza for eth0 to whatever the system found and 
> > named it to in the /var/log/dmesg file.
> > 
> > You should at that point be able to do a "sudu service restart 
> > networking" and have the ability to "ping -C2 yahoo.com" and get a 2 
> > normal ping responses from yahoo.com which indicates that networking is 
> > now working.
> > 
> > > It is an AMD64 though, and the installation was an i686.
> > 
> > A non-issue AFAIK.
> > 
> > > Danny
> > >
> > >  "Peter C. Wallace"  wrote:
> > > > On Fri, 27 May 2016, Danny Miller wrote:
> > > > > Date: Fri, 27 May 2016 00:11:08 -0500
> > > > > From: Danny Miller 
> > > > > Reply-To: "Enhanced Machine Controller (EMC)"
> > > > > 
> > > > > To: emc-users@lists.sourceforge.net
> > > > > Subject: Re: [Emc-users] Copying an installation
> > > > >
> > > > > I do recall we went through much more than expected just getting
> > > > > all that installed.  And I don't have a complete list of all that
> > > > > was done.
> > > > >
> > > > > I did poke around again on this machine.
> > > > >
> > > > > Mesaflash says the card's there at 10.10.10.10.
> > > > >
> > > > > After launching LinuxCNC, the VFD does respond to commands just
> > > > > fine.
> > > > >
> > > > > I experimented with the FERROR value- it'll allow the coordinates
> > > > > to change significantly before throwing an error, but the axes
> > > > > will never move regardless.  The 7i92 won't put out steps at all.
> > > > > I don't have any enable line on 

Re: [Emc-users] Copying an installation

[dannym]

Alrighty!

OK, found and renamed that .rules to a .rules.bak file and rebooted.

Can't see the 7i92 now.  Mesaflash --device 7i92 --addr 10.10.10.10 gives "not 
found".

dmesg has no "ifname" in it at all.

It does have:
[1.820851] tg3 :03:08.0: eth0: Tigon3 [partno(BCM95788) rev 3003] 
(PCI:33MHz:32-bit) MAC address 00:16:17:ad:3f:ea
[1.820858] tg3 :03:08.0: eth0: attached PHY is 5705 (10/100/1000Base-T 
Ethernet) (WireSpeed[0], EEE[0])
[1.820862] tg3 :03:08.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] 
TSOcap[1]
[1.820866] tg3 :03:08.0: eth0: dma_rwctrl[763f] dma_mask[32-bit]

Danny


 Gene Heskett  wrote: 
> On Friday 27 May 2016 12:54:22 dan...@austin.rr.com wrote:
> 
> I've sent this message 3 times now.  What black hole is gobbling it up?
> 
> > It's a direct dd copy of the drive.  If that wasn't complete, a lot
> > more would be broken.
> >
> > I would not dismantle the (mostly) working system like that.  There's
> > a risk of something getting stored wrong on the working drive while
> > it's on the new machine, and I don't see anything to prove by moving
> > it.
> >
> > 99.9% sure it's just something different about the ethernet driver on
> > the new motherboard.  Something small.  No idea how to fix it, though.
> 
> See my reply to Peter, delete /etc/udev/rules.d/70-persistent-net.rules 
> and reboot.  It will be rebuilt to match the ethernet hardware in finds 
> as it reboots, and networking will likely be restored.
> 
> If not, delete it again, grep ' ifname ' /var/log/dmesg to see what it 
> did call it, you should get something that resembles this:
> 
> gene@coyote:~$ grep ' ifname ' /var/log/dmesg
> [1.401462] forcedeth :00:08.0: ifname eth0, PHY OUI 0x5043 @ 1, 
> addr 00:1f:c6:62:fc:bb
> [1.929064] forcedeth :00:09.0: ifname eth1, PHY OUI 0x5043 @ 1, 
> addr 00:1f:c6:63:07:97
> (word wrapped, darn it, what you want is the string after the first 
> ifname. in this example eth0)
> 
> then use an editor as root to look at the /etc/networking/interfaces 
> file, and rename the stanza for eth0 to whatever the system found and 
> named it to in the /var/log/dmesg file.
> 
> You should at that point be able to do a "sudu service restart 
> networking" and have the ability to "ping -C2 yahoo.com" and get a 2 
> normal ping responses from yahoo.com which indicates that networking is 
> now working.
> 
> > It is an AMD64 though, and the installation was an i686.
> 
> A non-issue AFAIK.
> 
> > Danny
> >
> >  "Peter C. Wallace"  wrote:
> > > On Fri, 27 May 2016, Danny Miller wrote:
> > > > Date: Fri, 27 May 2016 00:11:08 -0500
> > > > From: Danny Miller 
> > > > Reply-To: "Enhanced Machine Controller (EMC)"
> > > > 
> > > > To: emc-users@lists.sourceforge.net
> > > > Subject: Re: [Emc-users] Copying an installation
> > > >
> > > > I do recall we went through much more than expected just getting
> > > > all that installed.  And I don't have a complete list of all that
> > > > was done.
> > > >
> > > > I did poke around again on this machine.
> > > >
> > > > Mesaflash says the card's there at 10.10.10.10.
> > > >
> > > > After launching LinuxCNC, the VFD does respond to commands just
> > > > fine.
> > > >
> > > > I experimented with the FERROR value- it'll allow the coordinates
> > > > to change significantly before throwing an error, but the axes
> > > > will never move regardless.  The 7i92 won't put out steps at all.
> > > > I don't have any enable line on it.
> > > >
> > > > Danny
> > >
> > > Did you try swapping hard drives as someone suggested, in case
> > > something was forgotten when moving?
> > >
> > > (when linux using generic kernels its much easier to just swap hard
> > > drives than moving a setup to a new machine)
> > >
> > > > On 5/22/2016 6:27 PM, andy pugh wrote:
> > > >> On 22 May 2016 at 19:51, Danny Miller  
> wrote:
> > > >>> Any advice, folks?  I've gotta move off that Dell machine ASAP
> > > >>> and really want to avoid a whole reinstall.
> > > >>
> > > >> I would suggest a complete reinstall of the OS and LinuxCNC, but
> > > >> keep the same config files. The LinuxCNC config files should be
> > > >> entirely portable.
> > > >
> > > > --
> > > > What NetFlow Analyzer can do for you? Monitors network
> > > > bandwidth and traffic patterns at an interface-level. Reveals
> > > > which users, apps, and protocols are consuming the most bandwidth.
> > > > Provides multi-vendor support for NetFlow, J-Flow, sFlow and other
> > > > flows. Make informed decisions using capacity planning reports.
> > > > https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> > > > ___
> > > > Emc-users mailing list
> > > > Emc-users@lists.sourceforge.net
> > > > 

Re: [Emc-users] Copying an installation

[dannym]

Hmm good question- I don't have any inputs right now.

Danny

 andy pugh  wrote: 
> On 27 May 2016 at 17:54,   wrote:

> 99.9% sure it's just something different about the ethernet driver on the new 
> motherboard.  Something small.  No idea how to fix it, though.

Do the inputs work?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Copying an installation

[dannym]

It's a direct dd copy of the drive.  If that wasn't complete, a lot more would 
be broken.

I would not dismantle the (mostly) working system like that.  There's a risk of 
something getting stored wrong on the working drive while it's on the new 
machine, and I don't see anything to prove by moving it.

99.9% sure it's just something different about the ethernet driver on the new 
motherboard.  Something small.  No idea how to fix it, though.

It is an AMD64 though, and the installation was an i686.

Danny


 "Peter C. Wallace"  wrote: 
> On Fri, 27 May 2016, Danny Miller wrote:
> 
> > Date: Fri, 27 May 2016 00:11:08 -0500
> > From: Danny Miller 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: emc-users@lists.sourceforge.net
> > Subject: Re: [Emc-users] Copying an installation
> > 
> > I do recall we went through much more than expected just getting all
> > that installed.  And I don't have a complete list of all that was done.
> >
> > I did poke around again on this machine.
> >
> > Mesaflash says the card's there at 10.10.10.10.
> >
> > After launching LinuxCNC, the VFD does respond to commands just fine.
> >
> > I experimented with the FERROR value- it'll allow the coordinates to
> > change significantly before throwing an error, but the axes will never
> > move regardless.  The 7i92 won't put out steps at all. I don't have any
> > enable line on it.
> >
> > Danny
> 
> Did you try swapping hard drives as someone suggested, in case something was 
> forgotten when moving?
> 
> (when linux using generic kernels its much easier to just swap hard drives 
> than moving a setup to a new machine)
> 
> 
> >
> > On 5/22/2016 6:27 PM, andy pugh wrote:
> >> On 22 May 2016 at 19:51, Danny Miller  wrote:
> >>> Any advice, folks?  I've gotta move off that Dell machine ASAP and
> >>> really want to avoid a whole reinstall.
> >> I would suggest a complete reinstall of the OS and LinuxCNC, but keep
> >> the same config files. The LinuxCNC config files should be entirely
> >> portable.
> >>
> >
> >
> > --
> > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> > patterns at an interface-level. Reveals which users, apps, and protocols are
> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> > ___
> > 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.
> 
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] USB flash drive issue

[dannym]

I have trouble with the USB drive too, but different.

If I plug into the drive and try to load, LinuxCNC doesn't see any files.  If 
you browse File Manager to the drive even once, then there's no problem, all 
the flash drive data is available.

This is kind of annoying, the design stuff is on another computer and we 
shuttle frequently.  So you've got to bring up a File Manager each time before 
LinuxCNC can see the drive.  Any idea why?

Danny


 Jim Craig  wrote: 
> All,
> 
> I found an issue that I think is a bug but would like feedback before I 
> post it on the GitHub issue list.
> 
> I was using a USB flash drive to transfer files from my CAD/CAM pc to 
> the LinuxCNC box. To do this I would plug the flash drive into the Linux 
> box and would mount the volume. The files are then available at /media/usb/
> 
> If I accessed a file from LinuxCNC in the Axis GUI at the location of 
> /media/usb/ the file would open fine and would run perfectly.
> 
> The issue is when I wanted to eject the volume so I could take it back 
> to the CAD/CAM box. To do this I would open a file that is on the local 
> hard drive in LinuxCNC so that it should release the /media/usb/ 
> resource. I would then attempt to eject the volume and it would throw up 
> an error message stating that it was still busy.
> 
> The only way I could eject the media was to completely close the 
> LinuxCNC application so it would release the /media/usb/resource so it 
> could be ejected.
> 
> I am running Debian Wheezy with 2.7.4.
> 
> Let me know if this is a bug or if there is something else that I should 
> be doing. I know I could copy the file to the local drive and not open 
> it from the USB flash drive.
> 
> Thanks,
> 
> Jim
> 
> 
> 
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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

Re: [Emc-users] Appropriate PCs

[dannym]

Well it's a Dell Optiplex 330, Intel G31 Express chipset.

I looked through BIOS- I couldn't find anything to disable that might be system 
management interrupts.

With Linux localhost 3.2.0-4-rt-686-pae #1 SMP PREEMPT RT Debian 3.2.78-1 i686 
GNU/Linux, still have onboard video, browsing the web and running bittorrent:

Servo Thread Max Interval 1,217,422ns Max Jitter 217,422ns
Base Thread  Max Interval 199,820ns  Max Jitter 174,820ns

There's an optiplex 360 with G31 chipset result here: 
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Latency-Test
They got:
1,010,913   16,443  
39,908  14,966 

So that jitter's WAY higher on my 330.  I know the onboard video can add to it, 
but can it be THAT much?   And it's beside the point because that other guy's 
test says "Intel G31 onboard Video. SMP Kernel "... those lower numbers were 
ALREADY using a video card.

I can add a video card, got several lying around, just a good amount of 
installation time really.

Danny

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

Re: [Emc-users] wj200 vfd "wait-for-speed"

[dannym]

Hmm I just noticed it started moving while the spindle was still spooling up.  
But that may have only been G0 moves it allowed.  I just saw motion and became 
concerned.

If it waits if it encounters a G1 before is-at-speed=TRUE, then that's already 
perfect!

Danny


 Chris Kelley  wrote: 
> Do you have wj200-vfd.N.is-at-speed connected to motion.spindle-at-speed?
> Have you checked to make sure that wj200-vfd.N.is-at-speed is only going
> true when expected?
> 
> We have several machines set up to use the motion.spindle-at-speed pin and
> have never had a problem with it working incorrectly. Just remember that it
> is only supposed to stop the _first_ feed move after a spindle start or
> speed change. It's not supposed to pause/hold any rapid moves.
> 
> On Fri, Apr 29, 2016 at 1:11 AM, Danny Miller  wrote:
> 
> > I have a VFD running on:
> >
> > http://linuxcnc.org/docs/html/man/man9/wj200_vfd.9.html
> >
> > Actually it's an X200 VFD and the code is slightly different, but that's
> > not important.
> >
> > I noticed that it doesn't wait for the spindle to get up to speed when
> > started in-code.  It just goes.
> >
> > What are my options here?  I could write a HAL for "if spindle.on and
> > !spindle.at-speed and !paused, set Pause to true", but that sounds
> > overly complicated, and I can't release it with "if spindle.on and
> > spindle.at-speed and paused, set Resume to true" because the user may
> > have requested a pause and that would spuriously cause  a resume.
> >
> > Danny
> >
> >
> >
> > --
> > Find and fix application performance issues faster with Applications
> > Manager
> > Applications Manager provides deep performance insights into multiple
> > tiers of
> > your business applications. It resolves application problems quickly and
> > reduces your MTTR. Get your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> --
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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

Re: [Emc-users] Can't get XHC-HB04 MPG to work

[dannym]

Didn't realize I sent off-list.

OK, I think I see a key problem, under Hal Meter, "xhb-hb04.require_pendant = 
false", although "connected" is true.

Right in the main .ini:

[XHC_HB04_CONFIG]
require_pendant = yes

I tried "true" instead of "yes", no change.

[HALUI] for all the MDI_COMMAND stuff is in the main ini file now.  It shows up 
under the HAL meter- but are always false.  I pressed every button on the mpg.

The jog.enable-x show true/false when selected.

So, what I'm seeing is that any button listed inside my xhc-hb20.hal file works 
fine.  But all the  [HALUI] and [XHC_HB04_BUTTONS] stuff is inactive.


Danny


 Gene Heskett  wrote: 
> On Wednesday 20 April 2016 15:28:39 dan...@austin.rr.com wrote:
> Back to the list Danny, so its locateable in the list archives for the 
> next person with a similar error.  That IS the main reason this list 
> exists.
> 
> That, and to nag you unmercifully about your top posting,  We like to see 
> the answers mixed in so its a conversationally ordered read for the next 
> person.  Your emails header lines do not identify your "user agent" so I 
> can't sharpen a finger in its direction.
> 
> > Sorry I didn't type the complete sentence: "So you're saying [HALUI]
> > in a supplemental .ini file won't work?" was what I was shooting for.
> >
> > Looking over the other stuff.  This looks like a GREAT help!
> >
> > Is it ok that [XHC_HB04_BUTTONS],[XHC_HB04_CONFIG], [EMC], and
> > [APPLICATIONS] are still in that layout20.ini file and not the main
> > .ini?
> >
> > There is already an [EMC] in the main .ini:
> > MACHINE =   HM2-Stepper
> > DEBUG = 0
> >
> > layout20.ini additionally has:
> > [EMC]
> > MACHINE =  xhc-hb04 layout2
> >
> You may want to put that in its own file, with a suitable name, and then 
> source "suitable" name.
> 
> But OTOH, I have not done something like that (sourceing a file, which 
> when done, essentially is identical to opening  up a small gap in the 
> first .ini file and inserting the contents of the sourced file at that 
> point in the first file, but I haven't done that myself except in hal 
> files.  Laziness or my don't fix whats working attitude, flip a coin. :)
> 
> But it stands to reason it should work, at least till it throws it back 
> at you in a meaningfull error message.
> 
> > Is this ok?  Do they just combine into what's effectively "MACHINE=
> > HM2-Stepper xhc-hb04 layout2"?
> >
> > Danny
> >
> >  Gene Heskett  wrote:
> > > On Wednesday 20 April 2016 11:31:28 dan...@austin.rr.com wrote:
> > > > So you're saying [HALUI] in a supplemental .ini file?
> > > > Alright, that sounds like the problem!
> > >
> > > Not supplemental, but in the ini file as a marked [HALUI] section.
> > > Taken from the top of my ini file, the important parts:
> > > =SOF===
> > > [DISPLAY]
> > > DISPLAY = axis
> > > PYVCP = pyvcp-panel.xml
> > > EOF===
> > > this pyvcp_panel.xml was a community developed file, a bit long, but
> > > here it is after I elide some commented out code:
> > > SOF==
> > > 
> > >
> > > 
> > > 
> > > 
> > >   
> > > RAISED
> > > 3
> > > 
> > >   "spindle_rpm"
> > >   "Spindle"
> > >   "RPM"
> > >   235
> > >   0
> > >   2750
> > >   500
> > >   100
> > >   0,2250,"green"
> > >   2250,2600,"yellow"
> > >   2600,2750,"red"
> > > 
> > >   
> > >
> > > 
> > >   
> > > RAISED
> > > 2
> > > 
> > >   "SPWR"
> > >   ("Helvetica",12)
> > > 
> > > 
> > >   "on-led"
> > >   "20"
> > >   "72"
> > >   "green"
> > >   "red"
> > > 
> > >   
> > >
> > >   
> > > RAISED
> > > 2
> > > 
> > >   "FWD"
> > >   ("Helvetica",12)
> > > 
> > > 
> > >   "fwd-led"
> > >   "20"
> > >   "72"
> > >   "green"
> > >   "red"
> > > 
> > >   
> > >
> > >   
> > > RAISED
> > > 2
> > > 
> > >   "REV"
> > >   ("Helvetica",12)
> > > 
> > > 
> > >   "rev-led"
> > >   "20"
> > >   "72"
> > >   "green"
> > >   "red"
> > > 
> > >   
> > > 
> > > 
> > > 
> > >   
> > > 
> > >   "checkbutton1"
> > >   "CamOn"
> > >   ('Helvetica',10)
> > > 
> > > 
> > >   
> > > "button1"
> > > "CamOff"
> > > ('Helvetica',10)
> > >   
> > >   
> > > "button2"
> > > "CamStor"
> > > ('Helvetica',10)
> > >   
> > >   
> > > "button3"
> > > "CamCtr4"
> > > ('Helvetica',10)
> > >   
> > > 
> > >   
> > >
> > > 
> > >
> > >   
> > > 
> > > "align-start"
> > > "Align Start"
> > > ('Helvetica',10)
> > > 
> > > 
> > > 
> > > "align-y"
> > > "Align Y"
> > > ('Helvetica',10)
> > > 
> > > 
> > > "align-x"
> > >

Re: [Emc-users] Can't get XHC-HB04 MPG to work

[dannym]

Sorry I didn't type the complete sentence: "So you're saying [HALUI] in a 
supplemental .ini file won't work?" was what I was shooting for.

Looking over the other stuff.  This looks like a GREAT help!

Is it ok that [XHC_HB04_BUTTONS],[XHC_HB04_CONFIG], [EMC], and [APPLICATIONS] 
are still in that layout20.ini file and not the main .ini?

There is already an [EMC] in the main .ini:
MACHINE =   HM2-Stepper
DEBUG = 0

layout20.ini additionally has:
[EMC]
MACHINE =  xhc-hb04 layout2 

Is this ok?  Do they just combine into what's effectively "MACHINE= HM2-Stepper 
xhc-hb04 layout2"?

Danny

 Gene Heskett  wrote: 
> On Wednesday 20 April 2016 11:31:28 dan...@austin.rr.com wrote:
> 
> > So you're saying [HALUI] in a supplemental .ini file?
> > Alright, that sounds like the problem!
> >
> Not supplemental, but in the ini file as a marked [HALUI] section.
> Taken from the top of my ini file, the important parts:
> =SOF===
> [DISPLAY]
> DISPLAY = axis
> PYVCP = pyvcp-panel.xml
> EOF===
> this pyvcp_panel.xml was a community developed file, a bit long, but here 
> it is after I elide some commented out code:
> SOF==
> 
> 
> 
> 
> 
>   
> RAISED
> 3
> 
>   "spindle_rpm"
>   "Spindle"
>   "RPM"
>   235
>   0
>   2750
>   500
>   100
>   0,2250,"green"
>   2250,2600,"yellow"
>   2600,2750,"red"
> 
>   
> 
> 
>   
> RAISED
> 2
> 
>   "SPWR"
>   ("Helvetica",12)
> 
> 
>   "on-led"
>   "20"
>   "72"
>   "green"
>   "red"
> 
>   
> 
>   
> RAISED
> 2
> 
>   "FWD"
>   ("Helvetica",12)
> 
> 
>   "fwd-led"
>   "20"
>   "72"
>   "green"
>   "red"
> 
>   
> 
>   
> RAISED
> 2
> 
>   "REV"
>   ("Helvetica",12)
> 
> 
>   "rev-led"
>   "20"
>   "72"
>   "green"
>   "red"
> 
>   
> 
>  
> 
>   
> 
>   "checkbutton1"
>   "CamOn"
>   ('Helvetica',10)
> 
> 
>   
> "button1"
> "CamOff"
> ('Helvetica',10)
>   
>   
> "button2"
> "CamStor"
> ('Helvetica',10)
>   
>   
> "button3"
> "CamCtr4"
> ('Helvetica',10)
>   
> 
>   
>   
> 
> 
>   
> 
> "align-start"
> "Align Start" 
> ('Helvetica',10)
> 
> 
> 
> "align-y"
> "Align Y" 
> ('Helvetica',10)
> 
> 
> "align-x"
> "Align X" 
> ('Helvetica',10)
> 
> 
> 
>  "clear-offset"
>  "Clear Offset" 
>  ('Helvetica',10)
> 
>   
> 
> EOF=== 
> 
> then later,
> Example from my .ini for a G0704 I'm still tuning for original mistakes.
> ==SOF===
> [HAL]
> HALUI = halui
> HALFILE = GO704fast.hal
> POSTGUI_HALFILE = postgui_call_list.hal
> SHUTDOWN = shutdown.hal
> 
> [HALUI]
> MDI_COMMAND=o<_camon> call
> MDI_COMMAND=o<_camoff> call
> MDI_COMMAND=o<_camstore> call
> MDI_COMMAND=o<_camcenter3> call
> MDI_COMMAND=o<_camcenter4> call
> MDI_COMMAND=o call
> MDI_COMMAND=o call
> MDI_COMMAND=o call
> MDI_COMMAND=o call
> 
> Those are all subroutine calls whose links are created by the postgui 
> files that also add a tach, spindle power & direction tallies, and a 
> series of clickable buttons that will execute those above HALUI 
> commands.
> 
> postgui_call_list.hal:
> source postgui.hal
> 
> This may not be 100% correct as its being taken out of context, but it 
> should serve as a somewhat poor tutorial to show what can be done.  I've 
> abused the list enough by posting the .xml file already.
> 
> > Are there more elements which will only work if placed in the main
> > .ini file?
> >
> > layout20.ini has [XHC_HB04_BUTTONS], [EMC], [HAL], [XHC_HB04_CONFIG],
> > and [APPLICATIONS].
> >
> > I'm guessing [EMC] and [HAL] need to be in the main .ini, right?  What
> > about [APPLICATIONS]?
> >
> >
> > [XHC_HB04_BUTTONS]
> > step= xhc-hb04.stepsize-up
> > spindle = halui.spindle.start
> >
> > So, the step size did not go up when I pressed the button.  Spindle
> > didn't start.  Those are NOT an MDI, so I still have another problem,
> > right?  What might it be?
> 
> Best guess is that the action from the jog wheel kit is not all properly 
> linked in your hal file. Clear dmesg by running it as root 
> with "dmesg -c", then run LCNC and stop it after its finished loading, 
> then run as root, "dmesg". Screen copy it to get a list of everything it 
> found, then check your hal file to see if its in there, both as a source 
> for a "net" "name" "source_of_sig" "where_it_goes". The latter can be a 
> space/tab separated list. If the list is too long, add another 
> identical "net name" line anyplace below the first one, and 

Re: [Emc-users] Can't get XHC-HB04 MPG to work

[dannym]

So you're saying [HALUI] in a supplemental .ini file?  
Alright, that sounds like the problem!


Are there more elements which will only work if placed in the main .ini file?

layout20.ini has [XHC_HB04_BUTTONS], [EMC], [HAL], [XHC_HB04_CONFIG], and 
[APPLICATIONS].

I'm guessing [EMC] and [HAL] need to be in the main .ini, right?  What about 
[APPLICATIONS]?


[XHC_HB04_BUTTONS]
step= xhc-hb04.stepsize-up
spindle = halui.spindle.start

So, the step size did not go up when I pressed the button.  Spindle didn't 
start.  Those are NOT an MDI, so I still have another problem, right?  What 
might it be?

Danny


 andy pugh  wrote: 
> On 20 April 2016 at 07:29, Danny Miller  wrote:
> IIRC the halui.mdi-command-01 etc didn't seem to exist under halui.


Those pins are created by halui based on the MDI_COMMAND entries in
the [HALUI] section of the main INI file.

So, you need to find or create a [HALUI] section in your main .ini
file (as many as you need) and each one will define a single-line
G-code command that will be run when the corresponding HAL pin is
triggered.

http://linuxcnc.org/docs/2.7/html/config/ini-config.html#_halui_section

For more complex actions your MDI_COMMAND can be a subroutine call
such as O CALL

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

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



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

Re: [Emc-users] Modifying homing

[dannym]

For XY, it's homing the machine coords.

For Z, I know touching off the Z and homing the z coord are different, but I 
never really saw the need to home the Z.  It doesn't prevent work table 
crashing in a manual TC situation.  It prevents excessive Z+ that hits the 
stops, but I have a LOT of Z-height and it never really comes up whether I home 
or not.  

touch-off, whether it's to the table or top of the stock, has to be done every 
time. 

Homing the Z might be essential as a part of the XY home.  If you just seek XY 
from the current Z, if someone goofed and didn't lift the Z, it could run the 
spindle through the stock.  If you lift the Z at all to be more foolproof, the 
Z+ homing switch would be the only spot that makes sense to stop at.  

So, really I'm looking at a deadman Z-XY home, and a deadman Z touchoff.

Danny

 Sebastian Kuzminsky  wrote: 
> On 04/13/2016 12:29 PM, dan...@austin.rr.com wrote:
> > Z-homing upwards for machine coordinate zeroing doesn't serve a lot
> > of point for manual toolchangers.  It can't prevent crashing into the
> > table because you don't know how far the tool tip is from the nut.
> > Zeroing the work coordinates to the table or top of the material is
> > essential for almost all ops, though.
> 
> All my machines use manual tool changing, and they all home Z upwards 
> (away from the table).
> 
> Remember, "homing" means finding the machine's position within the work 
> envelope (ie, finding the actual machine coordinates of the controlled 
> point), and "touch-off" means finding the controlled point's position 
> relative to the work or fixture.  They're different operations with 
> different requirements.
> 
> Homing happens only once, at machine startup (plus each time your joint 
> motors lose power, if you are using VOLATILE_HOME).
> 
> Touch-off happens once for each tool change and each new setup.
> 
> I'm thinking now that you're asking about touch-off, not homing.
> 
> 
>  >> Maybe you could implement this with some hal circuitry like this
>  >> (hal pseudocode):
>  >>
>  >> z-home-button-in => halui.joint.2.home
>  >> (!axis.2.homing || z-home-button-in) => motion.enable
>  >
> > I'm not sure I follow these "enable" solutions.  I don't want it to
> > be NOT enabled for other purposes if the button isn't true.  Does NOT
> > motion.enable being true render axis.2.homing false, so it will end
> > the homing, make homing FALSE, so motion.enable subsequently becomes
> > TRUE while the homing button is still FALSE?
> 
> That second line reads like this:
> 
> motion.enable is True if either:
> 1. axis.2.homing is False, or
> 2. axis.2.homing is True and the z-home button on the pendant is pushed
> 
> Otherwise motion.enable is False.
> 
> 
> -- 
> Sebastian Kuzminsky


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

Re: [Emc-users] Modifying homing

[dannym]

Sure, estop is an option.  But this is a large machine in a shop open to many 
users.  Really I'm thinking the whole idea of a "home" button you could press 
once and walk away is less safe than... I guess we're calling it "deadman 
homing" now.

I try to think of real-world use.  Heard of plenty of cases where someone was 
doing touch-off and forgot to lay out the touch-off plate and everything looked 
fine until the tip started jamming into the table.  If it's automated without 
deadman, the process becomes "oh crap oh crap it's doing that thing what do i 
do where's the estop it's right here ok press it".  Reaction time for such an 
unexpected outcome is near-instantenous if you're consciously holding down a 
button, "oh cra..." and you let go reflexively, typically.  You don't have to 
find the button at all, just let go.  I think the act of releasing a button 
would be done quicker in the real world than an active press, even if a person 
had already pre-hovered their finger over the e-stop.

Danny

 Dave Cole  wrote: 
> That's what the E-Stop button is for.Until you have homing nailed 
> down, you should keep your hand over the E-Stop button while running 
> risky procedures.
> 
> Also, there is no reason why you need to home close to a hard stop when 
> first testing software.   Move your home switch so it makes well before 
> you hit a hard stop so you have some time to take
> corrective action to prevent a machine crash.Or put a cardboard box 
> under the Z axis so it hits the cardboard first and trips.  If it keeps 
> going through the cardboard you have some time to hit the E-Stop before 
> tweaking your Z axis.  Also, slow down your homing routine so you have 
> more reaction time.Then speed it up after you are confident in the 
> software.
> 
> Dave
> 
> On 4/13/2016 12:25 PM, dan...@austin.rr.com wrote:
> > I have an XHC-HB04 wireless MPG that doesn't "quite" work yet.  While 
> > working on it, I had a thought.
> >
> > Homing is one of the riskier functions. You could Z-down to a touch plate 
> > and not realize the plate's not underneath it at all and go scrambling to 
> > stop it.  Having automated process buttons that take command away from the 
> > operator are inherently risky.
> >
> > My idea would be that you would have to HOLD DOWN the Home Z button for the 
> > process to continue.  If you release the button before it's complete, the 
> > axis just stops and it forgets about homing.
> >
> > This would tend to direct your attention to what's happening and if things 
> > go wrong you just let go.  Also if you were to accidentally press the Home 
> > Z button, nothing serious would happen.  It would bump down like 1/4 in and 
> > stop when you realized you pressed the wrong button.
> >
> > What might it take to implement such a thing?  I do have trivkins for the 
> > gantry, and the homing is already a somewhat complicated special-case.
> >
> > Danny
> >
> > --
> > Find and fix application performance issues faster with Applications Manager
> > Applications Manager provides deep performance insights into multiple tiers 
> > of
> > your business applications. It resolves application problems quickly and
> > reduces your MTTR. Get your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> --
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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

Re: [Emc-users] Modifying homing

[dannym]

Z-homing upwards for machine coordinate zeroing doesn't serve a lot of point 
for manual toolchangers.  It can't prevent crashing into the table because you 
don't know how far the tool tip is from the nut.  Zeroing the work coordinates 
to the table or top of the material is essential for almost all ops, though.

I'm not sure I follow these "enable" solutions.  I don't want it to be NOT 
enabled for other purposes if the button isn't true.  Does NOT motion.enable 
being true render axis.2.homing false, so it will end the homing, make homing 
FALSE, so motion.enable subsequently becomes TRUE while the homing button is 
still FALSE?

Danny

 Sebastian Kuzminsky  wrote: 
> On 04/13/2016 10:25 AM, dan...@austin.rr.com wrote:
> > Homing is one of the riskier functions. You could Z-down to a touch
> > plate and not realize the plate's not underneath it at all and go
> > scrambling to stop it.  Having automated process buttons that take
> > command away from the operator are inherently risky.
> 
> Z generally homes upwards (in the safe direction) for this reason.  A 
> switch or prox sensor is mounted on the machine and the Z carriage trips 
> it at the top of its range of motion.
> 
> 
> > My idea would be that you would have to HOLD DOWN the Home Z button
> > for the process to continue.  If you release the button before it's
> > complete, the axis just stops and it forgets about homing.
> 
> That sounds like a good safety improvement over homing down without a 
> "dead man switch".
> 
> Maybe you could implement this with some hal circuitry like this (hal 
> pseudocode):
> 
> z-home-button-in => halui.joint.2.home
> (!axis.2.homing || z-home-button-in) => motion.enable
> 
> Or this alternative, which reads cleaner to me but has the drawback of 
> going through non-realtime halui to abort the home when the user 
> releases the button:
> 
> z-home-button-in => halui.joint.2.home
> (axis.2.homing && !z-home-button-in) => halui.abort
> 
> Maybe that's no big deal, since the USB jog pendant already has a 
> non-realtime hal component driving it.
> 
> 
> -- 
> Sebastian Kuzminsky
> 
> --
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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

[Emc-users] Modifying homing

[dannym]

I have an XHC-HB04 wireless MPG that doesn't "quite" work yet.  While working 
on it, I had a thought.

Homing is one of the riskier functions. You could Z-down to a touch plate and 
not realize the plate's not underneath it at all and go scrambling to stop it.  
Having automated process buttons that take command away from the operator are 
inherently risky.

My idea would be that you would have to HOLD DOWN the Home Z button for the 
process to continue.  If you release the button before it's complete, the axis 
just stops and it forgets about homing.

This would tend to direct your attention to what's happening and if things go 
wrong you just let go.  Also if you were to accidentally press the Home Z 
button, nothing serious would happen.  It would bump down like 1/4 in and stop 
when you realized you pressed the wrong button. 

What might it take to implement such a thing?  I do have trivkins for the 
gantry, and the homing is already a somewhat complicated special-case.

Danny

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

Re: [Emc-users] XHC-HB04 on LinuxCNC

[dannym]

But wouldn't that break the ability to home the gantry's sides independently? 

That's a huge problem.  The gantry isn't going to align itself.  

A relevant point of the context here is this is going into a community shop, 
with a constant stream of new users with very limited supervision.  So "power 
down these axes and mechanically align them" doesn't sound like a viable 
option.  In the past I've had the stops aligned and ran the gantry into the 
stops until both sides' steppers stalled... gently.  

But that sort of hackery won't really fly here.  People would just be jamming 
it at high speeds and damaging the drives or at least keep screwing up their 
zero.

Danny


 andy pugh  wrote: 
> On 31 March 2016 at 16:34,   wrote:
> Pardon my ignorance, but what does "branch" mean here?  I have LinuxCNC 2.7.4 
> with Preempt-RT kernel support.  Would this mean going with something other 
> than that?

Yes, it would mean going with a development version of LinuxCNC rather
than a released version.

For aesthetic reasons I have been running JA versions on my machines
for years (none of my machines require it). However for "normal users"
it is maybe a step too far.

This is why I was suggesting that you try running a trivkins config
and use the "gantry" HAL component to link the joints.

There is a sample HAL file here:
https://github.com/cdsteinkuehler/linuxcnc/blob/0e0418b362f45d7ad332fa3f211cbf8c2f24efd9/configs/ARM/BeagleBone/Probotix/Comet.hal

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] XHC-HB04 on LinuxCNC

[dannym]

Pardon my ignorance, but what does "branch" mean here?  I have LinuxCNC 2.7.4 
with Preempt-RT kernel support.  Would this mean going with something other 
than that?  That's a nonstarter.

Danny

 Dewey Garrett  wrote: 
> As mentioned, you might want to try the joints_axes12 branch.
> (See below for example xyzx sim configurations in joints_axes12.)
> 
> All recent mainline branches (e.g., 2.6.x, 2.7.x, master) support
> JOG_CONT and JOG_INCR modes as used by 1) the axis gui for keyboard
> jogging and 2) halui pins with names: halui.jog-speed, halui.jog.N.*
> 
> The mainline branches do _not_ support wheel (mpg) based jogging in
> teleop (world) mode.  Only recent joints_axesNN (NN >=9) branches
> support wheel based jogging in teleop (world) mode.
> 
> Also note:
> 1) In recent joints_axesNN branches, some halui hal pin names have been
>renamed and pins have been added to distinguish joints/axes and joint/world
>modes of jogging.  See the joints_axesNN docs, for example section 4.2
>in:
> 
> http://buildbot.linuxcnc.org/doc/scratch/v2.8.0~pre1-ja~joints-axes12~44c2e6d/html/getting-started/updating-linuxcnc.html
> 
> 2) The LinuxCNC distribution includes a script (LIB:xhc-hb04.tcl) to
>aid in configuring an xhc-hb04 pendant and provides example sim
>configs located in:
> 
>configs/sim/axis/xhc-hb04
> 
> 3) In the joints_axes12 branch, the LIB:xhc-hb04.tcl script is
>'joints_axes aware' and will connect the proper wheel jogging pins
>for _both_ joint and telop jogging for known kinematics, namely
>trivkins and gentrivkins.
> 
> 4) A gantry config like xyzx is more complicated than simple
>gentrivkins configs because two joints control the x axis coordinate.
>I have added a set of configs to illustrate xyzx configs with simulated
>wheel jogging and with an xhc-hb04 18button pendant.
> 
>
> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=73829e047a2074a0da10a7cdb0cb2c3284ee92d0
> 
>The configs, located at configs/sim/axis/ja_tests/xyzx_mpg are simplified
>in order to focus on config items that affect joint/world jogging 
> functionality:
>  a) position commands are connected directly to feedback
>  b) immediate homing is used (no home switch logic is included)
>  c) machine position limits are set to large numbers
> 
> The configs and a README can be examined at:
> 
> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=tree;f=configs/sim/axis/ja_tests/xyzx_mpg;h=0f6bcb48131beca706ce51ca237173af3ff5a1ab;hb=73829e047a2074a0da10a7cdb0cb2c3284ee92d0
> 
> 
> 5) To use the joints_axes12 branch, you can make a RIP build from source
>or use a 'scratch' deb from the buildbot.  Instructions for buildbot
>are at :
> http://buildbot.linuxcnc.org
> -- 
> Dewey Garrett
> 
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users