Advanced Search

John can you post the complete HAL pin list with the 7i76 connected? or do you have two connected?

Well, for some strange reason the upload of the file failed but reported a good upload.

I uploaded it again...

John

BigJohnT wrote:

You can get it here for now:
gnipsel.com/shop/emc2/emc2.xhtml

"404 File not found

Well it looks like I screwed up a link."

chimpera wrote:

Peter, as a new user what is the best way for me to get the 5i25+7i76 configured with steppers?
Thanks, Ben

You can get it here for now:

gnipsel.com/shop/emc2/emc2.xhtml

John

I will have a basic 5i25 + 7i76 config up on my web site later this morning that you can build on. As soon as I'm done I'll post a link. When I'm happy with it I'll add it to 2.5.

John

Ok, I see. This behaviour is fine.

Thanks!

fma wrote:

When moving XYZ axis, I guess that the F param. is the resulting XYZ vector speed (which means that individual axis has different speeds).
But what happens when adding U(VW) axis? Is the speed of U(VW) computed indepently of XYZ? Or are they all linked together?

ABC, UVW are not included in the vector calculations. They simply move at such a speed that they each reach their end-points at the same time as XYZ.

Basically, the path length in XYZ is calculated using Pythagoras. This distance is divided by the feed rate to get a motion-time and then each of the 9 axes moves at the correct speed to all arrive at their end points after that time.

In "inverse time" feed mode you can set the motion time explicitly.

It would be nice to consider all the motions, but is pretty much impossible without telling EMC2 an awful lot about how the axes are configured. An XY / UV hotwire cutter is completely different to a XYZ W mill with knee and quill. Rotaries really add to the confusion.

Hello,

I'm using EMC2 to drive a reprap. A reprap has 3 standard XYZ axis, and an extruder axis to push the filament in the hotend. In my setup, I use U for the extruder axis.

Recent skeinforge (the program which slices the object to extrude) versions now generate the length of filament going into the hotend, rather than setting the speed of the extruder axis. There are a lot of parameters in Skeinforge, but this way of doing has simplified how to configure it. Now, feedrate (XYZ speed) and flowrate (extruder speed) are set equals.

What I need to understand, is how EMC2 drives the tool when using U(VW) axis...

When moving XYZ axis, I guess that the F param. is the resulting XYZ vector speed (which means that individual axis has different speeds).

But what happens when adding U(VW) axis? Is the speed of U(VW) computed indepently of XYZ? Or are they all linked together?

Thanks for your help.

Very crudely its:

First download EMC 2.5 (either build from source or get from buildbot)

run the hm2-stepper-5i20 demo from the EMC menu (this will copy the HAL and ini files to your
~/emc/configs/hm2-stepper directory)
Then copy the 5i20.ini in the ~/emc/configs/hm2-stepper directory to a file called 5i25 .ini
now edit this file and delete the firmware parameter in the config='xxxx" line
and change the 5I20 references to 5I25
You now have a very basic set of config files.
You may need to delete some GPIO references in the hm2-stepper.hal file as they are not appropriate to the 5I25
then run the 5i25 hm2-stepper demo from the menu...

Peter, as a new user what is the best way for me to get the 5i25+7i76 configured with steppers?
Thanks, Ben

Andy, Simply Golden. You make it almost childs play.

Andy,

Thank you for that explanation... even I can comprehend that now. PID has always been a black box only privy to the select few who understood the Greek and higher math symbols used to describe it. It is rather clear to me now.

Thanks
John

A PID controller performs some very simple calculations on the commanded value and the measured value, to produce a control output.

The P (for "Proportional") term is the simplest. it calculates the difference between the commanded value and the measured value, multiplies it by a fixed constant (the P-gain) and the result is the output.
Mathematically:
P = (Commanded - Measured) * Pgain.
The classic real-world example would be filling a bath to a fixed level. You would open the tap all the way while the difference between the actual level and the required level was large, and close it slowly until the bath level error was zero, at which point you would close it completely.

There are not many real-world examples where pure P-control works. Take the example of driving a car to the speed limit. You might press the pedalall the way to the floor to accelerate up to speed, but you don't apply zero throttle once you get up to speed, if you do that then you will slow down. If you stop driving now, and engage a very simple Cruise Control based only on a P-controller, then you would reach a speed just far enough below the required speed that the Pgain * speed error was enough to hold a steady speed. The higher the Pgain, the closer you get. Imagine that 25% pedal gives you 25 mph, and 50% pedal is 50mph. With a required speed of 50mph and a Pgain of 1, you would have 0% pedal at 50mph, 10% pedal at 40mph, and 25% pedal at 25mph, so your steady state speed would be only 25mph. With a Pgain of 100, then you would settle at 49.5mph. This sounds better, put what happens if you hit a gradient, and the speed falls to 49mph? The cruise control would immediately run to full throttle, then lift it all the way off at 50mph, then when the car slowed, run to full throttle again. P-controllers always do this, if you turn the Pgain too high, and this is why there is a limit to how high you can set the Pgain and have a stable loop. This also indicates that for many systems P-only control will never quite hit the setpoint. (Non-leaky baths are one of the exceptions)

To get that last bit of control, most controllers also have an I (for "Integral") term. This sounds a lot more technical than it is, and is normally described in textbooks in terms of calculus and greek symbols. But, if you look at any practical controller code, it is far more simple:
I(new) = I(old) + Igain * (Commanded - Measured).
So, every time the calculation is done, a fraction of the current error is added to the I term. Taking the example of the car above, with a P-gain of 1 the car sat at 25mph. If we add an I term with an Igain of 1, then the first time the loop runs, the I term will be 0 + 0.5 * 25mph = 12.5%, so the pedal position is now 37.5% (P + I), the next time the controller runs, the car is doing 37.5mph (this is an infinitely powerful massless car), so the I term is 12.5% + 6.25% = 18.75%. The P-term drops to 12.5% (because the error is less) and the pedal position is P + I = 31.25%, the car reaches 31.25mph...And so on.
Given enough time the car will reach a steady state very close to 50mph, with an I-term of 50% and a P term of zero.

What about that "D" term? Lets start with the car analogy. Imagine that you have your personal Pgain set rather high (and I think we have all met drivers like that). You want to accelerate to 50mph, and put your foot to the floor. The car turns out to be much higher-performance than you expected and you see that the speed is rising so quickly that you will over-shoot the speed limit, so you back off a bit. Despite the fact that you are still not even half-way to the speed you want. This is your own internal D (for "Differential") term. Again this is normally described in terms of calculus, but in the actual code it is something like.
D = Dgain * (New_measured - Old_Measured)
D gain is useful for avoiding overshoots, and can often allow you to run with a higher P-gain than would be stable otherwise. It can also help to slow the response to step-changes in command value (or, if required, enhance the response to step changes)

So, the final equation in the PID controller code is just P + I + D.

This was snatched from another post and Jon did a good job of explaining FF0, FF1, and FF2. Now I need something in plain speak about PID.

Each of the FFs take some parameter from the commanded position and add a
value to the PID output. So, FF0 does commanded position * FF0 = value and then
adds that value to the pid output. FF1 is first derivative of position * FF1 = value
and FF2 is second derivative of position * FF2 = value.

So, when I say FF0 would be bad for an axis, it would cause a following error
that would be proportional to position. You could get the following error to zero
at one spot like X=1.2345", but there would be an accumulating error either side of that magic
location. This would not be a good thing.

So, FF0 is proportional to position (assuming an axis) or otherwise whatever parameter
is the input to the PID. FF1 is the first derivative of position, so that is proportional
to velocity. FF2 is second derivative of position, so it is proportional to acceleration.

I have not used the PID for a spindle application, but I can see that the PID is
given a position command for an axis, but a speed (velocity) for a spindle, so
there FF0 would be the right thing to adjust to compensate for finite servo
gain.

Jon

John

picpic77 wrote:

Then when I start the machine, It's like the software don't wait to have finish one side to start the second and at the end, I have the square on the right size but with round corner..

Normally you would expect the rounding to be almost imperceptible, it may be that you need to adjust the acceleration settings of your machine, it seems likely that they are far too low. (this does, though, rather depend on how much mass is moving).