Finally I made a successfull connection of the mesa 7i97t.
When I turn the motor still standing on the table i can see the X Dro increase in numbers to what could be expected in relation to the counts/rev.
Now two things are still beyond my understanding.
1. When I try to jog the axis the DRO only moves 0,18mm when pressing and releasing the < or > key. Same result if I use arrows in AXIS. Jog mode is set to continuous. 
2. When I release Estop and enable the drive F1 & F2 the motor starts rotating at a speed which looks like something that could be1v. 
Any explanations?
HAL file attached 

No, no other errors. Only joint following error.

I don't think LinuxCNC has changed anything basic like this
it's more likely a hardware, wiring, hal, or ini file change.

  thank you for the response, i have an older Dell 980 optiplex with onboard parallel port. the output of lspci shows no parallel port controller and under communications controller is has no i/o ports line in between "flags" and "memory at".
in bios its set to epp and address 378h.
i ran the command cat /proc/ioports grep parports and it showed 0000-0000 : parport0 (twice, one above the next)
so i ran the command sudo cat /proc/ioports grep parports and after enter my password it showed 0378-37a : parport0 and 037b-037f : parport0.
i tested every pin of my parallel cable and its good. im not sure if i need to do something with enable amplifier on pin 1 because i tried it unused, enabled, and enabled active low and i still got no movement. i read somewhere that the kernel may not be reading my parallel port but i am not that savy at this, its been a week or two since i started dabbling in this..
i will attach my .ini and .hal files

I’ve updated and replaced all the Probe Basic Lathe files and copied my configuration into the folder (HAL file, INI, and postgui). Everything is still the same. The bottom part of the screen is cut off (in PB Mill it displays correctly), the on-screen movement arrows don’t work unless I perform a home after referencing the machine, The conversational section doesn’t work, and the default RPM isn’t shown (for example, S500 in the INI file). It’s the same in simulation mode.

I changed the prefix today, and now the machine no longer moves automatically.

I'd like to know why this is happening. The Debian version and the Linux CNC version have changed. I haven't made any changes to the INI file itself.

 

I’m looking for some guidance.

I’m using a similar VFD (Model G75). Are you able to control the spindle, or are you only able to monitor the parameters?

For some reason, I’m not able to get LinuxCNC to connect to this VFD. However, I was able to connect using Modbus Poll and successfully read some registers. I did this to confirm that my wiring and communication setup are correct.

Any suggestions would be appreciated.

I'm pretty sure it's easiest to just add a printf("%d\n", r); between the libusb_transfer_call and the assert statement. And I'm also fairly sure I did that at one point.

And then you can just match the terminal ouput against the libusb_error enum:
github.com/libusb/libusb/blob/master/libusb/libusb.h#L1282

The docs for libusb_submit_transfer also has a section about the errors it can return and a little bit about what they mean:
libusb.sourceforge.io/api-1.0/group__lib...7dad2fee4b27962848ce

Face-palm moment! image missing /media/kunena/emoticons/shocked.png

No need for homing the ram... I think. All I need is set hm2_7i80.0.encoder.04.index-enable then have the operator manually jog the ram past the lone index pulse. This will zero the encoder counter. Good enough? Forget setting up a complete homing package for the hydraulic joints.

Life just got easier. If I need a home offset I can easily add that in pullmax_optima.comp

I wonder what "r" is - it doesn't say.
I'll some printouts.
One can possibly dig deeper into the layers and see exactly where it fails.
One level down:
github.com/libusb/libusb/blob/dcd30cec9a...ff/libusb/io.c#L1486

The crashing doesn't respond well to provocations. I can generally get it to crash when switching modes,
but it doesn't crash when I want it to crash.

Hi all,
I've been running a 3 axis stepper cnc voor a couple of years now. Everything was working fine 4 days ago. Today after powering on when I try to jog or G28 I get joint following errors on all axis. If I lower the feedrate substantially I can jog manually, bur starting any job fails joint 'x' following error. I havent made any changes to hall or ini file. Can anyone point me in the right direction for troubleshooting?
Thanks in advance.

Okay, thank you. I'm fairly certain that the reason for that message is that the pendant (dongle) has reset itself. But I don't think we know why it did so in this case. It could be something that the xhc-whb04b-6 component is doing wrong (different from the mode change delay). But it could also be that the dongle firmware is just that unstable.

I don't have any real good way to troubleshoot this. For the mode change timeout, I could capture the USB signals with a logic analyzer. But that is not feasible with my equipment if I need to wait for maybe one hour for the issue to occur. Wireshark is a possibility, but it does not show the low level packets...

I have also implemented support for MDS-B-SVJ2 Servos via ethernet. That's the first test. X/Y/Z and the spindle are ok (the video only shows X/Y). I will make some other videos within the next weeks. For a test it's connected via USB ethernet adapter to my notebook (I will move it to a raspberry PI within th next days)

Still quite some way to go .. tool changer, lubrication system, chip conveyor and so on. My Meldas M65 controller had issues with the battery 3 times in a row (and we bought them original from Mitsubishi), everytime the settings are gone we would have to drive to Mitsubishi to put the options in... I'm done with that and move the system to LinuxCNC now.