Re: [Emc-developers] possible hostmot2 bug ?
Michael, It works now. Thank you so much. Christophe On 13/05/2013 19:35, Michael Haberler wrote: I think it is fixed now, please pull and rebuild - Michael Am 13.05.2013 um 18:14 schrieb Christophe Grellier c...@grellier.fr: Hello, I got my new 5i25 / 7i76 cards connected today to G203V drives. I compiled LinuxCNC rtos-integration-preview3-merged-into-master branch on Kubuntu 13.04 AMD64. RT kernel is xenomai from machine.net repo ( the precise kernel ). I get very good timings ( aroud 5000 for both threads ). So everything seems fine here. I configured the machine with PnCConf and I can move the motors. The problem is that I must shutdown the 7i76 field power before I start LinuxCNC, and power it once LinuxCNC is running. If I try to start LinuxCNC while the 7i76 field power is ON, I get this result : LINUXCNC - 2.6.0~pre Machine configuration directory is '/home/tomate/linuxcnc/configs/CNC-6048' Machine configuration file is 'CNC-6048.ini' Starting LinuxCNC... io started halcmd loadusr io started hm2: loading Mesa HostMot2 driver version 0.15 hm2_pci: loading Mesa AnyIO HostMot2 driver version 0.7 hm2_pci: discovered 5i25 at :04:00.0 hm2/hm2_5i25.0: Smart Serial Firmware Version 38 /home/tomate/linuxcnc-dev/bin/rtapi_app: symbol lookup error: /home/tomate/linuxcnc-dev/rtlib/hostmot2.so: undefined symbol: kzalloc CNC-6048.hal:9: /home/tomate/linuxcnc-dev/bin/rtapi_app exited without becoming ready CNC-6048.hal:9: insmod failed, returned -1 Shutting down and cleaning up LinuxCNC... Running HAL shutdown script hm2_pci: not loaded commandline:0: exit value: 255 commandline:0: rmmod failed, returned -1 hostmot2: not loaded commandline:0: exit value: 255 commandline:0: rmmod failed, returned -1 probe_parport: not loaded commandline:0: exit value: 255 commandline:0: rmmod failed, returned -1 motmod: not loaded commandline:0: exit value: 255 commandline:0: rmmod failed, returned -1 trivkins: not loaded commandline:0: exit value: 255 commandline:0: rmmod failed, returned -1 commandline:0: unloadrt failed Cleanup done When I run Linuxcnc when field power is off, it works fine, even though it segfaults when I quit : LINUXCNC - 2.6.0~pre Machine configuration directory is '/home/tomate/linuxcnc/configs/CNC-6048' Machine configuration file is 'CNC-6048.ini' Starting LinuxCNC... io started halcmd loadusr io started hm2: loading Mesa HostMot2 driver version 0.15 hm2_pci: loading Mesa AnyIO HostMot2 driver version 0.7 hm2_pci: discovered 5i25 at :04:00.0 hm2/hm2_5i25.0: Smart Serial Firmware Version 38 hm2/hm2_5i25.0: 34 I/O Pins used: hm2/hm2_5i25.0: IO Pin 000 (P3-01): StepGen #0, pin Direction (Output) hm2/hm2_5i25.0: IO Pin 001 (P3-14): StepGen #0, pin Step (Output) hm2/hm2_5i25.0: IO Pin 002 (P3-02): StepGen #1, pin Direction (Output) hm2/hm2_5i25.0: IO Pin 003 (P3-15): StepGen #1, pin Step (Output) hm2/hm2_5i25.0: IO Pin 004 (P3-03): StepGen #2, pin Direction (Output) hm2/hm2_5i25.0: IO Pin 005 (P3-16): StepGen #2, pin Step (Output) hm2/hm2_5i25.0: IO Pin 006 (P3-04): IOPort hm2/hm2_5i25.0: IO Pin 007 (P3-17): IOPort hm2/hm2_5i25.0: IO Pin 008 (P3-05): IOPort hm2/hm2_5i25.0: IO Pin 009 (P3-06): IOPort hm2/hm2_5i25.0: IO Pin 010 (P3-07): IOPort hm2/hm2_5i25.0: IO Pin 011 (P3-08): IOPort hm2/hm2_5i25.0: IO Pin 012 (P3-09): IOPort hm2/hm2_5i25.0: IO Pin 013 (P3-10): IOPort hm2/hm2_5i25.0: IO Pin 014 (P3-11): Encoder #0, pin Index (Input) hm2/hm2_5i25.0: IO Pin 015 (P3-12): Encoder #0, pin B (Input) hm2/hm2_5i25.0: IO Pin 016 (P3-13): Encoder #0, pin A (Input) hm2/hm2_5i25.0: IO Pin 017 (P2-01): IOPort hm2/hm2_5i25.0: IO Pin 018 (P2-14): IOPort hm2/hm2_5i25.0: IO Pin 019 (P2-02): IOPort hm2/hm2_5i25.0: IO Pin 020 (P2-15): IOPort hm2/hm2_5i25.0: IO Pin 021 (P2-03): IOPort hm2/hm2_5i25.0: IO Pin 022 (P2-16): IOPort hm2/hm2_5i25.0: IO Pin 023 (P2-04): IOPort hm2/hm2_5i25.0: IO Pin 024 (P2-17): IOPort hm2/hm2_5i25.0: IO Pin 025 (P2-05): IOPort hm2/hm2_5i25.0: IO Pin 026 (P2-06): IOPort hm2/hm2_5i25.0: IO Pin 027 (P2-07): IOPort hm2/hm2_5i25.0: IO Pin 028 (P2-08): IOPort hm2/hm2_5i25.0: IO Pin 029 (P2-09): IOPort hm2/hm2_5i25.0: IO Pin 030 (P2-10): IOPort hm2/hm2_5i25.0: IO Pin 031 (P2-11): IOPort hm2/hm2_5i25.0: IO Pin 032 (P2-12): IOPort hm2/hm2_5i25.0: IO Pin 033 (P2-13): IOPort hm2/hm2_5i25.0: registered hm2_5i25.0: initialized AnyIO board at :04:00.0 task pid=3960 emcTaskInit: using builtin interpreter /home/tomate/linuxcnc-dev/scripts/linuxcnc : ligne 717 : 3961 Erreur de segmentation (core dumped) $EMCDISPLAY -ini $INIFILE $EMCDISPLAYARGS $EXTRA_ARGS Shutting down and cleaning up LinuxCNC... Running HAL shutdown script hm2_5i25.0: dropping AnyIO board at :04:00.0 hm2/hm2_5i25.0: unregistered RTAPI_PCI: BAR 0 unmapped hm2_pci: driver unloaded
Re: [Emc-developers] lathe style toolchange patch
Andy, I think there are two questions here: 1. Should the operator interact with the control in a way that mirrors the Fanuc implementation? This includes both Txxyy tool call and G10 P100xx offset setting, even if we suspect that it wouldn't break compatibility. It also includes a way of editing a table of geometry and wear offsets with sensible names (not in the 10,000+ range). 2. How do we store the data? I think that the answer to question 1 is yes, provided that either someone is willing to rewrite tooledit or create a Glade tool table widget. The answer to question 2 is open to debate, but I've not given it too much thought because of the talk about 0MQ replacing NML (and the tool table restructuring that would come along for the ride.) The only thing that I would advise is - don't couple the wear offset to the geometry offset. The entire scheme hinges on the ability to apply the wear offset from tool X to a different tool Y. Rogge -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] lathe style toolchange patch
On 14 May 2013 15:04, Daniel Rogge dro...@tormach.com wrote: The only thing that I would advise is - don't couple the wear offset to the geometry offset. The entire scheme hinges on the ability to apply the wear offset from tool X to a different tool Y. This is the part that I don't really understand. We appear to end up with a number of dummy tools that are used only to store wear offsets. Does T44 apply wear-offsets 44 as well as geometry offset 44? If so, why not store them both in box 44? We can already apply offsets from one tool into another with G43 Hnn. I am not clear on whether the tool nn in this case would normally be a real tool, or a dummy tool set up to store alternate offsets. I guess that would be the operator's choice. The Fanuc lathe style of working makes the offsets explicitly a dummy tool. (and appears to put the _geometry_ in the dummy tool, and the wear in the real tool. This may actually make some sense, as the tool holder is likely to very rarely be changed. I just find the Fanuc approach to be rather kludgy, and it becomes even more so when forced into the LinuxCNC structure. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Hitatchi WJ200 Inverter Driver (using comp)
Ok I have integrated the wj200_vfd driver into linuxcnc src/hal/user_comps/wj200_vfd The repository is available at https://github.com/OKComputers/linuxcnc I have not yet completed the driver, I need to add command line option parsing to set the modbus communication parameters. However I have run the driver on my own machine for about 10 hours of operation now, and it is performing nicely. During my work, I discovered a bug in the comp.py program. The problem is option userinit yes generates code that will not compile. Here is a link to the commit that has the fix Is there anyone out there that can integrate that change for me? I can send a patch or do whatever is needed to help out... https://github.com/OKComputers/linuxcnc/commit/782e98456d278be90b7198ce8b552e824748f5b0 Thanks, Curtis On Wed, May 8, 2013 at 6:54 PM, Sebastian Kuzminsky s...@highlab.com wrote: On May 8, 2013, at 16:46 , Curtis Dutton wrote: Are there any pointers on how to integrate my .comp file into the Makefile system? Even examples elsewhere in the source tree would be useful. You just put your .comp in src/hal/components. Add a test if you're feeling frisky. Check out commit a307a69fc19df523668f191f21061f9d5457fef9 for an example. Hmm, you link against libmodbus, right? That might make things more complicated… -- Sebastian Kuzminsky -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] lathe style toolchange patch
Andy, T44 applies the geometry offsets for tool 44 only. T applies geometry and wear offsets for tool 44. T4402 applies geometry offsets for tool 44 and wear offsets for tool 2. Say I've got a drawing of as shaft with two diameters. Diameter 1 is 20mm +0.0/-.03mm. Diameter 2 is 30mm +.03mm/-0.0mm. If I want to hold the tolerances using only one tool, I need the ability to apply two different offsets to the same tool. G43 isn't an accepted Fanuc lathe code, so if you want programs to be compatible across LinuxCNC and Fanuc machines, you won't be using G43 to apply two different offsets. The only reason the wear offset appears to be a 'dummy tool' is that we happen to store it as a tool due to limitations of NML and the LCNC tool table. I thought about hijacking U and W offsets for wear, or adding new fields, but this seemed the most minimally invasive option (and it still has generated a lot of pushback from the developers!). I'm all for not gobbling up half the available tools to store wear offsets, but I think it should wait until the table/NML restructure. I just find the Fanuc approach to be rather kludgy, and it becomes even more so when forced into the LinuxCNC structure. It can be easy to think that some of the Fanuc stuff comes from blundering engineers or engineers who were or limited by the computing resources available at the time. I've found that every time I think that, I'm later surprised by some corner case that's elegantly handled by their implementation. I wouldn't discount the many years of experience that company has brought to bear on their variant of the G code standard. Rogge -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Hitatchi WJ200 Inverter Driver (using comp)
Curtis Dutton curtd...@gmail.com wrote: Ok I have integrated the wj200_vfd driver into linuxcnc src/hal/user_comps/wj200_vfd The repository is available at https://github.com/OKComputers/linuxcnc Great, i'll review it later today. During my work, I discovered a bug in the comp.py program. The problem is option userinit yes generates code that will not compile. Here is a link to the commit that has the fix I'll have to look closer at the bug later today. A request: it's helpful to reviewers if you put a good description of the problem you're fixing in the commit message. src/objects is not the right place for the bugfix, it should go in src/hal/utils/comp.g. src/objects is a temporary directory for files generated by the build system. Thanks for your work on this! -- Sebastian Kuzminsky -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] lathe style toolchange patch
On 14 May 2013 15:38, Daniel Rogge dro...@tormach.com wrote: Say I've got a drawing of as shaft with two diameters. Diameter 1 is 20mm +0.0/-.03mm. Diameter 2 is 30mm +.03mm/-0.0mm. If I want to hold the tolerances using only one tool, I need the ability to apply two different offsets to the same tool. There are other ways to do that, though not Fanuc-ways. One option would be to have two different tools in the same Pocket with the same Geometry and different wear. This isn't actually possible in LinuxCNC at the moment, as it enforces one tool per pocket, and doesn't understand wear at all. G43 isn't an accepted Fanuc lathe code, so if you want programs to be compatible across LinuxCNC and Fanuc machines, you won't be using G43 to apply two different offsets. I only mentioned G43 for comparison. When using G43 H you have the choice of using a dummy tool or a real tool as the place that the offset comes from. The offsets are not additive in that case, though. The only reason the wear offset appears to be a 'dummy tool' is that we happen to store it as a tool due to limitations of NML and the LCNC tool table. I thought about hijacking U and W offsets for wear, or adding new fields, but this seemed the most minimally invasive option (and it still has generated a lot of pushback from the developers!). I'm all for not gobbling up half the available tools to store wear offsets, but I think it should wait until the table/NML restructure. My concern at the moment is to not paint ourselves into a corner now, with an eye to the future restructure. If the tool data moves into a key-value store (such as Redis, which was one suggestion) then it would be possible for an one tool to have multiple wear offsets. (which would settle your multiple tolerances issue) In fact, the issue then becomes one of deciding what a tool _is_. I suspect that the answer is that the tool is only the number that appears on the tool-selected pin, and the pocket is only what appears on the pocket-selected pin. I can think of reasons that you might want multiple tools in the same pocket (gang tooling) , and multiple pockets with the same tool (duplicate tools at optimised positions in a long tool chain). I am not sure what the default behaviour would be for choosing which pocket number to broadcast in the duplicate-tool scenario, and in that situation you would probably want the wear offsets to be instance-specific. (And, in fact, it may be too intractable an issue to consider, and better handled by having physically identical tools with different tool numbers) Personally I don't mind this patch going in now, as the whole thing will hopefully be replaced relatively soon. But I would hate for us to have to compromise the new system to suit the limitations of an old Fanuc control. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] proposed feature for ARM(+) flavors: HAL GPIO pin access coordination
we have now several HAL drivers which access GPIO pins (for now in ARM builds, but I am sure the problem is more general) due to the way hardware resources are accessed in RT threads, one cannot rely on kernel coordination between different HAL drivers accessing pins; in fact drivers might have to be disabled, or at least ignored, and so cannot assumed to provide access coordination in all cases this leaves the question how different HAL drivers access GPIO pins such they dont trample on each others assumptions (that would be true for other resources as well, like PWM's, ADC's, SPI channels etc, but I start with GPIO for now) a current case is Ian's hal_bb_gpio.c driver and Charles PRU stepgen - both wiggle GPIO pins but are currently ships in the night: uncoordinated pin access, and it's just a matter of time until the support problems will surface -- here is a starting point to address the issue: The idea is to have an allocator module (gpiomap) which does the following: - view pins as an array of 0..some maximum (the latter defined by platform) - pre-reserve the pins which are unavailable for HAL drivers (eg because they might serve some other vital function, like HDMI or mmc access) - export RT methods to test, reserve and free pins at runtime - this would be used in rtapi_app_main/rtapi_app_exit of these drivers. The usage scenario looks like so: halcmd loadrt gpiomap platform=platform [reserve=list of extra reserved pins beyond platform reserved pins] # example: reserve all GPIO pins unavailable in the BeagleBone Black; ontop of those, # block pins 42 and 45 from use by other HAL drivers: halcmd loadrt gpiomap platform=bbb reserve=42,45 This gpiomap module has no RT functionality proper, it just exports some methods for use by other components: Using code (HAL drivers using GPIO pins) shall do this: - a using module should include gpiomap.h - the RT methods are: retrieve number of pins described for the current platform: int gpio_npins(void); test pin availability (to test allocate, pass reserve=1): int gpio_test_pin(int pinno, int reserve); this returns 0 on success and 0 if the pin already was allocated free a pin (usage example: rtapi_app_exit() of a HAL driver): int gpio_free_pin(int pinno); this returns 0 on success and 0 if the pin was unallocated An initial implementation of gpiomap, and an example using driver (gpiouse) is here: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/arm335x-hal-pru-module what needs to be done by driver writers (Ian and Charles, plus the folks working on RPI's for a start): to agree on a numbering convention, and macros, to uniquely map a certain platform pin onto an integer 0..maxpins this should go into header file(s) I'm happy to integrate but happily pass the buck on working out the convention -- the code is here: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/arm335x-hal-pru-module (I have merged Ian's bb-hal-gpio branch into arm335x-hal-pru-module and added the gpiomap work there). please integrate, and let me know what's missing/needs work while I dont think a full replica of kernel resource management is desirable or warranted - I think the scope is 'goof detection' here - some other resource classes might be subsumed here too (eg PWM, ADC, SPI etc); extending this scheme to multiple categories beyond GPIO shouldnt be hard. However, describing cross-dependencies between categories (eg. using PWM X disables GPIO use of pin Y) might be hard, and out of scope. - Michael -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] proposed feature for ARM(+) flavors: HAL GPIO pin access coordination
On 14 May 2013 22:21, Michael Haberler mai...@mah.priv.at wrote: halcmd loadrt gpiomap platform=platform [reserve=list of extra reserved pins beyond platform reserved pins] Would it be neater to have the drivers reserve their pins internally (in much the same way as hal_malloc is called by each driver)? The first module to be loaded wins, but any module which finds its pins pre-allocated is free to quit and moan. This does require the driver modules to be well-behaved, but does save the hal-file writer from having to rememeber the allocator function. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] proposed feature for ARM(+) flavors: HAL GPIO pin access coordination
On 14 May 2013 22:41, Michael Haberler mai...@mah.priv.at wrote: the platform and reserve flags on the gpiomap module are just there to block a standard sets of pins from use per-platform, and have an escape mechanism with reserve= if that doesnt completely fit the bill Sorry, I see that now. Reading it with a different prior assumption about what I am seeing. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC 2.6 remapping with manual tool change
On 14 May 2013 05:56, ENGELMANN Luc luc.engelm...@epf.lu wrote: Yes you are probably right, those were my thoughts too, as I can't find any error, nor in my test code (tcdemo.ngc) neither in the manual_change.ngc. I guess that the problem could come from the GCode Interpret, because after probing the correct offset length is showen in Axis TLO Z. Playing in the sim, the program simply doesn't run the probe move after the second tool. It returns immediately. I couldn't get any debugging prints to work in manual_change.ngc, so I put in an M0 pause in an attempt to check the program flow. Curiously, this pause was completely ignored, but suddenly the probe moves happen all the time. Try it, add an M0 command after the G91 on line 55 of manual_change.ngc. This shouldn't fix the bug, and I rather suspect that ignoring M0 and (debug, ….) statements might be a bug too. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC 2.6 remapping with manual tool change
Am 15.05.2013 um 00:46 schrieb andy pugh bodge...@gmail.com: On 14 May 2013 05:56, ENGELMANN Luc luc.engelm...@epf.lu wrote: Yes you are probably right, those were my thoughts too, as I can't find any error, nor in my test code (tcdemo.ngc) neither in the manual_change.ngc. I guess that the problem could come from the GCode Interpret, because after probing the correct offset length is showen in Axis TLO Z. Playing in the sim, the program simply doesn't run the probe move after the second tool. It returns immediately. I have seen that too, and I suspect a UI issue with gladevcp widgets here to exclude that, it would be helpful to reproduce the issue without any UI interaction - a 'remap' is nothing but a glorified ngc procedure call I couldn't get any debugging prints to work in manual_change.ngc, so I put in an M0 pause in an attempt to check the program flow. you probably just need to dig harder where the output goes.. see recent discussion on logging destinations ;) Curiously, this pause was completely ignored, but suddenly the probe moves happen all the time. Try it, add an M0 command after the G91 on line 55 of manual_change.ngc. This shouldn't fix the bug, and I rather suspect that ignoring M0 and (debug, ….) statements might be a bug too. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] lathe style toolchange patch
There are other ways to do that, though not Fanuc-ways. One option would be to have two different tools in the same Pocket with the same Geometry and different wear. This isn't actually possible in LinuxCNC at the moment, as it enforces one tool per pocket, and doesn't understand wear at all. G43 isn't an accepted Fanuc lathe code, so if you want programs to be compatible across LinuxCNC and Fanuc machines, you won't be using G43 to apply two different offsets. I only mentioned G43 for comparison. When using G43 H you have the choice of using a dummy tool or a real tool as the place that the offset comes from. The offsets are not additive in that case, though. I might add this is not 'Fanuc style' - it's 'lathe style'. Eg Okuma does exactly the same - I'm sure other control all do something very similar The patch is about changing the tool changing code so it closely follows industry 'standards' for cnc lathes not because we cannot already do what we want. If the tool data moves into a key-value store (such as Redis, which was one suggestion) then it would be possible for an one tool to have multiple wear offsets. (which would settle your multiple tolerances issue) I think you really have to separate the ideas of tool number, wear offset and tool offset. Heck in one Okuma manual I found they supported multiple offsets and multiple wear offsets. A single wear offset could actually be used on two different tools. T0102 and T0202 or T0102 and T0103 are all valid tool calls - even in the same program. At least on the control I used. Personally I don't mind this patch going in now, as the whole thing will hopefully be replaced relatively soon. But I would hate for us to have to compromise the new system to suit the limitations of an old Fanuc control. I want to add the patch sooner rather then later, because changes are coming and I want this style considered in that change, rather then hack it in later. I am happy Daniel wrote it. Chris M -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Hitatchi WJ200 Inverter Driver (using comp)
On 05/14/2013 08:51 AM, Sebastian Kuzminsky wrote: Curtis Dutton curtd...@gmail.com wrote: Ok I have integrated the wj200_vfd driver into linuxcnc src/hal/user_comps/wj200_vfd The repository is available at https://github.com/OKComputers/linuxcnc Great, i'll review it later today. Looks like you checked in wj200_vfd.c, which is a file that's the output of comp, was that intentional? Generated files should be generated by the build system from whatever their source is (a .comp file in this case), not checked into git directly. During my work, I discovered a bug in the comp.py program. The problem is option userinit yes generates code that will not compile. Here is a link to the commit that has the fix I'll have to look closer at the bug later today. A request: it's helpful to reviewers if you put a good description of the problem you're fixing in the commit message. src/objects is not the right place for the bugfix, it should go in src/hal/utils/comp.g. src/objects is a temporary directory for files generated by the build system. Your .comp doesn't use userinit, but there's definitely a comp bug there. Was this a bug you discovered during some testing that didn't make it into your branch? The only comp that sets 'option userinit yes' is bldc, but it doesnt set 'option userspace yes', so comp doesn't try to call it. Hmm, I'll update the comp docs to explicitly state that userinit only has an effect if userspace is set, and i'll update comp to fix the two syntax errors you found. Thanks for the bug report! -- Sebastian Kuzminsky -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC week at MPM/SFI
Michael and I have a room reserved at the Motel 6. It's 2 miles from the shop and about $50/night for a room with two singles. I failed to check if they have wifi, which the website says they do but for which there may be a fee. John On 05/10/2013 09:07 AM, John Kasunich wrote: I will be arriving Wednesday afternoon and leaving early Sunday morning. Haven't made hotel reservations yet, open to suggestions. On Fri, May 10, 2013, at 09:46 AM, Charles Steinkuehler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/9/2013 9:02 PM, Jon Elson wrote: Stuart Stevenson wrote: Gentlemen, Just a reminder about the week of June 17th. Give me an idea if you think you may come to Wichita that weekend. It would be nice to have an idea of how many could be here. I will set up for however many wish to be here. Looking forward to seeing everyone. Well, it is time to make reservations. I'm trying to get a sense of how many people would be arriving on Sunday or on Monday, so I can decide whether to book a room for Sunday night. I'm currently planning on coming down from Topeka on Thursday morning, and staying through Friday or Saturday evening, depending on how much time I can get away from the family. That should overlap with when Michael Haberler and John Morris are there (Wed. - Sun.). Since I'm not too far away, I can possibly come down earlier in the week as well if there are going to be some folks who will be leaving early. Sadly, I can't stay all week. :( Also, is Western Holiday still the best, or is there a better place that is still quite inexpensive for a whole week? Does Western Holiday have internet now? I'll be in the Holiday Inn or Candlewood if I have enough points for free nights, otherwise looking for whatever is the best deal for a one or two night stay. Suggestions welcome, it looks like there are a lot of choices nearby. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGM+jwACgkQLywbqEHdNFwLzACfeUizu07/qlznKzmpIBbQ6zCg 6OEAoKrQOAE5QCnqT+/bobC4Zu0qCPzA =wx/9 -END PGP SIGNATURE- -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC week at MPM/SFI
Date: Tue, 14 May 2013 23:08:34 -0500 From: j...@zultron.com To: emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] LinuxCNC week at MPM/SFI Michael and I have a room reserved at the Motel 6. It's 2 miles from the shop and about $50/night for a room with two singles. I failed to check if they have wifi, which the website says they do but for which there may be a fee. John Do you have a web address for that motel 6 and what days are you going? Weds - Sun? Chris M -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC 2.6 remapping with manual tool change
Hi Andy, On the real machine it does. The spindle comes up to the change position and waits for tool change as expected. After confirming with the tool changed button, it moves directly to the probe and is probing. I'll try to increase the debugging level in my .ini and will put the M0 in the manual_change.ngc. just to see what's happened on the real machine. I'm new to that stuff and it's difficult for me to narrow where the problem comes from, so I'm happy for all help I can get :-) MbG - Luc - -Original Message- From: andy pugh [mailto:bodge...@gmail.com] Sent: Mittwoch, 15. Mai 2013 00:47 To: EMC developers Subject: Re: [Emc-developers] LinuxCNC 2.6 remapping with manual tool change On 14 May 2013 05:56, ENGELMANN Luc luc.engelm...@epf.lu wrote: Yes you are probably right, those were my thoughts too, as I can't find any error, nor in my test code (tcdemo.ngc) neither in the manual_change.ngc. I guess that the problem could come from the GCode Interpret, because after probing the correct offset length is showen in Axis TLO Z. Playing in the sim, the program simply doesn't run the probe move after the second tool. It returns immediately. I couldn't get any debugging prints to work in manual_change.ngc, so I put in an M0 pause in an attempt to check the program flow. Curiously, this pause was completely ignored, but suddenly the probe moves happen all the time. Try it, add an M0 command after the G91 on line 55 of manual_change.ngc. This shouldn't fix the bug, and I rather suspect that ignoring M0 and (debug, ) statements might be a bug too. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers Ce message a fait l'objet d'un traitement anti-virus. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
