Adjust duration of step pin low state #472
Comments
|
These are the periodic gaps I was seeing with FREQUENCY_DDA set to 300000. Note that the scale is 1ms / division here:
If I could get rid of the gaps, this would probably work for me. I was actually surprised it worked at all with a frequency above 200kHz. |
|
Please use edge-preview for testing if you can. On the Due you likely want to stay below 150khz for the DDA or you’ll starve the planner and you’ll see moves start to slow down due to internal throttling. You cannot step more than 50% of the DDA rate since it needs at least half of the time low and half the time high. We don’t stretch the pulses at this point, meaning a step (generally low) pulse will be one step tick, so at 150KHz that’s 1/150000th of a second, or about 7us. The 1us pulse you’re seeing is the processor trying to set and unset the pin in the same dda call, effectively with no timing in between. The bug here is that the planner is allowing you to set travel faster than the motors can go with your current configuration. This is tricky because the planner doesn’t know that info, kinematics does, but the separation of concerns dictates that those should be independent. What we need to add is a check when the motor configuration is set to ask kinematics what the new max feedrate for each motor should be. The only part you can change there without a mechanical change is microsteps. It sounds like you need to lower it to get the speeds you’re looking for. Or mechanically lower the gearing / belt ratios (etc) to raise the travel per revolution. Your step rate is: feed rate * microsteps_per_unit, and in gcode feedrate is per minute so divide by 60 to get per second. Microsteps per unit: travel_per_revolution / (full_steps_per_revolution * microsteps) |
|
Thanks for the explanation Rob. It must be that my double steps are showing up above 75,000 steps/sec, which would be ~88 ipm on my machine. That also explains why I could get to almost 120 ipm when I set the DDA rate to 200kHz, since a 100kHz step rate is ~118 ipm. One thing I don't quite get is how the planner would be starved by a higher DDA rate. Does that mean the Gcode interpreter couldn't supply it with moves fast enough? If so, I don't see how reducing the amount of microstepping would help the machine go faster either, since faster movement must require faster gcode interpretation. It's kind of a moot point in my case anyway, because my motor drivers are internally hardwired for 10X microstepping, and not adjustable. The easiest way for me to move faster might be to get a faster controller board. Is there any faster hardware out there that is compatible with g2? Is it possible I am witnessing planner starvation in that scope trace above showing gaps between move segments? |
|
We are in the process of getting our newer and faster boards released now. I don't have an eta yet but I think in the new few months. |
|
Hmmm, those step rates seem like they're pushing the hardware limits. Wonder if that's a sign that using steppers at that step rate isn't really the right thing? eg a "square plug fitting into round hole" type of problem. @lllars What's the scenario you're working through? eg what's the goal, etc? Just wondering if we're coming at this from the wrong direction, and there's a better way to achieve it. 😄 |
|
Just spiffing up an old milling machine. Part of which has been giving it a new control board. I was in the process of figuring out how fast the axes can reliably go when I ran into this issue. It was looking for a minute like they could handle upwards of 140 ipm. But, after testing them at higher jerk rates and then adding in a safety margin, it looks like I'll be sticking below 80 ipm. That's just under 150kHz DDA in my case, so it looks like the Due will work OK after all (though I did still have to bump that up from the 100kHz default in edge-preview). g2core currently seems like the best choice for a control board. I'm planning to have a raspi running UGS on the touchscreen. The mill originally had a flood coolant system and partial enclosure which were lost sometime long ago. So, I'd like to fabricate replacements for those. I have a couple other items on the todo list that might involve trying to extend g2core a bit. One is that there is a joystick on the control panel for jogging the z-axis, so I'm wondering if I could get that working by wiring it into the Due. It has an analog voltage output. The motors all have encoders so I'm also wondering if I could feed those into g2core and at least have it halt if the encoder position varies to much from the expected position. I also have a router that has been running g2core for about 5 years now. It has been running an old firmware with backlash compensation hacked in. I haven't been able to update its firmware because of that, so it interesting to be able check out the latest g2 improvements on the mill. Here is a photo of the mill: |
|
Awesome, that looks like a serious piece of kit. 😄
It'd probably be possible to do, but I think people using joysticks (and/or other control pad type of things) tend to configure them as inputs to UGS instead, and let that figure out sending the commands to the board. From a super quick search online, stuff like this:
That being said, when having to figure out how to use existing hardware... sometimes getting creative is needed. 😄 |
|
@lllars I'd like to see a demo video of that machine running with g2 and UGS. 😍 Regarding the option for adding external controls I would like to mention the brand new joystick/gamepad implementation in UGS. https://github.com/winder/Universal-G-Code-Sender/wiki/Usage#gamepad-and-joystick There seems to be a problem running this on RaspberryPi at the moment though. |
|
@breiler That gamepad control looks really nifty. Can't tell from the video if it's only directional, or if moving the joystick further in a direction increases the rate of motion too? |
|
Sorry for being a bit off topic... @justinclift it's hard to see in the video but you are correct, it will use the analog values from the gamepad/joystick and use that to control the speed of the motion. It's not perfect yet as it will have som latency between control and action (which is clearly visible in the video). But I think that it works good enough for now. |
|
Yeah, sounds like a really good start. Well done! 😄 |
|
Ok, made a video. No cutting yet though. https://youtu.be/6mW6SubdNiI |
|
Heh Heh Heh. That's really awesome. 😁 |
|
What is that UI?
|
|
Looks like a recent build of UGS. 😄 |
|
@lllars When you have some good video of it cutting chips, would you be ok for us to link to it for things? We really should be doing more promo stuff... 😄 |
|
Yes, you could link to a video to promote g2. I'm making plans for flood
coolant and a partial enclosure. So that might be good for theatrics too.
UI is UGS Platform
|
Is it possible to increase the minimum amount of time the step pin is held in a low state between steps? I'm seeing that it is sometimes low for only 1us, particularly at higher speeds. I believe the 1us is slightly too fast for my motor drivers, so I'd like to extend it slightly if possible.
I've found that I see the 1us low states at speeds above 85 ipm, which on my machine corresponds to about 72,000 steps/sec. I'm observing that the high state is ~5.5us long regardless of speed. Here is look at my pulse train in the middle of a 90 ipm move:
Notice that towards the middle of the photo, there are two steps in quick succession, with only 1us between them. This "double step" occurs more frequently at higher speeds and I suspect my drivers are treating it as a single step.
My drivers claim to require a minimum of 1us duration in both the low and high states. So I suspect I don't need to increase the low state duration by much, since it seems to be approximately 1us already. It should also be OK to reduce the high state duration.
I've had some success adjusting the FREQUENCY_DDA parameter in hardware.h. Setting it higher reduces the duration of the step high state, which seems to push the occurrence of double-steps up to higher speeds. However, I can't even reach 120 ipm with FREQUENCY_DDA set to 200000. I did try setting it all the way up to 300000, but then started seeing periodic 100us gaps in the step train.
I did most of this testing on edge, although edge-preview also seems behave similarly. I'm happy use either branch for further testing.
The text was updated successfully, but these errors were encountered: