584,842 active members*
4,389 visitors online*
Register for free
Login
IndustryArena Forum > CNC Electronics > UHU Servo Controllers > Servo processor "upgrade module" - looking for volonteers.
Page 1 of 4 123
Results 1 to 20 of 69
  1. #1
    Join Date
    Jul 2007
    Posts
    887

    Servo processor "upgrade module" - looking for volonteers.

    Hello everyone,
    I've developed sort of an "upgrade module" (for lack of a better name) for the UHU based servo drives. This module is pin-compatible with the original UHU chip but allows you to use step-frequencies of 1Mhz or more and the encoder inputs are capable of tracking the encoder at speeds up to 2.5Mhz.

    Here's a photo of a prototype mounted on the HP-UHU:


    Other features are:
    * Velocity and acceleration feed forward.
    * Sliding scale following error.
    * Data recorder (plot following error, PID output, motor velocity etc).
    * Servo loop rate 1220-2500Hz (adjustable in 10 steps)
    * Antidither function with setable range and scale for the PID gains.
    * Output offset for unbalanced loads.
    * Digital encoder filter for increased noise imunity.

    Here's a [nomedia="http://www.youtube.com/watch?v=U-jrxK7u_34"]YouTube- Servo module 1.avi[/nomedia] video showing the module running on the HP-UHU driving a servo motor equipped with a 3600line encoder at ~3900rpm (936kHz step frequency).

    Here are links to a preliminary datasheet and a preliminary manual.

    What I'm currently looking for is 3-4 volonteers that are interested in trying/testing a module. I'll give you one module for free and in exchange you give me feedback on the operation of the module and its documentation which I linked to above. What's good, what's not good, what's missing - that sort of thing. I promise to do my best to sort out whatever problems we may find but I give no gurantees what so ever.

    I've been testing the module myself for quite some time without having any real issues (lock-ups, motor run-away etc) but you need to understand that I can not be held responsible for any damages to humans or equipment that, in a worst case scenario, may be the result of using the module.

    Once we've sorted out any bugs/issues/problems you may, if you like, send the module back and have its firmware updated and then returned to you free of charge - you pay shipping one way. (The firmware is not open source and, for the record, is not based on any other open source servo project code.)

    I'd appreciate if you, as a beta tester of the module have a general understanding of how a closed loop servo system works and how to tune it - it'll make any problem solving neccessary a lot easier for both of us.

    General questions, if there are any, in the thread please. If your interested in testing a module please PM me here on the zone or E-mail me at: henrik [at] henriksplace [dot] se

    /Henrik.

  2. #2
    Join Date
    Jan 2006
    Posts
    297

    UHU chip replacement

    'WOW' I'm impressed, no wounder you've been hard to get. wonderful project, hope it goes well. unfortunately I've stripped a good portion of the wiring in my machine & an working at resolving a gremlin. so I'll not be of much help. between my gremlin & very little time I'm going backward. keep us posted.
    Best of Luck & let me know if I can be of any assistance
    Paul

  3. #3
    Join Date
    Jul 2007
    Posts
    887
    Thanks Paul,
    I'm sorry if you've been trying to reach me by e-mail lately, my ISP decided to discontinue my e-mail adress so I had to get a new one. If you need me please feel free to e-mail me at the adress shown in the first post or you can always PM me here on the 'zone.

    /Henrik.

  4. #4
    Join Date
    Dec 2005
    Posts
    231

    Testing

    Cool. Looks like a dsPIC?

    I've not even finished the patterns for my HP-UHU's although I finally ordered and bought (way too many) of the threaded inserts so that I can clamp down the FETs.

    The casting is done for the knee but that uses a stepper. Drawings are done for the X and Y axis but no patterns built yet so no motors mounted. Looking at file dates of drawings etc. I can see I stopped the moment I started on the Olympic Ring projects back 01Dec08 for delivering a working ring set 02Feb09 that was then increased in scope by 50% so pushed to 05Mar09.

    After that the rest of the year was a writeoff. Now I'm back and working on all this stuff like a busy beaver but I'm afraid I can't help you with testing.

    John Dammeyer

  5. #5
    Join Date
    Jul 2007
    Posts
    887
    Hi John,
    No dsPIC, it's an "ordinary" 18F2431. Sounds like we're in the same boat, my knee-mill project have been on "hold" since last September or something like that. I always seem to get sidetracked, but being a hobby I don't really have a problem with that. Looking forward to declaring the machine conversion done though - like that is ever going to happen ;-)

    /Henrik.

  6. #6
    Join Date
    Dec 2005
    Posts
    231
    Quote Originally Posted by H.O View Post
    Hi John,
    I always seem to get sidetracked, but being a hobby I don't really have a problem with that. Looking forward to declaring the machine conversion done though - like that is ever going to happen ;-)

    /Henrik.
    I sidetracked myself by starting a JGRO CNC router. Stepper controlled in this case and built with anal retentiveness. If you can be anal with MDF. Most of the metal bits are all castings so first I have to make patterns and then I cast. I have 3 more bearing holders to cast and 6 more rail holders.

    I'm hoping this will be a nice addition to the shop for pattern making and milling holes in plastic enclosures. I also have a nice vacuum pump I picked up that will work well for a hold down system. Inbetween I'm doing the CNC conversion on the mill.

    Then there are the electronic projects that are unfinished...

    John

  7. #7
    Join Date
    Jan 2006
    Posts
    297
    It's good to hear that my project isn't the only one languishing for lack of attention! Arturo been waiting for, i hate to admit it, almost a year to help me with a gremlin! too many projects, interfering paying jobs & wife"s needs, etc
    Paul

  8. #8
    Join Date
    Dec 2005
    Posts
    231

    Latest Project

    Hi Henrik,

    Yeah, my latest project is a 5 channel slider pot controller that can send/receive messages via RS485 and generate the correct format messages out the CAN port.

    Or use the slider pots to send the correct messages out the CAN port.

    It talks to the same kind of lights used for the Olympic Rings. I still have to write the DMX-512A interpreter for it too. Then it can talk to the Light-O-Rama USB to DMX-512A module and I can control the ORing lights to Christmas music. Great Fun!

    John
    Attached Thumbnails Attached Thumbnails DSCN4524.JPG  

  9. #9
    Join Date
    May 2006
    Posts
    161
    Hi Henrik,

    Good to know you have some interest in upgrading the UHU drive. That is great as it has a lot of potential, I've been using the old board well over half an year and had no problems concerning the drive itself.

    I am interested in the whole thing, and could eventually upgrade my system if it becomes a good alternative. A little about my setup here. I was forced to remove my 2500 pulse encoders and put 1024 ones on their places. Of course the overall pulse count was the problem. Now I get reliable rapids at 5000mm/min, could do 7000 maybe, but going further leads to errors, well known problem. I am satisfied with this speed for now, as my previous machine did only 1200mm/min, but more is always welcome.

    As for the beta testing, what kind of hardware as machine, power supplies and other stuff will be needed? I suspect one should watch for all sorts of problems with this kind of equipment, curious if I could do something for the developing.

    Todor

  10. #10
    Join Date
    Jul 2007
    Posts
    887
    Hi Todor,

    Only real requirement is a terminal emulating software to communicate with the module (such as hyperterminal, realterm etc). The module uses different communication parameters compared to the original chip so the terminal software specifically developed for the UHU chip will not work.

    Apart from that there are no special requirements regarding powersupplies, motors, encoder etc and no special equipment should be needed. The module should work wherever the UHU chip did and "beyond" - that's the idea. So really, I'd appreciate whatever enviroment anyone can put it in. If it's within the original UHU chips speed envelope that's great, if it's outside that envelope it's even better.

    In your particular case it would be nice to see how it compares at you current setup and if possible try it with the 2500ppr encoder as well and see how it does. It's been verified to work at 1Mhz so if the motor can take it you should be able to get 6000rpm with the 2500ppr encoder - at least.

    I'd be more than happy to send you a module, free of charge of course, if you feel you have the time to try it.

    /Henrik.

  11. #11
    Join Date
    May 2006
    Posts
    161
    Hi,

    So you are driving it at ~1Mhz, I assume this is with the smoothstepper. I did some calculations here. My motors are 2000rpm max, I have 1024, 2000 and 2500ppr encoders. Even with the 2500 ppr I can get "only" 333Khz, and since I am using the PP, at a kernel of 45Khz, I should use a multiplier of 8 to 10 maybe to get a reliable movement. Your manual says it should be below 10 as I recall.

    From my experience here, using the UHU drives I realized that there are two main things where the drive should be good - keeping tight with the setpoint and always knowing where it is at. /Error counts = 0/. When this is done, there should be no problems driving this or that king of metal. Of course after proper adjustment.

    It was a little hard to tune myself the axes, as I wanted to use relatively higher accelerations, and I always get some overtravel when starting or stopping, looking at the terminal program. I am now at 600mm/sec^2, and I think some of the artifacts I get on my wooden pieces are due to this. This is seen on a change of direction or at the near end of a move, where one axis stops and the other accelerates, and stuff like that.

    Another thing that bothers me is the fact you are using the new chip on a HP UHU board. As I see you have preserved the original PWM ratios, and this should be no problem for the old power stage. I remember Kreutz did some changes to the drivers' dead times and such on the HP ver. Is there any difference in the control signal, going out of the processor concerning this?

    Todor

  12. #12
    Join Date
    Jul 2007
    Posts
    887
    Hi Todor,
    Yes ~1MHz with a Smoothstepper, 4000rpm motor 3600 lines encoder (14400 in 4X mode).

    From my experience here, using the UHU drives I realized that there are two main things where the drive should be good - keeping tight with the setpoint and always knowing where it is at. /Error counts = 0/
    The UHU uses interrupts and software to keep track of the encoder and position, if the frequency is too high it starts to miss "counts" because there's a certain amount of time needed between "counts" in order to process everything.

    This module uses a hardware quadrature counter incorporated inside the microcontroller, it'll keep track of the encoder at speeds up to 2.5Mhz. Aother thing that can cause "lost position" is noise. Noise is bad for any controler and the higher the bandwidth is the more sensitive the system is. Because of the UHU's "limitied" encoder count frequency it's a bit less sensitive to noise than what this module is. On the other hand, the module has a built in digital filter that can be used to "lower" the bandwidth in case noise is a problem. (It's always better to remove the problem but in reality that can sometimes be hard.)

    Tuning can be quite tricky, and it's no different with this module. It does offer a few more tools though that allows you to see what is happening in greater detail. First, it has a "peak error detector" that will show you the largest error detected since power-up or reset. Simply, as long as the following error limit isn't reached it'll tell you just how big of an error there has been.

    Then there's the datarecorder, it's not continously outputting the error like the UHU-chips analyse mode does but it records 128 values in internal memory and then outputs them to the terminal, this is very good for analysing the step-response. One of the possible "triggers" for the recorder is direction change - you could use that to see exactly what the motor does when reversing.

    Another thing that bothers me is the fact you are using the new chip on a HP UHU board. As I see you have preserved the original PWM ratios, and this should be no problem for the old power stage. I remember Kreutz did some changes to the drivers' dead times and such on the HP ver. Is there any difference in the control signal, going out of the processor concerning this?
    No, the UHU chip outputs a single PWM-signal modulated between 13 and 87% with 50% being "center", resulting a net current of 0A thru the motor (this is what's called locked antiphase). This signal, being only a single drive-signal can not contain any dead-time, the dead-time is handled completely by the drives hardware (the IR21844 drivers on the HP-UHU) and it can not distinguish the modules PWM signal from the UHU-chip's PWM signal, they look exactly the same. (Actually the frequency may be slightly (2.5%) higher on the UHU but it doesn't make any difference)

    What you CAN do is increase the modulation from 13-87% up to 8-92% if the hardware can accept that but as you noted it's by default the same as on the UHU. I've run my HP-UHU at 8-92% without problems but you should verify that the high side bootstrap capacitor has enough time to refresh when doing that.

    /Henrik.

  13. #13
    Join Date
    May 2006
    Posts
    161
    Sorry about the delay.

    With my hardware I can achieve only 1/3th of the frequency you have done, so If you want to test it to the limits, someone else has to come up with a motor with higher rpm and pulses per rev. What I can do is hook it to any axis, tune it properly and do some real world cutting and bring some kind of results. Of course this will be far below its speed capabilities.

    Apart the obvious higher noise I get when using the multiplier option is there any other problem with the tuning and/or the control algorithm connected with it? As I understand the original UHU adds pulses next to the input ones and this makes some sort of jitter in the signal, which makes the motor to hum more. I guess if the chip can predict when the next encoder count arrives and put this additional pulse in the middle of the two, the motion will be a lot smoother. I've never really devoted myself with this kind of stuff, just thinking. They have taken care of this in the SS.

    What about the Fault I/O pins? I cannot ask if you have done any changes, because you don't know the original code but I am curious about the behavior. Does it have some software filtering? The original UHU and the schematic seemed to not have any filtering which made it too easy to reset. In the beginning here the chip faulted every time the motor took some more current from the drive. I managed to deal with this bypassing the IN pin with a small cap to ground. Now I get only rare resets when the 3 phase vacuum-cleaner gets stopped because of contactor arcing. Should take care of it. Just asking if this will be something similar.

    Todor

  14. #14
    Join Date
    Dec 2005
    Posts
    231
    Henrik,

    Did you ever get your mill finally up and running? The last page of your web site shows the electrical panel but that's about it.

    John

  15. #15
    Join Date
    Jul 2007
    Posts
    887
    Hi,
    With my hardware I can achieve only 1/3th of the frequency you have done, so If you want to test it to the limits, someone else has to come up with a motor with higher rpm and pulses per rev. What I can do is hook it to any axis, tune it properly and do some real world cutting and bring some kind of results. Of course this will be far below its speed capabilities.
    That would be great! Just because it CAN operate at higher speeds doesn't mean you HAVE to use it there. On the other hand if you get 300kHz that's probably atleast twice what you get with the UHU.

    Apart the obvious higher noise I get when using the multiplier option is there any other problem with the tuning and/or the control algorithm connected with it? As I understand the original UHU adds pulses next to the input ones and this makes some sort of jitter in the signal, which makes the motor to hum more. I guess if the chip can predict when the next encoder count arrives and put this additional pulse in the middle of the two, the motion will be a lot smoother. I've never really devoted myself with this kind of stuff, just thinking. They have taken care of this in the SS.
    On the module the number of input pulses between each servo update is simply multiplied by the step-multiplier setting and the result is added to the set-point register. Setting the step-multiplier to 10 and sending a single pulse will be the same as a step-multiplier of 1 and sending 10 pulses during the time between two servo updates. The difference is that with a lower step-multiplier the pulses usually gets "spread" across more than one servo-update which makes the control algorithm and motor think it should move 3+4+2+1 counts instead of all 10 in on go. Due to this it'll also be a little easier to trip the following error limit because the number of steps "adds" up quickly.

    Actually, I've experimented with a kind of filter algorithm that may be useful when using high multiplier settings. Basically it has an intermediate buffer in which the "multiplied" steps gets stored, the filter then calculates how many steps to take "from" this buffer in order to have it empty i x number of servo-loops. This smooths out the motion a bit when using a high step multiplier setting but introduces a slight "lag" to the system. This is NOT implemented in the current version though.

    Don't understand what you mean regarding the SS??

    What about the Fault I/O pins? I cannot ask if you have done any changes, because you don't know the original code but I am curious about the behavior. Does it have some software filtering? The original UHU and the schematic seemed to not have any filtering which made it too easy to reset. In the beginning here the chip faulted every time the motor took some more current from the drive. I managed to deal with this bypassing the IN pin with a small cap to ground. Now I get only rare resets when the 3 phase vacuum-cleaner gets stopped because of contactor arcing. Should take care of it. Just asking if this will be something similar.
    I'm not sure if you mean the actual Fault-input or the hardware reset input? If you actually get the chip to reset it's not a problem with the fault-input or it's filtering but rather the hardware reset pin or noise induced in the powersupply causing a reset.

    On my HP-UHU I haven't experienced any sort of unexpected faults or reset - not with the UHU chip and not with this module. But to answer your question, the hardware reset input is filtered by the capacitor on the HP-UHU board. The fault signal is not software filtered in the words proper meaning but it is polled each time thru the main loop of the firmware (not interruptdriven). Depending on how much the main loop has "to do", like sorting out serial commands, sending data etc the time between polls differs. The only real guarantee is that it WILL be checked at least once every servo-loop update, most of the time it gets polled much more often than that. If unexpected faults are an issue then I could add some filtering to the input but my general advice is to try to stop the noise at the source instead but I know that can be tricky or next to impossible some times.

    Todor, you bring up all valid points and considerations and your environment sounds like a perfect place for some real-life tests - if you feel you have the time.

    John,
    The mill runs but it's not done. I need to sort out some belt covers and get the source of the backlash on the Y-axis identified and fixed. Haven't touched it for several months :-/ I don't have the machine where I live so I squeezing in 30 minutes here and an hour there simply doesn't happen. I'll get there though and when I do I'll update the thread.

    Thanks guys!
    /Henrik.

  16. #16
    Join Date
    Dec 2005
    Posts
    231
    Quote Originally Posted by H.O View Post
    Hi,

    John,
    The mill runs but it's not done. I need to sort out some belt covers and get the source of the backlash on the Y-axis identified and fixed. Haven't touched it for several months :-/ I don't have the machine where I live so I squeezing in 30 minutes here and an hour there simply doesn't happen. I'll get there though and when I do I'll update the thread.

    Thanks guys!
    /Henrik.
    Henrik,

    You're still further along than I am. I got sidetracked building a JGRO router for doing patterns and milling holes in the plastic boxes for my ELS. I'm just about ready to try a stepper on the knee which will have 3:1 reduction and a 600 oz-in motor. I doubt it will be strong enough which is why I'm probably procrastinatin.

    The Y Axis will be next and done with the HP-UHU. I finally ordered and received the screw in inserts for the transistor clamps. Next I'm making a pattern for the heatsink. I have all the power supply parts but have yet to assemble it. I'll be running about 112 VDC.

    I also have the motors, encoders, belts, pulleys, bearings. Just need to get going on it.

    Looking forward to finally getting it all working.

    John

  17. #17
    Join Date
    May 2006
    Posts
    161
    Quote Originally Posted by H.O View Post
    On the module the number of input pulses between each servo update is simply multiplied by the step-multiplier setting and the result is added to the set-point register. Setting the step-multiplier to 10 and sending a single pulse will be the same as a step-multiplier of 1 and sending 10 pulses during the time between two servo updates. The difference is that with a lower step-multiplier the pulses usually gets "spread" across more than one servo-update which makes the control algorithm and motor think it should move 3+4+2+1 counts instead of all 10 in on go. Due to this it'll also be a little easier to trip the following error limit because the number of steps "adds" up quickly.

    Don't understand what you mean regarding the SS??
    I was thinking about the multiplier and how it can produce smooth motion but you already explained it above. I referred to the SS as e device with less jitter than the PP. I've watched some videos that one guy scoped the output of each one.

    I'm not sure if you mean the actual Fault-input or the hardware reset input? If you actually get the chip to reset it's not a problem with the fault-input or it's filtering but rather the hardware reset pin or noise induced in the powersupply causing a reset.
    I meant the Fault input, on the original board it has only one resistor of 22K to +5V, and no caps. As soon as I hook a wire of say 10cm, it starts to fault when I twist the shaft of the motor. It acts like an antenna. When I remove the wire from the terminal, it is all OK.

    The hardware reset input has its large cap to ground and it should not be a problem. I know electrolitics have high inductance and are not made for HF filtering, but I think it's not the case here.

    On my HP-UHU I haven't experienced any sort of unexpected faults or reset - not with the UHU chip and not with this module.
    I don't know if it makes so big difference but the HP UHU used 10K resistor instead of 22K on the Fault input. Still no capacitor though.

    Todor, you bring up all valid points and considerations and your environment sounds like a perfect place for some real-life tests - if you feel you have the time.
    I have mentioned a long time ago here that my encoders have POTs on each output which regulate the length of the pulses. This is for first-time setup but could be used to disrupt the signal waveform in order to test some sort of stability. The original drive seemed to be very sensitive to this, I had to do some fine scope measurements to get it going without error counts. Could this be of some help for the tests?

    Todor

  18. #18
    Join Date
    Jul 2007
    Posts
    887
    Ahh, yes the SS's pulse-train is less jittery compared to Mach3's LPT-port driver but currently the step-multiplier won't help if you have a jittery signal.

    I meant the Fault input, on the original board it has only one resistor of 22K to +5V, and no caps. As soon as I hook a wire of say 10cm, it starts to fault when I twist the shaft of the motor. It acts like an antenna. When I remove the wire from the terminal, it is all OK.
    Leaving a wire "hanging" like that is not very "nice", you should have it connected to something in the other end, preferably with a pullup resistor in that end as well. I also think that PCB layout of the original board is less than optimal hence more sensitive to noise etc. I'd like to point out though I don't have any personal experience with ANY board except the HP-UHU so I'm going by hear-say...

    I have mentioned a long time ago here that my encoders have POTs on each output which regulate the length of the pulses. This is for first-time setup but could be used to disrupt the signal waveform in order to test some sort of stability. The original drive seemed to be very sensitive to this, I had to do some fine scope measurements to get it going without error counts. Could this be of some help for the tests?
    I really wish I could tell you the requirements regarding symetry of the quadrature signals but I can't seem to find that type of info in the datasheet for the microcontroler. I will continue digging though and let you know if I find it. I have used this uC with a bunch of different encoders though like Hengstler, AMT, Scancon and HP and haven't noticed any trouble so I guess it'll accept the "usual signals" for lack of a better term.

    If you're going to test it I don't see any reason for you to tweak the symetry. If it works with the UHU it should work with this module, that's the idea. In case it shouldn't work THEN it might be worth verifying the symetry.

    Thanks!
    /Henrik.

  19. #19
    Join Date
    Jan 2006
    Posts
    297

    Your UHU Modules

    H.O.,
    I'm looking forward to your modules arriving. sounds like they should arrive about the same time I'll be back. I'd like to encourage other's out here who are converting used machines to help with this beta testing. I'm betting that the added capabilities of these new modules will improve performance & resolve some bugs related to the higher rapids & feeds
    Thanks for your sharing with us
    Paul

  20. #20
    Join Date
    Dec 2005
    Posts
    231

    Encoder speed.

    So the new processor will handle faster encoders.

    Let's see if I have the math right. Suppose I want to use a DC servo for my JGRO router project. Assuming I have a 3000 RPM motor with a 500 line encoder in quadrature I get 2000 pulses per rev. At 3000 RPM or 50 RPS I'm going to see 100,000 pulses per second?

    Now to turn this into a real world application the servo would have a 4:1 set of pulleys ultumately turning a 20T pulley that has a pitch of 0.2" (XL series). That means each revolution moves 4" worth of belt.


    With a motor of 3000 RPM and 4:1 reduction the pulley is turning 750 RPM which is moveing 4" * 750 RPM or 3000 IPM?

    Yikes! If I reduced the speed to 20:1 then 3000 RPM becomes 150 RPM at the 20T pulley which means 150 * 4" = 600 IPM. That's a decent rapid.

    Currently for CNC systems then to work with the HP-UHU the encoder should be more like a 200 line encoder? And the standard UHU processor can handle 50,000 steps per second?

    Thanks

    John Dammeyer

Page 1 of 4 123

Similar Threads

  1. "ISO" post processor in Solidcam
    By codevark in forum SolidCAM for SolidWorks and SolidCAM for Inventor
    Replies: 1
    Last Post: 09-06-2013, 06:12 PM
  2. Solsylva 24" x 48" 1/2"-10 acme upgrade
    By rc_flyer in forum CNC Wood Router Project Log
    Replies: 39
    Last Post: 08-05-2009, 11:13 PM
  3. Heidenhain TNC2500 or TNC360 Teksoft Post Processor " G " code ISO
    By RMARCH in forum Bridgeport / Hardinge Mills
    Replies: 0
    Last Post: 06-11-2009, 05:51 PM
  4. Replies: 1
    Last Post: 01-14-2009, 08:40 PM
  5. Looking back... would you "upgrade" to ver22.?(2007)
    By msomerville in forum BobCad-Cam
    Replies: 18
    Last Post: 06-23-2008, 02:47 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •