Advanced Search

With further testing, I'm seeing one weird quirk that I can't quite figure out.

I would like the two sets of clamping radio buttons to also indicate the state of the clamps. Because the clamps can also be activated/deactivated by custom M-codes in g-code, or by set of physical buttons on a user panel on the other side of the machine, I added some hal pins in the call back file to set each radio button active. The real buttons and M-codes all work as expected as I want them to. But when I press the unclamp button in the GladeVCP the clamps, unclamp then reclamp, then unclamp again. (And I have not even connected or used any of the hal pins I've added yet.) The GladeVCP clamp buttons seem to be working correctly.

Any ideas?

Many thanks to the community.
I choosed Ventoy. Very useful tool.
Rufus stays for workaround with Win 11 install.
Balena sometimes is problematic with arm images for me.

Good luck for you all,

/eugenius.

If the problem stays with the X axis with motor driver and 7I96S channel changes,
it really sounds like the issue is more likely to be mechanical than electrical.

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...