Advanced Search

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.

Are you using master? If so you might have to update as a fix for such an issue was merged here:
github.com/LinuxCNC/linuxcnc/pull/3516

Yes, that was the problem. Thanks

Yes they also jog w/o probe screen. But then the axis stop when I release the button. Only in probe screen the axis don't stop.

Probably locale setting issues, so set the locale to en_US and UTF-8 and try again.

Hello,

Apparently I found the right place in the code, at least the image quality changes.
Enclosed the pictures I have reached, maybe you can use or expand it in the future.

Thanks to everyone and best regards, Frank

Thank you very much.
Attached are both filters for LinuxCNC, the normal 3 axis and the generated 4th axis noted in the file names inside the zip file, also require adding these two lines to the ini fileorAnd another try at explaining things, badly as usual, the attached 3D image has the blueish-green cut line that is the actual gcode, so the tool should be horizontally positioned to cut the line

No, maybe the wrong firmware? See attached file

This error occurs when we select the automatic G code file at the first startup from the gmoccopy settings.

It looks like it supports incremental jogging, which might be safer:
github.com/verser-git/probe_screen_v2/bl...probe_screen.py#L360

My guess would be that for some reason the button-release events are not calling the button-release routine.

Though it might be nothing to do with probe-screen directly at all. Do the keys you mention also jog in the UI you are using _without_ probe-screen?