Re: [Emc-users] threading Z oscillation depends on encoder PPR
Am 21.10.2009 um 07:08 schrieb Jon Elson: Haberler Michael wrote: Am 21.10.2009 um 02:40 schrieb Jon Elson: Well, there's the problem, the sampling rate is just too low. well that's what Steve said about his setup, but it's not the problem I described Well, that HalScope trace sure indicates SOMETHING is really wrong. I ... I think having the traj. planner at the servo thread rate has been standard for a couple of years, but you should check that in your hal file. loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD traj_period_nsec= [EMCMOT]TRAJ_PERIOD key=[EMCMOT]SHMEM_KEY num_joints=[TRAJ]AXES If you have a line like this, then your trajectory planner is running at a rate specified in your .ini file in the [TRAJ] section, the parameter is named TRAJ_PERIOD. that was in place as you described I'll post the config files later today, I'll remove the fluff first The fact that the error increases linearly and then suddenly reverses indicates your servos are in either current or velocity limit, and the system is completely open-loop all the time. You might look at the output of PID and see what it looks like. (I am expecting it will appear as a square wave, always on one limit or the other.) I now doubt a higher resolution encoder will help this at all. well, it's a stepper system, no PID's on the axes. Any signals (motion, axis etc) you're suggesting to plot? -Michael -- 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] threading Z oscillation depends on encoder PPR
Am 21.10.2009 um 03:04 schrieb Stephen Wille Padnos: Haberler Michael wrote: [snip] here's a halscope shot of severe Z axis oscillation: http://mah.priv.at/gallery2/main.php?g2_view=core.DownloadItemg2_itemId=70522 Could you post the config (HAL/ini) files you used to see this? Thanks - Steve Here are the configs: http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove/?root=CVS I did two runs with 45 and 500 PPR and took videos and halscope plots. The only config changes are in http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove/drehbank-k12a-hm2.hal?revision=1.1root=CVSview=markup and marked with 'Video1 setting' / 'Video2 setting'. Video - 500 PPR simulated encoder: http://www.youtube.com/watch?v=PC-xLQS72qI threading passes start around second 19 and look clean --- Video - 45 PPR simulated encoder: http://www.youtube.com/watch?v=GUpJCaqOX30 The snchronized moves are either sort-of-stable or wildly oscillating. The pass starting around second 26 shows heavy oscillation, halscope plot of such a pass: http://mah.priv.at/gallery2/main.php?g2_view=core.DownloadItemg2_itemId=70528 The pass between seconds 33-36 is sort-of-stable, although there's initally audible wobble in the move this also shows in the halscope plot: http://mah.priv.at/gallery2/main.php?g2_view=core.DownloadItemg2_itemId=70525 The gcode file is: http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove/threading-mah.ngc?revision=1.1root=CVSview=markup -Michael -- 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] threading Z oscillation depends on encoder PPR
Am 21.10.2009 um 14:33 schrieb Haberler Michael: ok, following up to myself once more: - set acceleration from 300 back to 70 - changed net spindle_rev_count encoder.1.position = motion.spindle-revs to net spindle_rev_count encoder.1.position-interpolated = motion.spindle-revs Result: problem gone completely. to sum up so far - let's call this the 'position update underrun' problem: - a low PPR encoder without using position-interpolated translates into jerky position updates into the TP (=no *updated* position values for one or several servo intervals) - jerky position updates tickle a TP behaviour which looks like oscillation but really is a catch-up game once a position update finally becomes available - the TP really cant do much better - a high servo/stepper acceleration value makes catch-up easier and less noticable, but is not a fix for the underrun problem per se - the problem shows at *slow* spindle speed, not *high* spindle speed because the servo cycle defines a lower bound - it's garbage in-garbage out. so here's my pet theory: for stable synchronized movement, there should be a *updated position value* available to the TP at least at each servo interval. To get at a ballpark figure, let's assume 1msec servo intervals, and a ridiculously low spindle rpm like 60rpm, or 1/sec. So we'd need an updated position value each msec, or 1000/sec . If the encoder has 250PPR and is in x4-mode, we'd get 1000 updated position values/sec (in theory, probably should leave some margin here). So that would be stable (hopefully) even without position-interpolated . So the lower bound on threading RPM depending on PPR would be 60 / (servo interval * PPR * pulses_per_line) in my case that would be 60/(0.001 * 45 * 4) or 333 RPM. Guess what - I tried with 240 RPM and boom, problem appears. I just tried with my lathe wether this is plausible lower limit. So I reverted to position instead of position-interpolated = motion.spindle-revs and tried some speeds (auro-optical measurement only). 360 RPM - fine 320 RPM - still ok, some wobble 270 RPM - heavy oscillation one some passes So it's actually a bit more robust than my assumption would indicate. But I'd say that is a usable ballpark formula if position-interpolated is not available. The relative speeds of updated position values and servo runs might also explain that some passes look almost ok, and on some there's heavy oscillation. Could be that if RPM is near the lower limit some passes suffer more serious underrun than others depending on load or beat effects possible fixes: - thread at high spindle speed - variant a) use a high PPR encoders and hardware q-decoder - forget about parport+encoder altogether - variant b) use a low PPR encoder + parport+ encoder + position- interpolated and live with it - use position-interpolated if available - cant underrun by definition because an updated position is computed on the fly at each servo cycle - increase servo intervals (potentially a bad idea) It seems higher acceleration isnt really a workaround, just makes the problem less noticeable. -Michael reading up on http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-10-21.txt was very helpful -- 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
[Emc-users] threading Z oscillation depends on encoder PPR
several folks (including me) reported problems with threading - namely oscillations of the spindle-synchronized feed (G33 and G76), mostly with homebrew encoders. Most people looked at their encoders and signal properties. I've isolated the problem now with a *simulated encoder* - decoder pair - it looks and sounds the same like a real encoder with same PPR. After trying with various PPR values in this setup, it turns out the problem depends on PPR - if the PPR value is set high enough the problem goes away. Here's my observation points: PPR behaviour 2000fine optically + acoustically 1000acoustically not as clean as 2000, but fine otherwise 200 ok, but Z axis definitely sounds rough 70 Z axis oscillation clearly audible 50 heavy Z axis oscillation 45 same (that's my encoder disk :-/) 4 same I had the sim-encoder RPM fixed at 240rpm. The problem shows on both the threading.ngc and lathe-g76.ngc examples. -- Even if some folks have problems with encoder noise, I think the problems more likely stem from the fact that homebrew encoders tend to have a low PPR value - that might explain some of the observations. I dont fully understand the trajectory planner, but my gut feeling it's a control loop oscillation which gets excited with the encoder quantization/noise spectrum gets too close to the loop frequency. -Michael -- 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] threading Z oscillation depends on encoder PPR
Am 21.10.2009 um 02:40 schrieb Jon Elson: Steve Blackmore wrote: .. Here, with my hardware and PC, EMC can't read pulses reliably over about 200 rpm with a 1024 encoder, which is totally impractical. Well, there's the problem, the sampling rate is just too low. well that's what Steve said about his setup, but it's not the problem I described in fact I had it appear with a 45PPR homebrew encoder funneled into a Mesanet board with firmware quadrature decoder but yes, with a decent resolution encoder my problem likely would go away and that's what I'm going to do still.. I dont get why the problem is there in the first place, which seems *not* to be a sampling issue -Michael -- 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] threading Z oscillation depends on encoder PPR
Am 21.10.2009 um 00:21 schrieb Steve Blackmore: On Tue, 20 Oct 2009 23:26:27 +0200, you wrote: several folks (including me) reported problems with threading - namely oscillations of the spindle-synchronized feed (G33 and G76), mostly with homebrew encoders. Most people looked at their encoders and signal properties. It's not only home made encoders, expensive commercial encoders have the same problem. I figured sim-encoder signals would be cleaner than any hw encoder, and if the problem shows there, it should show with hw encoders as well; and it does, so the encoder make doesnt matter I dont fully understand the trajectory planner, but my gut feeling it's a control loop oscillation which gets excited with the encoder quantization/noise spectrum gets too close to the loop frequency. Neither do I, but I tend to agree that there is some other design limitation that is not helping somewhere. I'm a CNC retard, so here's my question: where is the benefit in incrementally controlling the feed depending on continuous spindle position updates as opposed to just assuming the spindle angular speed stays constant for the next full revolution? it's a pity - I own a mill which sort of was designed as a Mach3 peripheral and it does rigid tapping fine with a 1 PPR optical reflex encoder on the spindle with Mach3 -- I do use a 5i20 so I dont think a high encoder PPR would be much of a problem here, but that leaves the parport folks in limbo -Michael -- 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] threading Z oscillation depends on encoder PPR
Am 21.10.2009 um 01:11 schrieb Andy Pugh: 2009/10/20 Haberler Michael mai...@mah.priv.at: I dont fully understand the trajectory planner, but my gut feeling it's a control loop oscillation which gets excited with the encoder quantization/noise spectrum gets too close to the loop frequency. The problem seems to be with a bad initial velocity estimate. Chris looking at axis.2.f-error it would occur to me it's not just the *initial* estimate here's a halscope shot of severe Z axis oscillation: http://mah.priv.at/gallery2/main.php?g2_view=core.DownloadItemg2_itemId=70522 Note the following error is linearly increasing until some line of code kicks the joint into higher gear which makes it reduce f-error at a similar rate. When f-error gets close to zero, the process reverses. Interestingly the maxima of f-error become slightly less over time, while the resiudal errors increase. From the plot it looks like the tp has only a limited range of discrete speed settings - for the first five f-error maxima, like 'too fast' and 'too slow'; after the sixth f-error maximum it looks like it tries with a slower speed to correct the error and figures that's too slow after all. I admit I could be reading coffee suds or an artefact in the first place. I hope I hit the relevant signals to plot after all - hints appreciated. Radek came up with a patch that gave me a huge improvement with my 50ppr bit-of-laserprint-wrapped-round-the-spindle encoder I suggest you give it a try, though it does involve compiling your own development version of EMC2 at the moment. patch: http://timeguy.com/cradek-files/emc/0001-Improve-initial-threading-synchronization.patch in fact I did my tests with that particular patch applied, as well as with the patch in git; it seemed to help a bit. But clearly it's not a stable situation. I'll retry tomorrow with vanilla, git and this patch applied and see if it makes a difference wich can be quantified with my aural analysis procedure ;-) -Michael -- 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] parport_pc and the http://linuxcnc.org/experimental/hardy/smp/ kernels
Am 09.10.2009 um 22:34 schrieb Eric H. Johnson: Michael, How recently was that updated. I just did rebuilt of smp (2.3.3) earlier this week and have just not gotten around to posting them. the files in http://linuxcnc.org/experimental/hardy/smp/ are all 22- Apr-2009 if that's what you're referring to, emc is 2.3.0 in there could I pull the smp kernel debs from you? how? regards Michael -- 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
[Emc-users] parport_pc and the http://linuxcnc.org/experimental/hardy/smp/ kernels
through the improved parport detection by Jeff Epler the parport_pc module is back in the game unfortunately parport_pc is missing from the http://linuxcnc.org/experimental/hardy/smp/ kernels, so I'm rolling my own as per hhttp://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC_With_Custom_Kernel :-/ just noting for the next build -Michael -- 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
[Emc-users] reading hal pin from python script
how would I go about coding the equivalent of halcmd getp halpin in a Python script? I'm writing a user-defined Mxxx code script in Python. It's started by halui.mdi-command and should access a value from a Pyvcp widget. thanks in advance, -Michael -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Axis ui sugar
how would I go about to display fixed components in the backplot (e.g the chuck footprint, the spindle axis or the footprint of a tool height sensor for a mill)? a suggestion (for lathe mode): how about indicating wether radius or diameter mode is in effect by either displaying an icon next to radius or diameter values in the DRO, or maybe different fonts/colors? how about displaying the mouse current coordinates in the X,Y and Z perspectives? -Michael -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] halui mdi command questions
bear with me through my learning curve.. I'm using self-built trunk via git on hardy. 1. my lathe has limit switches just outside the softlimit. Homing works fine. Also, if I jog a joint to its limit, jogging stops at the soft limit and wont bump into the limit switch, which makes me believe the limit setup is ok. However, halui.jointon-soft-max-limit remains false in this case, which leaves me puzzled. btw tripping the limit switch manually is reflected fine in halui.jointon-hard-max-limit . Does on-soft-XXX-limit work for other folks in this case? I'd be willing to gdb my way out but I'm a bit at loss where to start. 2. I'd like to run a small g-code program triggered by a pyvcp widget. halui.mdi_command looks promising, so I thought I'd use a O-word subroutine and call that from halui.mdi-command. However, I'm stuck at trying to call *any* oZZZ or ofilename subroutine even manually from MDI. Any variant which would execute a g-code sequence which is NOT currently loaded and would be pulled from a file (either ZZZ, ZZZ.ngc or oZZZ.ngc, or filename.ngc, or just filename) would give me a 'file not open' error. I'd be grateful for a *working* example of a o-word subroutine stored in an external file. I realize emcrsh might be an option (eg http://fabricationsofthemind.blogspot.com/2009/03/using-joystick-buttons-to-run-complex.html) but this strikes me as a bit involved. 3. now some real dumb question.. How do I access the current machine coordinates in G-code? I couldnt find a #5xxx register for that. I could zero G92 and use the G92 offset registers. Is there a more direct way to do this? same for tool number..how do I reference the current tool number in G-code - is there a register for that? thanks for the patience.. -Micahel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] spindle index, again - now actually got it to work with spindle-synced motion
a while ago I described how I added a simple optical encoder wheel to my lathe. Meanwhile, I eventually got it to work with G33 threading, but it wasnt as straightforward as I would have believed, so I thought I'd describe my experience. My first attempt was to use the encoder component as described in the Spindle Feedback example (User Manual chapter 34). Trying that with the threading.ngc example failed miserably - the synced-motion threading part was everything but synchronized - heavy speed variations in the Z axis (see http://www.youtube.com/watch? v=efiNyzhGFbQ , starting around second 27). I traced the problem to serious noise on the encoder.0.velocity signal (red signal in http://mah.priv.at/gallery2/main.php?g2_itemId=69102). I first tried to feed it through a lowpass (white signal) but that a) didnt work either and b) massaging a feedback signal would be counterproductive to start with. I admit that the codewheel finish left to be desired - I managed to glue it onto the pulley with maybe 0.5mm runout (the outer diameter is 18cm). And the disk isnt perfectly flat on the pulley - too much glue here and there, so the disk-sensor distance varies as well. These inaccuracies cause periodic fluctuations in the index signals, the relation to the spindle revolution can clearly be seen (note blue index pulse). So that introduced some phase noise on the signal, and that in turn causes the position estimate to fluctuate wildly, hence causing the strange Z move pattern. Adjusting the sensors and pulley brought some improvement but not sufficient. So I played around with encoder options. The fix was finally to turn off x4-mode and use encoder.0.position- interpolated instead of encoder.0.position to feed into motion.spindle- revs. The noise is pretty much gone (http://mah.priv.at/gallery2/main.php?g2_itemId=69105 ) - except for the wobble introduced by the runout of the codewheel (which btw can be clearly heard from the Z stepper during the threading run :-). The setup works fine for threading now, but I'll eventually change this to a more precise encoder wheel. hal of test setup is at: http://mah.priv.at/cgi-bin/viewvc.cgi/emc-drehbank-test/drehbank-k12a.hal?revision=1.6root=CVSview=markup out of curiosity - anybody got spindle-synced motion with *just* an index puls (1ppr) to work? -Michael btw - I'm stunned by EMC2's capabilities - great piece of work, folks! -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Sunix Sun1888 parports broken in in-mode
after spending disordinate amounts of time I'd warn folks to use Sunix chipset parallel port cards I have several Sunix 4008T parallel pci cards (distributed by Digitus) which show the same symptom: one cannot reliably set 'in' mode for pins 02-09. They seem to work ok in default (out) mode. After swapping for a card with Netmos 9835 chipset (1xparallel, 2xserial) all problems in in-mode are gone. -Michael emc2 version is 2.4.0 pre . -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] EMC2 Developer Manual - broken pdf
it seems the PDF linked from the Wiki http://www.linuxcnc.org/docs/devel/EMC2_Developer_Manual.pdf ist broken -Michael -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Modbus driver for Toshiba VF-S11 VFD available
I've finished a first release of a HAL userspace component to drive a Toshiba VF-S11 VFD via Modbus, vfs11_vfd. It's adapted from gs2_vfd.c and works fine for me so far. A description how to connect the VFD and set initial parameters is included. I would assume that folks with other Modbus-capable VFD's find vfs11_vfd a bit easier to adapt than gs2_vfd because it is not assumed that register range are continuous, or multiple holding reagister read/writes are availaible. Code, manpage etc currently is at http://mah.priv.at/cgi-bin/viewvc.cgi/vfs11_vfd/?root=CVShideattic=1 . Code should go into src/hal/user_comps and added to the Submakefile like gs2_vfd, then make. Bug reports success stories are welcome. -Michael ps: I'd appreciate a hint as to how to socially-compatible add this to the EMC2 tree. Thanks. -- 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/Challenge ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Modbus command line utility Toshiba VF-S11 VFD results
ok, along my quest towards VFD control via Modbus I didnt find an appropriate command line utility to talk to Modbus, so I wrote one. It helped me de-mystifying how to work with the Toshiba VF-S11; results, VFD setup instructions and sample control files are included. I think now I'll actually be able to adapt gs2_vfd.c for the VF-S11. And eventually also for the other make I have, a pdrive MX. Maybe this is useful for other people. see http://mah.priv.at/cgi-bin/viewvc.cgi/modio/?root=CVS . -Michael -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Adapter for Toshiba VFS-11 VFD / RS232 for Modbus control
just in case anybody has a Toshiba VFD and wants to play with Modbus - here's a working adapter. It's *almost* standard TTL RS232. Schematic: http://static.mah.priv.at/cnc/vfs11-rs232.pdf The circuit is based on recommendations by Toshiba support (who were very friendly, helpful and thorough). -Michael -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] spindle index, once more
my lathe was lacking a spindle index sensor and quadrature encoder, so I built one as follows: The code rings are printed on plain paper with an inkjet printer, and laminated into a plastic pouch; then cut with a scissor and glued to the spindle pulley (with some pressure so as to get a reasonably flat surface). The pulley on my lathe is 18cm in diameter and has about 2cms wide space for the code rings. Laminating the paper into the a plastic pouch protects the printout very well against oil and cooleant. The sensor are reflex couplers - I had CNY70's at hand, so I used those. The schematic is unspectacular: http://static.mah.priv.at/cnc/index.pdf . The couplers are mounted at about 1.5mm distance from the codewheel. - edit codewheel parameters in the Postscript source file to your liking: http://static.mah.priv.at/cnc/codewheel.ps - the parameters are reasonably documented. Pictures: http://mah.priv.at/gallery2/main.php?g2_itemId=68003 -Michael -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] spindle index, once more
Am 30.06.2009 um 17:09 schrieb Andy Pugh: 2009/6/30 Haberler Michael mai...@mah.priv.at: The code rings are printed on plain paper with an inkjet printer, and laminated into a plastic pouch Interesting. When I tried a similar approach using clear tape I found that the reflectivity of the tape in the frequency range of the detectors was so high that the underlying colour was irrelevant. I didnt try different colours but tried b/w on paper versus black stripes on a transparent slide, so the reflection would come from the aluminum pulley. The latter gave somewhat higher voltage swings on the coupler's collector, but the glue used to attach the ring would deteriorate things again (and dissolve the ink if glued onto the pulley without laminating), so I settled for the paper variant. Laser printers do give worse results than inkjet. The pouches came with the laminator. I mounted the sensors quite close so they'd focus on the paper and not the reflective surface (and due to lack of space :-). Angular displacement turned out to be fairly uncritical. Is there any sign of interference from your VFD on the sensor pulses? I am finding that a bit of a problem. no, actually not. In fact the cable is unshielded but I'm going to change that in the final setup. -Michael btw - there are two flavours of CNY70 in the wild, and some have collector and emitter reversed - make sure to identify the manufacturer and get the proper data sheet. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Micro-controllers
Am 02.06.2009 um 21:23 schrieb Kirk Wallace: . I haven't found the specs for the PWM feature yet. Can I assume that I can get above 20kHz? The rest of the features will be fluff. Yes you can. Assuming you have a say, 12Mhz crystal, and do not prescale the clock, an 8bit PWM would run at 47kHz. A 16bit PWM signal would run at 183Hz though. I'll take the AVR's over PICs any day given the quirky architecture of the PICs. I feel like I'm back in the 8086 century with its odd segmented architecture. For german speaking folk www.mikrocontroller.net is the place to go to get up to speed. -Michael -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] modbus integration . design question
Hi I have two VFD's (a pDrive MX eco and a Toshiba VF-S11) both of which are Modbus-capable and I'd like to integrate into Emc. I've read the GS2 VFD driver, and adapting this good example would be an option. It seems Modbus integration comes up frequently though. I'd be curious what people think about a generic userspace hal component to deal with different Modbus devices (without going through ClassicLadder), and what would be good design choices to map Modbus read/write commands to signals and parameters in a generic fashion. On an abstract level, I'd see a parameter being mapped to one or several register writes, possibly with some arithmetic and boolean expressions applied; on the input side: certain registers or 'coils' being read, fed through expressions and resulting in signals. A generic, configurable python component might be an option. Is it worth the effort? or should I just go ahead and adapt the gs2 driver for each component? -Michael I am a newbie in automation bus matters, but I'd assume other control software has the same problem (plus dealing with other buses). -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
