Advanced Search

To be honest I'm still not sure what to do.

Currently I have no probescreen added to gmoccapy. I searched for a screen and just found topics about probescreen which requires a probe with electrical contact to the probe input pin. 

I do not have a probe like this. I just a simple probe with a 10mm probeball where a light flashes by contact or a simple 3d probe with analog measurementvalue. 

Is there any option to deal with? Simply probing an edge is not that problem. But how should I find the piece zero inside a hole?! Could you give me some tips? Maybe there is still an easy way to find the center of a hole... This is my main problem for now. 

Could I have some type of issue with the comms and data is getting corrupt?

No, modbus uses a crc checksum (ie the last two bytes of the messages). If your request got corrupted the crc would be wrong and the vfd would then ignore the request and you would not receive any response.

MAYBE the actrual issue here is the register to say enable spindle is the incorrect register in my drive, so the response is illegal data address?

Note that it says that it is 'reading setup parameters:' which fails. Enabling the spindle would not be a read function.

Is it odd that there is only 6 bytes received then a time out occurs?

The component does not handle exception responses (which are only 5 bytes), I guess.

I'm afraid I cannot help much more as I have no information about the vfd or the setup values for the component.

mBender wrote:

 with a W5500
 

I tried W5500 without success.
This module is not programmable and always requires initiation after the power turned on.
You need a programmable module that remembers the settings.
I suggest WT32-ETH01 (tested, and cheapest on Aliexpress).

@ccatlett1984 That was a bit of a pain to do, I would not recommend unless you have experience soldering and particularly desoldering.
I removed the factory Raspberry Pi two row header and soldered on a new stackable female header in it's place from the bottom. A
good tip to help with factory header removal is to pry off the plastic and desolder each pin one by one.

I want to say the exact part I used was a Pololu 2749, but check the dimensions of the header to be sure.

Thread update: MX4660 is gone, Thread can be locked no items remain.

Perhaps a newer kernel helps, here is version 6.10 rc1
drive.google.com/drive/folders/1L28lG0zD...2XQJx?usp=drive_link

After trying many combinations of PID as suggested and what I gathered on the net, it seems I cannot get a stable setup with any meaningful amounts of I or D. So I'm limited to P < 200 and I,D < 10, otherwise the table shoots rapidly and stops with a following error.

What I also noticed is that when I click the quick zero buttons, instead of G54 coordinates resetting to 0,0,0, it goes to the same offset seen at home -0.002, 0.001, 0.0006. Additionally, the G54 zero coordinates (set when clicking the quick zero buttons) change with the P setting (and without homing). Higher P = smaller quick zero offset.

Not sure what kind of connection wiring or software could be causing this? What does the quick zero reference to assign G54 0,0,0 ?

That looks like the standard realtek 8168 driver rather than the DKMS driver
so it sounds like the DKMS driver install did not work for some reason

If I understand this correctly, it is trying to read the data starting at address 0305h?
If thats true, I think that address does not exist in my controller.

So what I am taking away from your wonderful description is this :
Comms are happening in both directions, and are understood by each side.
MAYBE the actrual issue here is the register to say enable spindle is the incorrect register in my drive, so the response is illegal data address?

Not sure about the coil observation yet.

Is it odd that there is only 6 bytes received then a time out occurs? Could I have some type of issue with the comms and data is getting corrupt? Again I want to point out this is the same setup I had before on a different VFD and worked fine. I literally disconnected the wires from 1 and connected them to the other.

I want to switch from normal HD to ssd. There is no other change in Hardware, neither the PC nor the CNC machinery.
It works over parallel port and M542 driver as for years. The mill itself is a DIY 3 axis machine.

I downloaded the current Debian Amd64 2.9.3 PREEMPT-RT Hybrid ISO and installed it.
Also I did create a new config for Gmoccapy/machine, my current config is just to old to get converted (got a lot of errors). Anyway, the installation went OK and the machine is working as expected.

Now I did an upgrade
which in general also went OK. Paranoid reboot and start LinuxCNC. Now I got the issue all but Y-axis moving. The motor gives some noise but not really moving. Whatever I tried, changing/relaxing timings and so on, it did not start to work correctly. X- and Z- still working.

I did search but did not found similar issue messages.
The question is, may someone had an easy fix or should I just reinstall and avoid upgrade for some time?

Thanks for reading,
DeJe

i added the same as the google doc "r8168.aspm=0 r8168.eee_enable=0 pcie_aspm=off loglevel=3"
i changed and add " pcie.aspm=0 r8168.eee_enable=0 pcie_aspm=off idle=poll" but still the same "hm2 error finishing read" (I restarted the PC)

 

Not sure how that gave you the '>' prompt but:

I would think that you need to replace this with the path to your local clone of the git tree from this earlier command:

If you intend to drive a small DC motor directly from the 7I96S outputs,
then yes, you need a flyback diode across the motor.
The motor also should not have more than 2A of stall current.