Advanced Search

Search Results (Searched for: )

  • PCW
  • PCW's Avatar
Today 15:41

Chinise mesa clone vs Original vs Ethercat

Category: Driver Boards

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

 
  • Aciera
  • Aciera's Avatar
Today 15:33
Replied by Aciera on topic PUMA 200 Robotarm and some Hal/INI issues

PUMA 200 Robotarm and some Hal/INI issues

Category: Advanced Configuration

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.
  • jelost
  • jelost
Today 15:15 - Today 15:18

M19 orientation drift with external encoder and orient component (LinuxCNC 2.9.4

Category: General LinuxCNC Questions

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 the
orient
component?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
  • tommylight
  • tommylight's Avatar
Today 15:01
Replied by tommylight on topic APT - Linux CNC Post processor

APT - Linux CNC Post processor

Category: Post Processors

Moved to "post processor" section.
  • hitchhiker
  • hitchhiker
Today 14:43
Replied by hitchhiker on topic PUMA 200 Robotarm and some Hal/INI issues

PUMA 200 Robotarm and some Hal/INI issues

Category: Advanced Configuration

You mean this position? 

I was thinking it was only to show dimension?!
  • Aciera
  • Aciera's Avatar
Today 14:37

Successful Raspberry Pi 4 Trixie LinuxCNC install.

Category: Installing LinuxCNC

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.
  • Aciera
  • Aciera's Avatar
Today 14:26
Replied by Aciera on topic Ver 10 NEW install

Ver 10 NEW install

Category: General LinuxCNC Questions

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/
  • Rykagon
  • Rykagon
Today 14:24 - Today 15:06

Successful Raspberry Pi 4 Trixie LinuxCNC install.

Category: Installing LinuxCNC

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!
  • 5280
  • 5280
Today 14:04
Replied by 5280 on topic Ver 10 NEW install

Ver 10 NEW install

Category: General LinuxCNC Questions

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
  • karlo.ugrin
  • karlo.ugrin
Today 13:33
APT - Linux CNC Post processor was created by karlo.ugrin

APT - Linux CNC Post processor

Category: Post Processors

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
  • Becksvill
  • Becksvill
Today 10:20
Replied by Becksvill on topic Conversational CAD CAM

Conversational CAD CAM

Category: O Codes (subroutines) and NGCGUI

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.
  • andrax
  • andrax's Avatar
Today 09:52
  • Aciera
  • Aciera's Avatar
Today 07:59
Replied by Aciera on topic PUMA 200 Robotarm and some Hal/INI issues

PUMA 200 Robotarm and some Hal/INI issues

Category: Advanced Configuration

It's going to very difficult to troubleshoot the basic setup by running random gcode files. You need to take a step back and simplify things so you can actually wrap your head around what is going on.

First you need to verify that your home position is really putting the arm in the pose it should be. Which means the pose shown on the drawing you posted earlier. If your flange is not correctly oriented to the base plane (ie parallel or perpendicular to your table) then you need to adjust your HOME, HOME_OFFSET values in the INI.


Once you have verified that the home position is actually correct, you can check your DH parameters by positioning the arm in different simple poses in joint mode, then switch to world mode and check if the cartesian coordinates in the DRO make sense. Simple poses would be those with joint angles like 0°,90°,180°. Make a diagram on paper, calculate the theoretical XYZ position using your robots link lengths and compare that to the XYZ values in the DRO.
Small inaccuracies are to be expected but if you have a rotation direction or a link direction wrong then your values would be way off.
  • NWE
  • NWE's Avatar
Today 06:19

Chinise mesa clone vs Original vs Ethercat

Category: Driver Boards

hi,
with Pulse and direction top speed and precision calculus are clear  but

But how to calculate the bandwidth on a Ethercat servo drive and precision?
let say leadscrew pitch 0.100inch encoder servo 10000 ppr?
if bus cycle time is 1000000 and refClockSyncCycles=1
how to determine the top speed IPM and minimal resolution in  Inches (minimal cut).
 

With ethercat servo drive operating in velocity mode, your main limitation will be the servo's rated/max speed. The resolution limitation will be time based, if I'm correct LinuxCNC EtherCAT will have something like a 2mS feedback latency on a 1mS thread, so this will limit your positioning accuracy during very fast moves. I am not aware that a regular machine tool is capable of reaching this speed limit.
Here is a detailed explanation how it is timed.  
Displaying 1 - 15 out of 14262 results.
Time to create page: 0.394 seconds
Powered by Kunena Forum