Advanced Search

I have the incremental encoders in my lathe, they are the beta versions
however. On these encoders the 10-bit absolute position is there and
accurate enough to use for commutation right from the start. There is
a step in this data however once the encoder passes the index.

The control computer had a backup battery, the battery connection of
the encoders was not used. So I assume the computer was responsible
for remembering the position. There are no homing sensors on the lathe,
so I guess they ran the lathe to its endstops when the battery failed.

For me the hard part was to get the encoder to respond. It wants a
positive pulse on the REQ line, and initially I was trying a negative
pulse. After that, verifying the encoder position was simple enough with
a scope indeed.

The nice part about the CRC is that there are only 32 possible
polynomials, so bruteforcing works like a charm

I hope my information helps someone, but if not... nothing is lost.
I doubt reading the VHDL and C code of hostmot2 would have been faster
than what I did, but I certainly would have tried it, if had known about
it. On the other hand, the microcontroller I use can only capture frames
up to 64 bits, so knowing the padding are actually start and stop bits
was crucial.

With that kernel version it may not be the same.
In any case, it sounds like it's something with the network, latency, etc. that PCW also points to.
 

I have installed r8168-dkms, and the realtek interface is using that driver. The other interface is supposedly an Intel card, using the igb driver, but it came from China, so there's no guarantee. Naturally the r8169 driver gave the same problems. I have tried other ethernet cards, but they all have realtek silicon.

Have you tried pinning the Realtek interface interrupt to last processor?
(also with using isolcpus=last_processor in the kernel command line)

This has helped in many cases.

This script allows you to test this:

 
 

Victory!! I finally have something working.
The spindle orients normally (all that's left is to set the orientation PID values ​​correctly...) in both directions, without using the M19's P1 or P2 prefixes.

I added an ABS for the analog control voltage of the driver command and
net spindle-fwdd abs.spindle.is-positive => lcec.0.D3.dout-0
net spindle-revv abs.spindle.is-negative => lcec.0.D3.dout-1

It was hard and laborious, but anyway... the rest will seem almost easy to me

Thanks for your reply. I guess I'll have to wait until a bug-free version is released.

self.logofile = str(args_passed[ index + 1 ]) gave an error on this line gmoccapy was not opened probably not a suitable solution for pi5

Debian 13 didn't work: apt-key isn't allowed any more, and I don't know what to do to work around that. Without that, I can't install linuxcnc.

Debian 12 doesn't work either: I can install linuxcnc and ethercat, but I can't start ethercat. I see the error "modprobe: FATAL: Module ec_master not found in directory /lib/modules/6.1.0-40-rt-amd64"

Greetings from the Czech Republic!

I'm working on a spindle (IMT 40kRPM) and the drive only has CAN, so I decided to use the EL6751, because everything else on my machine is on Ethercat. That's the problem.

There is a possibility that the CAN is running from TwinCAT and I can spin motor, etc. If I then connect the EK1100 to the LinuxCNC network, both cards start up (OP), but the CAN is red (flashing in the attached configuration, otherwise still red). Any idea what's wrong with that? Did I miss something?

Thank you. Best regards,
Pavel. 

Hello Everyone
Almost done the electrical end of my Fadal CNC retrofit. Im looking into the GUI for it now.

I see the LINUXCNC install comes with a few GUI already, is there an advantage to using those over lets say probe basic?

Right now Im leaning towards QTDragon because it comes with the install.

Thanks In advance for any help.

I'm not familiar with pi installations but you could try these modifications to gmoccapy which also fixed the problem for me:
github.com/LinuxCNC/linuxcnc/pull/3511/files

[edit]
Without rebuilding you will need to modify 'gmoccapy' in the /bin folder. 

I am using pi5, I could not find this file python_plugin.cc

mark-v-d wrote:

It could very well be the same, but I'm not sure. This is for the beta and not the alpha series of Fanuc. Like I said, I could not find the details of the protocol anywhere, but that could also mean I did not look in the right place.
 

I never found any document on the data format, but I managed to insert a pulse and get the encoder to send data.  Then, I looked at it on a scope, and created an FPGA to read the data and send it to a computer via the parallel port.  I then spun the encoder by hand and wrote programs to extract the data.  The hardest thing to crack was the CRC.  I took some of the extracted data, and ran it through a program that tried many different CRC polynomials until I got a zero result from every data pattern.  Then, I coded that up in VHDL and put it into my converter product.
Your description looks JUST like what I deciphered.

One note,  There are absolute and incremental versions of these encoders, at least on the older Alpha series.  The absolute ones have extra data at the end that provides a 10-bit resolution absolute position immediately at power-on.  The incremental encoders power-up assuming rotary position zero, and then the position count jumps when they pass the index position.  So, you can't get any reliable commutation out of them without battery backup.
Jon

I use ethercat

I do believe that a simplified milling procedure can be implemented.
The C-axis must be adjusted so that the milling spindle is approximately perpendicular to the cutting contour in every small section.
A fully converted X-Y-Z-C point file is required.

You write:
-pretty sure this needs TCP as the cut line is always 1mm under the material (also 1mm thick roughly) 
What exactly do you mean by that TCP?

You also write:
-having a look through the included TRT configs
What exactly do you mean by that TRT?

Surely you also have an envelope file (stp or similar)?

I've verified the vhdl and c code, and hostmot2 is indeed dealing with
the same protocol.

But at least now you know how to interpret the CRC, because that is not
done in hostmot2.

And I have learned where the batt_fail bit is (not that there is one on
the incremental encoder) They also don't seem to know what the purpose of
those 3 changing bits is. Maybe I'll figure that one out eventually.