Re: [Emc-users] Emc-users Digest, Vol 198, Issue 2
On 10/1/2022 4:55 PM, emc-users-requ...@lists.sourceforge.net wrote: Message: 1 Date: Sat, 1 Oct 2022 09:23:44 -0500 From: Thaddeus Waldner To: "Enhanced Machine Controller (EMC)" Subject: [Emc-users] Intel NUC Message-ID: Content-Type: text/plain; charset=utf-8 Hi, I am looking for a viable alternative to the Raspberry Pi. I need this to fit inside a pretty small enclosure, so I can?t accommodate a much larger size than the Pi. Has anyone tried the Intel NUK products? Thaddeus - I use them all the time; I have about 150 of them (with large touchscreens) deployed in place of ipads for public kiosks. I also use them for LCNC; their best features are typically removable PCIe wireless cards and real SATA interfaces. I stay with wired network (machine LAN such as MESA cards are on the native eth port) and comms LAN (internet, data servers, etc are on a USB-ETH adapter). The wireless chipset is random based on the platform, and sometime drivers don't work. The biggest problems I've had is that if it was prior-installed with a WIN environment, wiping the drive and simply installing LCNC from usb will not yield all the USB ports active - so you have to go hunting through the BIOS to manually enable those. It is quite happy in UEFI mode or legacy mode, your choice. I *prefer* to stick with the core i7 units, but I do have a couple of i5 and (Beelink? amd and rockchip) units also doing the same, just with a slightly lower response. Servo performance is quite acceptable, jitter is all over the map, so of course testing in your use case is warranted. I also stay clear of any that have dual HDMI ports - they seem to fail at the hardware level more often (irregardless of the OS that's running on them.) I don't use them for software stepping, so cannot speak on that particular topic. Worst part is dealing with the 19v power supply - they are often intolerant of anything but their own power bricks. Ted. -- This email has been checked for viruses by Avast antivirus software. www.avast.com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Press Brake Gui, was: Re: Variables for instantaneous transit vector, from python?
Date: Tue, 26 Apr 2022 09:52:11 -0700 From: "John Dammeyer" To: "'Enhanced Machine Controller \(EMC\)'" Subject: Re: [Emc-users] Press Brake Gui, was: Re: Variables for, instantaneous transit vector, from python? Message-ID:<067901d8598d$f9b466c0$ed1d3440$@autoartisans.com> Content-Type: text/plain; charset="UTF-8" Not having seen the press brake I'm curious about the need for back gauge up/down setting. Why would a press brake even have this? Is it because the bent section behind the press may be up at an angle and therefore miss the back gauge? If so, how much movement is there in the up/down direction. Inquiring minds... John John - not all brakes do; some might only have manually adjustable t-slots, or nothing at all. This particular model had front-rear travel automated (what they and we called "X"), a vertical travel automated (which they and we called "Z") - that also had additional "flippers" with a manual micrometer adjust so you could effectively do tramming (or even tapers to a certain amount), and then the ram itself which they called Y. The reason for this is that the tooling meetup point isn't/wasn't standardized - so you might have dies that are 4" tall and a punch to match - or you might have a die that is only 2" tall and use the same punch, or that same short die and a longer gooseneck punch to get into some weird area with little clearance. When you start playing with different meetup points, or progressive bends that don't have the material going in completely flat, then being able to adjust where the backgauge flippers touch vertically is also helpful. On my personal press brake, all my dies are 2" tall, and apparently all my parts start flat, so the meetup is always going to touch there - which is probably why the manufacturer didn't bother to do much more than a fence on two steel rods. TH. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Press Brake Gui, was: Re: Variables for, instantaneous transit vector, from python?
Date: Mon, 25 Apr 2022 10:40:02 -0500 From: Earl Weaver To:emc-users@lists.sourceforge.net Subject: Re: [Emc-users] Press Brake Gui, was: Re: Variables for instantaneous transit vector, from python? Message-ID:<956e40f7-92a0-34ba-b8fe-41248738c...@frontier.com> Content-Type: text/plain; charset=UTF-8; format=flowed -Ted, ?Just to comment on the pressbrake setup Not meaning to confuse from the thread being hijacked, but since there appears interest, I have also posted up the source project for my press brake iteration on the form (I don't hang out there too often), but your are welcome to it - all disclaimers apply: https://forum.linuxcnc.org/show-your-stuff/45716-vertical-press-brake-interface-and-comp (On a side note from my original posting for this, I was able to get my sphere-4points functions working as well as vector capture to determine contact direction - and although it doesn't really have much affect at the thou level (0.001") - it has shown to be a BIG difference when you hit sub tenths/micron. I'll be stealing the Reneshaw TP6 unit from work and putting it on my CMM to cross-test, but with manufacturing tolerances what they are, having more corrective values available is definitely worth it. Might be a reason why opening the "Advanced" tab in MCosmos shows over 200 corrective touch point calibration options...it's a huge matrix.) Regards, Ted. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Press Brake Gui, was: Re: Variables for instantaneous transit vector, from python?
Subject: Re: [Emc-users] Variables for instantaneous transit vector from python? (long) Message-ID: Content-Type: text/plain; charset="UTF-8" Hey I won't be much help but I would love to see how you did a break press gui! Andrew - I really do need to put together an entry for the wiki on this - we haven't quite given it the "full wrap" yet; it got the the point of daily supervised testing but stalled at that point (date: Dec 2018, I bet you can guess why) - however I did upload a screen cap from it at: https://pasteboard.co/nyWk9elvzxj7.png if it's of interest. The main points were to emulate the existing nomenclature of the press, so the vertical ram is "Y" (not R or X, for instance), and the two back-gauges (X and Z, also by those names originally) were servo driven. The Ram itself in this application was hydraulic with a Vickers proportional valve (0-10v control) and a glass scale attached - so it turned into a servo axis as well. We initially shied-away from trying to drive the valve in that tight of a loop, because we thought the system might cavitate, but it responds really really well that way. Way better than simply up-fast/down-fast/slam-stop! This project had about a dozen different (less than successful) approaches but the production version uses a more streamlined custom component that handles only safety and logic rather than motion control. (Our first attempt was to build a comp with full motion control, but it turned out to be too jumpy) - so the motion is actually controlled by triggering a couple of g-code files. Jogging or manual single bends are straightforward jog implementations, semi-automatic is the daily-use feature that the operator sets waypoints and times - so we have ngc files for ram down, ram dwell and ram retract that reflect that. Although there is a plan for full-auto, we haven't bothered to implement the fully-auto feature, which due to the change in our comp file got simplified to just plain old g-code that they would write. We skipped on that due to operators not being interested in that level of complexity. They also didn't seem interested in wizards for taking material, knowledgebases, k-factors, tooling details, and building numbers - they just wanted to run the ram down to the number they set and keep repeating. Still a very hands-on type of process for them. We took graphic and layout concepts from the original operators of the machine (it was an Accurpress 25 ton unit with a win98 control), as well as other shop operators using the current generation control on a larger unit but intentionally not wanting to copy it verbatim - as it turns out a number of the operators liked our different layout. Ted -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Variables for instantaneous transit vector from python? (long)
ent? I have examples for single arrays (using the dotted notation) but my first pass on doing multi-dim arrays using that type (and simply by double dotting) was not successful. (I am comfortable in c++, my python and ansi C is less refined...so variable typing knowledge is google-fu dependent) For b) the intent is to be able to create smaller fast-run components such as: "cmm-sphereo-from-4-points" - which takes in 4 coordinates and returns center plus radius - note there is no approach vector info on this one, it's 4-xyz's in, and 1 radius, 1 xyz out. "cmm-spherotouch-center" - which takes current machine coordinates, known center reference coordinate, known radius (from above), the approach vector coordinates and returns a difference which becomes an offset for the calibration table. "cmm-coord-vector-offset" - which might take the approach vector, the tool/stylus number, have to lookup a tool/offset table for calibration data and then returns a single corrected xyz coordinate "cmm-3pt-inbore" - which might take 3 xyz corrected from above and calculate an inner bore radius and center "cmm-6pt-inbore" - which might do same as above but finds an evolving tolerance band based upon iterating through elements 1,3,5 then 2,4,6 -(possibly more combinations) etc returning same as above but largest fitting result and smallest fitting result. -and so on, which would also then permit creation of wizard-based programming in the gui to create measuring recipes which could be saved, edited, recalled, run, data output, etc. The important thing to notice is the requirement for many multi-dimensional data values The functional result would be to: a) first use a probe of zero-size - not physically possible, but lets substitute "really pointy". We can then calibrate the system to a known sphere, eg a precision tooling ball, and those first captured coordinates can then be fed into the sphere map to give us a confidence on the size of the ball and its position. This is not really part of the calibration procedure, but just to ensure that our basic programing understanding is correct, and that we can actually figure out where the center of a sphere is. We are restricted to points on the sphere the probe can reasonably access, but hitting 40% on top is quite feasible, assuming a vertically mounted probe. b) confirming the sphere properties, now we have a known/accepted center position and radius, which we can now move to a non-zero-size stylus (real probe ball) and using that known sphere data plus the approach vectors, back-calculate the offset and stuff it into a calibration table (note that this also takes into consideration the probe actuation offset since it is unique to the approach vector). We have made an assumption that the tooling ball is precise, and that is an acceptable assumption. We are not assuming the ball is mounted in a particular symmetric location, which is what a single radial offset does. c) now with approach vectors and a "Triggered current machine coordinate" we can now forward-calculate a feature coordinate. I don't need to know right now if it is inside a bore or outside a boss, it's just the "real" world coordinate of some physical transition from void to part, but we also happen to know the travel vector from void to contact as a side-effect, so we could infer inside or outside based upon if multiple approach vectors would intersect on an internal or external virtual sphere d) now we have datasets to work with, whether that next step is setting up a virtual work plane, or actually getting coordinates to define a hole. There are other math items like what is the best fit for an approach vector that is close but not exactly as calibrated? That is important too, but baby steps, right? Thoughts and opinions appreciated, Thanks, Ted. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Fwd: Requesting a short history review, if you'd be so kind.
s PID module config is clearly outdated. So here's the big question - is there some major change that would prevent me from using the Mesa stepgen mode 0 (position) without the PID and use the glass scale as the feedback source? Is there a change to the motion planner that doesn't try to get the position to track continuously anymore on its own, and is that why the PID is in place? The PID just seems to be a clunky insertion just to force the stepgen to run in velocity mode, so unless I completely missed the reasoning, I'm not sure why the extra effort. Much obliged, Ted. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] SSD reliability
I'm quite partial to traditional 2.5" SATA SSD's; I have about 30 servers with SAS/SATA slots running either Kingston or Sandisk 3Gb/s SSD's in 480Gb capacities. My home SAN runs 20 x 1TB SSD's (also Kingston) and if I rummage through my gig bag, I'll probably find half a dozen 1tb M2 SSD's in sata/usb3 cases. After about 6+ years in 24-7 run capacity (yes, servers do get rebooted and wiped/rebuilt of course) in effectively webserver / asset server /db server setups - meaning lots of writes, I have yet to have a 2.5" 3GB/s SATA ssd fail. Conversely, those "ultra-awesome" Crucial Micron M2 SSD modules I have had fail on 4 separate occasions - all of them within "warranty," and Crucial was not able/willing to RMA any of them - completely lousy customer service, which tempted me to just "buy and replace" through amazon (no I didn't, morally incorrect, but tempting). I also have some of the hybrids (both early Hitachi, whatever Apple was using in the early mac pro tubes) - many of those have failed, so I avoid hybrids like the plague, even if that new Fire series from Seagate is touted as the next best thingfor full transparency, I do have another SAN shelf with 24 1TB 2.5" traditional spindles (because it's an SAS-only shelf without interposers) that has been a solid performer for a long time - probably up 5+ years now, the only time off was moving the server racks and power failures. It's a Netapp shelf, so somewhat surprising that it has held up so well (nothing to do with the drives however). Which just goes to show that mileage may vary wildly. I could have a dozen drives go out within 5 minutes of hitting send, or not. But for power savings and speed*, and not having to worry about what happens if a server is mounted directly on top of the UPS stack, or how the drives get transported, SSD media is a benefit in my book. (* - my server installs have shown to run faster against the default SAS 72GB slow drives that my servers come with - some folks have shown that SSDs can be slower than fast HD's with specific testing, and that stable platters consume less continuous power than idle SSDs during initial writing. My power bill tells a different story.) Cheers, Ted. ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CNC Press Brake at TXRX Labs
Chris - it must be press brake season! I've been working on retrofitting an Accurpress 25 ton unit (about the same size as yours) with a Vickers proportional valve for the hydro and a 2 axis backgauge. I originally built a (really long) component that hard-coded the workflow, but about a month ago rewrote everything once I was able to tune the proportional valve loosely enough to act as a servo. Realizing that CNC builders years ago (like Moog) figured out servo hydraulics, I was actually surprised that it took so long to trust it in a servo mode than just an open loop floating ram. (My original testing gave so little confidence that it could be trusted that I didn't focus on it - however it just never "sat right" running as an open loop positioner that I ended up just getting lucky to trying again.) To David's comment - "press brake friendly" is a real thing - in the shop I'm doing this work for currently, they are a mix of CNC, form and weld folks; the CNC guys know g-code and automation, the others not so much. The original control for this press (which was Windows based and died horribly despite a pacemaker and multiple surgeries) while it was a 3-axis control, looked and acted unlike LCNC-Axis, for instance. It was a well-designed Mattel or FisherPrice experience. Axes references like X,R1,R2 and Y for a vertical traveling ram make perfect sense to a press op, but to give them letters of X,Y and Z would completely mess them up. Little pictures in the right spot help a lot, and there's really no use for a backplot. I'll try and get a quick vid up of the version I'm working on too as a comparison, and eventually post the glade, python and configs for review. BTW Chris, kudos on the slick shoe stops for repositioning the die between the multiple operations - you know your craft well! Ted. On 2/5/2019 7:03 AM, emc-users-requ...@lists.sourceforge.net wrote: Date: Mon, 4 Feb 2019 21:47:25 -0600 From: Chris Kelley To: "Enhanced Machine Controller (EMC)" Subject: [Emc-users] CNC Press Brake at TXRX Labs Message-ID: Content-Type: text/plain; charset="UTF-8" I've been working on retrofitting a CNC press brake at TXRX Labs in Houston, TX. ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] O subroutines limited to 4 parameters, not 30?
Greets - I'm calling an o sub from python and need to pass 8 parameters to it. Per the docs, I'm expecting to be able to pass up to 30 parameters, not just 4 Whether I make the call in python, or just in Axis' MDI window, I get the same response at the 5th parameter "Interp_error Bad Character '[' used." I can replicate this with any o sub (as external file) and it always fails on the 5th parameter, eg: 300.ngc: o<300> sub (DEBUG, I actually have 8 params: [#1] [#2] [#3] [#4] [#5] [#6] [#7] [#8]) o<300> endsub and calling it via python or just simply in Axis' MDI: o<300> call [1.0] [2.0] [3.0] [4.0] [5.0] [6.0] [7.0] [8.0] will cause it to fail.. Calling only o<300> call [1.0] [2.0] [3.0] [4.0] will run, but of course a full routine is missing parameters 5-8. Running (Axis) 2.7.0 on Wheezy from LiveCD install. Any help appreciated. Thanks, Ted. ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] LCNC Glade Python State Machine
Greets - I'm trying to write a machine-specific glade gui and I need to
create a multiple step jog sequence while a button (and/or preferably a
HAL pin) is true.
The jog info and my test jogging to a single target value works fine in
my glade panels, however the "if" tests (trying not to set up "while"
blocking) don't seem to actually get tested while the glade button is
depressed for the multiple target points version.
For example: a glade panel contains 3 spinners (feed, target_a,
target_b) and a button (go), and there is a working basic environment
for axes and feedback. Assuming the current position is 0.00, the
target_a is 1.00 and target_b is 2.00, and feed = 50if I have a
function and assuming we are in linuxcnc.MODE_MANUAL:
def go_pressed(self, widget, data=None)
feed = self.builder.get_object("feed").get_value() # which
comes from the glade panel as 50.0
target_a = self.builder.get_object("target_a").get_value() #
which comes from the glade panel as 1.00
target_b = self.builder.get_object("target_b").get_value() #
which comes from the glade panel as 2.00
if feed > 0: # test to make sure there is a motion feedrate so
we don't stall forever...
self.s.poll()
position = self.s.actual_position[0] # assuming X axis for
testing
if position < target_a: # tests that position is less than
target_a, where we are going to jog positive to get to target_a
self.c.jog(self.cnc.JOG_CONTINUOUS, 0, feed) # assumes
joint 0 for testing
elif position < target_b: # we should fall through to here
once position = target_a, but we DON'T!
self.c.jog(self.cnc.JOG_CONTINUOUS, 0, feed / 10) # note
the div 10 for "really slow".
else:
print 'All done'
self.c.jog(self.cnc.JOG_STOP, 0) # and stop motion even
if the button is still pressed, yet this also doesn't get tested!
so the above has a companion go_released function for completeness that
I didn't show (the basics of this came from John Thorton's excellent
tutorials - thank you , BTW) -- the function above is the crux to get
right first.
I understand the concept of non-blocking routines from other aspects of
my career, so have been cautious to avoid a test like "where" that could
potentially stall the python script. What I am observing with the above
(and about 5 or 6 variants I tried without success, including external
functions, mdi sequences, wait_for_complete - which does block etc) is
that if I keep the button pressed the routine keeps running, it seems to
get stalled in the first "if" test and never jumps out. If I release the
button, motion stops as expected - and if I'm lucky to do it between
states, the "if" statements get re-evaluated, and the 2nd test will get
tried. For example, if I press button and I release before position gets
to 2.00, the re-press, the feed will be 10% - as required, but it will
never re-test to find position >= target_b. IF I release and re-press
past 2.00, then it does fall through to the final else.
I had originally built this with a very long (and ugly) halcomp. Is
there a clean way to keep this all in python, or does it need a
companion halcomp, and if so, how does one pass data between comps and
python?
Thanks,
Ted.
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Axis -> EMCMOT -> Yaskawa SMC-2000
Greets - I have a press brake I am working on rebuilding; eventually we will be converting it over and using LCNC to fully control the system, however due to request, I am going to [try] using LCNC only as the graphical front end to send commands to the existing Yaskawa SMC-2000 motion controller. (The press's original Win95 pc has failed after a number of extended rebuilds over time.) The SMC 2000 takes commands over a serial port (typically a 2 letter command with a couple parameters) and the command protocol is well documented. For my purposes, the most common command will be "move axis n to position xxx.xxx with feedrate yyy.yyy and stop", of which the SMC 2000 will take care of without further intervention. I have used serial port devices in userspace in prior works (typically PIC or atmel microcontroller low-speed interfacing) that doesn't require any realtime priority. The sending of a command also isn't a high realtime priority as with a pressbrake, there really isn't co-ordinated axis motion like with a cartesian machine. (Life is much slower with a press brake). My concern is with the readback of the position data. I'd like to use the SMC-2000's position variables and feed them into Axis' DRO (preferably right into axis.n.motor-pos-fb) however it would be at a relatively slow rate - perhaps 2-5 times per second. With an update rate so slow, I expect my (virtual) following error will become huge and cause a fault. The actual following error doesn't exist, just the perceived deviation between DRO updates. Any recommendations on getting around that problem? Just a huge following error allowance, or is there a cleaner method to omit EMCMOT or certain other components to simply accept a motion command from axis, and accept an occasional position feedback? I will be washing the position command through a custom userspace component to translate the command into a proper string for the SMC 2000, as well as convert the feedback value to something Axis can use. Both the command and feedback update rates will be at the mercy of the userspace update loop of course. The SMC2000 controls feedrate, as well as has its own interlock and e-stop loops for safety. If anyone has used an SMC 2000/4000 platform before, I'd certainly appreciate any advice that comes my way. Regards, Ted. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- 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] LCNC 2.6.4 (Release) - Replace Bundled Mesaflash utility?
Greets - I've been playing with the Wheezy/2.6.4 release on the Live ISO and intended to move it over to an older 2.4 machine while upgrading hardware in the process. (old system: Mesa 7i43) The target machine will have a Mesa 7i90 via EPP. The included samples do not run, unfortunately. Peter assisted somewhat, in that there is a typo in the 7i90.ini file where the board name needs to have a capital I, but that only gets us partway. The version of Mesaflash utility bundled with the install is 3.0.0-July which has the '--list' option still available. When executed via script or CLI, it throws a Segmentation Fault. Downloading the current ver 3.0.0 that does NOT have the '--list' option (time to change the version numbers, isn't it?) builds and executes, and successfully finds the 7i90 board attached. Apt, however still believes the old version is current, so even removing and force reloading the package won't update it. LCNC insists on using the old version when it finds it, and balks when it was force-removed. I saw an old thread on gmane about this, but it didn't appear to get resolved. I realize this is a more generic Linux question overall to some extents, but it's specific to the LCNC build: it's not how does one make the package, but WHERE should it be extracted to, made from and made to, so that LCNC uses it? The loading of the hm2_7i90 driver appears to depend on running mesaflash (according to dmesg), so there's no moving forward it seems until I can resolve this. Thanks, Ted. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] LCNC 2.6.4 (Release) - Replace Bundled Mesaflash utility?
Peter - dmesg dump at: http://pastebin.com/2uZJV2Gi but the core is an inconsistent Module Descriptor What led me to believe Mesaflash was important is that when I had it installed, and prior a force removal, it would load just after the RTAI[math] section and give two lines of segmentation faults. Seemed logical at the time that perhaps it was trying to perform some form of lookup (like probe_parport). May have just been coincidental. Additionally, the sample files don't include a 'loadrt epp' reference, per the man pages - is this necessary? Thanks, Ted. On 11/21/2014 10:10 AM, emc-users-requ...@lists.sourceforge.net wrote: Message: 4 Date: Fri, 21 Nov 2014 07:01:12 -0800 (PST) From: Peter C. Wallacep...@mesanet.com Subject: Re: [Emc-users] LCNC 2.6.4 (Release) - Replace Bundled Mesaflash utility? To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Message-ID:pine.neb.4.64.1411210602010.11...@freeby.mesanet.com Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Fri, 21 Nov 2014, Ted Hyde wrote: Date: Fri, 21 Nov 2014 07:26:21 -0500 From: Ted Hydelaser...@gmail.com Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To:emc-users@lists.sourceforge.net Subject: [Emc-users] LCNC 2.6.4 (Release) - Replace Bundled Mesaflash utility? Greets - I've been playing with the Wheezy/2.6.4 release on the Live ISO and intended to move it over to an older 2.4 machine while upgrading hardware in the process. (old system: Mesa 7i43) The target machine will have a Mesa 7i90 via EPP. The included samples do not run, unfortunately. Peter assisted somewhat, in that there is a typo in the 7i90.ini file where the board name needs to have a capital I, but that only gets us partway. The typo I found was a capital 'I' in the BOARD= line This seems to have been fixed in the latest ISO The version of Mesaflash utility bundled with the install is 3.0.0-July which has the '--list' option still available. When executed via script or CLI, it throws a Segmentation Fault. Downloading the current ver 3.0.0 that does NOT have the '--list' option (time to change the version numbers, isn't it?) builds and executes, and successfully finds the 7i90 board attached. Apt, however still believes the old version is current, so even removing and force reloading the package won't update it. LCNC insists on using the old version when it finds it, and balks when it was force-removed. I saw an old thread on gmane about this, but it didn't appear to get resolved. I realize this is a more generic Linux question overall to some extents, but it's specific to the LCNC build: it's not how does one make the package, but WHERE should it be extracted to, made from and made to, so that LCNC uses it? The loading of the hm2_7i90 driver appears to depend on running mesaflash (according to dmesg), so there's no moving forward it seems until I can resolve this. The driver does not depend on mesaflash, and works for me with the included hm2-servo/7i90.ini file (after I fixed the typo) What exact error message do you get? -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] MPG pendant
Billy - I have each of these. The red button one was the first I picked up over a year ago, before a lot of the heavy lifting was being worked on for the HID interface for LCNC; I thought perhaps I would find some time to reverse-engineer it, and worst case, I could give it to a friend of mine who uses Mach3. I couldn't get it to set up with Mach3 at all, neither could my friend, and it refuses to connect with the current HB04 components. Your particular ebay link states Does not work with Mach3 and that should be a warning, although the one I got didn't disclose that. I can't say if it's the same problem, or if the unit was defective, I couldn't even get the HID descriptor to decompile, so perhaps I just received a flaky unit. On the other hand, the silver power button version (actual HB04) I picked up about 6 months ago, worked perfectly right out of the box (profile 2 for the menu layout, I believe), I now have a second one, and both work fine simultaneously, in a shop that has 3 CNC machines, lots of neighboring industrial equipment, and even an RF testing lab a few doors down. I get a very solid 50+ foot range, it's just a matter of ensuring the right remote stays with the right machine. I'm typically the only one using the pendants, so I have an additional level of safety where there is typically only one in use at a time. Plenty of traditional control and estop on each system remains. I have no idea how each pendant is paired to its receiver, whether it's just a factory-side pairing, a serial number or GUID, or just luck from different batches at different times. I agree that a wired pendant is often more appropriate for daily operation because it restricts the operator physically, although a wireless one I've found to be very handy and I believe safer particularly for maintenance or during the building of a machine, to not be hindered by cords, where you can just place the pendant on anything steel (the back is magnetic) and it will stay there, and not accidentally get pulled off by the dreaded coily cord syndrome. (Admittedly, the cabled USB version of this pendant isn't coily, which I consider a good thing). And if you forget it there, the pendant is not likely to be damaged, just perhaps your pride. Kudos to Fred, Seb, Dewey co for great work on that component inclusion. It's clean, stable, and I think just the right amount of thought for using a USB interface for this purpose. Regards, Ted. On 2/7/2014 11:55 AM, emc-users-requ...@lists.sourceforge.net wrote: -- Message: 4 Date: Fri, 07 Feb 2014 11:49:19 -0500 From: Billy Huddlestonbi...@ivdc.com Subject: Re: [Emc-users] MPG pendant To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Message-ID:52f50e8f.2070...@ivdc.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed These look interesting.. I might get one.. Only issue I see is.. all the ones I can find are the 18 key version.. Which hasn't been tested with the driver according to the Wiki. Also, Ebay has several of which that have a different face plate.. Ones with Blue and have Macro.. I like the 16 Key better.. Has Step Mode instead of and says X Y Z 4 Spindle Feed. Looks like the newer one Has X Y Z Spindle Feed and Something Else ? Also like the silver all metal button vs the cheap looking red one.. Can anyone comment on the different ones ? On Ebay http://www.ebay.com/itm/New-NCStudio-CNC-3-4-Axis-Wireless-Handwheel-Manual-Pulse-Generator-MPG-Pendant-/171161089364?pt=BI_Heavy_Equipment_Partshash=item27d9fef554 One with BLUE keypad -- Has the nice silver Button. http://www.ebay.com/itm/2-4G-Wireless-Mach3-MPG-Pendant-Electronic-Handwheel-For-CNC-Mac-Mach-3-4-Axis-/390713482854?pt=LH_DefaultDomain_0hash=item5af8569e66 -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Structs Unions with Comp
Greets - can Unions of custom types be used in a comp? (actual .comp for
use with the Comp generator, not a native c file)
I seem to have a handle on structs, and I can declare a union that
doesn't get its members used which doesn't throw an error, but any use
of it faults:
portion from .comp file:
option sen sensor_data;
snip
typedef union
{
bool s0;
bool s1;
} sensor_data;
will not throw an error when Comp'd.
However, attempting to access sen.s0 or sen.s1 faults with 'sen' being
undeclared.
Ideally, the end result is a 12-bit wide word accessible as the low-end
of an s32 or via individual bits, thus the sensor_data union would
actually be a union of a 12-bit type and an s32 type.
I went through a bunch of other comp files to see if I could gloss any
examples buy came up with zip. Are there any recommendations on how I
may accomplish this?
Thanks,
Ted.
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT, Pic controller? needed for high school play
like a combination lock; two channels need to be on with one off, then the arming channel is turned on, then the fire channel is engaged. That's 5 channels, but it's the best use of channels I've had when more intelligent pyro controllers are not available. On easier things like confetti cannons, for instance, an arming and a fire channel are really all that's necessary - only when both channels are on does something happen - they don't need to be consecutive, just kept mentally separate (example with the confetti cannon: the fire was an r/c servo on a cam to engage the trigger, but the arm channel was actually a relay that controlled the power to the servo. If fire was triggered nothing would happen. Arm and fire had to happen for it to go off.) These methods typically preclude an operator from accidentally triggering a device by mis-programming or being in the wrong mode, as well as lost or noisy signals generating false control data, and to act as a hands-off when techs are preparing or loading the devices. It is amazing how often a single effect channel (like fog) accidentally gets included in a cue or a chase due to a typo Regardless of which path you take, it will be important to set time aside to play - whether that be learning a lighting console, or debugging timing on your PIC device. Consider the amount of time or need to implement cue changes - a PC on the ground may be more comfortable to make late changes or experiments with than having to break out the PIC programmer As one last sell point, the DMX modules you'd get would be rather generic - that means you have a generic asset that could be used in the future. I don't want to undersell the potential experience of the students getting involved in the electronics of developing on a PIC, but you may get better response from the budget folks if you can develop and teach a theatre-centric technology experience. Regards, Ted. On 10/15/2013 10:32 PM, emc-users-requ...@lists.sourceforge.net wrote: Subject: [Emc-users] OT, Pic controller? needed for high school play To: Enhanced Machine Controller \(EMC\) emc-users@lists.sourceforge.net Message-ID: 1381876486.79370.yahoomailba...@web140506.mail.bf1.yahoo.com Content-Type: text/plain; charset=us-ascii I need help First let me say i know zero about controllers. I am building the chandelier for the high schools performance of Phantom of the Opera. I need to remotely control the lights, two actuators and some spark emitters. The chandelier will sit on the stage all crumpled up as the play starts it will slowly raise and the lights will flicker and all come to life as the chandelier reaches is apex. Later in the play we will lower the chandelier a few feet and shake it with the actuators, flicker some of the lights and set off the spark emitters. Everything need to run off a 12 volt battery. There are: 48 LED globes. Some types of spark emitters, not sure what I am using yet, don't want to set of the smoke alarms Some type of linear actuator to pull two tiers of the chandelier together to shake it. Open to suggestions. Run everything but the winch, remotely. I'm told I need a pic controller for this and the engineer where I work says he'll put it all together and program it, but I need to find it and buy it first. Any help I can get on this will be greatly appreciated. Bruce -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT, Pic controller? needed for high school, play
On 10/16/2013 6:19 AM, emc-users-requ...@lists.sourceforge.net wrote: But plays don't run to split second schedules. Since remote control is snip Erik Humorously, of course: Um, yeah we do - locking to time code (30 fps) is a pretty common occurrence. What used to be a hard line of high school plays are paper costumes and a followspot versus the good toys are reserved for Broadway has almost disappeared. Although I was really surprised too the first time a community theatre project required a media server for the show.the world has been changing and technology has infused itself everywhere! Ted. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] MTConnect
Kirk, I think MTConnect would be a great addition to LCNC; I started to play with the building of an adapter shortly after MT was released at IMTS some years ago, but quickly got stalled. I have an MTConnect-compatible agent/adapter on my Mazak 410 machine, and it's pretty much a duplicate of the basic info (DROs, program/run status, spindle and axis loads) only. It is NOT intended to be a remote-control platform. It's not much more useful than that, in a single machine installation, however it's not MT's fault, it's the limitation of the agent. I do occasionally run a terminal server window instead (the Mazak uses Win XP embedded for GUI control on top of the Mitsubishi motion platform) - which for all intents is just as capable as someone who already runs LCNC in a remote xwindow. (BTW, for the top level overview, MTConnect spec defines three levels of soft-ish-ware; the adapter (optional) is the hard worker part that is specific to the machine and does the unification of useful data; the agent, one level up is the middleware, and effectively the webserver or dbase; and the client is the top view that actually displays or parses the useful info. That's the really short and vague version.) I was playing with building an MT adapter/agent for my lathe, (agent would just be httpd to start) that would basically replicate the information that the Mazak would deliver - this is where I started to run into universal problems with development; since LCNC is so modular and adaptable, there would be machines that would have some features and lacking others (spindle load % for example) - so writing a comp to cover everything became too daunting. That is the best and the worst of MTConnect, and by design; the adapters (or more often adapter/agent combos now) are specifically deployed unique to your machine (or at least unique to your machine family) and it unifies the info for serving up to the client viewer/app/dbase. Since MTConnect spec information is free, it's certainly of value to expand one's knowledge. I was hoping to contribute to the LCNC community with this type of development, but the challenge so far has been that it would be like needing to have an additional HAL layer of connectivity just to accommodate all the possibilities of HAL itself. The XML definitions by the adapter would accommodate where the data would go to, what the data was, and how it was formatted, but the spec doesn't allow for additional info, such as where it comes from - ie the HAL pin it would be connected to, and at that point I had lost too many brain cells to spend more time writing something that couldn't be extended. It might be feasible to just accommodate all the general DataItems in the dictionary, expose a ton of pins to the LCNC integrator, and if not useful or connected, they return null or 0; but when it comes to the tool cutting info, however, it just gets plain messy. In regards to Rockhopper, IIRC, that was more than just a status window, it was intended to be a [complete] doc builder on the LCNC installation (?), but did have a status window, that for simplified intents, would be similar in result. Perhaps that is the better starting point, in that the same variables that are exposed that RH was referencing are the same ones used to build the initial MT adapter. If there are some that wish to form a collaboration on something like this, I'd be happy to contribute, though! Ted. On 8/30/2013 12:30 PM, emc-users-requ...@lists.sourceforge.net wrote: Is MTConnect something worth learning more about? Has anyone used it with LinuxCNC? http://www.amit-deshpande.com/2008/06/mtconnect-live.html -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/ -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] 3d scanner
with a joystick), or by script/conversational, program the machine for repetitious tasks. Even macros or sub-programs within a semi-auto task. (We can even, if we choose, make a probing program in g-code for probing in LCNC, so not too unrealistic right now). The best I've seen so far (but not yet in LCNC) imports a 3d model of your finished part, or if in-process, a partially finished part, and generates a probing boundary plus specific parametric checks (like diameter and depth of a hole), based on a combination of the raw part outline and user input. That's where I consider the logic to be in the right place - I don't think it's necessary to take the human all the way out of the equation, sometimes the grey matter still exceeds the silicon. Ted. On 12 June 2013 13:52, jeremy youngs jcyoung...@gmail.com wrote: not exactly just compare it to an iges file that will never change . or other parametric solid Going from a point-cloud to a parametric solid is not even slightly easy. However, in this case I guess that you could create a virtual point-cloud from the IGES file for point-by-point comparison. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Why is LinuxCNC Great?
Like many others, I started with a very old Mach3 (bless Art) on a Win32 system, controlling steppers on a converted HF mini mill. That still runs, btw, mostly for teaching and demos. It was a paid copy, although most of my work would have fit within the free version (# blocks limited - 1000, IIRC). About $90, I was really drawn to the style and the way you could change the interface - the concept of servo drives were way too expensive, thus I was in a comfortable place. It was closed-loop-feedback that made the change, eventually. First, I appreciate the open flexibility of the HAL. I use (used EMC2/) LCNC for a variety of things - and the only 3-axis-mill-thingie I have that runs it is that original HF mill! LCNC is operating my Tsugami lathe, (still being retrofitted, btw - it's a never-ending project of upgrades, even though it runs production parts right now), it's gone onto a couple plasma tables for clients, a CMM, some printers (non-3d), a Puma arm, and a ton of single or dual-axis automation - all of that simply possible due to HAL. Right now I'm building a custom comp set for a 5-axis press brake. Not a lot of cross-platform press brake controls out there - that's a world of custom closed-source development, if it's enough to even be considered Development. Second, but not far behind is the co-operation of the community. I've worked on repairing or installing Mitsubishi, Fanuc and and Siemens controls - mostly because that's what a client had or demanded due to brand name label desire, but I still prefer LCNC. If the demand required me to be a fully-accredited Fanuc integrator, complete with all open maintenance contracts, I'd probably have better access to information. But with LCNC, there's always someone around who has at minimum part of a solution, or will at least discuss the options - put a few of those together and you're on a really good path to success. It may not be paid support, but I don't consider it any less valid or valuable. Third, is the continued consistent development. Fanuc may release an O-series control one year, and next year tack another letter on there, and it may not be compatible with your gear, setup and config files. (Probably a bad example, the alpha channel is pretty flexible). But you could have a 5 year old EMC system with a parallel port, have that PC die, and replace it with a current PC with parallel port and be up and going again rather quickly. Or mix servos and drives without LCNC caring much. That list goes on Moreover, aside from a few (very minor) changes, when we add capability (like GladeVCP) we haven't traded it for earlier capability (xml VCP) that in doing so strands all the previous users like say, Mazak's T series versus their Matrix series. A user could follow the upgrade path if needed, but isn't forced to. Ted. On 6/13/2013 9:14 AM, emc-users-requ...@lists.sourceforge.net wrote: On 13 June 2013 12:07, Charles Steinkuehlerchar...@steinkuehler.net wrote: Why do you use LinuxCNC and what are the features you like best? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] 3d scanner
the touch probe is in 3d space given the lengths/offsets of the arm components and the encoder angles, then determines an xyz co-ordinate of the probe tip, relative to a defined home position. It then adds that xyz to a text file which I import to Rhino as a point cloud. Although I can just do generic point clouds that way, I've been separating the triggers into segments that through some RhinoScript I can join points together with lines; either open curves, or polylines based upon points (like the circle example). I then use that info similar to a SolidWorks sketch to make solids. From there, I can import a companion Iges, and through absolutely no automatic work whatsoever, rotate/move the parts for comparison. It is a grueling and manual process between pressing the button and a finished comparison, certainly an area worthy of more development. Additionally, I don't yet have automatic tip offset - so I'm careful about how I probe (0.5mm ruby ball, typically), again, something that will see more help.eventually! The framework is generic enough that it could be adapted to any digitizing arm of similar style - and if Win32/Mac/or Linux is your aquisition platform of choice, (as opposed to Android) then it can be all compiled with the indie version of Unity. I'm using PICs as my encoder counters, over a little I2C net to a master that sends out the packets of angles to the Unity App via RS232 or BT. But it's not the only way. This wouldn't really fit as the poor man's dig arm, but it does fit as this poor man's dig arm! Ted. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] 3d scanner
In regards to a depth sensor, there's a good change Aram is referring to a Kinect or the Asus Xtion (Pro Live). There's been plenty of hacker-friendly attempts for point-n-shoot capture solutions using these over the years, adding to the laser-line, and distributed-light methods. The Xtion unit retails sub-$250, so it's an expensive experiment, but a contender for entry-level scanning - but it's only part of the hardware side. The DAVID project uses just laser and distributed light methods (at current, IIRC), so not a compatible software piece. There are retail packages that speak with a Kinect or Xtion, my favorite low-cost at the moment is Manctl's Skanect, but I also like the free Faro (tickler), Scenect. There are of course others. Most are Win32 or Win64 offerings only. OpenCV is often used as a framework for open-source attempts, so not all hope is lost if someone wants to try In a commercial environment, I do create and provide difference scans of parts in some cases as required by a client, but it's pretty rare. A big thing to note about volumetric scanning versus probing is that scanning gets you a profile, and it takes a lot of time; probing gets you parametric data and can be extremely fast. To implement an in-process scanning technique effectively, I would have to do it in between machining operations - not just at the end, as one part feature may be dependent upon the next, such as a helical thread inside a drilled then bored hole) - and although most faults like that would cause tool damage, I wouldn't want to write part programs so that each individual feature is a separate operation (that's what automation is supposed to make easier!) - thus the logic decision as to how to fix the problem won't exist. Even if it did, one would have to scan a known-good-master at each step of the production for the test scan to reference against. If you want accuracy, measuring scale on a single volumetric scan is near impossible. You need to have many angles and views stitched together to see past obstructions. Any imperfection in the part, including unintended, is recorded [perfectly]. Furthermore, the scanner is unable to understand chips, swarf or coolant sitting on the part - it will look like a fault in the part and raise an alarm. Get coolant on the lens and your scanning is of no value. Probing, on the other hand, can be more easily automated, and directed towards achieving the stated goal - whether or not a particular feature is within tolerance. I use both laser and depth-based scanning plus probing for a variety of tasks, but only probing on my machines. I would liken volumetric scanning versus probing to the earlier implementation of a webcam (camview by pavel et al, for example, which I really do applaud) for tool-length-setting (and more) versus a touch probe. Although I'm enamored with having a non-contact tool setter, a camera is much less tolerant of mistakes or changes in the environment than a touch probe. When you just want to get parts out, the touch probe JustWorks. That's not to say that having a volumetric scanner as a tool in a machine isn't a possibility or a value, but the historical intent for LCNC not to require a 64bit 8-core watercooled machine with Cray loadbalancing (sic) makes it a difficult challenge to have it integrated with LCNC. My preference would be to have it on a separate machine as a standalone application, but load the sensor as a tool when needed. The benefit is the automation of the motion of the camera (instead of human hand) which in that aspect, would return a much more accurate result. Since the software has to chew on the scanning result, it would actually be dangerous to have this type of interruption (and I guarantee it would be an interruption) to the safety of the LCNC realtime loop. Ted. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] USB Pendant (XHC HB04)
Not to hijack the recent pendant thread, but I thought I saw scrolling past that someone may have had working the XHC pendants with LCNC? These are (rather sexy) USB or USB-Wireless units with an MPG, LCD for DRO and button pad. I picked up one of the wireless units, despite my misgivings about wireless control, more for fun with a friend who is still running Mach3 (so I could give it away if needed) - but thinking that maybe that someday I might actually get the time to see if HIDCOMP would see it. Although these are available from a variety of sellers, http://www.automationtechnologiesinc.com/products-page/mpgs/wireless-mpg-handwheel-for-mach3-controller is the most loved distributor by the Mach guys, currently. This isn't a plug for this device, as I certainly don't have it working (at all) with LinuxCNC (or even Mach at the moment) - but I'm fishing to see if someone already has Regards, Ted. -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] AXIS accel/velocity settings with other Kins
Greets - Is there a better explanation of the interaction of the ACCEL and VELOCITY settings for Axis in its' INI file? We've been working on a Puma arm which we used to have running on Copley amps in Torque mode (and a MESA card performing PWM angle output), but have moved it over to Gecko 320x amps using step/dir inputs. We're (obviously) using Pumakins instead of trivkins. The observation is that changing between joint and teleop (world-xyz) modes, the jog velocities are quite different (approximately by an order of magnitude). I would have expected that in joint mode, the _ANGULAR_VELOCITY group in the ini file[Display] section would affect this (since the axes are defined as type Angular), however it does not. Changing _LINEAR_VELOCITY affects both joint and teleop. As noted, in joint mode the jogging barely makes the machine move, while in teleop, it's about 10 times faster. That's a problem to merely bump up the velocities, as at 10x those values, the machine has problems keeping up, and faults due to following errors, so it's more prudent to keep the slider values within the correct limits. In the [Display] section, the _LINEAR_VELOCITY variables change the view of the Jog slider as intended, but it appears that the Max Velocity slider (located below it) is calculated as a function of all the [AXIS] velocity variables? Or is it derived from another hidden variable? (With the settings below, it indicated 30,000 mm/min) Is this difference potentially just a function of the Kins module? I'm running 10.04 current stable (from LiveCD install). Relevant INI snippets below: [DISPLAY] #+ Highest value that will be allowed for feed override, 1.0 = 100% MAX_FEED_OVERRIDE = 4.0 DEFAULT_LINEAR_VELOCITY = 1.25 MAX_LINEAR_VELOCITY = 1.5 DEFAULT_ANGULAR_VELOCITY = 1.25 MAX_ANGULAR_VELOCITY = 1.5 [TRAJ] #+ machine specific settings AXES = 3 # COORDINATES = X Y Z COORDINATES = X Y Z HOME = 0 0 0 LINEAR_UNITS = mm ANGULAR_UNITS = deg CYCLE_TIME =0.010 DEFAULT_VELOCITY = 60.0 MAX_VELOCITY = 250.0 DEFAULT_ACCELERATION = 60.0 MAX_ACCELERATION = 150.0 #+ First axis [AXIS_0] TYPE = ANGULAR HOME = 0.000 MAX_VELOCITY = 300.0 MAX_ACCELERATION = 50.0 BACKLASH = 0.000 INPUT_SCALE = 1.000 OUTPUT_SCALE = 1.000 MIN_LIMIT = -180.0 MAX_LIMIT = 180.0 FERROR =2.000 MIN_FERROR =1.200 HOME_OFFSET = 0.0 HOME_SEARCH_VEL = 0.0 HOME_LATCH_VEL =0.0 HOME_USE_INDEX =NO HOME_IGNORE_LIMITS =NO HOME_SEQUENCE = 0 // Axis 1 2 are practical duplicates of above. Thanks, Ted. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Usefulness - was Re: OT: 3D Printer Mods?
I think it's important to evaluate on the usefulness of a tool, within the design scope of that tool. Due to the nature of our business (fast turn, low volume, high mix parts, often called prototypes) we have a variety of tools in our shops, not just one hammer. I have a Mazak mill, a Tsugami lathe (retrofitted to LCNC), a small HF mini mill (also LCNC), a ULS laser cutter/engraver, and a Dimension 1200 FDM 3d printer, amongst other things. I use the 3d printer a LOT. We probably push about $5k in consumables a year through it. It's ABS material, relatively tough, and a good standin for passing quick prorotypes around the table. There are parts that one can draw in CAD and click print faster, not having to worry about fixturing, than one can push into CAM, create machining operations, figure out a workholding and tool strategy, monitor the cut, perform secondary operations, and hope you got it right. I do push what are considered the limits of FDM - in fact a lot of my parts are so organic in nature that the 3d printed parts become the actual production parts. An on-demand printed part 6 times a year doesn't justify creating injection mold tooling, and often where weight is an issue, cutting from steel or aluminum billet also isn't appropriate. I've used it to make single piece chain sprockets in a pinch where the needed part just wasn't available off the shelf. It ran for 5 days, which was 4 days longer than it needed to. That said, if the part demands material that isn't compatible with ABS, then 3d printing isn't appropriate. Agreed, you cannot take a micrometer to these parts and expect every feature to measure net zero accuracy. There is a learning curve to each machine on where to redraw a feature over or undersize, and to consider secondary operations. If you want a 0.3210 diameter hole, be prepared to ream it. Even grander however, is the large variety of 3d printing tools out there - I'm still very partial to SLA, but it's still incredibly expensive. (although DLP polymer is becoming reality). I've had the ZCorp powder printers, but the post-processing is exhausting, messy, and very limited in application. FDM (such as Stratasys and the extruder rep-raps) is a nice middle ground that in many cases, I can produce parts that literally just pop off the tray and go to finishing. If I needed sintering, I sent it out. All two times. What I really like though is that I can use the laser cutter and the 3d printer together to produce workholding fixtures that can hold a part for machining in the mill or on the lathe. The largest distribution of parts that come out of our 3d printer are either custom fixtures or patterns for casting. It is however very true that although the hardware or technology in many units is close to identical, the software or secondary features either makes or breaks a product. I have an early Darwin (reprap) from handmade parts, that has sat in a corner (probably smushed now) for a long time, because the software didn't keep up with the technology early on and the glitter wore off. Commercial technology came and filled the void. I wouldn't want to compare parts from the reprap to the Dimension - they're $50k apart in capabilities. The current crop of thing-o's with dual extruders will eventually catch up once builders copy the tricks that the commercial guys learned only through their own development. Some of those tricks relate to dimensional tolerances (you're adding physical fluid material, in a space that may already have material, as opposed to machining to zero, so particular decisions have to be made on the order of laying down that material and physical offsets versus cooling time). Some are omissions to simplify a product - the heated enclosed chambers that Stratasys use I feel are an essential part of the process; the open frames of repraps don't allow the deposited filament to anneal slowly and reduce the layer artifacts. You can easily tell a commercial part form a Hobby one. But that's common to all fabrication technologies. Even then, 3dp isn't a Fits all tool. Will a singular technology exist on the kitchen counter to make everything you need? Probably not. But then, I've never been one to stir my coffee with a hammer, either. Cheers, Ted. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] psu for atom boards
dave wrote: Hi all, Sometime ago I bought a D510MO to replace my aging 1.2 GHz Duron. I'm finally frustrated enough with the present cpu, etc. to actually upgrade. ;-) http://www.logicsupply.com/categories/power_supplies/dc_converters?gclid=COeJt5m4_q8CFSIHRQodoQGGHA I've been looking at the power supplies in the above link. Does anyone have experience, recommendations, etc. Further what are people using for the 12 VDC source; or is the preferred method to use a battery charger and go with one of the supplies that will tolerate= 14 V? Dave - I have a handful of the older units in service (of both the standard and wide-input variety) and the standard 12v units would literally shut down at 13.0v input as overvoltage - and that protection spec was clearly listed in the datasheet with the units. If a brick (other than theirs - I never tried their versions) went slightly out of compliance, which could be common, the unit would shut down often, and tough to trace. How the CarPC guys got these to work reliably, is beyond my guess. It was a little bit of a challenge in many cases trying to use an existing DC buss (utility 12v) that wasn't tightly regulated. If it was close to 12v, the wide input wouldn't work (14-35v), if it went slightly over 12, the standard wouldn't work. I eventually started feeding them with a dedicated DIN-mount adjustable power supply (the typical MeanWell style, 12 or 24v), adjusted slightly under, and then monitored to give a good average based upon the load. Spike draws (such as hard drive spindle motors) were eliminated as much as possible (by using CF card storage, etc) and fans were placed on their own alternate buss. I've noticed that the current online spec sheet for the standard PicoPSU says PG is acceptable between 10.5 and 13.5 vdc. It's not a bold statement spec - you have to hunt for it. However, I'd believe it in that if you fed 13.6, it would shut down. Cheers, Ted. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc-users Digest, Vol 70, Issue 11
On 2/3/2012 3:19 AM, emc-users-requ...@lists.sourceforge.net wrote: Beware - of these gotcha's No jog in feedhold! - So don't break an insert or get a swarf ball around a tool!!! Taper thread pitches are measured along the hypotenuse ??? ... Unfortunately any changes to EMC only happen if you can do it yourself even when you can prove it's sensible or Industry standard. Committee member ego's seem to overrule standards or common sense. Explains really why it's still a niche application with so few users... Really? I've followed the no jog in feedhold many times on this list - I'm still surprised at the discussion that comes up by how it should be obvious that when a tool is broken that you can just keep on cutting from where it failed. The ones that claim this as a need indicate to me that they really haven't been in the situation. My Mazak 410 VMC doesn't have jog in feedhold (brand new in 2008)- does that mean they owe me $100,000 back? Not at all - heck, in many circumstances, I can't even open the door in feedhold - it's a safety thing. The item that keeps escaping me is that one believes they can stop the machine just as the tool breaks in the toolpath (which by definition is physically impossible along a lateral plane), replace it, and pick up from where you left off. From production to prototyping - it doesn't happen. You either have to back up a few blocks or operations into the program to cut the scallop that the tool left, or scrap the workpiece and start again. Neither requires jog in feedhold - it requires stopping the program. And LinuxCNC is quite capable in that department, just like EVERY other control out there. In regards to a rats nest - from a turning workpiece to a turning tool - if you're getting a buildup of a continuous spiral from your cut, the cutting conditions are not correct. Aluminum, titanium and many polymers do tend to spiral - it is an indication of incorrect tool application. Feeds, speeds and depth of cut are no longer the realm of a secretive tool maker - they are well published, even equivalents for import/generic HSS tooling. Granted, most mini mill spindles are lacking the speed to run a 1/8 diameter cutter properly - the easy (and appropriate) solution is to program a Z+ raise in between machining operations - just a little higher than the clearance plane is sufficient - where you can then SAFELY hit feedhold and clear the swarf. Also something that traditional feedhold operations are capable of. In regards to the tapered threads - go ahead and look up how that thread is supposed to be cut - and measured - from Machinery's Handbook or an equivalent - Unless you're using a custom gage for checking, you're going to be measuring.along the hypotenuse! If you need to convert, the math is rather simple. Open a calculator app, or go retro and consult an antique known as a chart. I'm not responsible for programming or defining either of the above functions in LinuxCNC - I do tend to implement LinuxCNC as my control of choice in a number of installations - many of them hobbyists - that require instruction in the proper use of CNC equipment. (They thought that the 30 second cameo they saw on American Chopper showed them all they needed to know.) These things aren't photocopiers - the 100 hours you put into getting a mini mill cutting its first chip should be supplemented with 500 hours of learning proper machining and programming techniques. Even if using a free waterline CAM program is what you want, knowing how to write a couple lines of manual G code really is a requirement. I don't let anyone touch my machines that can't tell me how to use G04 and block delete. Just some rambling from someone who doesn't blame the control, Ted. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] MESA 7i43
Andrew - You noted that you are using step/dir into servo drives - does it follow that your servo drives require those SPI interfaced encoders? In the servo drives I've encountered, if it has a step/dir mode, the drive is an intelligent one and handles the entire PID and feedback loop itself, meaning the encoder (or at least halls+) is fed directly to the servo drive. Although I agree with Viesturs and recommend you go right to analog for your production setup, it's quite acceptable to work with what you have first and get comfortable with it. In that regard (step/dir) it's unlikely that you'd be feeding back encoder data to EMC (you're treating the system like stepper motors). True, some have succeeded in getting steppers with encoders for closed-loop, although it's not the typical implementation. Does your drive by chance send out a buffered or recreated quadrature signal? Some drives do, as they are used for encoder following installations. If it does, you can likely keep the drive-encoder relationship as SPI (as the manufacturer intended?) and grab the quadrature signal coming out of the drive for EMC when you decided to convert to analog command mode.. On 7/3/2011 8:35 AM, emc-users-requ...@lists.sourceforge.net wrote: Date: Sun, 3 Jul 2011 14:06:24 +0300 From: Andrewparallel.kinemat...@gmail.com Subject: [Emc-users] MESA 7i43 To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Message-ID: CAJZ=btnpfjyy8le7-easvaggnskonzhg43z7kqsla4a4gt_...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, I consider purchasing 7i43 board to control 6 servo drives. First in step/dir, later in analog mode (with homemade PWM to analog convertors). As long as I have SPI encoders, I'm not sure it is that simple to connect them to EMC2 for analog servo mode, but I hope it's possible. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] stepConf configuration | EMC conversion
Andy - per your bottom assumption, and the fastest way to get things up and going: yes you'll probably want to remove the serial (if it truly is serial) to step-driver motion controller board from your system. The beauty is that the IB106's (although discontinued) are plain ol' stepper drivers, with step/direction/enable inputs, and are apparently capable of half- or full-step modes. The very first thing you need to do to make informed decisions is to get as many datasheets as you can; google will be your friend, (although since I had to go and drop by Schneider's website anyway), check out the PDF for the 106: http://www.imshome.com/downloads/datasheets/ib10x.pdf Don't stop there - if there are limit switches, get info on them. Spindle drive/controller, same thing. Vacuum stuff? Ditto. Practically everything in what you are doing is related only to being on or off - so don't let the electronics spook you. If you look at the system now, without that motion control board, you have a standard 3 axis stepper system. You can choose to buss the enables for each drive together as one, or keep them separate, or for testing just jumper them. You can most likely ( unless the datasheets indicate differently), use the default values from either conf or the stepper sample configs for testing with your hardware. Get one section going first, then add, then add, then add. Are there limit or home switches? Remote control for the spindle? Speed? Vacuum platen/hold downs? Toolchanger? -- Get the table motion going first, then add the remainder to the mix. Put the power for the stepper drivers/spindle on a powerstrip/switch SEPARATE from your computer - this is a temporary OMG e-stop until you get a real emergency stop system in place, that doesn't power off your computer. Keep that switch within reach. The next decision you're going to make is whether to use a motherboard/PCI parallel port for control, or go with an external pulse generator board (PPMC/Mesa/etc). For instant gratification, lowest budget, fastest time - if you have a PC available with a parallel port, I'd recommend that first. (again, start with simple knowns, add more stuff later) Regardless, make sure you get some form of breakout or opto-isolation board for protection. From here on in, you can pretty much follow any (or all) of the stepper-driven projects whether they be micromills or shopmates or anything else with steppers. There are plenty of projects in the wiki that you can learn from. The EMC Getting Started Guide includes pretty much a step-by-step recipe for stepper systems. As an aside, and Not To Be Recommended, but technically you can get a 3-axis stepper system running on only 7 wires (including ground) off the parallel port. More specific answers: driver variables - would actually depend a little more on experimentation given the mass/inertia in your system. Too quick on the pulses or too high an acceleration value and the motors may stall, or the drivers may not even sense it. Too long and the system will be sluggish. Since you have a router, which typically implies wood, you'll need to get your feedrates as high and consistent as possible so you don't burn tools. Leadscrew pitch - in stepconf it's looking for rev/inch (or if you prefer, TPI) - yes, you can count the number of threads per inch, (or in 10 inches, or in 100 inches - depends on what resolution you need) but don't forget to make sure you also include any gearing if it's applicable (there are other fields for that). You can always come back and edit/fine tune the scale values after the fact if necessary. Ted. = I got an old CNC router (phoenix) from a school district auction and am very eager to get it going. The old interface is using a serial cable and I need figure out how to connect this to EMC. The electronics part is where I am a bit rusty - sorry if I ask obvious questions. Here is the low down: Drivers:IB106 (seehttp://www.forsalesticker.com/drivers.jpg) Steppers: 1.8 deg - Eastern Air Devices LA34BJK-P500 snip -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Lathe Tool-Changer
Clint - my Tsugami lathe is similar, except it had a 3phase AC motor with hi and lo gearing for rotation - but did include the binary cams (position, top-dead center and a PARITY bit!) - although that setup did prove to be less-than-optimal in the long run (I have since converted the turret over to direct drive servo) - and am writing a component to handle the position offsets and auto-homing procedures more cleanly. My earlier CL work, which required two ladders (one for the turret operation and a second as a lookup table for conversions), is still posted at the Tsugami blog: www.casafrog.com/cfblog -- you're welcome to borrow whatever useful tidbits you find there. Ted. Clint Washburn wrote: I am in the process of setting up classic-ladder for the tool-changer on my Hitachi-Seiki NH500 Turret lathe. I am using a mesa 5i20 card for inputs and opto22 relays. For each tool position it uses a combination of inputs from six switches that follow 6 cams on a drum to dictate position input. The tool change process consists of: 1. The carriage extending to unlock with a solenoid. 2. Tool changer initializing solenoid for hydraulic motor rotating clockwise to switch combination for tool position 3. Once in position de-energize solenoid for rotation and return to locked state (also designated by switches.) 4. Depending on if it is an ID or OD tool position an auxiliary function would be then required to extend the ID tool if it is called. Does this make sense to anyone? Has anyone used this type of classic-ladder program for their tool-changer? Does anyone have an .clp program that would illustrate how to go about this so I can get an idea of how to go about it? Any help would be greatly appreciated. clint -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Single Phase Lathe spindle motor question
Clint - I have an older Allen Bradley 1336S drive (courtesy of ebay) - the collection of 5hp units I got without operator panels, and then finding a panel, probably ran me about $150. I don't see those drives at that price ($40 each!) on ebay currently. The motor was a 5hp Craigslist find, about $60. I added a new pulley and bushing for another $100. My power service is in a medium-industrial area, and sits pretty stable at 212 VAC, +/- 1v variance leg-leg, with a recorded typical of less than 5% variance. My mazak says it's at 60.2 Hz - so it's right on the money for USA domestic service. We are on a recent (last 3 years) installed site transformer, and one of only two customers on it. I cut typically aluminum and polymers, and the load meter has always been less than 50% with the exception of accel and decel. Even in a mild steel or stainless cut, 0.070 engagement, was only 40% loaded. I have inserts that will allow 200thou DOC, but I'm not expecting to use that capacity. My limiting factor really isn't power for my applications, it's surface speed; I top out around 3500 RPM now, and while that's more than sufficient for aluminum at 2, it gets kind of slow at 1/4. I do not currently employ an external resistor, although I should. EMC controls the external PID loop, while the drive takes care of the inner accel/decel loop - ie. the drive's accel/decel is faster than EMC and rarely takes precedence, but is there in case EMC (or I) command it to do something stupid. The spindle has a full A/B/Z encoder on it for feedback. It is NOT run in a tight servo-loop, just a relaxed at-speed loop. It's fine for threading straight, but needs a little tightening for tapers still. (change in surface speed related). I pulley'ed up the motor as large as I can go (given physical space restrictions) - the 3500 is actually more than what the lathe originally did (2880 to 3000) on it's DC motor, so I guess I should be happy. The motor I have on there now has class-H insulation, so it's technically not inverter-grade - thus I'm not going to overclock the VFD - it's running at 60Hz. Many VFDs you can freq-up to 100 or even 120Hz, but consensus is that you really Should have an inverter-duty motor for that. Aside from lucky finds, I'd look at either surpluscenter.com or automationdirect.com for retail units - probably cost as much to ship as they do to buy - a 5hp motor will weigh about 151 lbs - just enough when crated to be over UPS small package, so it goes by truck. However you could still have yourself a decent motor for about $500. I understand the retrofit cost versus the iron cost - I paid $500 for my Tsugami complete, but $1200 to truck it, and have probably sunk only an additional $2k of gear into it. However, exclusive of labor, it has already paid for itself. I have no doubt my hobby lathe will continue to be such until the day it is retired - it's unlikely it would ever be a completed project - one more bell or whistle to add to it, a software upgrade etc. If you can find a servo drive for that size of motor, I'd recommend it - if you think C-Axis work will be in your future. You can use a VFD to work as a servo drive (hack, cough. disclaimer), but the challenge is that most VFD's have a built in accel/decel profile that has a minimum setting of 0.1 seconds, not 0 seconds or disabled. So although EMC could control the servo loop, it will always have that 0.1 sec (*2) delay. Which won't get you consistent or repeatable results in absolute degrees. I originally had a VFD on my turret toolchange motor, and although it would work, it took a lot of effort and multiple gear changes to get it there. Even then, if it went from one tool to a neighboring tool (like #3 to #4) it would often hunt for a few seconds before it was close enough to let the turret lock again. There is now a real servo with gearhead and a real servo drive on there and the difference is night and day. I don't have a C axis going on my unit yet, but I plan on following what Tsugami did in the past - the headstock has provisions for clutching in and out a secondary servo for fine positioning. Since the mech is already there, I just have to find a suitable servo for it. One final caveat - the firmware in my AB spindle drive is set for forward run only - however I haven't used a tool that I need to run backwards. Ted. - Original Message - From: Clint Washburn cl...@clintandheidi.com To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Tuesday, March 08, 2011 7:18 PM Subject: Re: [Emc-users] Single Phase Lathe spindle motor question Ted, What kind of motor did you go with and what model of vfd do you use? Also I have not yet purchased a drive yet I am weighing my options. I am thinking of 5-7.5 hp. With the price some of the vfds are going for I would pay several times over what I paid for the lathe. Thanks, Clint
[Emc-users] Single Phase Lathe spindle motor question
emc-users-requ...@lists.sourceforge.net wrote: Message: 5 Date: Mon, 7 Mar 2011 22:03:45 -0800 From: Clint Washburncl...@clintandheidi.com Subject: [Emc-users] Single Phase Lathe spindle motor question To: 'Enhanced Machine Controller \(EMC\)' emc-users@lists.sourceforge.net Message-ID:00bd01cbdd56$99811290$cc8337b0$@com Content-Type: text/plain; charset=us-ascii I am in the process of converting my 1978 Hitachi Seiki CNC lathe to EMC. It currently has a 7.5 KW dc motor that used to be powered by FUJI SCR drive. My first problem my house does not have 3 phase power. I am having to work around this issue with my whole retrofit. I wish to convert this to a 3 phase AC spindle. What VFD's are people having success with as a spindle drive with single phase power? Is it realistic to have a 10 hp 3 phase spindle on single phase power? or will I have to go with a spindle motor closer to around 7.5hp instead? What is everyone's input on this? Clint Washburn Clint - I converted my Tsugami lathe (also 7.5Hp DC spindle) over to a 5hp AC spindle - and for testing was running on single phase 220. My AB VFD would only get the motor up to about 70% speed (2200rpm) before going into Bus Undervolt Fault - I was running this directly from the front panel of the VFD without EMC intervention at the time, so there should have been little to no regen or accel/decel problems. The spindle was also under no load (from cutting) - so under a cut scenario, I'd expect the unit to fault just as soon as the insert entered the cut. The unit functions just fine under 3phase power, of course. It may be worthwhile to note that although many VFDs with 3 phase input are built on a simple bridge-cap system, how they check the line-line voltage may differ, so going leg R-T instead of R-S (for example) may get you lucky. Alternatively, you may look at a separate DC supply, and feed the ?440 into the DC bus input on your VFDassuming your VFD supports it. I can do this on my AB, apparently. I recall Rexroth (Bosch) did this with a lot of their high end servo and spindle drives, so did Mitsu - one central DC supply, with drives that connected to the buss, instead of all AC input units. My instinct based only one one experience says you're going to have a challenge getting that 10hp spooled up on single phase. BTW - where did you get a 208vac 10hp drive? By the time you get higher than 5hp, most are wanting 380-480 inputor you have to mortgage the house. :-) Best wishes, Ted. -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Control offsets or variables from Hal pin?
Is it possible to control offsets from a Hal pin? I'm looking to change the x,y, and z offsets dependent upon a tool change, without using the tool table. I need absolute tooltip offsets, not radial left/right sets. At the moment, I'm putting G92/.1/.2 commands in my post file, but would prefer to write a comp to do this based upon fixed parameters. (For our application this works, as it offsets relative to any of the additional WPC's called (like G54 or the other work coordinate systems, of which we're using about 6). Our application has a circular array of tools, from which tool 0 (reference) is programmed to the center of the array. T1-12 are spaced around a pair of concentric circles, and due to length, thus have x,y and z offsets from the reference. I have a couple custom components running too, as there are accessories running that are being controlled (not in realtime) over a couple serial ports. It's in one of these comps that I'd love to be able to command the offsets. I know I can read pins like halui.tool.length_offset.x or motion.tooloffset.y -- however those pins are read only. Is there anything out there, or even the ability to change variables (perhaps like #5211-5219?) Thanks, Ted. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] M53/54/55 Addition to EMCTask?
Hi all-
I've been working on getting the live tool system working on my lathe
and am curious if it is at all possible (for me) to add interpretation
of M53/M54/M55 to EMCTask, to activate new pins
{motion.livespindle-forward, motion.livespindle-reverse,
motion.livespindle.on} - which are equivalent to M3/M4/M5, but assigned
to the live spindle motor. Spindle speed would be handled with the
existing pins.
I realize I can do this in the M100-M199 range, (which is what I'm doing
with it right now) - however I'm hoping to retain some form of
traditional Fanuc/Mori functionality.
The real question is, can any non-implemented (m) code be parsed by an
external rogram - just like the process of M100-199, or does it have to
happen within a modified version of EMCTask? (ie, would my changes
have to be redone if a new and lucrative release comes out?)
Since one already gets a unknown m code used fault if M100 is called
without an associated program, could EMCTask check for the existence of
M53 (and thus any non-implemented code) in the PROGRAM_PREFIX directory
as well by default?
Thanks,
Ted.
--
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] EMC2: Genserkins params
Stuart - you're not crazy - at this point it doesn't look like genserkins accepts the theta parameter, thus it's most likely hardwired into the transforms. I lost braincells working on matricies over the past few months and Alex's work on genserkins was a godsend. I now have a Puma 500 up and running quite happily under genserkins - of which I'm forcing out only 3 joints of kins for our application. I would love,love,love however to reposition the theta parameter for Joint 0 in order to re-orient the xy plane to not emulate a vertical machine quill. That's not availableyet. Along with a couple others, my next step will be to dive back into that work and see if theta can be integrated as well. It is the least-used parameter, given a Puma-style-manipulator, so I'm not surprised it didn't get in for the first round. If you look at pumakins, it's STRICTLY Puma(R)-style and leaves very little room for other configurations - so generkins even at this level, is quite an accomplishment! There is an amazing disconnect in the world of robotic arm manipulators - it was mentioned that Mach3 would have a tough time doing this - would you believe that Unimation (Puma), Yaskawa (Motoman), Kuka, Kawasaki, Fanuc FM (or whatever they changed their name to again this month) - and others - practically all arm manufacturers can't do what EMC2 does? In their world, a robot arm is strictly a parts manipulator. Teach-in and point-to-point programming - that's it. True, there's a Mastercam plugin for most platforms, and if you're really clever with VAL programming, you can write scripts that covnert xyz point tables into macrosbut to directly take g-code and emulate a mill quill? I got a lot of lost deer in headlights looks, even from support reps at the booths in IMTS this year. I was specifically pushing them on this capability and their response categorically was that sounds incredibly cool - we'd like to see it - but to operate your robot arm we have this pendant-thingie here. Or one guru back at headquarters that can write some XML for you. I think one of the big reasons it isn't pursued is due to the fact that understanding the work envelope versus the workpiece envelope is a challenge. The first thought of looking at a 6' tall arm is wow...you can do a really big part with that thing - we anthropomorphize the machine to our own arm/shoulder capabilities. On my Puma 500, (17 links, and is currently mounted to a wheeled 48x48 pallet!) I really only have a usable single-part work envelope of about 14x14x6 - why so small? The work envelope of the arm is spherical, and g-code operations are relative to planar surfaces - so I need to work within a planar surface that is tangent to the sphere of my robot. That space shrinks very very quickly. In a point-to-point program, (typical part manipulator) you can ignore the actual path as long as you don't crash. In g-code, the path is the whole purpose of the code. Thus if the arm is almost at a joint max extension, there may be a good chance you run out of length and fault. A fully extended arm can't extend any further. In a part-manipulator situation it is very easy to visualize where the conveyor and vice/chuck are - and if they are within the work envelope. If they are within, then there's little chance your application will fail. Since the kins has to resolve xyz into (any potential number of) solutions given current position, next position and mechanical limits, there is an incredibly high chance that eventually, it will fail. I think that's the reason that practically no one else out there is even attempting this (aside from research institutions). It always amazes me for what many perceive as a Hobby platform how absolutely cutting edge the stuff that is done here is! Ted. Stuart Wrote:Date: Wed, 17 Nov 2010 11:23:44 -0600 From: Stuart Stevenson stus...@gmail.com Subject: Re: [Emc-users] American Robot at MPM To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Message-ID: aanlktimjajak=wwaac=yazbujoqq19x8ig512+dk8...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Gentlemen, In studying the D-H parameter I see the use of 4 parameters. I see genserkins http://www.linuxcnc.org/docview/html//man/man9/genserkins.9.htmlhas only three listed. Either I don't understand how 4 becomes three or something is not correct in the DH parameters description or genserkins. Any clarification would be greatly appreciated. Also, I saw a comment by SWP of a change made during the setup of the robot here. Clarification here would also be met with happiness. I only ask this as I am still uncertain of PC start success (I haven't used the hammer yet) and think I may be facing a start over from blank hard drive. I am off to find a hammer. :) thanks Stuart -- dos centavos -- -- Beautiful is writing
Re: [Emc-users] Emc2 Safe Zone ?
The Matrix control on my Mazak Vertical has a component called an Intelligent Safety Shield that does what you were describing. However, does is a bit misleading, as you have to load a model file that describes the machine, the table and the out-of-bounds areas. And a lot of parameter changing. Depending on the tool, you may have model files for each one. I had our install tech demo me a prebuilt version and it was quite painful to watch him try and implement it - not something that could be changed easily. Thus it wouldn't be practical for collision avoidance with a vise, or to be honest any type of workholding. I don't know if it's as difficult on the lathe setup (same control), but if you do both chuck and collet work, changing over from a jaw to collet nose would require a lot of effort. I can certainly agree with the request though - the Tsugami lathe I'm almost done rebuilding to EMC (honestly, though, does it ever get done?)showed evidence of boring bars or drills slamming into the firewall when someone didn't pay attention to their extension in regards to another tool (like a cutoff) on the turret! Those impact marks only showed up AFTER I finished the nice white paint job, too! That fact, however is an indication of how difficult implementing this would be; my turret has 12 stations; there would have to be a collision zone for the firewall, the chuck/nose, the cabinet sheetmetal, probably 12 axial and 12 radial zones (depending on tool selected) for positive and negative motion, and a tail or median workholding (steady, etc) if used. That's a lot of continuous 3d to analyze in realtime - that may require more than an old pentium to keep up with The point is you really couldn't (shouldn't) just implement a little bit of safety. If you implement a shield just to avoid the current tool with the chuck, it doesn't do you any good when a bar in another location slams into the firewall. It becomes a human problem, not an automation one, as the operator/programmer will begin to assume that since there is a shield, it will prevent programming or operational errors. On my Tsugami, I have two sets of ini files, one for my 3jaw chuck, one for my 5c collet nose. The only differences are in their soft limits. So far, that has seemed to work for me. I've been doing a lot of chuck work, with varying jaw heights, so I do have the occasional need to change those. I would love to have a drop-down or manual edit to change the limit variables, though - or quick profiles instead of exiting Axis, editing, and restarting. To date however, it hasn't been enough of a bother to worry about. My project of the moment is graphical tool representation in a panel. :-) If I could expand the tool list, I'd love to be able to add at the per-tool-level, either a tool profile code that references another file, or a set of +/- xyzabc limits (in machine space) that when this tool is selected become the internal (more restrictive) soft limits. There may be other ways to accomplish this already, however. Ted. Message: 7 Date: Mon, 30 Aug 2010 21:36:57 -0500 From: Daniel Gollermor...@gmail.com Subject: Re: [Emc-users] Emc2 Safe Zone ? To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Message-ID: aanlktimfjkgsgrr3meqonncvub8gadxfqbhmeb0sq...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 What additional info would be required to know what I was asking about. Or is it more Oh no dude, we know what you wanted, it's just so not possible, we just don't want to touch this one : -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Lathe ATC Integration
emc-users-requ...@lists.sourceforge.net wrote: On 25 July 2010 14:53, Schooner schoone...@tiscali.co.uk wrote: The ATC is currently assigned to axis A, so I could just write GCode to achieve the same result, but would rather it responded properly to M6. Can anyone point me to some info or tell me the secret?! ArcEye - I have a 12-station turret running on my Tsugami Lathe as a pseudo-servo controlled joint - some ClassicLadder grabs the tool change request (Tx M6), runs the hydraulic locks, ensures the rest of the machine is in feed-hold, controls a PID component that is driving a small VFD that drives the AC induction motor that spins the turret. The VFD has a very quick accel/decel curve in it. I have an incremental encoder on the output of the gearbox (there is a high- and low- speed clutch as well as a brake on the turret gearbox) that reads about 180,000 pulses per full turret rotation. The index pulse on the encoder is ignored and generated by a separate inductive sensor on the turret itself, once per true revolution. The ladder is written to go directly to the tool number (hand-coded encoder position) as opposed to the shortest distance; thus if I'm at tool 12, and call tool 1 (which is right next to it physically), the turret will unwind all the way from 12 to 1 - which is not the fastest, but since it runs the change in high-speed for the majority of the time, I get a maximum tool change speed of about 3 to 4 seconds; and for that I'm not going to complain about. The ladder shifts the gearbox into high for most of the transit, and downshifts for about one tool position; it reduces the hunting (since the VFD really isn't designed for that) to a minimum. The joint doesn't exist as an actual axis; so it isn't subject to modes or feed hold status of EMC. Homing is accomplished by button on startup (or any convenient time afterwards); it winds and unwinds the turret searching for the index pulse, then sets tool 1 ready for the first cutting operation. The index is ignored after that. You can check out the entire process here at: http://www.casafrog.com/cfblog/ or the turret-specific pages starting around: http://www.casafrog.com/cfblog/?p=1214 Cheers, Ted. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] OT: Fwd Kinematics Equation
Does anyone happen to have a completed (or process to complete one) equation for forward kinematics to solve the following structure? Origin Fixed point (A) -- Joint Length (L1) -- Wrist (F) -- Elbow (B) -- Joint Length (L2) -- Wrist (G) -- Elbow (C) -- Joint Length (L3) -- Wrist (H) -- Elbow (D) -- Joint Length (L4) -- Terminus The input parameters would be a) Fixed Lengths L1, L2, L3, L4 b) dynamic angles in degrees of Wrists F, G, H, that rotate about the joint axes c) dynamic angles in degrees of Elbows B,C,D that rotate orthogonally to the joint angles. Output solution would be geometric location of terminus in x,y,z co-ordinates relative to the Origin point (assume 0,0,0 ok) I've pushed through a lot of the DH descriptors - but to be honest, my few remaining brain cells just aren't up to the task of multiplying and transforming 6 4x4 matricies anymore (if they ever were!)- of which I probably would get it wrong a lot Does anyone have a method to create this layout (using one of those computer thinginesthose things that are supposed to do the hard work for us?) and generate the equation set to determine the terminus X,Y,Z location? I've found a couple of simulators that are supposed to (but don't) do this. Matlab is also supposed to have an OS plugin, but it's apparently been purged from existence, and I don't have a seat of Matlab to play with, anyway. I've looked through the pumakins as well as a lot of the available (and yes, mind-numbing literature) on kins descriptors - and am still kind of lost to solve it. This is for a device similar in design to a digitizing arm that I want to eventually attach to an EMC machine - so to be honest, I'd rather spend time integrating it with EMC instead of solving the maths by hand. Opinions and Thoughts welcome! Thanks, Ted. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] EMC2 Homing with Index Pulse
Don - I am running with 2.3.0 with a Mesa 5i20 and am noticing the same behavior; I have at least for the moment returned to mode 2 (home switch use only) as that is currently sufficient; my initial expectation was that an unfinished part of my system may have been at fault. It's a servo system, separate limit +/-, separate overtravel +/-, separate home for each axis (total 5 sw per axis, nothing shared), running encoders as hostmot2 modules, and the index pulse does occur. If I use mode 3 or 4 for homing, the do_homing() proc doesn't appear to see the index pulse at all and continues to the overtravel limit. I can reset count signals with the .index-enable, so I believe the hostmot2 and hardware are fine. I expect there is an additional encoder.xx.index-enable 1 or equivalent required for the system to actually use the index, however in my earlier dealings with the hostmot2 I thought that particular parameter was to clear the position counter on the next index pulse, instead of being used by another part of EMC; and thus you would have to set that parameter true every time you wanted to clear the position. I may of course be, way off, however it is also described this way in the current man page for hostmot2. I was unable to find any additional requirement to set it true for homing use. (EDIT: encoder.xx.index-enable 1 does indeed work as described in the hostmot2 man page; verified just now on my lathe. I can't see how one would use the same parameter for the homing setup). Ted. EKCo Inc Don Stanley wrote: Hi All; I have installed EMC 2.3 on a lathe using the Motenc Light interface. Two problems have me stumped. 1- I want to Home at the Encoder Index after using Plus-limit / Home combination Switch at the Plus end of travel to get to a known start position. This is shown in the third homing diagram on the page of four diagrams in the Integrator Manual INI file homing section. I can't stop if from Homing at the Home Switch release point. Does anyone know how to make this work with my equipment? -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool change
a usable part. To be honest, even with controls that do have this functionality, I rarely, if ever find a practical use for it. Ted. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Non-parametric for CNC
(such as Inventor) and bring them in for rework and production. They aren't the machinists or builders, but they use those tools to workout their initial intent. For them, it is a very valuable tool. From strictly a machining aspect, I find it doesn't add any value. I cannot yet machine the whole assembly from a single billet (and trust me, I'll be cheering when I can!), so knowing how a u-joint rotates against a shaft doesn't (as yet) lend any value to the machining operation. A number of the job shops in my area don't even want to hear about solid models - some only accept 2d dimensioned prints - not due to lack of technology - but due to liability. No one wants to be the guy who mis-interpreted or assumed a relation. Thus, they want to follow every feature on the page, wrong or not! Ted. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Fwd: Blatant Update for Ted's Tsugami Lathe Retrofit
For those that may or may not have been following the progress on my Tsugami NCM45 lathe retrofit, I'm finally at the point of getting EMC2 integrated into the system. You're welcome to see the current (and past) progress over at http://www.casafrog.com/cfblog I've closed automatic comments due to spam, but you're welcome to email, or even keep relevant comments on-list. Cheers, Ted. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] FS: More Iron to retrofit...up for grabs
In an interesting twist, Richard, the kind gentleman who sold me my Tsugami NCM45 also has another Tsugami lathe, this time a (per Richard - 1986?) 'PL3B which has 11.8 on XZ, some kind of air chuck and was used for machining lenses. (r)an the spindle,nice and quiet. Very clean sump to top. Oiling system works great.' Appx weight is 5000lb. Alternative to an angel is the scrap heap. It's a gang tool unit, smaller than my NCM45. Richard got it to strip out the Fanuc O-t control as spare parts for some of their other equipment. (Which by my guess means it could be primed for an EMC2 refit!) That's all the info I have, but if anyone in interested, PM me and I'll put you in direct contact - and you can negotiate all you want. Since Richard isn't a list member, I didn't want to put up his personal info publicly, however he'd be quite happy to hear from someone who wants the unit! rishard is in Nescopeck, PA and if you drop by my blog you'll also note that the freight/trucking company a few miles from his place was quite helpful! (And apologies for the somewhat weird post). Does anyone make bumper stickers for Save Old Iron? :-) Ted -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Build Blog: Ted's Tsugami Lathe retrofit
Hey guys - just thought I'd drop a shameless plug for the Tsugami Mercury lathe project I'm retrofitting from its original Fanuc 6T(a) control to EMC2 - if you're interested in some pictures, humor and maybe even an occasional tidbit of useful info, feel free to drop by: http://casafrog.com/cfblog/ Comments and suggestions always welcome. Cheers, Ted. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] line limitation - and auto mode interrupt capability
None of the Mori Seiki, Kitamura, or Hwacheon machines I have used have this magic ability. ( I leave out Mazak- cause they are just different, and Okuma, which doesn't really break the rules, they just made up there own.) Greg - you can safely add Mazak to that list too - My very current Matrix Nexus control in its Mazatrol conversational mode, true, can do modal-safe restarts (because each machining op/pocket/line/arc isn't a block of gcode or sub; it's a description of the operation in a standalone, complete manner), you don't have that luxury in EIA/traditional GCode mode! True, yes, there are 4 levels of TPS (no, not reports, but manual teach points that can be used to move out of the work, then return back in) - however, if you stop the spindle, you get a spindle abnormal alarm. Reset, dump program. If you move out of memory or tape mode, dump program. If you attempt to open the door, door interlock alarm, reset, dump program. Move to MDI? Dump program. There is also a restart function. It turns out to be non-modal. You need to have searchable strings/comments/ sub numbers on your code for that to work, as the Matrix doesn't use line numbers. Again, all aimed more to the conversational/Mazatrol or manual machining modes than streaming GCode. BTW - I don't use Mazatrol conversational. At all. I build my CAM with VisualMill, and it is a happy production scenario. I also use VMill to write code for my hobby EMC installs. (Other customers use anything from hand to Master X and Gibbs.) However, in a weird twist of fate, I think it ends up being more the way you do have to evaluate your methods to the machine, than trying to force the machine to use your methods - for instance, true, it would be fabulous to, upon discovering a broken tool (on a machine with no tool check or management) pause the program, have the tool disengage, spindle stop, change tool, update offsets, then re-engage and continue - however - that's a lot of non-program interference, and is an incomplete solution - it's also likely that the broken tool left a scallop or poor edge on the cut, and you don't have the opportunity to BACK UP - you only have the opportunity to carry on - in that case, you've likely made or are about to make your workpiece unusable. Also, it's important to consider, why did the tool break? Is there debris/interference/tool remnants left that will cause more failures? I embarrassingly admit, I do mess up on a feed/speed/DOC entry more than occasionally, just trying to get the first run in. And the tool goes pop. I don't want to rerun that mistake, I need to go back to my CAM and fix it, then run it correctly from the start. Thus, for the most part, I'll break down my machining ops into a lot of little sections that I can (and do) post, then run, individually - it's not uncommon to have 10 little programs that I load and run sequentially for the first-off run. If I'm happy with the optimization (which I rarely am the first time), I'll then go back, fix, and post everything as a single program. Since I'm a specialty resource, not a job shop, I don't have to justify my spindle-on time; in fact, I probably only have about 600 spindle hours in the past year on that particular VMC, which would barely break in a new machine. That also means I don't have to justify a 5S, lean, super-optimized, kanban, every-second-accounted-for machining principle. I probably produce 10 or fewer parts in a single run, with 20-50 of the same family - EVER. That definitely fits the low-volume, high-mix profile. So, given that, I don't feel bad about having to do things twice in regards to a CAM session. I also never make just one. If I were a lights-out job shop owner, I would want and demand tool management (that I do have on my Matrix, I just don't use it either) - but I'd also have a lot of other automation working in concert for workpiece movement, measurement and verification - and with any luck, the incoming dollars to support it. For that case there would also be no need for manual interruption of a program; a workpiece would likely still be damaged, possibly continue to damage other tools, but most likely just carry on with the occasional failed part that gets tossed into the scrap bin. When doing a night run of 500 parts, overrun with 10%, tossing one or two isn't a big deal. But again, it's not something I specialize in. This isn't a photocopier-scenario where interrupting a job to copy one page of someone else's document is okay - every time I see a point where I'd think hey, I wish I could interrupt and do...x.., it's quickly followed by but it really wouldn't make any difference, since ..y... is screwed up anyway. Just a few cents worth, Ted. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment
[Emc-users] EMC: Lathe Users CAM preferences?
Hey guys - I started this thread on the forum, but since there's not much activity there at the moment, I thought I'd bring it here: Rather simple question: what are the EMC-lathe users out there using as their preferred method of developing GCode? The wiki lists a few - and in many cases - outdated options. I'm a lover of Mecsoft products myself, but would also prefer to support the OS community if something exists. So, given a DXF profile or equivalent, what's your method of: rough/finish, thread and grooving (and are you using gang, turret or toolpost)? Cheers, Ted. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Mesa 5i23 and 7i37 I/O problem
Peter Wallace wrote: Also the: setp watchdog.timeout_ns line is commented out Perhaps someone thought that the watchdog would be disabled if this value is not set. I think with the current driver, the watchdog cannot be disabled, probably a good thing... So at least the first fix is to uncomment the two watchdog related lines in m5i23.hal In my PRE-2.2.8 TESTING setup, performing anything with the watchdog on the HM2 7i43 caused errors, hence its inclusion, but being commented out. For the sake of function, I just assumed that portion of the driver wasn't completed yet. (Keep in mind this was back in October '08). Significant improvements have been made to the drivers and firmware since then. Those hal configs weren't tested on a 5i2x (or anything else for that matter) on my setup, as at the time all I had were the 7i43s. Since the 5i20 is the more mature hardware, one could conclude that the 'dog function is completely capable. Side note also that the 5i2x has additional, separate thread calls for gpio (can't recall if you're using them) - that the 7i43 file doesn't use currently (IIRC, per Peter, due to EPP timing restrictions). Ted. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Pissed off of EMC2 and 7i43 (Ted - long)
a firmware (.bit file for the Spartan) explicitly in the .hal file. That means the firmware loader needs to know where to look, and by default it typically doesn't. This is referred to as symlinking your sandbox, and goes something like this: $ sudo ln -s $HOME/emc2-sandbox/src/hal/drivers/mesa-hostmot2/firmware /lib/firmware/hm2 The first reference (with the $HOME path) needs to actually point to where you compiled your trunk version - there are plenty of google references to help you with this. Power input to the 7i43 is via an external 5v power supply. You can use USB power if you want, but you can't just plug a USB cable into the USB port - the board will attempt to enumerate with the MB BIOS. Even if you remove USB drivers from Ubuntu, the 7i43 will (in my observation) get stuck, doing what, in fact, it's been told to do: make a USB connection - thus, if you use the USB power from the MB, remove the D+/D- lines from the cable, or preferably, just connect 5v to the proper power connector. Jumpers are set for EPP config (W4 W5 down), USB Power off (W6 down) - since I'm feeding power into the external 5v connector - Power Enable is on (W7 up). Data cabling is via a short (12 long) crimped D25-IDC ribbon cable. After that, I made sure that I could actually get firmware to load into the 7i43 - and the best way to do this, IMO, is through the command prompt. Too much is variable in an untested system, so wanting an ini and hal fileset at this point is a) useless, and b) a waste of time. I am going to hope that you already have established communication with your board, but the pastebin files didn't help me, so for reference: $ halrun Halcmd: loadrt hostmot2 Halcmd: loadrt hm2_7i43 config=firmware=hm2/7i43/SVST4_4B.BIT I happen to have the 400k gate Spartan, if you have the 200k version, substitute SVST4_4S.BIT - you should hopefully have read that there are 2 different firmware sets, one for the 400k (Big) version, and one for the 200k (Small) version...Note that in my hal file, the same 400k vs. 200k requirement applies.. If the hm2_7i43 component loaded without error, the hardware is likely good to go. If it failed, there is more hunting you have to do, and all the config files in the world aren't going to help. Here, you really need to know your system, and track down problems with patience. If you got this far, we can now cheat a bit and you can download my files from here: http://filebin.ca/hvthwk/m7i43_th.hal and http://filebin.ca/thqbtc/m7i43_th.ini You will want to put them in their own directory (inside your trunk EMC2 would be nice, but desktop is fine, too) You will also need to build a .var file, a .tbl file and copy over the emc.nml file - all as referenced in the ini file, or you can just download them also from here: http://filebin.ca/tymdgd/emc.nml and http://filebin.ca/weppbt/m7i43.tbl and http://filebin.ca/jutbos/m7i43.var Those 5 files, together with a properly configured launcher shortcut will launch EMC with the Axis gui, and set up 3 PWM servo axes (x,y,z), that output to the P4 connector on the 7i43. All shared without warranty, fitness, merchantability or liabilities of any kind. The .hal and .ini files are slightly stripped from my current ones, as I'm adding less mill-style connections to run the laser and various workholding options, conveyors, limit switches, height sensors, etc. - I pulled that stuff out to confuse less, and replaced the estop chain with the standard/virtual version - make sure you implement an appropriate physical estop chain. Hopefully this works for you, but as you probably don't have my exact setup, there's a chance you may still run into problems. It's important to take it one step at a time and strip out as much of the complexity as possible, but I can respect your desire to test against a confirmed functional baseline. Keep at it - you'll get there! Ted. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Mesa 7i43 2.2.6, Hostmot2 (Ted) - SUCCESS!
Ted Hyde wrote: 7i43 (400K Spartan3) board is USB powered now (Sebastian's suggestion, though no difference from external port was found) - and is set for EPP firmware load/config. I suggest starting with GPIO instead of the encoders, just to verify the 7i43 and HAL functioning before adding more hardware to the mix. Load the hm2_7i43 driver with all functions turned off (by saying config=num_encoders=0 num_stepgens=0 num_pwmgens=0). All the pins become GPIOs, which default to inputs with pullup resistors If I change BIOS to EPP 1.9, hm2_7i43 components will fail to load, halrun notes: SNIP Sebastian - I moved back to external power supply- it appears that the FTDI USB driver may have been Getting in the way when I reset the 7i43 power during testing. Didn't catch that until just now. I also moved back to EPP 1.7; EPP1.9 still fails with the same messages, and adding the _debug token doesn't get any additional info than before as the driver fails to load, thus cannot start to issue debug messages. However, here's the important part - now the board in EPP1.7 mode works fine. It was NOT thrilled with the components being disabled (set to all GPIO mode) - this took the better part of 30 seconds to return to the halcmd: prompt - it may have been partially my fault of not giving a component sufficient time to load, and the occasional mistype (I would often forget to include the 'firmware=' portion after config=.and of course get invalid parameter errors!) That, coupled with the phase of the moon and a new bag of tea leaves, has GPIO, encoders and PWM functioning. (And for John's sanity, I was loading threads, linking the drivers and starting rt services - but it's always good to confirm, nonetheless!) I believe the USB connection was my major stumbling block; and unless the Epia BIOS was labeled incorrectly - which I would never rule out - in this case, EPP1.7 works, while EPP1.9 does not, at least while hard-selected at the BIOS setup screen. FWIW, I am pulling power for the 7i43 from an isolated bench supply now, although frame grounds are common. Time to go turn the servo shafts and watch the numbers move! Woo Hoo! Ted. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Mesa 7i43 2.2.6, Hostmot2
Does anyone have a working 7i43 setup (with hostmot2) currently? (Eric? Anders? Peter?) I shifted from step/dir drives to servo and added the 7i43 card to my system. I was previously running a functional, fully-updated-to-11Oct08 Ubuntu 8.04, EMC2 2.2.6 system with step/dir (stepper-mm, modified) to the onboard parallel port of my Epia 1 board, and have started the Slow move to full closed loop servo. The Ubuntu install was originally from a LiveCD. After lots of pre-show effort, I am starting simply inside of halrun: # components loadrt siggen loadrt hostmot2 loadrt hm2_7i43 config=firmware=hm2/7i43/SV8B.BIT num_encoders=1 num_pwmgens=1 num_stepgens=1 loadrt threads name1=tt period1=10 # parameter values setp hm2_7i43.0.gpio.P3.047.invert_outputFALSE setp hm2_7i43.0.gpio.P3.047.is_output TRUE setp siggen.0.update.tmax0 # realtime thread/function links addf hm2_7i43.0.read tt addf hm2_7i43.0.write tt addf siggen.0.update tt When this is run (either manually typing or loading from CL, the 7i43 inits, loads and reacts as expected; done and init flash, and go out. 7i43 is set for EPP config, power always on, external 5v (with external 5v connected!) Epia parport is set for EPP mode in BIOS. My sandbox was obviously symlinked, else the firmware wouldn't have been found. Now, when I view 047.out on halmeter, and toggle it with some setp, it changes as expected, on the halmeter. Also as expected, it does not output to the board, as the rt threads aren't actually running. So I type start, and the system locks up; no kbd, no mouse, video freeze. Siggen is just there for what would be my next stage (pin strobing) - if I could get there... I can still load and run stepper-mm (or any other parport-based setup) just fine, either by a launcher shortcut, or forcing the halfile with a CL halrun call; no rt errors or broken tasks (it appears) - the hardware in this system (less the recent 7i43 addition and its glue) has been in use for about two years now, with various versions of Mach and EMC. There is a mechanical cable swap between working with my step/dir servo drives, and the 7i43 board; so only one is attached at a time. I have read recently that the 7i43 support is still ongoing, and all the good stuff is in the trunk, not release, so I went and pulled down the HEAD (which showed the most recent entries to the hostmot2 components - 6 days ago). Couldn't compile it - so many packages missing with the LiveCD install (I stopped counting at 14!) - Python and OpenGL were the main unresolvable culprits; even tried to configure with Python disabled (--disable-python) - still wouldn't finish out. An attempted make did break my EMC2 build. So time to wipe. Thoughts? Kindest regards, Ted. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] EMC: AC Drives recommendation
Does anyone know if the CNC-fest Mazak retained its original servo drives, or if they were swapped out, and more importantly, with what? I have a Mitsu laser I'm working on with 3 AC (3phase, encoder w resolver combo)servos, but due to its age, I won't be retaining the servo drives themselves. I'd like to hear if anyone has found a good US source for 208 3ph input drives, up to 10kw (the x-axis is about 8kw, iirc) - and preferably either step/dir or +/-10v inputs. If there are any Mitsubishi friends out there that want to chat about the glory days of the HA900 motors, I'm open to that, too! Thanks, Ted. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] open loop galvanometer control
Klemen - You'll no doubt shortly get questions about how fast you want to scan, and that EMC may not be appropriately fast enough for both axes. Since graphical laser scanning is a persistence-of-vision process, the graphical image must be continuously rescanned. How fast? In the laser graphics industry (oh, right - 10 year+ veteran here - 20 watt mixed gas, 150watt YAGs - big side-of-the-mountain type shows - lots of 480volt camlock cable!)we measured vector graphics in points per second. When I started, a LaserMedia Z80 processor could do about 12000 pps with closed loop galvos (General Scanning's G120 were the defacto standard). Now a Pangolin or similar PC-driven system can do over ten times that. You absolutely must have closed loop scanning to do anything better than 20,000 pps with mirrors of mass more than 1.25 grams. The inertial mass of the mirrors and the rotor doesn't stop on a dime, and closed-loop scanning provides a reverse-kick-in-the-pants to prevent the rotor from overshooting the target. You will also not get sharp corners open-loop at faster than 1000 pps on those units. Physics just sucks that way. Finally, the MFE galvos (old workhorses that are still in use currently) are slow devices; check out the resonant frequency - 90-100 Hz - that's really as fast as you can accurately go before the rotor mass affects performance. This rating is exclusive of any mirror you attach - and the mirrors are small for a reason - a 1 square glass will shatter on its own from internal stresses if you wiggle it too much. That 100 Hz freq will go down as you increase the mirror mass. A high-performance scanning mirror is about 3-5mm square and 0.25grams mounted. Even the drop of acrylate glue was precision dispensed for balance. I should probably mention that points per second does not necessarily equal Hz; if you have a graphic with lots of anchors, corners, etc - you have a lot of points, thus to try and retain those corners, you have to go through the loop slower; if you have a 2 point line, you can get really zippy. This however should not discourage you from your development - I started out the same way and would recommend everyone experiment that way too - in fact, most of the major players in the laser entertainment industry started out the same way, less than 30 years ago. The eye will maintain vision on a 30 degree field with about a 20Hz refresh - so a 20-30Hz circle is a good graphic to start scanning. It's a good test and will let you get the phasing tuned in on your PID loop. Having a known envelope to work with is important - you may not get text and corporate logos (you didn't mention blanking) - but you'll easily accomplish lissajous patterns and good beam effects (with a powerful enough laser and atmospheric haze) that will be a good compliment to any show. The EMC challenge is how comfortable are you to interrupting the HAL translation to push in the vector data? I expect that the gcode parser may not behave quickly enough to continuously refresh without getting bogged down. A step/direction setup will be of no value here, and straight PWM will work, but you'll severely restrict your beam/projection angle. The early el-cheapo pattern scanners of yesteryear used +/-15v supplies and drivers, and not always variable drive signals - not PWM either - just -15, 0 and +15 with an RC network and clever timing. The RC network locked in your scanning speed, unfortunately, but it was cheap, sturdy and reproducible. Even recent closed-loop scanners still use bipolar supplies (your MFE unit can too - the torsion bar will self-center with zero-current applied). Your R2R ladder will work - and will be faster than a serially-commanded DAC. If you can take a PWM from EMC and make it bipolar (a few opamps here, an H-bridge there...) you'll have the basis for a good driver. The top speed of EMC processing on the HAL-side (PWM generation, etc) will likely not be a factor - again your top scanning speed with the galvos you have will be around 1000-5000 pps, once you mount mirrors. I would recommend highly, especially for the instant gratification aspect, to build the servo amps and get the galvos moving first (just put in a line-level audio signal - it's fun) so you have a known working baseline instead of trying to hunt down unknown peculiarities. Cheers, Ted. Original Msg Date: Sat, 1 Dec 2007 06:13:17 -0800 (PST) From: Klemen Dovrtel [EMAIL PROTECTED] Subject: [Emc-users] open loop galvanometer control To: emc-users@lists.sourceforge.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 I have two open loop galvanometers ( http://www.laserfx.com/Backstage.LaserFX.com/Systems/Pinouts/MFEdataLG.jpg ) which i would like to use emc controlled laser show (similar to this one: http://elm-chan.org/works/vlp/report_e.html ). I will use a hardware encoder for measuring the angle of galvanometer. I will configure hal using hal-encoder and hal-pid. I think i will manage
