Advanced Search

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

 

Yes, although I think that your DH parameters have the wrist pointing straight down. Having it point straight down instead of 90° to the right as in the image is not wrong but it is a singular pose and hence you need [JOINT_4] 'HOME = 0.1' in your ini file to avoid an inverse kinematic failure right after homing.

In any case, the important thing is that the home pose MUST be the same pose as what you used to derive your DH parameter values. If an angle in the model is 1.570796 then the angle between the corresponding links of your physical arm needs to be as exactly 90° as possible when all joints are at 0°.
In other words:
With all joints at 0° your upper arm needs to be horizontal and your lower arm needs to be vertical like in the drawing. If you have setup your DH parameters for the pose with the hand pointing straight down then the center of the flange needs to be exactly vertical below the wirst.

That is really why you need to understand what those DH-parameters mean in your particular robot.

Hello,I am trying to configure M19 spindle orientation on LinuxCNC 2.9.4 using the standard orient component.My spindle is driven by an analog servo drive (0–10 V speed command) and direction is selected by a relay (CW/CCW). Because of this hardware, the PID output is converted to an absolute value and the direction is handled separately. The orientation itself works surprisingly well, but I have a strange drift that I cannot explain.Hardware

• LinuxCNC 2.9.4C10 breakout boardParallel portAnalog servo drive (0–10 V speed reference)External incremental encoder (100 PPR, TTL, A/B/Z)Encoder position-scale = 400 (quadrature)

  encoder.0.position

  increases by exactly 1.0 per spindle revolution

HAL architectureThe orientation chain is:

• orient

  pid

  mux2

  PID output →

  abs

  Sign handled separately by logic (

  and2

  ,

  or2

  ,

  not

  ) driving the CW/CCW relay.

The relevant HAL section is attached below.What works

• M3 and M4 work correctly.Rigid tapping (G33.1) works correctly.M19 works mechanically.

The problemBetween different executions of the same G-code program, the spindle zero slowly drifts.1–2 degreesAdditional observationsAfter M19:

• orient.0.is-oriented

  is always FALSE.

  spindle.0.is-oriented

  is also always FALSE.

  orient.0.poserr

  is typically around 73 degrees.

  orient.0.tolerance = 0.5

  Visually, however, the spindle is correctly oriented.

Signal values:

• encoder.0.position = spindle.0.revs = orient.0.position

  Position is in revolutions (1.0 per revolution).

Another observationWhile debugging I discovered something unexpected.With the servo drive powered ON (motor stopped), the external encoder produces random A/B/Z pulses.The encoder is even removed from the motor and rotated by hand.If the servo drive is powered OFF, the encoder signals become perfectly clean.This may be a separate EMC issue, but I do not know whether it could also explain the orientation drift.QuestionHas anyone seen a similar behaviour with thecomponent?In particular:

• should

  orient.0.is-oriented

  become TRUE after a successful M19?is a

  poserr

  of about 73° compatible with a visually correct orientation?could the drifting reference be caused by the encoder/EMC issue, or is there something wrong in my HAL logic?

Any suggestions would be greatly appreciated.I can provide the HAL file if necessary.Thank you.jelost

Moved to "post processor" section.

You mean this position? 

I was thinking it was only to show dimension?!

There is little more than a single bug fix in 2.10 so unless that is going to affect you which it probably isn't, just get your Mesa card up and running with the working system you have.

The whole point of version 2.9.10 was that the 'single bug' could crash a users machine. So if the 'which it probably isn't,' turns out to be a wrong assumption then it might actually crash your machine if you happen to use existing probing routines.

That is why there is a ready made ISO to get you started:
Download and install 'Debian 13 Trixie PREEMPT-RT ISO'
linuxcnc.org/downloads/

Thanks very much for your knowledge and advice rodw!

I'm taking it to heart and will NOT update for now.

I'm going to continue posting progress and I hope you'll find it entertaining rather than laughable!

Thanks Guys fro trying.

"the realization is " I am "OVER MY HEAD and sinking FAST
Linux / LinuxCnC.

toooo many choices and tooo many variables
in OVER MY HEAD
But thanks for trying

Hello, I am working on a little project.So far I made it only for WinNC Sinumerik, but how usefull could this be once finished?Currently since I have just started the project, it can only do CatiaV5 aptV1.0 but Autodesk has a really good post processor open source code. Also there are some functions missing in Catia, bc I am waiuting for the GPU for my pc to arrive.The idea is to use the free APT output from Catia and translate it to needed G code.Here is the git repo, I am currently yet to finnish my website when done so it will be free to use it on.github.com/karlo-c277/APT-Gcode

Hey tux CNC

Thanks for the feed back

This software is still getting worked on. It was just made for me but hoping to help others also.. Thanks for the feedback. And keep adding to it as you test and I'll try fix stuff if that's possible.

About the sizing yes made for axis so it's a nice fit on my screen.