Advanced Search

La salida 4 que tiene mejor aislamiento es dc o ac  por que he puesto un ssr de dc y no corta se queda en contacto aunque no este dada la antorcha de plasma

You mean the ini file or what ?

Difficult to troubleshoot. Please attach your zipped config folder so we can see how things are setup.

Hello everyone,I’m facing a persistent issue with implementing a Python-based M6 remap in LinuxCNC 2.9.4 running on Debian Bookworm. No matter what I try, LinuxCNC always reports that my remap function is “not a Python callable function,” even though I have followed all the official documentation and community advice.Details:

• Configuration:
  • In my INI file, I have:
  • [RS274NGC]
    
    
    PARAMETER_FILE = linuxcnc.var
    RS274NGC_STARTUP_CODE = G21 G40 G90 G94 G97 G64 P0.025
    REMAP = M6   python=my_m6_remap_function modalgroup=6
    
    [PYTHON]
    PATH_PREPEND=/path/to/my/python/scripts                            
    PATH_APPEND=/path/to/my/python/scripts  
    TOPLEVEL=/path/to/my/python/script/m6_tool_change.py
    
    The Python file is in the correct directory, and the function name matches exactly. The function signature is:
    •     def my_m6_remap_function(self, **words):
              # minimal test code
              print("Hello from  REMAP")
              return INTERP_OK
      
      
      
      I have tried different function names, ensured the function is top-level (not inside a class or another function), and removed any __init__.py, .pyc, or __pycache__ files.File encoding is correct (UTF-8/ASCII), and permissions are set properly.Result:I always get the following error:
          'my_m6_remap_function' is not a Python callable function - ...:REMAP = M6   python=my_m6_remap_function modalgroup=6
      I have tested this on multiple machines, with fresh configs (including a clean Axis config), and even on a different PC – always the same result.Remapping using ngc (subroutine) works perfectly.
      I can import linuxcnc in Python 3 without issues.
      I have tried examples from stdglue.py and the forums – same error.Environment:Debian BookwormLinuxCNC 2.9.4 (from official repositories)Python 3 bindings are present and workingNotes:I suspect this is either a bug in LinuxCNC 2.9.4 on Bookworm or a missing package/feature in the current build.
      Downgrading to an older distro or using Python 2 is not a practical option for me.I need Python remap for integration with a custom PyQt5 GUI and an Automatic Tool Changer (ATC).Has anyone else encountered this issue or found a practical solution?Is there a way to enable Python remap support in this environment, or any workaround besides using ngc?
      Any help or suggestions would be greatly appreciated!
      

El thcad2 no lo se por que no se como comprobarlo

he comprobado lo de step/dir 04 y funciona perfectamente 

Hi Patrick,

so, regarding the encoder resolution I have come one step further. It actually is configurable and the default value is 4000 counts/rev.
I suspect that the drive doesn't have a "real" hardware encoder but uses hall sensors or other electronic tricks to know/estimate the position. Thus the resolution can be set kind of arbitrary and is dependent on the accuracy of the sensors.

I was able to set the resolution to 10_000/rev without problem. But the question remains how accurate that actually is and if such a high resolution makes any sense. I think I'll settle with just 1_000/rev which will still give me an accuracy of 10µm in combination with my 5mm/rev ball screw.

If you're interested in more details, let me know and I will share what I found out.

Regarding the XML configuration I'd be interested to see what you came up with.

Good luck with your exams,

Uwe

 

The THCAD connection should not have any effect on the 7I96S unless there was
some kind of issue with the 7I96S side (encoder side) wiring, as the plasma
(Analog input) side of the THCAD is completely isolated from the 7I96S.

Is the THCAD2 in the same case as the 7I96S?
 
 

got a new card didn/t help. same messages. I finally just install version 2.9.4 and everything works.

Post your custom homing procedure please.

My bad, aluminium is about 1.2 kg for 1200mm
So it is about 2.5 times as heavy but many times stronger against deflection.
That is why the choice was made for the 80x40 extrusion profile.

The guides weigh a lot more there, more could be gained there.

Thanks for the reply.
I removed it but it had no effect.

I would try to remove the PARAMETER_FILE (sim_mm.var) and then start the program

W4 is not used on the 7I84U, its position does not matter.
(note that the 7I84U was tested with the as shipped jumper settings)

What LEDs are illuminated on the 7I84U when the system is powered
(but linuxCNC not running?)

You should have 2 yellow LEDs and 1 red LED illuminated. If not, 
there is a power issue.

Do you have both FIELDA and FIELDB voltages applied? 

 

I just noticed that halui.axis.x.pos-relative read the value correctly and it retains it after restart. The axis.x.pos-cmd always starts at -496.2247. When i move the robot the halui.axis.x.pos-relative reports the correct absolute position but the robot moves as if it has been started at -496.2247. Any ideas?

Hi, I have a delta robot built on ethercat and running linuxcnc.
We recently got drives with absolute encoders so i had to make a specific homing procedure that just triggers the internal homing on the drives.
The drives then reset their encoder positions internally to 0 or home offset if it's set in HAL with lcec.
Then, when using the robot i could move it somewhere, turn off linux cnc and then start it again and linuxcnc always shows the same position when starting [ 0. , 0. , -496.22474747]. When i disable the home offset this number still stays the same. I move the robot to [0,0,-700], restart and it still shows the same position, and then moves "ignoring" the soft limits. The encoders themselves retain their position information properly, it's just linuxcnc that reads it wrong (or doesn't read it for some reason) What am i missing here?
Here are the files for my config.