Advanced Search

So Axis starts, and remora.SPI-status is true too. Resetting the MCU actually throws SPI Errors. I think that looks fine. Unfortunately I can't toggle the emergency switch.

I looked at the PRU-reset pin and its on FALSE. is that how it should be? Am I missing something obvious?

Thanks, Alessandro

Since RTAI has reached the end of its life the way forward might be   Xenomai 4 

How many users might find this useful? it will be lots of work and we aren't sure yet how to support Mesa cards with it yet.

Hi,
I've bought an oscillating tangential knife (Stepcraft OTK3) a few month ago but didn't found a linux post processor for it, So, I created one myself that should be generally usable because it does not contain any special features for my device. Probably, it may be useful for someone else,

It's written in C++ and can be easily created (needs g++ package on linux, compiling on Windows should be possible as well). Just extract the tgz into a subdirectory by
 tar xvzf OTKPP.tgz
Go into the directory and compile it with
 g++ OTKPP.cc -o OTKPP
alternatively just type
 make 

This should create the OTKPP executable. Copy it somewhere in your search path where it can be found by e.g. by your CAM program. It can also be called in the console For the file "engraving.ngc" you might call
  OTKPP -i engraving.ngc -o engraving_OTK.ngc
If no output option is specified, the result is printed to stdout.
  
There are some more options for example to change the OTK axis (default is C) or the max. angle for retraction. The available options are as follows (also printed if OTKPP is called without parameters):
  
  -a   --axis <axisname>   Name of the OTK axis e.g. A or C (default is C)
  -d     dwell <delay>     Delay time to run-up the oscillation (default 3 sec)
  -dbg --debug             Adds comments to the output about what's going on
  -f   --feed <speed>      Default z-feed (will be replaced by g-code if exists)
  -h   -? | --help         Prints the syntax and available options
  -i   --in <filename>     Path of the input gcode file 
  -l   --limit <angle>     Max. rotation without retraction (default 20°)
  -m   --modulo            Created rotation range [0..360)
  -o   --out <filename>    Path of the modified output gcode file
  -z   --zsafe <position>  Safe retraction height (default 2 machine units e.g. mm)

If the -dbg (or --debug) option is specified, the modifications are commented in the resulting code which should be still executable. The attached tgz also contains an example file (original and after processing)
  
It should be also possible to set up the OTKPP as post processr in your preferred CAM software in order to create the programs for the OTK directly. As I only use CamBam for Linux, here are the steps for the integration (sorry, I don't use Mach3/4 and thus, don't know how to set it up there).

1. Open the post processors settings in CamBam
2. Create a copy of your favorite post procesor (e.g. LinuxCNC -> LinuxCNC-OTK)
3. Add the following line in the "Post-Build Command" option:
    <Path_to_the_program>/OTKPP
4. Add your favorite arguments in the "Post-Build Command Arguments" option (e.g.):
     -dbg -a C -l 25 --in {$outfile} --out {$outfile}
5. Select the LinuxCNC-OTK post processor in the project's operation

Just one warning:
Please take care if your machine works with imperial units (inch), as the default retraction value is 2.0 which is equivalent to 2mm on my metric machine. Adjust the value in the code or by using the -z or --zsafe parameter if necessary. Nevertheless, it might be better to run a dry test anyway.

Feel free to adapt or modify it. If you have questions or run into problems just response.

Hope it helps,
Stefan

• Sakhalin_Cat

Hi can you repost the file the link seems dead

Please respond to this post IF you still use RTAI.

Hey guys, trying to get monokrom or at this point qtpyvcp to run, but I always end up with problem in the DB lookups. Since i don't really know how the ORM works i struggle to fix this myself. This is with a clean sqlite db. With the latest main branch on monokrom.

Thanks! 

I'd forgotten what a mission I'd had at the start of my linuxcnc adventure with limit switches, so building a config from scratch was a sufficient challenge. Anyway after copying in just the essential parts from the working hal, was able to home it and run the spindle. Runs, of course, without any hiccups at all. Will start adding in the complications and see which one is the bad guy. Will report back.

You can use smart serial, there are open source project on github

I just updated my plasma to Qtplasmac.  Everything seems to be working fine except I am having trouble understanding the run from line command.

In the attached partial ngc file, If I try to start on line 420, It creates the rfl file, with the first line being the last move before the M05 (Which is a G02...).  When it tries to start on this line, Qtplasmac  gives me a radius calculation error because it has no real start position.  If I change this line before the M05, (which is an exit command from the plasma cut), to a G01 - it works since there is no radius calculation.  Is there any way to just start on the G00 command, or am I doing something wrong? 

Unfortunately, all my files contain an arc for an exit.  

I wrote a long (hopefully correct explanation of how offsets and sensors worked, over in the general questions -> Where should linux cnc tool offsets be stored? thread forum.linuxcnc.org/38-general-linuxcnc-q...ets-be-stored#342300
That may help. If not, it may help you ask more specific questions

Hi all,
Hope you are doing well! I'm trying to implement a status bar using a LED strip (WS2813 RGB LED - Grove) and an Arduino (uno or nano). I wanted to connect the arduino through serial communication directly to the a MESA 7i95T board, to send some string commands to the Arduino to control the LED strip behaviour.

Is it possible to do so? Can I just connect the Arduino to one of the two RS422/485 interfaces of the board? Do I need a specific firmware for the board? In case yes, my setup also includes a MESA 7i87 for reading some sensors.

Thanks,
Best,

Amedeo

Hey everyone,

we are making progress. All axis work, limit switches work, spindle works (ish) and remote works now.
We are using QTdragon as interface.

Coming from CNCGraf my biggest question right now is: Probing.
For most cutting operations that I do, i just need to go to a position and place the Z0. The top surface of stock, since I am either driving into the material or through the material.
Now it is all totally different in setup.

My normal workflow was that I am using the tool-length sensor for three operations.

First i had to calibrate the tool length sensor. The value (lets say 22.2mm) was stored as variable. For first setup i had to measure the table dimensions with this as well.
Normal Process then would be:
I am putting in the tool, measure the the tool length, place the same sensor then on top of my stock and on top of the scrificial plate. Then I am measuring again and set the Z0 (I think this is a relative value or workspace coordinate, not a machine coordinate) add the 22.2mm of the tool length (automatically) and this will then give me perfect Z-0 and Zheight of my work piece or stock.

How is it done in linuxCNC? How do you calibrate the sensor?

Can this be made for newer versions of linuxcnc? like 2.9.8

I see — if you want to explore EtherCAT and your machine already has absolute servos (including the tool changer magazine), that’s a perfectly valid reason to go that way.

Just be aware that you’re moving from a very KISS, well-understood Mesa setup into more of a “welcome to the jungle” zone: more knobs to turn, more things that can affect determinism (NIC, kernel, DC config, drive modes, etc.), and more commissioning work before you get the same level of predictability.

Coming from Mechatrolink, where a lot of this is implicit in the controller, with PC-based EtherCAT it looks like you first have to make these fundamentals explicit (DC, cycle stability, NIC behavior, jitter) before worrying about pushing the servo thread frequency.

A lot of people on the forum are still exploring this space too, so expect some iteration and experimentation along the way. And those who are really “in the trenches” with EtherCAT on LinuxCNC can probably give you much more concrete numbers and practical advice.

Please specify what you mean by idle. Is this with LinuxCNC running or one of the other programs polling the pendant?

I left the pendant connected last night directly to the xhc-whb04b-6 component, and now some 15 hours later there still hasn't been a single disconnect.