Advanced Search

Hello,
Thank you for your reply
Ideally, I would like to integrate the project from PedPex which is a COS SIN converter (with IC-NV chip) for heidenhain glass scale directly as an ethercat module. It would receive COS SIN signal, convert it to quadrature, read by the STM32 then sent to Ethercat.
But this is a little bit out of my league knowledge wise, even if you did most of the job regarding ethercat and Pedpex most of the job regarding COS SIN conversion

I am currently running LINUXCNC - 2.9.7
6.1.0-30-rt-amd64 #1 SMP PREEMPT_RT Debian 6.1.124-1 (2025-01-12) x86_64 GNU/Linux
This was upgraded, re-installed and built from source after my initial installation. I installed Mint on another drive, but the OS took forever to boot, and just felt sluggish.
My main aim is to get something functional and stable going ASAP. I can always make it nice later.

Actually when you know where to look, the documentation runs to hundreds of not thousands  of pages.
setting up a gantry machine requires joint axes and is covered in the  homing docs. linuxcnc.org/docs/stable/html/config/ini-homing.html
You usually need to read that link about 10 times before it makes sense.
Briefly you need a home switch on each joint (eg a joint is a motor). When set up right with negative  home_sequence, the first side of the gantry stops and waits for the other side to catch up before moving in unison. Gantry Squareness is adjusted by setting the home_offset in the ini file 
 

Yes, you do need switches for each joint for tandem axis to work properly and be able to square the gantry anytime the machine homes.
If you do not have switches, you can just wire both Y drives to the same output on Mesa and make a new simple XYZ config.
BTW, you can make as many configs as you like, test, experiment, try things out, have a blast...
And feel free to ask as much as you like, you are always welcomed.

The machine does not currently have limit switches. I have the limit switches commented out.

I recently rebuilt the machine from the ground up. As the software is an upgrade, I am trying to get it working in its most basic form before adding limit switches, a touch plate, a probe, and a tool changer.

Do I have to have hardware limit switches set up in order to get the gantry to work correctly?

Apologies if that is a dumb question. I have found the documentation incredibly lacking, which is why I’m here on this forum.

unknown wrote:

Do you want the OS to mount a drive when plugged in or do you want to mount & umount the drive manually ?

Reminds me, i have disabled caching for USB devices as for the life of me i can not find a reason for it to exist, and any internet reasoning that it is safer = boo fakin hoo!!! How the hell is it safer when you get notified the copying is done while the coping is still ongoing in the background and you yank out the USB ending up with corrupted files. And the copy time is always wrong.
Not a huge issue with 8 or 16GB of RAM, but an absurdly annoying thing with 96GB of RAM and copying 10 Linux ISO's at once.

Quail wrote:

Right now the machine fires the torch using a regular output pin, which works fine when everything is going perfectly, but when a limit is triggered or the E-stop is pressed, it doesn't quite understand that it needs to disable the torch as well. 

Have not tested QtPlasmaC in quite some time, but for sure it did disable/shut off the torch on any of those, and also on program stop and program pause and when hitting ESC.
Also it would not turn on until F9 is pressed or an M3 is issued from MDI or gcode.
That is basic plasma behavior, so i doubt something was changed there.

See the right side of PCW's screenshot, did you choose the pin/home/limit switch for Y2 axis?
More importantly, does the machine have a separate switch for each joint of the Y axis?

Thank you.

This essentially gives me the HAL I created by hand. This does not bind the two Y axis motors together. Launching LinuxCNC with this HAL still shows me the 4 joints, until I home the Y axis where it sits, which is not where I need it to be homed.

I pored over the HAL and INI files created by PnCConf using your settings multiple times, and cannot see what I am doing wrong. There seems to be no difference between what it generated by selecting Y2 Tandem StepGen, and my manual HAL where I simply copied the Y axis settings, pasted them in, and changed every instance of Y to Y2, and 01 to 02.

I may not be asking the right question. Is there a way to ensure that when the estop is pressed or a limit switch is triggered, to tell the torch to come off and not come back on?

I thought maybe by editing the M3 g-code, I could get it to work for my machine and also get the estop and limits to turn off the torch.

Is there any way to link the output pin 00 to the estop and limits, in such a way that it wont turn back on even when the machine is reset, and stay off until it gets a new command to turn on?

My next idea is to make my own M code that has my needs in it, but i feel that i will still run into the same issues where the estop either doesnt turn off the torch, or if it does, the machine "remembers" it was firing and immediately arc.

One thing to look out for in Mesa's design of the 7i92 fet bus switches were used for translation between 3.3 to 5v. I think I can recall PCW saying that they were never intended to drive any loads directly but through at the least a buffer or more likely through a breakout board.
Another thing is, if the vendor has changed any pin assignments and have not provided a ucf file the only way to find out pin assignments would be via JTAG, the easier method of via direct probing of pins, which isn't a lot of fun with the pin spacing of the FPGA. Not knowing the in assignments would make modifying the firmware somewhat difficult at best.

So there could be some gotchas for new players.

Currently working on a machine using the QTPlasmaC GUI, and I was wondering if there was any way to access the M03 sub routine file anywhere? I would like to edit it to disable the homing of the Z-axis that it does. 

Right now the machine fires the torch using a regular output pin, which works fine when everything is going perfectly, but when a limit is triggered or the E-stop is pressed, it doesn't quite understand that it needs to disable the torch as well. 

I was able to almost work around this by messing with the hal file and using an and function to turn off the the torch when the e-stop is pressed, but the problem is when the machine is reset it has a memory of last being told to turn on, and so the torch fires.

My thinking is that if I can go in and mess with the M03 instructions I can just completely disable the Z-homing because all of this has been a work around for that, because my machine has no z-axis. 

Thanks!

By what metric have you been testing latency ? Your process and figures would be interesting to see.

The other thing that would be a major obstacle is that there is no real time kernel for BSD in the way that there is for Linux. Syscalls maybe another issue as well, I'm unsure whether the APIs for BSD and Linux are the same.

Linuxcnc isn't "designed for debian" originally the ISO were built for Ubuntu, but licensing became an issue. Linuxcnc can be built for any distro. Years ago I was running Linuxcnc on Slackware and in a moment of pure madness I built it on a system built using the LFS & BLFS way.

As for "stupid back ground processes" it's up to the user what they want to run in the background and what features they want to lose. Do you want the OS to mount a drive when plugged in or do you want to mount & umount the drive manually ? What processes do you sugeest turning off for the best system ?

I have a choice of 12 items, and tried the Qcombobox. I was able to populate it, but it seems its not integrated to get the selected item for further processing. I used radiobuttons for a choice of 2 or 3, but for this amount of selections the switchboard is getting too big. Am i doing wrong, or is this not part of flexgui yet?

 

Do you get any motion now?