Advanced Search

Currently running Ubuntu 10.04 and Axis 2.5.4 with the RTAI kernel on a P4 3GHz with 2 G RAM going out to a G540 controller with close to 1000 programs ran.
Latency: Servo 7k (ns) Base 22k (ns) running glxears and accessing directories, etc.
Tried the latest ISO for 2.9.3 RT-Preempt kernel live from an almost-full flash drive
Latency: Servo 77k to 90k(ns) Base 72k (ns) running glxears and accessing directories, etc

Computer is currently standalone, no web surfing or networking. Currently it is partitioned for Ubuntu and an old Windows install.

Wondering if there is hope with this PC or if I am better off getting something else. And if get something else, what? I am not so PC and Linux savvy.

Refurbished i5 desktops start around 130$ in my market Dec 2024  but would need a card for the parallel port.

I saw on another thread where a solution was to load a Wheezy ISO which gets one up to 2.7.X LinuxCNC IIRC (yes?)

Thanks, I appreciated the input.





 

Hello, thank you very much and a very Merry Christmas!...
Since I would like to see your project, maybe share it on your YouTube channel, I want to learn and I was really happy with the news that I could use Ubuntu to work seriously.
Thanks a lot!...

Hello, thank you very much and a very Merry Christmas!...
It doesn't have that port, what board do you recommend for this little one?
Thanks a lot!...

I did some more testing and milling and everything seems to work for me know. There are some differences to your setup: this is how I measure the tool 

    #<touch_result> = #5063
    #<setterheight> = #<_hal[qtversaprobe.probeheight]>
    #<blockheight> = #<_hal[qtversaprobe.blockheight]>
    (print, #<touch_result>  #<setterheight>  #<blockheight>)
    ;(DEBUG, %fTouch Result: #<touch_result>)
    ;(DEBUG, %fProbe Height: #<_hal[qtversaprobe.probeheight]>)
    ;(DEBUG, %fBlock Height: #<_hal[qtversaprobe.blockheight]>)
    ;(DEBUG, %fnewtool: [#<touch_result> - #<_hal[qtversaprobe.probeheight]> + #<_hal[qtversaprobe.blockheight]>])

    G10 L1 P#<newtool> Z[#<touch_result> - #<_hal[qtversaprobe.probeheight]> + #<_hal[qtversaprobe.blockheight]>]
    G43

Whole file can be found here . Main remap is base on user Guihue and versaprobe macros for axis  adopted to my needs in qtdragon. 
github.com/zieluch22/sorotec_cl0604/blob...cros/rack_change.ngc 
From ini check section 
[RS274NGC]
#PSNG parapeters
RETAIN_G43 = 0
INI_VARS = 1
HAL_PIN_VARS = 1
SUBROUTINE_PATH = macros 
RS274NGC_STARTUP_CODE = G17 G21 G40 G43H0 G54 G64P0.0127 G80 G90 G94 G97 M5 M9
and I am using python3. 
whole file 
github.com/zieluch22/sorotec_cl0604/blob...d_sorotec_cl0604.ini 

hope you can find something and you can enjoy the software.

beauxnez wrote:

hello
i have an nvem card based on rt1052 but i can't flash it with st link, the card is not detected, i tried with a card with a stm32f401 and it is detected?
 

Hello beauxnez,
First and foremost, you should be able to see the ST-Link as a probe using PyOCD. I would suggest enabling the Windows default Administrator account and trying it from there. In my case, I couldn't get PyOCD to detect either the ST-Link or CMSIS-DAP even when running the terminal as an Administrator!

So, I'd recommend giving the Administrator account a shot. If the "pyocd list" successfully recognizes the ST-Link probe, let me know and we can proceed from there.

Good luck!

Hi,

I've been spending the last couple of days trying to figure out how to make the "software estop" work together with my safety relay. But i'm going in circles and i need a kick from someone, maybe you?

First off, i have this physical circuit to handle the emergency stop logic in hardware:
 
...the idea is that estop should work without any software involvement. And everything should be as redundant as could be. I have dual (safety) contactors(KM1 + KM2) that cuts power to all drives and at the same time prevents resetting the estop-circuit in cause of failure. I have a proper estop-button(it's redundant contacts, but only shown as one here in S5). On top of that i have added an inline relay, K13, which can be triggered by software, aswell as the wire "1" which goes to an input in LinuxCNC in order to tell it the state of the safety relay. There is a short delay(~0,5sec) between the two sets of relays in the safety relay, so ideally the signal to LinuxCNC should be able to tell the servos to emergency stop just before the power is killed. 

So far, so good. Everything works just like i want it. The latching works excellent and the signals to and from LinuxCNC also works as expected....

However, i'm totally going in circles when i try to add an estop latch inside LinuxCNC to work in conjunction with the hardware safety relay. I took inspiration from a thread from the user Unlogic  who seem to have it working. But i end up having a latch #1 that depends on latch #2 that depends on latch #1 again....ehh... so currently i'm just having the inputs tied into LinuxCNC like this:
..this "sorta works" and prevents anything powering on before LinuxCNC has booted properly. However the UI experience is kinda bad as i have to press a button extra and there is not really any feedback to the user

SO, the question: Has anyone got a combination of a physical safetyrelay and an estop latch to work "like it should"? I'd be very interested in seeing how others have solved this issue...

/Thomas

1. Convert an ST-Link to a CMSIS-DAP probe by using a a second ST-Link and the ST-Link utility to flash the CMSIS-DAP firmware.

mvdlande.wordpress.com/2015/10/05/cmsis-...ink-v2-mini-adapter/

2. Use pyOCD with the newly flashed CMSIS-DAP probe to flash the firmware to the controller board

python -m pip install -U pyocd
pyocd flash .\remora-rt1052-3.1.3.bin --target mimxrt1050_quadspi

github.com/scottalford75/Remora-RT1052-c...ora-rt1052-3.1.3.bin

Hello,
I am converting a Biesse Rover 13s over to LinxCNC and am testing the remap functions with Python and the commands take about 5 seconds to process each one. It's nearly instantaneous from MDI and I don't see any errors in the terminal output when the python command runs. It also works just fine when I reference a straight ,ngc file with REMAP=M201 modalgroup=10 ngc=m201.

Any ideas as to why Python is so slow? I can use the direct ngc remaps but would like to experiment with python also.

Terminal output when running Python
is_callable(oword.remap_m201) = FALSE
Executing remap_m201: Loading m201...
Wait 10 seconds
m201 executed successfully.
task: main loop took 65.045437 seconds

toplevel.py
import sys
import remap

My INI file
[RS274NGC]
PARAMETER_FILE = linuxcnc.var
USER_M_PATH = ngc
SUBROUTINE_PATH = ngc
#RS274NGC_STARTUP_CODE = G21 G40 G90 G94 G97 G64 P0.025
#REMAP=M201 modalgroup=10 ngc=m201
REMAP=M201 modalgroup=10 python=remap_m201
#ENABLE_EMBEDDED_PYTHON=1
DEBUG = 5

[PYTHON]
TOPLEVEL=/home/wrhammer/linuxcnc/configs/Rover13s/python/toplevel.py
#PATH_PREPEND=/home/wrhammer/linuxcnc/configs/Rover13s                                   
PATH_APPEND=/home/wrhammer/linuxcnc/configs/Rover13s/python/     
LOG_LEVEL=10


Python Test Scipt:
def remap_m201(prolog, params=None):
    """
    Python-based remap for M201 to manually load and execute m201.ngc.
    """
    print("Executing remap_m201: Loading m201...")

    import linuxcnc
    cmd = linuxcnc.command()

    try:
        cmd.mdi("M64 P0")
        cmd.wait_complete()
        cmd.mdi("M64 P1")
        cmd.wait_complete()
        cmd.mdi("M64 P2")
        cmd.wait_complete()
        print("Wait 10 seconds")
        cmd.mdi("G4 P10")
        cmd.wait_complete()    
        cmd.mdi("M65 P0")
        cmd.wait_complete()  
        cmd.mdi("M65 P1")
        cmd.wait_complete()  
        cmd.mdi("M65 P2")
        print("m201 executed successfully.")

    except Exception as e:
        print(f"Error in remap_m201: {e}")

    return

There is a problem with linebreaks in the code above from pasting. I'll post the file tomorrow. Or you can fix it in a text editor in the mean time.

Thank you very much for the reply. I will check the procedure to set lost arc delay. I believe it will be very helpful.
Everything does work fine and I am do have proper grounding and shielding.
What really happens is:
The Hipertherm PowerMax 105, when it turns it off the plasma, it have a overflux cicle for about 20 seconds that sends air pressure through the torch (for colling purpouses). During this overflux cycle of the plasma souce, it does not work to close the contact to turn the plasma ON again. The first try just reduce the air flow but it does not start the arc. It needs to turn the relay off and then ON again to start the plasma (or we have to wait the overflux to end).
When doing some small cuts as little holes arond a circle it takes too much time to wait for the overflux after every little hole. That is why we are trying to get the retries to turn the plasma ON to work.
The tests I was doing were without the plasma source itself. I was using the contact of the relay used to turn on the plasma to indicate arc OK to LinuxCNC. On the other hand I installed a push button in serial conection to avoid the ok signal to be send to Linux. Linux sets the alarm right after reading the M3 and setting the relay. It does not wait to set up the alarm as well it does not retry to turn the relay on again.
Any information on how to use this resource will help a lot.
Thank you.

Thank you very much for the reply.
Everything does work fine and I am do have proper grounding and shielding.
What really happens is:
The Hipertherm PowerMax 105, when it turns it off the plasma, it have a overflux cicle for about 20 seconds that sends air pressure through the torch (for colling purpouses). During this overflux cycle of the plasma souce, it does not work to close the contact to turn the plasma ON again. The first try just reduce the air flow but it does not start the arc. It needs to turn the relay off and then ON again to start the plasma (or we have to wait the overflux to end).
When doing some small cuts as little holes arond a circle it takes too much time to wait for the overflux after every little hole. That is why we are trying to get the retries to turn the plasma ON to work.
The tests I was doing were without the plasma source itself. I was using the contact of the relay used to turn on the plasma to indicate arc OK to LinuxCNC. On the other hand I installed a push button in serial conection to avoid the ok signal to be send to Linux. Linux sets the alarm right after reading the M3 and setting the relay. It does not wait to set up the alarm as well it does not retry to turn the relay on again.
Any information on how to use this resource will help a lot.
Thank you.