Advanced Search

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! 

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 there
I bought a Chinese servo driver XP200 30 PL. I can't setup this very well in my cnc lathe. I want (if there is) a tune up program for this servo. Any idea?
 

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.

I think the github issue is dead so better discuss here.

It's always the same error:github.com/LinuxCNC/linuxcnc/blob/ffc393...whb04b-6/usb.cc#L465
Don't have an actual log available, pretty sure it's that line

Yeah, at least for me the loops = 10 was not the solution to everything, so not surprised the situation is the same for you. As far as I have seen, this loops = 10 would only help during a LinuxCNC mode change (auto/manual/mdi/teleop/joint).

I was not aware of that issue, so that you for bringing that up. I will write a comment there (if I can), because I think what we have discussed here is a partial solution.

I would be interesting in knowing the error message (if any) when it fails, i.e. console ouput. This I can also "generate" myself, but right now I'm not using the machine.

Orbiter V2 is also very good and has a lot of pulling force (10KG according to spec), is very small and high quality, but not centered enough for your setup.
I have one on the big (huge) Voron i built and it went to a local school here:

Perhaps should change the subject line now, since my hardware has changed...

We have now installed a 7i97T/7i74/7i84U combo and have the machine up
and running. I would still like to use the mesa modbus component to
talk to our several modbus I/O boards and the spindle.

To enable this, I'd be grateful if you would make a firmware for this
combination:

7i97T with pktuart/modbus on the TB4's RS485 port, and a 7i74 on the
P2 expansion connector with pktuart/modbus on channel 7 and 7x SSERIAL
ports on channels 0-6

if possible?