Re: [Emc-users] Stepper configuration
Sebastian, Thanks. A couple more questions. 1 I assume I will have to build from source to use hostmot2? 2 On an m5i20, how do you use the general purpose I/O? I don't see, for instance, the equivalents of: addf m5i20.0.misc-update servo-thread 1 addf m5i20.0.digital-in-read servo-thread 1 addf m5i20.0.digital-out-write servo-thread -1 3 What are the pinouts? Do they remain the same for P3 and P4 as with the standard m5i20 configuration. Regards, Eric Do you know anything about hostmot2? I see it has step and pwm, but did not see a sample configuration on how to use it. Is it completed or still a work in progress? hostmot2 is still a work in progress, but i think it's ready for more widespread testing. I've added a very simple incomplete sample config, it's in CVS (TRUNK and the 2.2 branch) but it's not in the released 2.2.5 package. It will be in 2.2.6 which is dues out real soon now. You can see the sample configs here: http://cvs.linuxcnc.org/cvs/emc2/configs/hostmot2/ or here: http://bazaar.launchpad.net/~seb-highlab/emc/hostmot2/files/470?file_id=hos tmot2-20080704040329-dmc6hkstgm2r40ep-1 - 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
Re: [Emc-users] Stepper configuration
On Sat, 9 Aug 2008, Eric H. Johnson wrote: Date: Sat, 9 Aug 2008 09:19:44 -0400 From: Eric H. Johnson [EMAIL PROTECTED] Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: 'Enhanced Machine Controller (EMC)' emc-users@lists.sourceforge.net Subject: Re: [Emc-users] Stepper configuration Sebastian, Thanks. A couple more questions. 1 I assume I will have to build from source to use hostmot2? 2 On an m5i20, how do you use the general purpose I/O? I don't see, for instance, the equivalents of: addf m5i20.0.misc-update servo-thread 1 addf m5i20.0.digital-in-read servo-thread 1 addf m5i20.0.digital-out-write servo-thread -1 3 What are the pinouts? Do they remain the same for P3 and P4 as with the standard m5i20 configuration. If you download the 5I20 support package from Mesa, the pinout files for some HostMot2 configurations are in the HOSTMOT2 directory, they are .PIN files. I think Sebastians driver can print out the pinouts as well (the pinout is embedded in the FPGA configuration). Regards, Eric Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. - 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
Re: [Emc-users] Stepper configuration
[EMAIL PROTECTED] wrote: For now you have to build from source to get hostmot2. It will be in 2.2.6 when it comes out, which might be as early as this weekend. Hostmot2 treats the board I/O pins differently than previous firmwares drivers. High-level functions like stepgen, pwmgen, encoder by default own all the pins, but you can (at module load time) disable the stepgens etc that you don't want. The pins of the disabled module instances become gpios and are exported to HAL.. Hostmot2 gpios are read and written along with all the other stuff (stepgen, pwmgen, etc) by the per-board read and write functions. Hmmm - that means that the general purpose I/O is limited to the speed at which you update everything else. Was that decision driven by some architectural requirement, or just convenience? How hard would it be to pull the GPIO update code into it's own HAL function? Oh, I be I know the issue - it's the parport (EPP) interfaced boards. You can't share the EPP bus between threads. That issue doesn't exist for the PCI boards, but the unified driver architecture is limited by the least capable of the interfaces. The hostmot2 pinouts are almost certainly different than the ones in the other 5i20 firmwares drivers. The pinout used is determined by the firmware loaded and the configuration chosen by the user. The pinout used is written to the system log when the driver is loaded. It can't be too different if it is going to work with the existing interface boards like the 7i33, 7i37, etc. I've tried to describe how all this works in the hostmot2 manpage, take a look at it and let me know what parts of it are unclear or incomplete. Regards, John Kasunich - 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
Re: [Emc-users] Stepper configuration
John Kasunich wrote: [EMAIL PROTECTED] wrote: For now you have to build from source to get hostmot2. It will be in 2.2.6 when it comes out, which might be as early as this weekend. Hostmot2 treats the board I/O pins differently than previous firmwares drivers. High-level functions like stepgen, pwmgen, encoder by default own all the pins, but you can (at module load time) disable the stepgens etc that you don't want. The pins of the disabled module instances become gpios and are exported to HAL.. Hostmot2 gpios are read and written along with all the other stuff (stepgen, pwmgen, etc) by the per-board read and write functions. Hmmm - that means that the general purpose I/O is limited to the speed at which you update everything else. Was that decision driven by some architectural requirement, or just convenience? How hard would it be to pull the GPIO update code into it's own HAL function? It was a (perhaps misguided) deliberate decision. The old (now deprecated) m7i43_hm2 driver has individual read/write functions for gpio, stepgen, pwmgen, etc, but I just didnt see the value of it. I found myself with a single HAL thread like this: read_gpio() read_stepgen() read_encoder() do_pid() do_other_stuff() write_pwmgen() write_stepgen() write_gpio() Then when I wrote the hostmot2 driver I decided to put all the reads together in one function and all the write in another. This setup (together with the HostMot2 firmware TranslationRAM feature) also makes DMA accelleration easier and more effective, which is one of my long-term goals for the hostmot2 driver. Other than that DMA consideration, there's no reason the hostmot2 driver can't export different functions for different modules. What's a use case where it's valuable to read/write the modules separately? Oh, I be I know the issue - it's the parport (EPP) interfaced boards. You can't share the EPP bus between threads. That issue doesn't exist for the PCI boards, but the unified driver architecture is limited by the least capable of the interfaces. I believe it's fine to share the EPP bus between RTAI threads, because I believe RTAI threads (at least as used by HAL) are not pre-emptable. Isn't that true? The m7i43_hm2 driver has the I/O for the different firmware modules in different functions, but I never tried running the functions from different threads. The hostmot2 pinouts are almost certainly different than the ones in the other 5i20 firmwares drivers. The pinout used is determined by the firmware loaded and the configuration chosen by the user. The pinout used is written to the system log when the driver is loaded. It can't be too different if it is going to work with the existing interface boards like the 7i33, 7i37, etc. That's true - all the existing firmware images mate up well with the other Mesa products. -- Sebastian Kuzminsky You think you can defeat me with your rebellious beard? http://www.youtube.com/watch?v=k_QAPjtO2cA - 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
Re: [Emc-users] Stepper configuration
Sebastian Kuzminsky wrote: John Kasunich wrote: [EMAIL PROTECTED] wrote: For now you have to build from source to get hostmot2. It will be in 2.2.6 when it comes out, which might be as early as this weekend. Hostmot2 treats the board I/O pins differently than previous firmwares drivers. High-level functions like stepgen, pwmgen, encoder by default own all the pins, but you can (at module load time) disable the stepgens etc that you don't want. The pins of the disabled module instances become gpios and are exported to HAL.. Hostmot2 gpios are read and written along with all the other stuff (stepgen, pwmgen, etc) by the per-board read and write functions. Hmmm - that means that the general purpose I/O is limited to the speed at which you update everything else. Was that decision driven by some architectural requirement, or just convenience? How hard would it be to pull the GPIO update code into it's own HAL function? It was a (perhaps misguided) deliberate decision. The old (now deprecated) m7i43_hm2 driver has individual read/write functions for gpio, stepgen, pwmgen, etc, but I just didnt see the value of it. I found myself with a single HAL thread like this: read_gpio() read_stepgen() read_encoder() do_pid() do_other_stuff() write_pwmgen() write_stepgen() write_gpio() Then when I wrote the hostmot2 driver I decided to put all the reads together in one function and all the write in another. This setup (together with the HostMot2 firmware TranslationRAM feature) also makes DMA accelleration easier and more effective, which is one of my long-term goals for the hostmot2 driver. Other than that DMA consideration, there's no reason the hostmot2 driver can't export different functions for different modules. What's a use case where it's valuable to read/write the modules separately? Mostly something like the arrangement Kirk Wallace has - software stepping, using the GPIO for the step pulses. You might ask why do software stepping when there is hardware stepping available? In many cases that is a darned good question, but in Kirk's case, I don't think the existing firmwares supported hardware stepping. There is also the case where you need one more channel of stepping, or encoder counting, or whatever, and you don't necessarily need the full hardware performance. For example, the Mazak at the CNC workshop uses a 4-channel Motenc board. Three encoder channels are used for X, Y, and Z, and the fourth is used to count the spindle encoder for spindle orient and rigid tapping. We used a software encoder counter and two GPIO pins for the jogwheel, since it doesn't spin fast enough to require hardware counting. The GPIO is the _only_ portion that I think would be nice to have in a separate function, I agree completely with your logic for merging the rest. Oh, I be I know the issue - it's the parport (EPP) interfaced boards. You can't share the EPP bus between threads. That issue doesn't exist for the PCI boards, but the unified driver architecture is limited by the least capable of the interfaces. I believe it's fine to share the EPP bus between RTAI threads, because I believe RTAI threads (at least as used by HAL) are not pre-emptable. Isn't that true? Not true. Threads are interruptable, based on priority. Fast threads are higher priority than slow ones, under the assumption that the code in a 1mS thread might take 200uS to execute, and a 25uS thread might need to interrupt it and run a few uS worth of code several times. The m7i43_hm2 driver has the I/O for the different firmware modules in different functions, but I never tried running the functions from different threads. Regards, John Kasunich - 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
Re: [Emc-users] Stepper configuration
John Kasunich wrote: Sebastian Kuzminsky wrote: John Kasunich wrote: What's a use case where it's valuable to read/write the modules separately? Mostly something like the arrangement Kirk Wallace has - software stepping, using the GPIO for the step pulses. You might ask why do software stepping when there is hardware stepping available? In many cases that is a darned good question, but in Kirk's case, I don't think the existing firmwares supported hardware stepping. There is also the case where you need one more channel of stepping, or encoder counting, or whatever, and you don't necessarily need the full hardware performance. For example, the Mazak at the CNC workshop uses a 4-channel Motenc board. Three encoder channels are used for X, Y, and Z, and the fourth is used to count the spindle encoder for spindle orient and rigid tapping. We used a software encoder counter and two GPIO pins for the jogwheel, since it doesn't spin fast enough to require hardware counting. Heh, the way to do that with HostMot2 is to email Peter and ask for a new firmware image with an extra stepgen and encoder. :-) Or just change a couple of constants at the top of the VHDL and compile it yourself (assuming you have enough gates pins). The new VHDL source (not in CVS yet) makes this kind of tweaking really easy. I believe it's fine to share the EPP bus between RTAI threads, because I believe RTAI threads (at least as used by HAL) are not pre-emptable. Isn't that true? Not true. Threads are interruptable, based on priority. Fast threads are higher priority than slow ones, under the assumption that the code in a 1mS thread might take 200uS to execute, and a 25uS thread might need to interrupt it and run a few uS worth of code several times. That make sense. I stand corrected. -- Sebastian Kuzminsky You think you can defeat me with your rebellious beard? http://www.youtube.com/watch?v=k_QAPjtO2cA - 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
Re: [Emc-users] Stepper configuration
Not true. Threads are interruptable, based on priority. Fast threads are higher priority than slow ones, under the assumption that the code in a 1mS thread might take 200uS to execute, and a 25uS thread might need to interrupt it and run a few uS worth of code several times. Sounds like the simplest compromise would be to separate the GPIO update call from the others, so GPIO could be accessed via a different thread, with the proviso the EPP based cards cannot use multiple threads (though this may be fixable with some magic save/restore context foo) Regards, John Kasunich - 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 Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. - 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
Re: [Emc-users] Stepper configuration
How valuable is it for hostmot2 to have stand-alone gpio access (for the PCI cards only)? It seems like sort of a klunky interface. The differentiating feature of hostmot2 is the flexible firmware, which solves this problem very neatly. So I still think the current interface is the right one, and the solution to the problem JMK described is to compile another firmware image. -- Sebastian Kuzminsky never be discouraged just let your nerdy flourish -Original Message- From: Peter C. Wallace [EMAIL PROTECTED] Subj: Re: [Emc-users] Stepper configuration Date: Sat 2008 Aug 9 11:53 Size: 1K To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Not true. Threads are interruptable, based on priority. Fast threads are higher priority than slow ones, under the assumption that the code in a 1mS thread might take 200uS to execute, and a 25uS thread might need to interrupt it and run a few uS worth of code several times. Sounds like the simplest compromise would be to separate the GPIO update call from the others, so GPIO could be accessed via a different thread, with the proviso the EPP based cards cannot use multiple threads (though this may be fixable with some magic save/restore context foo) - 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
Re: [Emc-users] Stepper configuration
[EMAIL PROTECTED] wrote: How valuable is it for hostmot2 to have stand-alone gpio access (for the PCI cards only)? It seems like sort of a klunky interface. The differentiating feature of hostmot2 is the flexible firmware, which solves this problem very neatly. So I still think the current interface is the right one, and the solution to the problem JMK described is to compile another firmware image. There are arguments both ways. I agree that separate GPIO is a bit klunky. But on the other hand, compile another firmware image immediately takes it out of the reach of 99% of users, no matter how simple the VHDL is. The Xilinx toolset is a gigabyte+ download, and is not trivial to figure out how to use it. You might as well be telling them write another driver. In fact, they are more likely to have a C compiler and C programming skills than the Xilinx toolset and VHDL skills, and we have a makefile that handles the complexities of the build. Regards, John Kasunich - 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
Re: [Emc-users] Stepper configuration
On Sat, 2008-08-09 at 13:17 -0400, John Kasunich wrote: ... snip Mostly something like the arrangement Kirk Wallace has - software stepping, using the GPIO for the step pulses. You might ask why do software stepping when there is hardware stepping available? In many cases that is a darned good question, but in Kirk's case, I don't think the existing firmwares supported hardware stepping. There is also the case where you need one more channel of stepping, or encoder counting, or whatever, and you don't necessarily need the full hardware performance. For example, the Mazak at the CNC workshop uses a 4-channel Motenc board. Three encoder channels are used for X, Y, and Z, and the fourth is used to count the spindle encoder for spindle orient and rigid tapping. We used a software encoder counter and two GPIO pins for the jogwheel, since it doesn't spin fast enough to require hardware counting. ... snip Most of this thread is Greek to me, but my Shizuoka is my only stepper machine. I set it up with parallel port software encoder decoders and stepping because I could do it 'quick and dirty' without spending any money, plus I needed quadrature stepping output. It turned out that this setup drove the steppers (half-stepping) to their highest speed before stalling, with some to spare, so there isn't much incentive to use additional hardware. The plan is to go to servos in the future. A little off topic, because at a given step rate the A and B frequency is half the step rate, I was thinking that the quadrature output would double the effective max stepping rate. The more I think about this though, that is only true if the hardware pin frequency is the limiting factor. The stepping rate is limited by the max base-thread rate and will be the same no matter the form the output takes? After I got the Shizuoka set up, I got a Pluto-P. It doesn't output quadrature steps, but step/dir is easy to convert to quadrature isn't it? -- Kirk Wallace (California, USA http://www.wallacecompany.com/machine_shop/ Hardinge HNC/EMC CNC lathe, Bridgeport mill conversion, doing XY now, Zubal lathe conversion pending Craftsman AA 109 restoration Shizuoka ST-N/EMC CNC) - 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
Re: [Emc-users] Stepper configuration
John Kasunich wrote: [EMAIL PROTECTED] wrote: How valuable is it for hostmot2 to have stand-alone gpio access (for the PCI cards only)? It seems like sort of a klunky interface. The differentiating feature of hostmot2 is the flexible firmware, which solves this problem very neatly. So I still think the current interface is the right one, and the solution to the problem JMK described is to compile another firmware image. There are arguments both ways. I agree that separate GPIO is a bit klunky. But on the other hand, compile another firmware image immediately takes it out of the reach of 99% of users, no matter how simple the VHDL is. The Xilinx toolset is a gigabyte+ download, and is not trivial to figure out how to use it. You might as well be telling them write another driver. In fact, they are more likely to have a C compiler and C programming skills than the Xilinx toolset and VHDL skills, and we have a makefile that handles the complexities of the build. Agreed, telling a user to compile custom firmware is not reasonable. However, telling them to email Peter is, and that's actually already happened. Peter produced a firmware with the requested number of stepgens, pwmgens, and encoders in basically no time, and it worked with no changes to the driver or anything else. But even so: sometimes you might not be on the net, or Peter might be busy with something else, or it might just not be convenient for some other reason. Having the existing firmware driver be able to do something reasonable for you in that situation would be nice. I could add a threadsafe flag to the board driver struct, which gets set by the board driver if the board I/O hardware is thread safe (PCI), and cleared if it's not (EPP). The high-level hostmot2 driver would examine this and only export the full read()/write() functions if the board driver is not thread safe. If the board driver *is* thread safe, the hostmot2 driver would in addition export gpio_read()/gpio_write(). The PCI drivers would work just as well as they would if hostmot2 didnt have to care about thread safety in the low-level drivers. The EPP drivers would work just as poorly as they would in any case (ie, no quick access to gpios). But at least they wouldnt be broken like the m7i43_hm2 driver is, due to my earlier misunderstanding of RTAI multitasking model! -- Sebastian Kuzminsky You think you can defeat me with your rebellious beard? http://www.youtube.com/watch?v=k_QAPjtO2cA - 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
Re: [Emc-users] Stepper configuration
On Sat, 9 Aug 2008, Sebastian Kuzminsky wrote: Date: Sat, 09 Aug 2008 15:13:34 -0600 From: Sebastian Kuzminsky [EMAIL PROTECTED] Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Subject: Re: [Emc-users] Stepper configuration I could add a threadsafe flag to the board driver struct, which gets set by the board driver if the board I/O hardware is thread safe (PCI), and cleared if it's not (EPP). The high-level hostmot2 driver would examine this and only export the full read()/write() functions if the board driver is not thread safe. If the board driver *is* thread safe, the hostmot2 driver would in addition export gpio_read()/gpio_write(). The PCI drivers would work just as well as they would if hostmot2 didnt have to care about thread safety in the low-level drivers. That sounds like a good solution. Never know what people may want to do with the GPIO pins, so if fast thread access is possible in the hardware, the driver should allow access. The EPP drivers would work just as poorly as they would in any case (ie, no quick access to gpios). But at least they wouldnt be broken like the m7i43_hm2 driver is, due to my earlier misunderstanding of RTAI multitasking model! -- Sebastian Kuzminsky You think you can defeat me with your rebellious beard? http://www.youtube.com/watch?v=k_QAPjtO2cA - 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 Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. - 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] M19C45
Hi I am interesting in M19C(0-360) operation or spindle oriented stop. MAZAK has that option because MAZAK should stop spindle oriented to tool changer can taker tool out. I am interesting is any good setting of hardware – motor with driver that can be used with EMC2 that will use M19C(0-360) code? Thanks aram - 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] etch-servo pwm output to servo amp's input?
Tonight I hooked up the jogwheel and one of the motor's encoders (100 line and 2500 lines) to the parport, and with turning up the ferror in the ini I can use it like a DRO, turning the encoders moves the axis readings. I was wondering if i could just build an H bridge or similar switching circuit to run the output between the -12 and +12V rails on an AT or AT power supply, maybe use 7809 and 7909 regulators to keep it below 10V, to run to the analog VCMD input on the servo amp? the manual to the mill says that it runs +/- 9V, which seems odd compared to everything else. Then I'll have to likely put in a couple switches on the a and b's of the encoders to send the quadrature to both the amp and back to EMC. If I managed my math right, if i can get the parport sampling at 30 khz (i think i read somewhere that that should be realistic) I should be able to keep track of 180 RPM or so on the encoders, if everything stays ideal. Also, what do I need to add in the hal and everything to enable an index on the encoders? I'm thinking I can see if it is missing counts if I have an index to reference. I hope all of this makes sense, its been a long day and I'm excited I've actually made a little progress. Thanks guys, Jim Coleman - 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
Re: [Emc-users] Stepper configuration
Sebastian Kuzminsky wrote: I could add a threadsafe flag to the board driver struct, which gets set by the board driver if the board I/O hardware is thread safe (PCI), and cleared if it's not (EPP). The high-level hostmot2 driver would examine this and only export the full read()/write() functions if the board driver is not thread safe. If the board driver *is* thread safe, the hostmot2 driver would in addition export gpio_read()/gpio_write(). If RTAI supported mutexes and thread-blocking, then fast gpio access could be easily done even on the EPP boards. Instead of low-level drivers exporting a threadsafe flag, the high-level hostmot2 driver would create a mutex for each board, to make sure at most one RTAI thread was executing in the low-level driver's read()/write() code at a time. If another thread wanted to access the board, it would try to lock the mutex and block until the first user was done. It looks like rtai has semaphores but doesnt support blocking in the kernel (no run queues). Maybe something like spinlocks could be built around the non-blocking semaphore calls. Any comments on this? Anyone know RTAI? -- Sebastian Kuzminsky You think you can defeat me with your rebellious beard? http://www.youtube.com/watch?v=k_QAPjtO2cA - 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
Re: [Emc-users] etch-servo pwm output to servo amp's input?
On Sat, 2008-08-09 at 22:34 -0400, Jim Coleman wrote: Tonight I hooked up the jogwheel and one of the motor's encoders (100 line and 2500 lines) to the parport, and with turning up the ferror in the ini I can use it like a DRO, turning the encoders moves the axis readings. I was wondering if i could just build an H bridge or similar switching circuit to run the output between the -12 and +12V rails on an AT or AT power supply, maybe use 7809 and 7909 regulators to keep it below 10V, to run to the analog VCMD input on the servo amp? the manual to the mill says that it runs +/- 9V, which seems odd compared to everything else. Then I'll have to likely put in a couple switches on the a and b's of the encoders to send the quadrature to both the amp and back to EMC. If I managed my math right, if i can get the parport sampling at 30 khz (i think i read somewhere that that should be realistic) I should be able to keep track of 180 RPM or so on the encoders, if everything stays ideal. It sounds like you want to go directly from a jog wheel to a motor driver for axis movement. Then have EMC as a DRO. If that is the case, why not have EMC2 do the motion control and do manual machining with the jog wheel through EMC2? This is the normal setup. The hardware would be the same except you wouldn't need to build an encoder to motor drive interface. This could be tricky because the jog wheel is a position device and the amp input is a velocity signal. One unit change on the jog wheel doesn't correspond to a particular amp signal. I would look into setting up EMC2 to have a two parallel port pins for PWM Forward and PWM Reverse. Each of these could feed an opto-coupler that would switch your +9 or -9 Volts to convert them to a PWM modulated analog signal for your amp input. I am not sure of the details, and there might be vastly better ways to do this, but this is just to convey an idea of how EMC2 could output a voltage (velocity) that your amps need and have EMC2 do the position thing from the encoder feedback. Also, what do I need to add in the hal and everything to enable an index on the encoders? I'm thinking I can see if it is missing counts if I have an index to reference. I think you would need to write a custom component that reads the software decoder counter on the first index trigger and then compares that with subsequent counts on index to see if they happen on multiples of encoder counts per rev. I wouldn't mind seeing more background error checking of hardware subsystems. I hope all of this makes sense, its been a long day and I'm excited I've actually made a little progress. Thanks guys, Jim Coleman Are you doing more than one project? I thought you where well along on a mill conversion. Could you give us a summary of what you are doing? -- Kirk Wallace (California, USA http://www.wallacecompany.com/machine_shop/ Hardinge HNC/EMC CNC lathe, Bridgeport mill conversion, doing XY now, Zubal lathe conversion pending Craftsman AA 109 restoration Shizuoka ST-N/EMC CNC) - 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
Re: [Emc-users] Stepper configuration
Sebastian Kuzminsky wrote: Sebastian Kuzminsky wrote: I could add a threadsafe flag to the board driver struct, which gets set by the board driver if the board I/O hardware is thread safe (PCI), and cleared if it's not (EPP). The high-level hostmot2 driver would examine this and only export the full read()/write() functions if the board driver is not thread safe. If the board driver *is* thread safe, the hostmot2 driver would in addition export gpio_read()/gpio_write(). If RTAI supported mutexes and thread-blocking, then fast gpio access could be easily done even on the EPP boards. Instead of low-level drivers exporting a threadsafe flag, the high-level hostmot2 driver would create a mutex for each board, to make sure at most one RTAI thread was executing in the low-level driver's read()/write() code at a time. If another thread wanted to access the board, it would try to lock the mutex and block until the first user was done. No no no... that way lies priority inversion (http://en.wikipedia.org/wiki/Priority_inversion) and locked up computers. If the servo thread happens to be accessing the board when the base thread starts, and the base thread wants to access the board, what happens? The base thread can't busy-wait - as long as it is running, the servo thread will never run, so it will never release the mutex. It can't just yield the CPU to the servo thread - that thread is a lower priority for a reason. Who knows how long it will keep the mutex, and how many other base thread interrupts might arrive in the meantime. This is a well known problem in task scheduling. There are some techniques, such as priority inheritance (http://en.wikipedia.org/wiki/Priority_inheritance), but none of them are guaranteed, and all of them are complex. If a lower priority thread holds a mutex, the only thing a higher priority thread can do is simply skip accessing the device, and hope that by the next time the thread runs, the mutex will have been freed. Of course, that risks completely missing a step pulse or encoder count. The simple fact is that the EPP bus is NOT shareable between realtime threads. That is only one of the reasons why (in my humble opinion) the PCI based 5i2x family is so much better than the EPP based 7i43 family. HAL (and EMC2) uses Rate Monotonic Scheduling (http://en.wikipedia.org/wiki/Rate_Monotonic_Scheduling) which is the simplest way to guarantee meeting realtime schedules and avoid deadlocks. However, you simply _cannot_ share a resource between threads. Changing the scheduling/priority algorithms is not something to be done lightly. I think it is perfectly reasonable for those who are using the EPP bus to have to live with GPIO accesses in the servo thread only. It looks like rtai has semaphores but doesnt support blocking in the kernel (no run queues). Maybe something like spinlocks could be built around the non-blocking semaphore calls. Any comments on this? Anyone know RTAI? I really don't want to go there. We are talking about one use case, which everyone admits is not extremely common, and we've already discussed several possible workarounds that don't involve hacking the core realtime code. Regards, John Kasunich - 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
Re: [Emc-users] etch-servo pwm output to servo amp's input?
On Sat, 2008-08-09 at 20:54 -0700, Kirk Wallace wrote: On Sat, 2008-08-09 at 22:34 -0400, Jim Coleman wrote: ... snip I was wondering if i could just build an H bridge or similar switching circuit to run the output between the -12 and +12V rails on an AT or AT power supply, maybe use 7809 and 7909 regulators to keep it below 10V, to run to the analog VCMD input on the servo amp? the manual to the mill says that it runs +/- 9V, ... snip Thinking more on this, I guess you are right about the H-bridge for feeding the + to - 9V amp input. You would only need to have a single 9V supply to the top of each H leg with the two outputs going to the amp + and - inputs, assuming that the amp input floats. PWM Forward and PWM Reverse would go to the each H input. (?) -- Kirk Wallace (California, USA http://www.wallacecompany.com/machine_shop/ Hardinge HNC/EMC CNC lathe, Bridgeport mill conversion, doing XY now, Zubal lathe conversion pending Craftsman AA 109 restoration Shizuoka ST-N/EMC CNC) - 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
Re: [Emc-users] Stepper configuration
On Sat, 9 Aug 2008, John Kasunich wrote: Date: Sat, 09 Aug 2008 23:59:48 -0400 From: John Kasunich [EMAIL PROTECTED] Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Subject: Re: [Emc-users] Stepper configuration SNIP--- The simple fact is that the EPP bus is NOT shareable between realtime threads. That is only one of the reasons why (in my humble opinion) the PCI based 5i2x family is so much better than the EPP based 7i43 family. Its probably possible to make the EPP bus transactions shareable with a little bit of hardware (simple EPP hardware context save and restore, maybe triggered via a magic address cycle), but these would add even more slow EPP cycles to the preempting thread, lowering overall performance. Better to leave EPP peripherals running at the servo thread (and use the Stepgen/PWM/Quadcount/SPI hardware where speed is an issue). For PCI (and PCIe) where all I/O is atomic and separate hardware modules are truly independent, separate thread access to the GPIO is an advantage that should not be thrown away (I think I'm repeating myself... time to hit the sack) Regards, John Kasunich - 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 Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. - 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
Re: [Emc-users] etch-servo pwm output to servo amp's input?
On Sun, 10 Aug 2008, Jim Coleman wrote: Date: Sun, 10 Aug 2008 00:13:17 -0400 From: Jim Coleman [EMAIL PROTECTED] Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Subject: Re: [Emc-users] etch-servo pwm output to servo amp's input? I've hooked the encoders to the parport right now just to see if I could get that feedback working directly from the encoders to the parport. My goal is to get closed loop motion out of my motors without having to buy a card like a mesa. I think that if I can use the PWM output to derive an analog Vcmd for the servo amps, I'll be able to run it, slow enough for a parport to keep up with the encoder. I have the mill, the original control has been ripped out of it after it had a runaway on Y during a tool change (Y and Z axes are mounted on a gantry like, and X is under the table) I've only been making enough money to pay the bills and keep the car puttin along, so I havnt been able to invest any money into the m5i20 and 7i33 combo, but I sure would love to be able to get it running at minimill speeds with like $20 worth of hardware. buying 40 taper tooling definitely wont be easy, I might end up turnin some of my own if i have to. You might want to try PDM instead of PWM for generating your analog voltages as the reduced filtering required by PDM will allow you to get a higher system bandwidth for a given PWM/PDM resolution. Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. - 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
Re: [Emc-users] Stepper configuration
On Sat, 2008-08-09 at 11:50 -0600, Sebastian Kuzminsky wrote: John Kasunich wrote: Sebastian Kuzminsky wrote: John Kasunich wrote: What's a use case where it's valuable to read/write the modules separately? If I get the drift of this conversation (and that's always questionable) I think what you are asking is: Is there a situation where a GPIO pin needs to be read or written in the base thread, or in a faster thread than the 'modules'? If so, I think the most stressful situation is probing - the need for a high speed input surrounded by 'modules' that only require servo thread rate servicing. 1. Since I'm planning to use the PCI bus cards, I fully support the thread-safe flag idea ;P. 2. Another, possibly technically superior, method is to make a probe module in the FPGA. This could take a snapshot of the position registers (step generators and/or encoder counters) for later retrieval by EMC. The problem with this idea is that when the probe trips, deceleration wants to start immediately. Since trip detection is delayed by less frequent readings in the slower thread, a hard collision with the probe _might_ occur. This means that (unless we could have the Mesa card send a hardware interrupt to the real time system) the probe bit needs to be read at high frequency, although a hardware triggered position snapshot would maximize probe data accuracy. Heh, the way to do that with HostMot2 is to email Peter and ask for a new firmware image with an extra stepgen and encoder. :-) Or just change a couple of constants at the top of the VHDL and compile it yourself (assuming you have enough gates pins). The new VHDL source (not in CVS yet) makes this kind of tweaking really easy. On Sat, 2008-08-09 at 16:01 -0400, John Kasunich wrote (in another message of this thread): There are arguments both ways. I agree that separate GPIO is a bit klunky. But on the other hand, compile another firmware image immediately takes it out of the reach of 99% of users, no matter how simple the VHDL is. The Xilinx toolset is a gigabyte+ download, and is not trivial to figure out how to use it. You might as well be telling them write another driver. In fact, they are more likely to have a C compiler and C programming skills than the Xilinx toolset and VHDL skills, and we have a makefile that handles the complexities of the build. 1. The WebPACK is now about 2-1/2GB, and concerned scientists predict it will grow until the mass of it's bits is so great that the universe implodes. 1a. I couldn't get WebPACK to run on Linux because I'm on an x86_64 machine, and it's ia32 only. There was the beginnings of 64 bit support (references to non-existent directories in the install script), but even hacking the install script didn't work. This will probably be fixed soon, but this whole package should probably be distributed by bit torrent... 1b. I can't help but think that there is (buried under the IDE) a command line VHDLbit-image compiler. I couldn't find it, and we probably couldn't redistribute it without permission, but if there is, and we could, that would solve the first problem with making new FPGA code if incorporated into the build system. 2. I did try to do modifications to the FPGA configuration myself, and just couldn't understand what to do. In my defense, I was really tired at the time! I called Peter and he was very good about quickly making the changes I wanted! I haven't had the chance to test what he made yet (I'll get back to this sometime before September 1st), and maybe by studying the differences between what Peter made and the stock configuration files, I'll gain the understanding needed to help myself in the future. 3. Once I know enough about what to do to make new VHDL files, I can probably hack together a program that takes user input of the desired configuration and spits out the required VHDL. This would be limited to themes and variations, not entirely new module types, but could be helpful. Thanks, Matt - 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
Re: [Emc-users] Stepper configuration
On Sun, 10 Aug 2008, Matt Shaver wrote: Date: Sun, 10 Aug 2008 01:17:03 -0400 From: Matt Shaver [EMAIL PROTECTED] To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Subject: Re: [Emc-users] Stepper configuration On Sat, 2008-08-09 at 11:50 -0600, Sebastian Kuzminsky wrote: John Kasunich wrote: Sebastian Kuzminsky wrote: John Kasunich wrote: What's a use case where it's valuable to read/write the modules separately? If I get the drift of this conversation (and that's always questionable) I think what you are asking is: Is there a situation where a GPIO pin needs to be read or written in the base thread, or in a faster thread than the 'modules'? If so, I think the most stressful situation is probing - the need for a high speed input surrounded by 'modules' that only require servo thread rate servicing. 1. Since I'm planning to use the PCI bus cards, I fully support the thread-safe flag idea ;P. 2. Another, possibly technically superior, method is to make a probe module in the FPGA. This could take a snapshot of the position registers (step generators and/or encoder counters) for later retrieval by EMC. The problem with this idea is that when the probe trips, deceleration wants to start immediately. Since trip detection is delayed by less frequent readings in the slower thread, a hard collision with the probe _might_ occur. This means that (unless we could have the Mesa card send a hardware interrupt to the real time system) the probe bit needs to be read at high frequency, although a hardware triggered position snapshot would maximize probe data accuracy. The quadrature counters can already latch the count on index, and I've been thinking of adding a probe sense input (as alternate for index) as a counter option, I think there are even enough free bits in the CCR to allow this option. Heh, the way to do that with HostMot2 is to email Peter and ask for a new firmware image with an extra stepgen and encoder. :-) Or just change a couple of constants at the top of the VHDL and compile it yourself (assuming you have enough gates pins). The new VHDL source (not in CVS yet) makes this kind of tweaking really easy. On Sat, 2008-08-09 at 16:01 -0400, John Kasunich wrote (in another message of this thread): There are arguments both ways. I agree that separate GPIO is a bit klunky. But on the other hand, compile another firmware image immediately takes it out of the reach of 99% of users, no matter how simple the VHDL is. The Xilinx toolset is a gigabyte+ download, and is not trivial to figure out how to use it. You might as well be telling them write another driver. In fact, they are more likely to have a C compiler and C programming skills than the Xilinx toolset and VHDL skills, and we have a makefile that handles the complexities of the build. 1. The WebPACK is now about 2-1/2GB, and concerned scientists predict it will grow until the mass of it's bits is so great that the universe implodes. I guess they should call it DVDPack, its certainly too big for me to download... 1a. I couldn't get WebPACK to run on Linux because I'm on an x86_64 machine, and it's ia32 only. There was the beginnings of 64 bit support (references to non-existent directories in the install script), but even hacking the install script didn't work. This will probably be fixed soon, but this whole package should probably be distributed by bit torrent... 1b. I can't help but think that there is (buried under the IDE) a command line VHDLbit-image compiler. I couldn't find it, and we probably couldn't redistribute it without permission, but if there is, and we could, that would solve the first problem with making new FPGA code if incorporated into the build system. If you look at the log files the the IDE generates, all the command line stuff is there... 2. I did try to do modifications to the FPGA configuration myself, and just couldn't understand what to do. In my defense, I was really tired at the time! I called Peter and he was very good about quickly making the changes I wanted! I haven't had the chance to test what he made yet (I'll get back to this sometime before September 1st), and maybe by studying the differences between what Peter made and the stock configuration files, I'll gain the understanding needed to help myself in the future. The latest code is easier, just change the ModuleID (for number and type of modules) and PinDesc records (for pinout). These still need some cleanup to make them easier to understand, but at least theres only 2 VHDL files that change between differing configurations (IDParms.vhd to which you add the new ModuleID and PinDesc records, and hostmot2.vhd where you reference the new ModuleID and PinDesc records) 3. Once I know enough about what to do to make new VHDL files, I can probably hack together a program that takes user input of the desired configuration and spits out the required
Re: [Emc-users] etch-servo pwm output to servo amp's input?
On Sun, 2008-08-10 at 00:13 -0400, Jim Coleman wrote: I've hooked the encoders to the parport right now just to see if I could get that feedback working directly from the encoders to the parport. My goal is to get closed loop motion out of my motors without having to buy a card like a mesa. I think that if I can use the PWM output to derive an analog Vcmd for the servo amps, I'll be able to run it, slow enough for a parport to keep up with the encoder. I have the mill, the original control has been ripped out of it after it had a runaway on Y during a tool change (Y and Z axes are mounted on a gantry like, and X is under the table) I've only been making enough money to pay the bills and keep the car puttin along, so I havnt been able to invest any money into the m5i20 and 7i33 combo, but I sure would love to be able to get it running at minimill speeds with like $20 worth of hardware. buying 40 taper tooling definitely wont be easy, I might end up turnin some of my own if i have to. An L298 (dual) h-bridge is ~$5.00 but is over kill for an amp input. Do you have a make and model number for your amps? What kind of 40 taper? CAT, BT, NMTB? http://www.tools-n-gizmos.com/specs/Tapers.html -- Kirk Wallace (California, USA http://www.wallacecompany.com/machine_shop/ Hardinge HNC/EMC CNC lathe, Bridgeport mill conversion, doing XY now, Zubal lathe conversion pending Craftsman AA 109 restoration Shizuoka ST-N/EMC CNC) - 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
