Advanced Search

I noticed when looking at encoderS0.position I'm getting no valves. Also no valves when looking at spindle.0.revs in halshow. Could this be causing the issue ? EncoderS0.phase-Z is getting the signal from one of the remora input pins(my encoder index) which both are blinking in halshow when triggered. Should I be seeing the spindle.0.revs displaying a valve in halshow?

I was recently wondering if there's a company or someone who builds 3 or 4 axis mill control boxes pre-configured with LinuxCNC. Most hobby and semi-professional machines rely on a very similar configuration with one, maybe 2 steppers per axis and it would be awesome if a properly built control box with Linux CNC was available pre-configured and off the shelf. Is anyone aware of a product like this? I know that CNC drive sells their control boxes with UCCNC and stuff like VFD, fuses, relays and stepper drivers preinstalled.
Ever since Ethercat was integrated into LinuxCNC, I want to make a truly badass solution with Raspberry Pi, hardware control panel (there's a Shenzen company producign Ethercat panels with feed/speed knobs and macro buttons!) and Leadshine CS3E closed loop stepper drivers and Delta MS300 VFD. A complete Linux CNC solution like this will cost around 2500 USD which is the price for just the Centroid Hicory mainboard + software that offers similar capabilities.
If there's nothing like this on the market and enough people are interested, I could partner with my friend in China who could help me get this stuff assembled there.

That dkms error is an error in the debian distribution, they included a raspberry package. Just delete it.Well I thought the secure boot would be an explanation but now I don't know.
Happy you can use it, anyway.

Changing the latch velocity is worth a try _but_ having the same sign on search velocity as latch velocity is valid.

In this case, The homing logic is supposed to move towards the home switch at the search velocity, and when the
home switch is detected, reverse and back off until the home switch deactivates, and then move towards the home
switch again at the latch velocity for the final home switch detection.

Hi everyone, I've already done that. I've reinstalled the PC three times and always encountered the same problems. I included Mok Management during the second installation. I've done that again this time.

and yet something seems to have gone wrong:

With the workaround everything works so far (I hope) and thanks again

Hi rodw, thanks for the response. I think you are missing the problem so please allow me to clarify.

On my Tormach, this process makes perfect sense. I touch off with a probe or tool or edge finder or whatever, and then hit the zero buttons in the GUI. This sets the DRO readout to zero, puts the work offset origin symbol in the workspace viewer at the current position, and populates the offsets table with the position of the work offset in absolute coordinates. No problems here.

But on my new LinuxCNC mill, this process isn't working. When I hit the zero buttons in the gui, the DRO readout gets set to zero, the work offset symbol in the workspace viewer (3 colored axis arrows) gets put at my present position, but the offsets table doesn't update. It remains unchanged. You can see this in the images I attached to my previous post. More so, if I try to manually enter values in the offsets table, I get an error. I also included this info in my previous post.

Please let me know if there's anything else I can clarify. I understand that this is a bit of a subtle issue and I haven't done the best job of explaining it so far, so I hope this is a little better.

Edit: The mill is already homed in both situations described above. When run in what I call Bridgeport mode, moving the tool around manually and using the readout as a simple DRO, everything functions normally. The gui buttons zero the G54 work offset in the DRO correctly, it's just that the offsets table isn't updating along with this. When I load a G-code file, it appears to be respecting the offsets table G54 offset rather than the DRO-shown G54 offset, so the tool paths are not where I want them to be.