[SOLVED] Script to approximate involute to a circle - problem with Events

[wiekiera]

Dear QCAD users,

I prepared a script to approximate involute to a circle with splines.

My script has four states:
1. SettingN -> in this state it is supposed to take input from command window using commandEvent and its getCommand() function.
2. SettingCenter -> in this state it is supposed to take input from coordinateEvent and its getModelPosition() function.
3. SettingBasePoint -> in this state it is supposed to take input from coordinateEvent and its getModelPosition() function.
4. SettingTipPoint -> in this state it is supposed to take input from coordinateEvent and its getModelPosition() function.

Data collected in all the states is used to draw a spline that should resemble an involute to a circle.
The script works, although. It does not behave as I expect. It should cycle through the states from 1 to 4.
But when code belonging to SettingN is executed the script skips SettingCenter state and goes directly to SettingBasePoint instead.

I have checked the code many times but I am lost. I have no idea what is the reason of unexpected behavior. Did anyone had a similiar problem?
I have attached the script for reference.

Thanks in advance!

[CVH]

Hi,

I couldn't run it without the Init section so I added one as a script and placed it in Misc .. Draw for the time being.
Sortorders[54100, 800], the new release of FlexPainter I am working on uses [54100, 900]

May I remark that a number of points is usually something that is set in the Option Toolbar.
For that you need a simplistic UI file and implement a slot change function.
This value can then be stored persistent in QCAD.ini/config if required.

One would expect that InvoluteToACircle requires a Circle or Arc entity as base but you implemented it with picking points.

I can find two references implementing a commandEvent: Line2P & DrawPolyline
In both cases that is used to execute Option Toolbar button actions with the command line.
The event is then accepted after the slot actions of the buttons is executed.
The action here would be nothing more than accepting the entered value.

I tried that out and it works:

Code: Select all

InvoluteToACircle.prototype.commandEvent = function(event) {
    switch (this.state) {
        case InvoluteToACircle.State.SettingN:
            this.n = parseInt(event.getCommand());
            event.accept();
            this.setState(InvoluteToACircle.State.SettingCenter);
            break;
    }
};

Remark that you don't validate the entry made in the Command Line and this.n can be NaN.

Further, in setState I am missing that the next variables revert to undefined.
This is required because the escape event throttles back but the variables are not cleared.
Here that isn't really required because a preview is only generated when all 4 parameters are known.
But I don't see any input validation.

About approximation:
The generated Spline is of the control points type.
With a low number of points it is obvious that the curve will never come close to the calculated points.
For a fit-point Spline you need to add them as spline.setFitPoints([refs]) but that requires QCAD Pro PROTOOLS
or at least RSpline.hasProxy().

As Last:
I associate SettingTipPoint with gears.
QCAD comes with an InvoluteSpur gear library item.
That draws involutes approximated by line segments and it includes at least a fit point on the pitch circle.
Created by Iain Hibbert <Matfie> and he later posted a paper about approximating a circle involute with splines.
https://qcad.org/rsforum/viewtopic.php? ... 757#p21757
That would require Splines of degree 4 for an average accuracy of 3.6e-6 or degree 6 for 4.2e-9 ...

I have a revision of that script running with some fixes and a few additions.
I didn't had the time yet to implement something based on the paper.
Your second degree Spline doesn't come close to Iain's calculated points.

Regards,
CVH

[wiekiera]

Hi CVH,

Thank you for your reply.

I am afraid it could be a step too far considering my current knowlege related to UI files .

May I remark that a number of points is usually something that is set in the Option Toolbar.
For that you need a simplistic UI file and implement a slot change function.
This value can then be stored persistent in QCAD.ini/config if required.

Works for me too, again thank you.

I tried that out and it works:

I had that in mind along with other safeguards related to picked points. But till now my mind was fixed on "my problem with events".

Remark that you don't validate the entry made in the Command Line and this.n can be NaN.

Well, I need the curves to visualise some aspects related to gear desing on 2D drawings. Just as a for fun project.

About approximation:
The generated Spline is of the control points type.
With a low number of points it is obvious that the curve will never come close to the calculated points.
For a fit-point Spline you need to add them as spline.setFitPoints([refs]) but that requires QCAD Pro PROTOOLS
or at least RSpline.hasProxy().

As mentioned above. My main purpose is to visually resemble the curve. With enough points it serves the purpose.
I would love to dive deeper in the matter of approximation accuracy. But in case of my application it would be an overkill.

Your second degree Spline doesn't come close to Iain's calculated points.

Regards

[CVH]

Jakub,

Ok, the quote's are under the answers.
We do that inverse.

I am afraid it could be a step too far considering my current knowlege related to UI files .

It is not that of a big deal, I could guide you trough it.

But till now my mind was fixed on "my problem with events".

Ok, got it, that being fixed ...
... Please add [SOLVED] to your first post title.

With enough points it serves the purpose.

Yes, to a point it becomes overkill ...
... To know that every tooth has 2 involute sides.

The curvature of an involute is larger at the base.
In essence we should spread them exponential but in what degree is not readily clear at the moment.
Iain has implemented 2 evenly spreads, 4 points below the pitch circle and 5 above.
In my adapted version one can set these in the dialog.
The biggest problem with his script was that it is not module based.
Meaning that matching two gears is (was) not that straightforward.

If I compare the function involuteAngle(radius, base) in InvoluteSpur.js with your approach it is like day and night.
I am not pro or con for any of both I'll have to compare the results first.
For now it seems that at least one method doesn't really approximates the involute.

Cheers from Belgium,
CVH

[CVH]

Jakub,

I am seeing some artifacts when I increase the tip distance beyond one to more turns.
On can see the shape deforming while indicating the tip position at various points.
In some occasions the last point seems to be off.

Points are created by:

Code: Select all

new RVector(P1x + t1 * T11, P1y + t1 * T22) 

Variable t2 is thus never used.

The odd thing is that P1x and P1y are already the coordinates of the involute of a circle for a given angle.
Can you explain me what t1, t2 and T11-22 are for ...

Regards,
CVH

[wiekiera]

Hi CVH,

Can you explain me what t1, t2 and T11-22 are for ...

I thought to define approximation of involute by start point, end point and tangents.
So, the first and the last control point should exactly match the involute. All the points in between are interesection points of subsequent tangents.
That is also the reason why my spline is of 2nd order. I can elaborate on that if you are interested.

At this moment I am not sure anymore if my idea was so great. I played also with other approaches.
I think spline defined by fit points is actually better. But it all depends on how fit points are distributed along the spline.

Regards,
Jakub

[CVH]

I thought to define approximation of involute by start point, end point and tangents.

Figured something like that.
Shouldn't p1' than be related to p0 and p2 ... p2' to p1 & p3 and so on?

So, the first and the last control point should exactly match the involute.

At least that is a match.

Because t2 wasn't used and the effort taken to calculate it, I even tried:

Code: Select all

new RVector(P1x + t1 * T11, P1y + t2 * T22) 

But that is certainly wrong, especially near start and end.

I think spline defined by fit points is actually better. But it all depends on how fit points are distributed along the spline.

As mentioned, InvoluteSpur.js distributes that evenly based on radius.
If we look carefully then your approach by angle has a closer spread near the base.
And that will enlarge the longer the unwound string is.
Just as supposed to.
It is only harder to inject a point at the pitch diameter.

It looks indeed fine with a fitpoint spline and it was the intention to adapt InvoluteSpur.js that way for Pro users.
What I wanted to test is using e.g. 10 fitpoints and see how good 9 points in between are a match with the involute.
If we could reach 1e-3 or better in a simple way that would be great for actual machining gears now that module is covered.
The thing of the paper is that QCAD is not really good in 4th or 6th order splines.

When time permits I'll send you the ways to implement an Options Toolbar UI by private message (PM).
I would add CW/CCW to that.

Regards,
CVH

[CVH]

Seems to be promising ...
For a module 100 with 12 teeth a fitpoint spline mimics the involute within:

Code: Select all

20 points:  0.029364994876464844
50 points:  0.0043368244421288634
100 points: 0.0010555574067154891

Knowing the tooth height for the involute part is 136.1848 ...
... then 20 points is within 216ppm

Regards,
CVH