Advanced Search

i was aware that i would get max. 1500-3000mm/min out of the COM Port. This would bee acceptable, as i will mainly use LinuxCNC as an ELS option with the occasional automated part (switching axis off when hand cranking of course)

Thank you for the suggestions. Those are Sino glass scales (KA500 and KA300 TTL 5V). I boosted the signal with npn transistors to 24v (reversing pin logic, shouldn´t matter though) as the smaller scale only gave a 3.3V signal which did not work. The weird thing for me is the working perfectly compared to not working at all, i woud expect a bad/unreliable signal from noise. I will try again on the weekend, putting input on COM1 and Steppers on COM2. Or i finally buy a mesa card ffs . Any suggestions for a standard 2/3 Axis lathe with very little IO ?

My 3 axis router developed an interesting issue a while ago and after a lot of experimentation I'm pretty sure the problem is with the 7i96s.
The first thing that went wrong was that the X axis started moving more than it should. According to math the steps/mm should be 480, but suddenly something decided that about 455 is the correct number. On it's own, that wouldn't be much of a problem, but it seems to occasionally switch to a different number and loose its position.
I have tried the following:
- different acceleration settings (it happily did 3000mm/s2 for a while, returning to within 0,01mm, but sometimes lost steps at 250mm/s2) 
- different stepper drivers, both open and closed loop
- different wiring between the 7i96s and driver
- new linuxcnc installation
- flashed the firmware to the 7i96s again
- completely new configuration through pncconf
- moved x axis from stepgen 0 to stepgen 4

The other axis work perfectly everytime and for about a year so did X, at 480 steps/mm. Z axis has the same motor, driver and encoder as X.
I have access to a 7i96 and I will try it out on friday, but I still want to ask if anyone has a different idea for what could cause this?

Hello,

notice > well tuned RT machine with less then 2us latency

I every time start with the LinuxCNC logo startup file ... create the scope of acc + velocity preview and analyze step by step movement ... jerk 10k m\s3 then I move to the 3d chips and 3d test ... if this works well i am shifting to the my code 1d movement, 2.5 d movement and finally 3d movement .. I start with 0 type then I move to other one for right comparation.. it is freezing TP2 with 3dchips.ngc from default local folder after last update ... no diagnoze possible from my side right now

all step by step analyzing the scopes

Configuration starting basically from axis_mm.ini with custom tool table which is missing from default

Spiking was mainly during start of the scope at servothread and then periodicaly, looks like at each end of segment - but no exact proofing 

I am staying tune for more testing or cooperation ... 

thanks E.
 

How can I compile and install pyside6 branch? I am using debian trixie image

Hi, I have a bit of an update: I have the SSboard from Talla83 assembled and running now. (Thanks Mark for sending parts for that.)
The 7i97T works fine, and the setup is much cleaner now.
I also have the control panel and all the stuff in it connected to the 7i73. It’s not really used in the HAL yet, but according to HAL Show everything seems fine. And I have a basic E-stop chain running.So I think there is not a lot stopping me from starting to connect the axis driver and spindle. So hopefully there will be some movement in the near future.

Thanks! That does it.

bladekel wrote:

I tried it as you said but nothing changed.
Again receving "USRMOT: ERROR: command timeout" errors and couldnt control the LEDs.

 

    "rpi5": "true",
->
    "rpi5": true,

 

I tried it as you said but nothing changed.
Again receving "USRMOT: ERROR: command timeout" errors and couldnt control the LEDs.

LinuxCNC can only run one toolpath at a time, so to do what you want you might have to get creative.

You could certainly give the two tools a different Z-offset in the tool table, so the two passes could be using the same workspace coordinates. If you have only one physical Z axis, though, that won't really help, as LinuxCNC can only apply one tool offset at a time.

A kludge might be to use X for tool1 and Y for tool2. (unfortunately, no diameter mode in the Y axis)

You would need to split the paths, with a simple XZ move for the start of roughing, then a combined XYZ until Tool1 is finished, then switch to ZY moves.

I don't think you can do arcs this way.

Even with an XZ/UW setup, ie with a separate W axis, I don't think you can do _simultaneous_ XZ and UW arcs. This is mainly a limitation in G-code, as there is no way to define an alternate arc centre.

bladekel wrote:

Hello everyone,
First of all, Meister, I’d like to congratulate you on this amazing work.

I decided to use this project on my machine.
I made some adjustments to use the TangNano9K with an RPi 5 over SPI.
I currently have two LEDs connected to the TangNano9K, and for now I just wanted to start by turning them on and off.

I configured everything through the Setup-GUI, then generated, compiled, and flashed it to the TangNano9K.
I also compiled rio.c using halcompile.
After that, I ran the test GUI from Setup-GUI, selected SPI communication, and was able to control the LEDs successfully from that interface.

However, when I tried to run and test my own configuration rioDeneme with LinuxCNC, I encountered some issues.

When the Axis GUI opened, I first pressed the E-stop button.
After pressing it, I received several consecutive "USRMOT: ERROR: command timeout" errors.
Then I opened HAL Show and tried to change the LED states from there.
Although I could make changes within HAL Show, I couldn’t actually change the state of the LEDs in the real world.

Where do you think the problem might be? 
 

you try to mix software stepgen with rio stuff,
there is a working/generated hal/ini template in Output/cgr/LinuxCNC/

you can start it with :

sudo halcompile --install riocore/files/rio.c
sh Output/cgr/LinuxCNC/start.sh
 

It might be safer to use an established interface to LinuxCNC, possibly modifying it for your needs.

linuxcnc.org/docs/stable/html/man/man1/linuxcncrsh.1.html
linuxcnc.org/docs/stable/html/man/man1/linuxcncsvr.1.html - this is not very informative...

Does it have the same USB ID as the previous one? Possibly you need to change the USB identifier in the config files, or possibly the udev rules.

linuxcnc.org/docs/html/man/man1/xhc-hb04.1.html

This does feel like something that could easily(?) be done with LinuxCNC.
It is basically an ELS (electronic leadscrew) system. There are many options for an ELS, but I don't know if any of those support EtherCAT.

You could start off using a standard LinuxCNC GUI for manual control of spindle speed. Then add a PyVCP box (or a similar GUI element) to set the leadscrew TPI. Later on you might want to look at either making a custom GUI, or going further with the CNC conversion.

You might want to consider fairly early on whether you intend to keep the separate feed-shaft and leadscrew arrangement. Most CNC lathes replace the leadscrew with a ballscrew and use that for both threading and feeding. If you were to retain the leadscrew and the existing half-nut for feeding too, I think you might wear it out. However there were lathes that worked this way (Smart and Brown Model M, for example)

I would suggest keeping the back-gears and possibly the intermediate gearbox, they give a big increase in torque for larger workpieces.
If you do that you would need to add a separate encoder for the spindle to account for losing the fixed ratio between the spindle motor and spindle.

You might find my blog on CNC-converting my Holbrook Minor interesting:
bodgesoc.blogspot.com/2015/08/holbrook1.html

hitchhiker wrote:

Warum brauch ich für die 7c81 ein usb-blaster?
Kann man nicht mit dem w5500 modul zugreifen und per mesaflash flashen per ethernet?
 

weil das ganze mesa zeugs nur mit der mesa gateware läuft, also auch das mesaflash,
du könntest noch rio darüber drauf flashen aber danach nicht mehr.
Flashen über Ethernet/SPI ist in rio nicht eingebaut.

@ bladekel:
i take look later