Advanced Search

very easy, enter an x and y offset in the tool table for the probe. these are normally 0.0000 since the tool and spindle share the same centerline, but if your probe is offset, you can find the center of a probe calibration ring with an indicator on the spindle, and set a work offset to zero for x and y. then use the probe (with the probe tool offset for x and y set to zero and use the probe position only option on the probing page. when the center has been probed, the x and y dro's will show you how far from the spindle centerline the offset probe center is. enter these in the tool table under the x and y offset column, save and reload the table. if the entries are correct, the main dro's should now show zero.

now when you load the probe tool, the tool offset is called up which will include the x and y offset. so when you probe the work to set an offset it will be taken into account and when the probe tool is unloaded in the user interface and its offset deactivated the zero point will correspond to the spindle centerline.

if you do not have the x and y columns showing in the tool table, open the custom_config.yml file from your config folder and at XY to the tool table display settings as shown below:

This will now display those columns in the tool table when you next run probe basic!

Enjoy!

Chris

Good that you mention Python. A couple weeks ago I learned how to build custom .comp components and I was thinking about moving the communication and logic Part into one.
But I am not sure how much this would improve anything. I guess the Bottleneck is the USB Serial anyway? What do you guys think?

“Working with cnc” is a whole lot different than knowing how to operate a particular machine, say a mill or a lathe.

I like the fact there’s no adds.

It would nice to see a link of method to donate a few coins. If I’ve missed it if someone has a link it would be appreciated.

Whilst the editor is a pain, switching to “source view” can make life easier for edits.

Does remora use the spidev interface ? Whilst ai haven’t looked at the remora driver code lately I noticed a ref to bcm2835 headers which ties it to the RPi4. The RPi5 is a different kettle of fish.

Best bang for buck is going to be an ex corporate PC that has a PCIe for a Parallel Port card.

If just for a proof of concept, the Wheezy image of Linuxcnc with an RTAI kernel wouldn’t be a bad choice, ok it runs linuxcnc 2.7 and an old version of Debian that has been EOL for a few years, but it still works.

I ran my mill with a BBB using the Wheezy image of MK so no having to work over ssh. Was a decent setup for a while.

Linuxcnc-RIO is well worth looking at.

Well said. Especially like the comment about python.

Just a note, the 7i90, FPGA (not having a go but there is always some that breaks the rules) can be used as smart serial device. Just digital i/o and 3 mpgs, but the firmware that runs on the softcore can be modded for 4
Mpgs. Tho it was a little frustrating to do at first.

Posting your hal and ini files would make this easier to diagnose

How are the drives wired to the 7I96S?

(TB2 pin numbers to drive signal names)

I should note that PCI and PCIE parallel port cards are still available if you motherboard has a PCI or PCIE slot

Hi Friends, 

Just getting my machine powered up for the first time and i have a list of things that aren't working and im trying slowing to knock each one of them out. I have a Queenbee pro that i converted to a XYZC machine powered with a 7i96s. I carefully labeled all the signal wires as i wired everything up and now once i get LinuxCNC up and running and try to jog to test each axis most don't work or are mapped wrong. The only one that acts somewhat as expected is X and its loud and makes a grinding noise and moves very slow. 

Regarding their mapping, when I go to jog Z i get movement from the second y motor. It makes the same awful noise and moves slow, which i'd expect because its the same motor with the same settings as the X motor. I also have a C servo that i haven't gotten anything from so far. 

Any suggestions as where to start here? can i leverage HalShow? should I just switch the motors in the electrical cabinet until the Y button moves the Y axis? I feel like i would prefer to understand whats happening and i dont feel like i do yet. Is there a way to easily reconfigure the motors without running pncconf again? 

I'm also pretty new regarding LinuxCNC, and in the process of orienting for the direction to control my machine.
A quick search:
duckduckgo.com/?t=h_&q=Unimat+SL100+&iax=images&ia=images

SL1000 (with three zero's) is a hobby level lathe.

Do you already have a PC for controlling your machine?
LinuxCNC needs a specially crafted OS with a real time kernel and quick I/O capabilities, because it does all calcualtions on the PC side. If you want to use USB, something like GRBL may be more appropriate. With GRBL, you send the G-code to a microcontroller, and the microcontroller does all the real time stuff. This makes the communication between the PC and the controller very tolerant of timing issues, the PC also does not need to meet real time performance, and any PC can be used. Have a look at the GrblHAL project, where you can choose from quite a lot of different microcontroller families.

For LinuxCNC
Parallel ports are mostly obsolete as PC hardware, but there are still motherboards where an LPT port is available on an internal header, but does not have a connector on the outside of the PC.

The lowest cost option (except the 2nd hand PC from the attic) for LinuxCNC is probably one of those SBC's I once had a working machine with machinekit on a Beaglebone Black, but it was headless and X-forwarding over SSH was atrociously slow (about a 2Hz display update rate. In the meantime Machinekit has mostly died too, but a Raspi 5 combined with Remora is an option. This uses an SPI bus to communicate with a microcontroller that does the step generation, but it still needs a low latency communication channel to exchange data with a servo thread. Apparently it's untested or not supported to attempt to use an SPI bus from another SBC then the Raspi 5.

SPI is supposed to be unavailable on regular PC's, but as far as I know it's often available on the TPM module, together with the LPC bus. But I have not seen any hint of LinuxCNC being able to work with those communication channels.

I updated the older issues with the latest bug list:

github.com/LinuxCNC/linuxcnc/issues/2506
 

Hi, I'm new over here.  
I made a CNC router with a retractable 3D probe mounted next to the ATC Spindle.



I also installed ProbeBasic last year, as it seems to be a fantastic GUI with everything I could want from my CNC router. 
So far I have ProbeBasic up and running and I can run the probe subroutines. 



But my retractable, offsetted 3D probe configuration is maybe a bit special and needs a bit of customization to work. 
I'm hoping its possible in ProbeBasic.

Before I start hacking away , can someone point me in the right direction for the following:
- Configuring the offset position of the 3D probe relative to the spindle
- Programming a command that triggers an output, when initiating a probing subroutine (which I can use to control a pneumatic 3/2 valve). Would I need to add this to every subroutine, or is there an easier way?   
- And maybe an interlock to make sure no tool is loaded when probing

Any help is much appreciated. ) 

One of my older HAL files using COUNTS mode is attached.

Some differences from my earlier INDEX mode summary:

• Stepgen is in position mode
• carousel.N.scale is stepgen pulses per pocket
• carousel.N.counts is connected to stepgen.N.counts
• carousel.N.counts-target is connected to stepgen.N.position-cmd

As far as the difference between stepgen modes (velocity vs. position), the LCNC user manual has a description of these:

The section on Mesa card stepgens is here:
linuxcnc.org/docs/devel/html/man/man9/hostmot2.9.html#stepgen

But I think the generic stepgen component description is a little easier to understand.

If you read it like that you think its modmot loading threads. But reality is different.
rtapi creates the threads.

 

You might want to break the links between iocontrol and probe.. as I suspect that is prompting the popup.

Maybe try looping the tool change like the tool prep is.
(but maybe with no tools in the carousel, just in case....)