Advanced Search

@Fabian,

Most of the math of Frego is already inside the 2d clothoid library.
There it solves the clothoid G2 problem using 3 connected clothoids.
As later on discussed on github, adding the z component to the xy was proposed by using the Frego 3d paper.

The new paper is for me more understandable.

I have noticed in the new paper, that the 2 gcode segments are transformed to a null plane first.

This same approach i used before when we construct a clothoid when 2 gcode segments share same plane.

Then the 2 gcode segments in 3d space are transformed to xy plane, clothoid is build in xy plane, clothoid + gcode segments are
transformed back to original 3d space position. This worked flawless.

So this part of the paper, we can almost skip. As we know the mathematics for it.

Attached a few files where i tried to implement paper equatations. They may contain wrong approaches.

For now i am stuck at eq.40.

@Collins,
Maybe this is the same as starting with a bspline from segment a to segment b. Then manipulate the spline trajectory
to get a G2 result and apply a clothoid property like
"a curve whose curvature changes linearly with its curve length"

I cannot say anything about your analog predicion machine, as i can't imagine how to appy it to our work.

 

I went with
net x-fault => joint.0.amp-fault-in <= hm2_7i96s.0.inm.00.input-04
so I get an error on x for all my axis. Because I wired all alarms in parallel. Which is absolutly fine. As long as the machine stops on any error

Almost sounds like orients addf is missing (or some of its control pins are not in the correct state)

Played around with orient a bit and it seems to behave as expected:

Before orient enable:

 


After orient enable rising edge:

 

Note that the command has been rounded to the nearest whole number of turns
and the error shows the current difference of the angular position from the orient angle

The only odd thing I noticed is that the orient angle is latched on the rising edge of orient enable
so cannot be changed after orientation begins.
 

I have been loosely following this for sometime and, I have a sincere question. Would this not be better implemented as a analog NN ?

This problem is difficult to solve because the calculations are based in lots of heavy math and splines where in essence we are attempting to create a plot of points in a 3d cloud. But that's not really optimal in reality.

I wonder could a NN be created to replicate the function of a analog calculator like a Tidal machine that can take the various inputs of a spline, end point, curvature etc and then it would produce via analog calculation the correct output ? Sure seems like it would be a far better solution.

en.wikipedia.org/wiki/Tide-predicting_machine

I chose 47 Ohms because most OPTO inputs on step drives need
significant current (up to 10 mA each). I wanted to make sure that
The voltage at the (paralleled) ENA+ input was close to 5V when the
SSR was off.

As you can guess from my earlier reply, honestly I do not know.

It switches off all moves. And it makes the E-stop button on Axis GUI (General User interface?) greyed out.
On my mill this is the E-stop! I wired the E-stop-mushroom switch in series with the E-stop input to the VFD, so this tells the drive to stop. That is as safe as it gets for this machine, for me. Spindle stops via hard wire (with soft input to the VFD) and the motion control is aborted from Linux.
To switch on again, I need to pull out the mushroom button and power on the machine again via mouse cklick.

That is a small benchtop mill. I think I can take the risk for this size and speed of machine. On a real heavy industrial machine I would probably do more homework and invest in some more professional hardware.
e.g. on the manual Lathe a bigish contactor is installed by the manufacturer. If someone is barely touching the foot brake, it trips and cuts power to the motor. (all three phases) Before it turns on again, it must be switched off first and then on.

Here I found some other discussion with some aspects.

forum.linuxcnc.org/38-general-linuxcnc-q...-card-7i76e?start=50

I would widen the following error limits in the ini file
so you can see the behavior (be careful of runaways)

Have you verified that you can control the motor with the PWM signal?

Regarding the Frego paper, only the closed form solution needs to start from the straight line, the numerical calculation works for all cases.
However, the paper only gives the recipe how to calculate a 3D clothoid given the starting values. It does not explain how to fit 2 or more of them together to connect 2 points in space with given start and end conditions. So the new paper is the way to go as it also explains this part.

like Aciera said. tilde means the object is in the transformed coordinate system and the numbers of ' show the order of the derivative in respect to curve lengths s. In this case they are from the boundary condition trajectories (lines or arcs) so you get the expression from multiplying equation (26) or (27) with the transformation matrix. Well 26 is easy as 0 stays 0.

Ok that's cool. But is iocontrol.0.emc-enable-in already the location for the estop. So when the net connection is made. Does the event trigger the estop?

In the meantime I solved the issue. I connected the Raspberry Pi gpio output pin to motion.digital-in-00 and now I can read this RPI output pin with M66. No need for a macro anymore...

My guess: this is probably not certifiable real E-stop behaviour. It works for me, but for "real machines" dedicated safety circuits are probably required and all this is more for User interface not to actually switch things off.

Maybe someone can confirm if this guess is correct?