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.

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

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 DC 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.

oh dear....

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.

Also, just to be clear, at this point in my life (I’m 50), I’m not chasing résumé points or planning to change jobs — this is purely technical curiosity and personal interest in understanding the trade-offs better.

Out of curiosity: when you compared step/dir, were you thinking about software step generation / parallel port, or FPGA-based solutions like Mesa? In my experience, that distinction makes a huge difference in terms of performance and PC load.

posting for good luck:

The main motion control signals between the press brake state machine and the hardware interface should be a unified standard within this family of LinuxCNC press brake components.

The idea is to have a standard GUI and press-brake state-machine component, then separate customized hardware interface components for specific machine makes/models. There will also be a simulation "hardware interface component".

The redundant analog velocity and discrete velocity/direction commands are necessary due to some presses use both spool valves and servo valves to set velocity and direction. A press using only a servo valve might not need this component and could likely be connected to a PID just like a servo driven axis. A press using only discrete spool valves (no variable speed control) would allow leaving the velocity command disconnected.

This allows a straightforward command from the state machine to the hardware.

The main control command between the press brake state machine and the hardware interface will be like:
(additional feedback and home-offset pins not listed here)

Type: float    y_cmd_pos "Y Position command";
Direction:    press_state_comp    =>    hardware_interface

Type: float    y_cmd_vel "Y Velocity command";
Direction:    press_state_comp    =>    hardware_interface

Type: float    y_cmd_tonnage     "Y Tonnage command";
Direction:    press_state_comp    =>    hardware_interface

Type: bit    pedal_is_dn "decoded foot-pedal status from state machine";
Direction:    press_state_comp    =>    hardware_interface

Type: s32    motion_type_cmd
Values:        -99 = homing slow up
        -31 = up fast 1
        -21 = up med 1
        -11 = up slow 1
        -1 = pressure dump
        0 = halt
        1 = dwell
        11 = down slow 1
        21 = down med 1
        31 = down fast 1
        99 = homing slow down

This allows easily adding speed states for presses with additional speed selection spools. For example, a press with an additional med-fast down speed would also support motion_type_cmd = 22 “down med 2” On the pullmax_optima hardware interface component I delete the med velocities entirely, as the spool valves on this press do only “fast” and “slow”.

We will need to pass a “list of valid values” for the selected hardware_decoder, to the press brake state machine, ideally via the ini file.

file.ini:
[AXIS_Y]
valid_states = -99 -31 -11 -1 0 1 11 31 99

Something like that. I’ll see what I can do.

The pc is a HP Z400; workstation (quad core xeon with 8 gb memory and ssd). The interface is parallel port with step/dir. G28 moves all axis to machine zero.
I will upload the hal and ini files tomorrow (it's night time overhere). But I don't think that's the problem because it was working perfectly for the last couple of years.