i installed linuxcnc 2.9.10 via the released ISO. when i run the latency histogram from the application menu, it logs me out and pops up the login screen. i login again, and then the latency histogram program wont run at all. neither will the regular latency test. if i reboot, i can run the regular latency test, but if i try the histogram, it logs me out again.
is this a bug or maybe something wrong with my new system? 
i have
this motherboard , basically because i have one in my daily desktop, and it was cheap
this graphics card , because it is AMD not Nvida that was causing issues with scrambled screen
this network card , because it uses the intel chipset rather than the realtek one on the motherboard

 

thanks for the effort.. I think it is called a locked loop I have seen this also.
I have found that if i do a

ctrl + alt + F3

it takes me to the terminal login screen at which point I am able to log in with user name and password that was setup during setup and then do things in terminal mode. terminal mode seems to be working just fine. I have done the updates and the upgrade. per info on terminal screens but nothing past that at this point.

AI says there is fix for this locked loop thing but I have not done it yet. will do it later on.. now i have to learn all the command line stuff if i live that long .?

Thanks again for the help.
Ken

I did some tests with your big-blue-sim.zip.I made following changes:
1. Gmoccapy instead Axis.
2. Increased font size.
3. Removed comments from toolchange.ngc (looks horrible and unnecessary) :

This is some bug when you use gmoccapy's builtin tolchange :

(Need tool prepared -Txx- for toolchange)
This does nothing, only irritate, so I do not investigation now.
As I wrote, in gmoccapy ~/linuxcnc/nc_files/lathe/lathe_profile.ngc is not loading automaticaly and you must load it manually.

Becksvill wrote:

just wanted to message back here and explain some of the reasons for the tool wear remap t0101 etc
 

You have the right to use what you need, it doesn't matter why you do it and you don't have to explain it.
But when you share your project with others, you may find that they have different needs and preferences.
I suspect that the vast majority of LinuxCNC users use the standard M6Tn, have programs that use M6Tn, and tool tables that use M6Tn.
When standard LinuxCNC receives, for example, M6T7777, it will look for tool number 7777 in the table and if it does not find it, it will display an error and terminate the operation.
The solution to this problem is very simple - let the user decide whether he wants to use Tn or Tnnnn.
I suspect that you know your program and add one more button is not much work for you...

Please. Can someone tell me how to update debian bookworm. I am getting this error
dpkg: error processing package linux- image-6.1.0-40-rt-amd64 ( --remove) :installed linux-image-6.1.0-40-rt-amd64 package post removal script subprocess returned error exit status 1
dpkg: too many errors, stopping
Thanks
 

Grandixximo just wanted to ask have you done any work to fix the lookahead on multiaxis movements.  on the old trajectory planner the lookahead reverts to slower movement (almost no lookahead) when using a 4th axis.  or any extra axis after 3 axis  it's a real pain when machining

i have been playing with scurve sim but can't work out if it fixes the issue yet. so thought i would ask a question about it here

cheers

Chris there is a bug with the index enable stuff i think when summing the PID loops like this. I forget exactly why i connected both encoder index pulses to index enable

i read i think earlier in this thread that you can connect both encoders to index enable and also connect them with a physical wire so the first index to fire triggers the homing. but i couldn't get it to work. rereading my post it sounds like i just messed this up but i really do think there is a bug. I could test if you want to go through with me and prove the issue. we have messaged off forum on messenger before..

so i tried just one PID loop with the velocity input coming from the encoder and the position input coming from the scale. and that homed to index enable fine but the tuning was really rough. i couldn't believe how bad it was. it was like there was a stuffed bearing on the ballscrew. and the axis kept bounching back and forth around the 0.1mm backlash which was unusable. and after i had just tested the other way with a smooth as silk axis that always stopped perfectly within 0.002mm I wasn't going back I talked about the mesa index enable issue with PCW a bit but i ran out of time to fully prove it was a bug. But i definitely think that having the 2 separate PID loops breaks the index enable logic.

anyway after all that i read somewhere on the forum that someone else had the same issue for some reason and the really inelegant solution is to run the home switch through classic ladder and have it trigger on the home switch first and then look for the change in homing state and on the next state when the encoder is searching for index pulse use classic ladder to feed it the encoder physical index pulse from rotary motor encoder on end of ballscrew. this means that you have to home that last little bit extra slow as it can miss the pulse. and it is not that best. But in saying that i haven't had it miss the pulse yet and it's not that much slower to home.

But i would like to fix this as this is the last annoyance that if it was fixed i would probably go crazy and put scales all over my machines lol

So Chris your classic ladder is still getting used all the time by people keep up the good work.

cheers andrew

Hey Tuxcnc

just wanted to message back here and explain some of the reasons for the tool wear remap t0101 etc

On almost all commerical cnc controllers (fagor fanuc mazak misubishi semiens heidenhain (also Pathpilot which is sort of a commerical version of linuxcnc)  you can change a offset to account for the tool wearing or machining cutting slightly the wrong size over time or part to part.  usually you have a option where you can just change the value by 0.05 or something and it changes the size the machine cuts a bit.  if you only use T1 m6 g43 then you have to adjust the actual tool geometry offset.  which if you have boring bars and also turning tools can be like 300mm different.  if you muck up your maths here or make a typo.  i been there and done it then the next time you run the machine it crashes.  and then also if you have a unskilled operator on the machine it's even worse.  anyway all these issues are good reasons to have some way to make only small changes to the tool size.  the T0101 remap is not the best way i could be quite happy with just t1m6 also if there is a good way to include wear offsets but i haven't seen one so i use the remap that chris morley made years ago.  I have a production lathe that would have made 50,000 parts now and wear offsets are essential in my opinion.  

I can probably change the cycles to output only T1m6g43 once i am finished if you want it.  though your solution you showed seems to work.

cheers becksvill

Ah i think i understand what you mean.

The model stays in a different position as the seted dh paramters ? Because i rotate the hand axis ( all 3) and the main tower.

Dh parameters= real positon/ angles
Vismach model = not build by dh paramters.

Or what do you mean?

The dh parameters i set are the parameters i get from right hand ruled cs. Possible i do it wrong. Because .. if i home over my sharpie marks the arm is in this position:

Joint 1 0 ( about 140 +- to the mechanical limits)
Joint 2 0 (90 deg to tower.. means parallel to base)
Joint 3 0 ( 90 deg to joint 2... means parallel to tower)
Joint 4 0 ( mid position +- 320)
Joint 5 0 ( mid position +-125)up and down same direction as joint 2 and 3
Joint 6 0 (mid position +- 280) left right same as joint 4

The values of A and D i get from the drawing
The Alphas i get from right hand rule cs.. and the signs for the A and D values i get with the alpha stuff.

And the angles after homing i checked with a digital pritractor... and the scales i checked with 90 deg moves looking to the digital protractor.

Hi grandixximo,
We really appreciate your dedication to solve the jerk limiting trajectory planner issue.
Can you share the update on any git repo to get wider community feedback started?
Looking for to testing the new fixes.

-automata

Because I'm busy with work, I'll do testing when I have time.