Advanced Search

Yes, this is very interesting.

and after reading

forum.linuxcnc.org/ethercat/58227-how-go...ion-control?start=20

From: NWE

this Make me feel that 1,000,000ns thread is slow for ethercat
But as the same time I start to fill myself in the place of look ahead reading paradigm where I can make interpolated circles as fast as my control system can respond on time without lose the path

Thinking in real world G0 at 200IPM and I never machine a part beyond 100 IPM, and high precision, this is not my goal, I guess I will need a controlled temp room for this propose and this is not my field. +-0.003inch it is fine.

My question is Ethercat is enough at 1khz thread to keep the path? ,or should I look for a 500,000 servo thread. Or less?

I have a system full LCNC and Ethercat control, my concern is, how to reach a 200IPM max speed and 0.0001 min resolution in a repeatable and stable motion system, I think now about what is on my control and what is not, what variables I can candle and what I cannot handle, and what is on my budget and what is not.
And as well I fill lack of experience and acknowledge on a perhaps non mature control method. Compared with analog or pulse and direction methods

compared with pulse and direction method mesa card at 100 or 200 kHz is enough for a 200 or 300 ipm at 0.0001inch min resolution. Where even with my parallel port 10kHz I was not far from my needs. And under this method I feel that I can handle all variables that the system have, and I can keep them under control.

But in the other hand I feel ethercat is the future, clean wiring, a lot information from servos and VFDs, closed loop etc. and every day you can find more and more equipment that offering this control method.

Someone has been working with smaller servo thread than 1,000,000ns.
someone on a multi thread CPU has been isolated the ethercat servo thread In one CPU thread, as the same is done with LCNC, Is that possible? Can be helpful?

Please share your experiences.

I use UHU DC servo controllers. They compare the actual position with the target position. If the deviation is too large—for example, if I crank faster than the axis moves—the controller goes into a fault state and stop the axismoving.

tuxcnc wrote:

There are many reasons why you should not use MPG for turning, but I will give you just one - you can turn the handle faster than the axis is moving, in other words, when you are done turning, the axis will continue to move until it reaches the commanded position.

LinuxCNC MPG inputs can be configured to stop moving as soon as the MPG stops. (Because this is such an obvious problem)

joint.N.jog-vel-mode

at

linuxcnc.org/docs/stable/html/man/man9/motion.9.html

It might be worth looking through the PRs as I think that there is other work ongoing in this area.

github.com/LinuxCNC/linuxcnc/pull/3718

After homing in joint mode (idintity) i add second screenshot from world! but i moved B a little bit to go away from 0.0
in my ini:
 
RS274NGC_STARTUP_CODE = G21 G90 G94
#RS274NGC_STARTUP_CODE = G21 G10L2P0 x19.2 y5.5 z9.4 a0 b90 c0 (debug, ini: startup offsets set)

ALPHA-0 = 0
A-0 = 0
#D-0 = 330.2
D-0 = 328.93

ALPHA-1 = 1.570796
A-1 = 0
#D-1 = 121.92
D-1 = 0

ALPHA-2 = 0
A-2 = 203.2
#A-2 = 198.12
D-2 = 121.92
#D-2 = 0

ALPHA-3 = 1.570796
A-3 = 0
D-3 = 203.2

ALPHA-4 = -1.570796
A-4 = 0
D-4 = 0

ALPHA-5 = 1.570796
A-5 = 0
D-5 = 55.88


thanks for your help!

Lets verify your home pose:

1. Home the arm
2. Activate 'Identity' mode
3. Remove all offsets (MDI: g10 l2 p0 x0 y0 z0 a0 b0 c0)
4. Move all joints except joint_4 to zero (MDI: g0 x0 y0 z0 a0 b0 c0)
5. Take a screenshot of the axis gui window
6. Take a picture from the side (ie the Y direction) of your robot
7. Post the two images

Hello everyone,

I'm an engineer based in Switzerland, French and German speaking, doing
research before building my first LinuxCNC machine. I have a background
with other CNC and PLC systems (FANUC, Beckhoff, Siemens...), and I'll be using EtherCAT hardware.

I started with a week of plain reading — docs, forum, source. Coming fromother controllers, what I really wanted was a picture of how a G-code lineactually becomes motion. At the same time I was experimenting with AI for
my job, so I combined the two: I used the machine-learning work as a way
into the codebase, and the codebase as a serious test of the tooling.

Two things came out of it.

First, the Code Notes block diagram, redrawn and brought up to date:

   zia-research.github.io/linuxcnc-audit/sh...de-notes-errata.html

   The original diagram as published, side by side with a corrected
   version reflecting the current source.

Second, a generated command-flow sheet:

   zia-research.github.io/linuxcnc-audit/sh...nc-command-flow.html

   An animated sheet following one command all the way through: .ngc file
   -> Interp -> canon -> interp_list -> task -> the emcmot shared segment
   -> motion-command-handler -> the trajectory queue -> tpRunCycle ->
   inverse kinematics -> HAL -> pid/stepgen -> hardware, and the feedback
   path climbing back up. Hovering any block shows its role and the source
   file behind it. It also carries three detail panels: the servo cycle as
   a ring, the seven position representations, and every buffer drawn to
   scale.

I know the reputation AI-generated content has, so the rule throughout was
that nothing is claimed without being verified in the source, every
statement carries a file:line citation, and a script re-checks all 111
citations against the tree so anyone can validate them independently.

That verification work turned up a handful of places where the
documentation and the source have drifted apart over the years — the Code
Notes say so themselves in their opening paragraph. Nothing dramatic, but
a few would bite someone: an example in the HAL manual that names a funct
which doesn't exist, and one behaviour around spindle-synchronized motion
that isn't documented anywhere.

After that I let the AI implement the corrections as well. Small doc
patches are ready if there's interest, but that's secondary — the sheets
are what I mainly wanted to offer.

Everything targets master (2.10.0~pre1); I'm aware some details differ on
2.9.x.

The most important part:

   Could someone with real experience of the codebase take a look and tell
   me whether this makes sense? I'm new here, and a diagram that is
   confidently wrong is worse than no diagram at all.

Sources, findings and patches:
github.com/Zia-research/linuxcnc-audit

Many thanks. I'll give it a try.

ah i get it...i think..

this means... its important that if i jog in +.. the + the direction is of the joint i move... and this is the direction of the arrows +.

this means for the alphas from the drawing: 0,90,90,0,-90,0 would be tool to the table?!

my setup is alpha 0,90,0,90,-90,90

i throwed again my hand with the right hand rule.. thumb up is Z..
i get 0,90,0,90,-90,90 BUT the toolplate is parallel to the base/table. different is that the toolplate is in another angle?!

its so complex...

thank you for your help....

Routerworks wrote:

Any suggestions?
 

camotics.org/gcode.html

Regarding the joint rotation direction: It does not really matter if you follow the drawing or not the important thing is that the actual joint rotation directions on your arm match those in your DH-parameter model. Again, the DH  parameter values describe the sequence of translations and rotations used to transform the world coordinate system in the center of the base to the hand of your robot.
The positive rotation sense of each individual joint motor on your arm is determined by how you choose to manipulate the coordinate system on its path to the hand when you derive the DH parameter values. That is why you need to understand what the DH parameter model actually is. But I repeat myself.

The side offset (ie the one in the y direction) is the distance between the rotational axis of joint0 (likely the center of the vertical column) and the center of the wrist.

I have tried a few online g code viewers.  None of them seem great.  Actually the best and most accurate one is the one that comes with Linuxcnc.  However I would like to view my g code on my windows computer where my CAD and other software are locaated.  I have been using NC Viewer but it won't slow down g83 g code or show the pecking steps.  
Any suggestions?

Thanks in advance.

i got some datasheets... interesting part:


i the joint angle view.... the arm is upside down?!
the arrows and signs show the alpha for each joint?! or i am wrong.. then is my DH parameter list complete wrong...

in the drawing with the measurements... the arm is in the NEST position... dont care.. but all measurements are present... now.. i wonder because:

joint 1 is the base which rotate left and right              alpha 0
joint 2 is the upper arm on the shoulder                     alpha+
joint 3 is the lower arm on the elbow                          alpha+
joint 4 wrist rotate                                                        alpha 0
joint 5 wrist roll                                                            alpha +
joint 6 toolplate rotate                                                 alpha 0


we have a side offset from shoulder rotation point to base rotation point..
we have a side offset from upper arm to lower arm...

but i was thinking that the side offset ist from base turn point to middle upper arm..... complete wrong?!

thanks guys!

 

It does sound like the issue is EMI causing miss-counts.

Software read encoder counters are more susceptible to noise
because they do no have a high enough sampling rate to allow
oversampling/ filtering of the A/B/Z signals. This means  that very
short noise pulses on the inputs can result in a miss-count

Possible fixes:

1. Use differential signaling on the A/B/Z  signals and a differential --> single ended converter
to convert the differential signals to the single ended parallel port signals.

2. Use some RC filtering of the A/B/Z signals at the parallel port end of the wiring.

For velocity mode servos (of any kind) one limitation is that the drive effectively does
linear interpolation between waypoints, so  you get what I would call a chord error
which depends on acceleration and servo thread rate.

For typical machine tool accelerations and  and say 1 KHz thread rates, this error is quite small
but machines that have high accelerations and need high precision may require either higher servo
thread rates or using second degree interpolation in the drive.


Chord error polygon vs circle =
R (1-cos(180/N))

R = radius
N = sides

R = Minimum Radius= V^2/A
N  = Sides = T_Circle/T_Sample