Advanced Search

Guten Abend, ich habe die INI, HAL und XML configrutaion in meine neue maschine kopiert, ist momentan nur ein Motor angeschlossen um diese zu testen. Leider bekomme ich folgende Fehlermeldung. Welche eintsellung muss ich zusätzlich an den Endstufen vornhemen ?
Gruß Tom

I spent some hours..

1) flashed the octopus MCU with dfu-util
2) draft version of HAL and INI files done
3) wiring pi5 correctly to the octopus
4) pi5 is running remora flexi os

The error is from linux cnc when it loads my config: joint.5.scale pin doesnt exist. If I do a show pin with halcmd it shows a bunch of joints unit joint.4.

HAL file
INI file

@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?