Hi, 
after running our system for a while, sometimes linuxcnc basically stops working, starts acting very weird and i get this in the logs
halui: updateStatus: status buffer is not valid
Can you please help me diagnose this, as I don't event know where to start looking.

@grandixximo: I'd like to test it, but I'd rather wait until your changes and optimizations are incorporated into the official repository.
Until then, I'll stick with refClockSyncCycles="-1" for now.

ethernet - i've finished the hardware, but still working on software...

 

I have added 4th axis rotary and 5th axis tilting head, bascially XYZAB configuration. In vismach it moves machine parts (rotary and tilting head) as i move A/B axis. But tool remains at same loaction, it moves on xyz only.

grandixximo wrote:

The new PR with comp kinematics support for TP2 will have artifact debs at the end of this link

github.com/LinuxCNC/linuxcnc/actions/runs/23100211514?pr=3807
 

thanks a lot and 9d branch is now avaible for rip testing with TP2 without spindle sync movement? 

What errors do you have?
 

I made some headway today! I gave up on chasing ghosts in my existing configuration and decided to start all over again. I did a completely new pncconfig barbones setup without limits spindle or home switches. I was successful in getting a installation free of errors yeh!! I was able to get movement on all axis and that was good but no homing or limits that of course was not very good. Started playing around to get limits going until i totally messed up that installation combined with custom ini and hal files. That didn't work. So I started all over again and tryied with limits and estop and probe. Well non of the pins for those limits existed and at this point i cant get the machine to unlock even with no errors. I commented out beginning error lines starting at hal 34. and commented all of those non existing limits in hal. I have 24v at the inputs 04 thru 09 and .4v when the nc switches are activated. I have attached the new ini and hal file to see if anyone can help figure out what is happening. Thanks to all helpers

Maybe send as screen shot of your roster settings and probe page settings as well as your z travel.

Also have you edited your var file and added all of the parameter numbers shown in the probe basic docs so the settings are persistent?

Where is your zero home in z

Running the ClearPath motors in quadrature mode is free, same wiring and everything. AFAIK there are only upsides to doing so- your fastest signal becomes half as fast, so you gain margin, and noise is less likely to accumulate into "permanent" errors, more likely to jitter back/forth one step. Which is still bad, but less bad.

Even if that has nothing to do with anything you're experiencing, I'd still advocate for it as technically better.

tommylight wrote:

How much is that in distance?
 

Tommy...
The standard encoder for Clearpath is 800 counts/rev.  With 4mm pitch screws that's about +/- 20 microns before the servo vomits.

OP...
I've had issues with clearpath step/dir that were resolved using the resistor they indicate in the user manual.  Your cables may not be very long (mine were ~20 feet), but it did help with lost pulses from the PLC to the motor.

Note that I never had an issue with direction changes, only the motors not moving as far as I'd expected.  I chased couplings, planetary reducer shaft clamps, and everything mechanical until I put the resistors in.

Also, Clearpath has an input filtering setting in MSP software; might want to play with that if you think some of the pulses are going astray.