Advanced Search

oh, by the way, im using inductive switches.

I was thinking the same thing about if it was "normal" I would have been able to find those posts. So i just assumed maybe I just didnt set something up right yet (like the slow parameter you mentioned, Ill give that a try). thanx

I tested with the Branches dev from GitHub and the Tang Nano 9k, but the motor still couldn't return to the zero position after stopping. You must use the same DM542 stepper motor driver to reproduce this problem.

 
 
 
 

 
 

glxgears runs fine from a terminal. i was using a couple Nvida cards early on, but they had other issuse with scrambling the screen. so I was told an AMD card is prefered for Linuxcnc anyway, because the proper drivers are baked in. Thats why i got that amazon one.
I'll try and download the ISO again and use a different USB. but i cant for the life of me find anything about secure boot in my bios.

rubes@x3cnc:~$ sudo dmesg | grep gpu
[sudo] password for rubes:
[ 3.922158] [drm] GART: num cpu pages 524288, num gpu pages 524288
[ 3.948192] radeon 0000:03:00.0: fence driver on ring 0 use gpu addr 0x0000000100000c00
[ 3.948194] radeon 0000:03:00.0: fence driver on ring 1 use gpu addr 0x0000000100000c04
[ 3.948196] radeon 0000:03:00.0: fence driver on ring 2 use gpu addr 0x0000000100000c08
[ 3.948197] radeon 0000:03:00.0: fence driver on ring 3 use gpu addr 0x0000000100000c0c
[ 3.948198] radeon 0000:03:00.0: fence driver on ring 4 use gpu addr 0x0000000100000c10
[ 3.948609] radeon 0000:03:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18
[ 3.968652] radeon 0000:03:00.0: fence driver on ring 6 use gpu addr 0x0000000100000c18
[ 3.968654] radeon 0000:03:00.0: fence driver on ring 7 use gpu addr 0x0000000100000c1c
[ 11.149261] amdgpu: Virtual CRAT table created for CPU
[ 11.149286] amdgpu: Topology: Add CPU node
rubes@x3cnc:~$

I wouldnt begin to know how to decipher that.

Shared home/limit switches are pretty common so I would expect more
complaints about this if this always happened.

I wonder if this is possibly  caused by contact bounce.

Have you set the switch input inm pins to "slow" ?

that was what I understood to be the case...but it isnt!!! ive done .1" to 1" offsets in both positive and negative. it dont matter. all that does is change the final parking position of home.
The hard stop tripped status shows up instantly when the axis hits the switch initially.
this is just a visual annoyance at this time so ill deal with it the way it is.

I tried this method (but did RIP instead):

forum.linuxcnc.org/9-installing-linuxcnc...th-preempt-rt-kernel

and the latency was horrid. The thread is from Dec 2022 thought it seems, so maybe there is a better way?

The latency isn't very good on the 2.9.8 image from the downloads page either, but not as bad as it was following the above guide. Maybe that's to be expected?

Everything just feels sluggish, and "jerky".

wow... ok.... i thank you.. i understand now more...

but here are some news.....

today i start making a excel... because i wondering why the gear ratios not fit which i get from unimation.... and then.... i get it... i open the gear from joint 2.. count the teeths... suprise... they changed the gears...

i get gear ratio from a puma 250.. i have a puma 200... .. now i open every gear... and count...

when i start with the robot i done this:

open all covers... check encoders.. wiring.. lables.. all what i can get.

then i start in linux counting form index to index pulse and see what was the counting of a/b. ok i get 250 cpr encoder on joint 1 2 3 and 200 cpr on 4 5 6.

then i start with the motors and angles... i measured with inclinometer. parallel i wrote a mail to stäubli and unimation... stäubli give me contact to rp automation. rp automation share some details with me.. they only have what they have.. so all what i get was stuff for different puma 2xx versions.

i calculated then the scales for each axis... it never fit.. i was thinking ok.. lets stay at the values i measured... but today i start opening the gears and i was suprised.... the teeth counting i get doesnt fit my robot.

if i am done with counting every gear.. i come back and try what you wrote.. but i see my failures and i am happy that you teach it to me because now i understand it better..

thank you!

There is not enough info here. What are you trying to do step by step?

I created the original 2.9.2 image, but have not touched it since. I don't have a pi to do anything further. I think Andy may have rebuilt later versions.
We had no choice but to build the kernel from the official pi source back then.
I think there could be better ways to do this as preempt_rt is now supported.

As for Step2:

Draw some simple poses and calculate the expected x,y,z coordinates:
 


Then create a sim config for genserkins and feed in the derived DH parameters. then test the results by setting up the joint positions as in the chosen poses while keepin the angular offset for J1 and J2 in mind (+- 5.49°) :

 
 
 
 
 

I would not worry about it just use it. Keep a spare SD card preconfigured. The only thing you need to do is keep a copy of your ~/linuxcnc folder

I've had a Pi4B running for 4 years on a standard 16gB SD card and it never failed. There is far more transactional data happening there.

It seems like the BF20L has a MT3 spindle. In this case, I would recommend you adopt Tormach TTS tooling.
You will need to buy a genuine Tormach MT3 collet to hold the 3/4" tools. I got mine from littlemachineshop in the USA.
You can premeasure your tools. Tormach sell a tiny granite plate with a hole in it so you can measure the tools with a height gauge.
Enter your tools and their heights into the LinuxCNC tool library
Then if you use QTdragon or probe basic, the probing for a 3D probe is all built in. They will prompt you when to change tools.

If you have shared home/limit switch, you should add a HOME_OFFSET to move off the switch before homing finishes to avoid this.

Here is the corrected suggestion on how to build the modified DH parameter model. The vertical offset (0.75") between J1 and J2 make things a bit more complex then in the 'puma560' sim config.
 
Some explanation on how modified DH parameters work:

- Each parameter set describes the coordinate transformation from one coordinate frame (F0..F6) to the next.
- Each transformation consists of the same sequence (X,Z directions here follow the current coordinate frame!)
      1. Translation along Xn so that the origin of the coordinate frame lies on the rotational axis of the next joint (Jn+1) 
      2. Rotation around Xn   so that Zn is collinear with the rotational axis of the current joint Jn . Note that the direction of Zn and the rotational direction of the physical joint MUST be identical! 
      3. Translation along Zn so that the Xn direction intersects with the rotational axis of the next joint (Jn).
- At the end of each transformation sequence we have created a new coordinate frame Fn+1.
 
Note that with these rules it is not possible to build a transformation from F2 to F3 without rotating J1 by angle theta1 so that the rotational axis of the next joint (J2) intersects with the X vector of F2. This then requires rotating J2 the same amount but in the opposite direction so the lower arm is vertical again. This needs to be corrected in the configuration by either setting a corresponding HOME_OFFSET value for JOINT_1 and JOINT_2 in the INI file or setting the work_offsets accordingly when in JOINT mode (these must then be deactivated when switching to WORLD mode)