Advanced Search

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?

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.

Resolver can have much, much higher resolution, depending on the card used for them and the ADC used.
Also, they never fail, at least i have never seen any failed ones.

Hello,
Is there a solution to this problem?

Got my mouth watering, thanks for sharing!

My existing install is using kernel 6.1.0-30-rt-amd64 (from the 2.9.4 ISO).

I'm going to grab Debian 13 and try to assemble from scratch.

Did you install ethercat from the repository or did you build from source?

andypugh wrote:

Is this the serial protocol, or the 4-bit gray code?

I think that _some_ Fanuc serial protocols are supported by Hostmot2:
linuxcnc.org/docs/stable/html/man/man9/h...html#Fanuc%20encoder
 

Mark's message gives the details of the serial protocol.  I don't know why he had to duplicate the effort, I have already deciphered these encoders and have a protocol converter product.  But, now, Fanuc has a "High speed" encoder line that is incompatible with the older ones.
Jon

Can you check that the drive is in OP like below
 
And with halshow that you have the same values in the following parameters,
not the commanded and actual positions of course, but they should follow the same pattern.
 

For your Z drive.

jenachdem wie dein bob aufgebaut ist, also das hinter dem 25pol stecker,
kann man die auch mit 3.3v betreiben, also direkt am GPIO vom raspberry.
Diese china bob's www.amazon.de/Fasizi-5-Achsen-CNC-Breako...reiber/dp/B09Z29TYNL
hatte ich schonmal direkt am 3.3v FPGA vertratet

Danke, dann versuche ich das mal!

Raspy ist bestellt, mal schauen wo der Parallel Hat aufzutreiben ist.

Ich melde mich wieder, sobald ich alles da habe und in die ersten Fehler laufe..

Die Diadrive ist schon recht langsam (und auch nicht sehr stabil), aber für meine Zwecke voll ausreichend.
Gfk und CFK in 1-4mm geht gut, und ab und zu Holz oder ganz vorsichtig etwas Alu schafft sie.
Da drauf sind schon ein paar Motorradrahmen und viele Teile für meine RC Bikes entstanden. 

@tommylight I'm curious why you are recommending that I push to use the resolvers instead of switching to encoders? Shouldn't I want to use the latest and greatest technology when possible?

Sorry, my mistake. It is probe screen 2.9 from verser-git.

But I have similar problem like Marcodi:

So whenever you are inside of the probe screen and you use the keyboard numbers 2-8 4-6 and 3-9. The machine starts moving in the appropriate direction without stopping until it hits a limit switch

Same happens with my machine. And also when using page up and down with the z axis.

I don't fully understand the question, but I think that a material change would be handled by the touch-off process that is normally used to re-align the working coordinates to the workpiece.
This is typically achieved using one of the G10 code variants (G10 L1 / G10 L10 / G10 L2 / G10 L20)

Just to clarify, when you say "Probe screen v2" what are you referring to?

Is this: github.com/LinuxCNC/linuxcnc/tree/master...n-panels/versa-probe

Or some other probe screen?

I think you can leave multiple tools in one pocket in the table.
You call the Tool with a T-number in the G-code, then the system checks the tool table for the pocket, and puts that number on the pocket-number.

(This is useful for using two sides of a lathe tool, for example. You would get different tool-point offsets, but the tool0changer would use the same position for both sub-tools)