Advanced Search

Okay, will try that when problems retturn. Thanks!

Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.9.8
Machine configuration directory is '/home/ricco/linuxcnc/configs/mill_touch_sim'
Machine configuration file is 'mill_touch.ini'
INIFILE=/home/ricco/linuxcnc/configs/mill_touch_sim/mill_touch.ini
VERSION=1.1
PARAMETER_FILE=emc.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=
DISPLAY=qtpyvcp
COORDINATES=X Y Z
KINEMATICS=trivkins coordinates=XYZ
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(REL): ./mill_touch.hal
Found file(REL): ./custom.hal
Starting TASK program: milltask
Starting DISPLAY program: qtpyvcp
Can't execute DISPLAY program qtpyvcp  
Shutting down and cleaning up LinuxCNC...
task: 29 cycles, min=0.000006, max=0.012605, avg=0.005740, 0 latency excursions (> 10x expected cycle time of 0.010000s)
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
Unexpected realtime delay on task 0 with period 100000
This Message will only display once per session.
Run the Latency Test and resolve before continuing.
3180
3212
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

Z400 are very good, so i would not change it, but in case you have issues again, try removing memory modules, never happened to me on a Z400, but happens sometimes on Z420 and happens a lot on Z600, at boot reports of memory issues that mostly disappear on their own.

How did you design the process?
You write the values for homing in 0x6041 and 
then set a bit for start homing, right?
The servo should then respond with a status bit that can be monitored.

Or I have three other suggestions that could be considered 
1. 
After writing 0x6041, read the register again and check the consistency.  Then start homing and monitor a status bit

2. 
Monitor the axis movement.
The axis must start moving after start homing.
A minimum distance could be specified here, otherwise an error will occur.

3.
Gantry version
The axis positions could be compared with each other.
If the difference is too great, then there is a malfunction.

PS: There was once a project called “Ethercat auto configurator.”
Is this still being pursued?

Today all is functioning normally again. Ran a 30 minutes program without errors. So I don't know what happened yesterday, maybe I need a new pc.

remember limit switches need to stay triggered to the end of travel.

Hakan wrote:

From what it looks like, the only way out from homing is that is finishes.
This could probably be expanded to include error states and whatever can occur.

 

Back after my IP being banned for a week! (Thanks for letting me out of Jail Andy!)
Maybe thats an oversight. the homing process is managed by  the cia402 state machine. Homing completed is returned in Bit 12 (from memory) and if it errors, that is returned in bit 13). The function of these bits are often not well documented but its really standard cia402 behaviour.

The problem is that the dongle resets itself. Basically the same as pulling it out of the USB port and reinserting it.

In the situation where you try to jog with the pendant while running a program, this is caused by a too long time during which the xhc-whb04b-6 component does not poll the dongle. This we "fixed" with the loops=10.

In the other situations that happens "randomly" after some time, I do not know what the reason is.

My original Maho wiring diagram was wrong for the EXE wiring. I also had to try other pin outs. IIRR Heidenhain seemed to always use one of two pinouts, and the other one worked for mine.

What did you find as being the problem? You probably already wrote it, can you do it again?
What is the way to fix?

New PR from YangYang is ready, hopefully will be merged soon in master

This adds ruckig in the planner type 1
if you want to test it get the binary from

github.com/LinuxCNC/linuxcnc/actions/runs/21975584400

or build source from my repo

github.com/grandixximo/linuxcnc

Testers are welcome to report here or in github, thanks!

Mekanoid wrote:

output of lspci shows no parallel port controller

 

Not sure what to make of that. I was under the impression the motherboard parallel port and any PCI parallel ports always list in lspci. Maybe someone else can confirm this. My suspicion would be the controller I.C. for the parallel port is dead...

edit:
just learned onboard parallel ports don't always list in lspci

Do you have a parport in /dev?
I would also check output of sudo dmesg

My next step would be to check the parport voltage outputs with a multimeter or oscilloscope to verify the voltages on the pins change as expected when commanded in LinuxCNC. I would do this with the parallel cable disconnected from the cnc machine.

5_Zylinder wrote:

I'd like to know why this is happening.

For what it's worth, I once worked on a machine that did a similar thing. I my case it was encoder counts. The entire system was Seimens brand electronics from the 1980's. One day they switched it on and one axis experienced runaway until following error stopped it (nearly instantaneously). We had no documentation for that machine and nothing was labeled. I ended up swapping A and B from the axis feedback glass scale encoder then everything worked again.

We assume a logic fault somewhere in the computer's many circuit boards caused the mysterious fault.

No problem, I talk to myself a lot when I'm programming.

Marcos wrote:

Thanks for the explanation, that makes sense for your setup.

When I mentioned cost, I wasn’t really thinking only about the price of the drives themselves. The hardware can indeed be quite cheap nowadays, especially the Chinese EtherCAT kits. What I had more in mind was the total cost: time spent integrating, debugging, dealing with CiA402 states, homing behavior, synchronization issues, and so on. In LinuxCNC, that complexity is very real, as I’m sure you know.

For my own projects, I’m not looking at EtherCAT as something that would “upgrade” my machine in a practical sense. If I end up buying an EtherCAT drive, it would be purely to learn and experiment with the technology, not because it necessarily adds value compared to a Mesa + step/dir or ±10V setup, which are already very robust and proven.

 

My experience has been analog +/-10V servo control configs were a lot more labor intensive to get right compared to step/direction via parallel port or mesa boards driving open loop steppers (easy) or ethercat (a bit of network configuration plus some xml file programming). My analog servo configs have all been... quite a journey.

Might make a difference what kind of hardware you're dealing with. On nearly all my analog servo configs, I was connecting a new computer + Mesa board to old servo drives, the old servo drives usually had limited documentation to where it took some experimenting to figure out for example whether the enable is active high or active low. First power-up is usually a wanabe runaway.

Odd hardware like this old electric forklift I'm retrofitting with LinuxCNC. The motor controller expects 4V to 0V for the speed control. 0V is max speed we found out really quick.. We have it blocked up with the wheels off the floor so it doesn't run away on me. The program to monitor its motive stability will be interesting. It will have to be reliable and fail-safe before we take it off the blocks. This is a huge 72V forklift, I'm not sure on its lift capacity or mast height, but it is huge. The delivery truck brought it in two pc. because it was too tall to take down the road.