Advanced Search

 

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.

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?

Ethercat components are now very inexpensive to purchase. The servo kits at Stepperonline cost less than €200, including customs duties and taxes. Fieldbus modules are available at low prices on eBay.
Why Ethercat?
Step/dir: has limited frequency/encoder resolution and is only suitable for small tools. High demands on the PC.
Analog: I tried this, but unfortunately it was very disappointing.
Ethercat: Real-time capable, motion control, position feedback, extremely high speeds possible.

 

The forum decided to ban my IP because of its distorted view of the world during outages.
Thankfully, Andy rescued me back from the dead after a message to the developers mailing list!

Ihave a new component in progress that is designed to address many if the things you raise home jump, pv mode etc. be patient as i had to put it aside for a while

The mindset should be that the drive decides.
The component can only ask the drive to do things like switch op-mode, start homing, etc
for the rest the drive must react to every status condition that comes from the drive.

There are other circumstances when the position feedback can be out of sync with linuxcnc joint commanded position.
A spindle running in PV mode as a spindle motor, switching to csp mode as an axle comes to mind.
The component handles and offset in such a case.