Advanced Search

That worked well. Currently, I'm just testing that the electronics are working; the hardware isn't connected yet, so scaling isn't realistic. What is working is the C-axis and the M commands for spindle movement. The stepper motors are also moving as they should. There are still problems with the M19 command (the servo might be trying to reach a position too quickly, which isn't possible). I'm also checking that the C-axis is working reliably. Currently, there are still problems switching from M3 to S500 for a short time after the C-axis. The servo goes into overload because it seems to be trying to reach a position too quickly, which isn't possible.

Can see the results but no way to vote as unknown said.

Is everything else the same? Same OS same kernel?

It wouldn't expect anything to have changed, the release notes are here, and I don't think that motion was touched.

github.com/LinuxCNC/linuxcnc/blob/2.9/debian/changelog

If you _could_ try 2.9.5 that would eliminate some changes from the list of possibilities.

now I deleted everything related to python, in the ini I only added remap=m6 modalgroup6 ngc=toolchange
subroutine path to the folder where my toolchange.ngc is, if I type in mdi T1 m6 or o<toolchange> call I get an error like in the picture- 

my ngc is:

o<toolchange> sub
M73

; --- unload current tool ---
IF [#<_current_pocket> GT 0] THEN

```
IF [#<_current_pocket> EQ 1] THEN G0 X0 Y-80 Z-120 ENDIF
IF [#<_current_pocket> EQ 2] THEN G0 X0 Y-191 Z-120 ENDIF
IF [#<_current_pocket> EQ 3] THEN G0 X0 Y-302 Z-120 ENDIF
IF [#<_current_pocket> EQ 4] THEN G0 X0 Y-619 Z-120 ENDIF
IF [#<_current_pocket> EQ 5] THEN G0 X0 Y-730 Z-120 ENDIF
IF [#<_current_pocket> EQ 6] THEN G0 X0 Y-841 Z-120 ENDIF

M62 P0       ; LOCK
M64 P1       ; CLAMP
G4 P0.5      ; lock dwell
M65 P1       ; unclamp
```

ENDIF

; --- load new tool ---
IF [#<_selected_pocket> EQ 1] THEN G0 X0 Y-80 Z-120 ENDIF
IF [#<_selected_pocket> EQ 2] THEN G0 X0 Y-191 Z-120 ENDIF
IF [#<_selected_pocket> EQ 3] THEN G0 X0 Y-302 Z-120 ENDIF
IF [#<_selected_pocket> EQ 4] THEN G0 X0 Y-619 Z-120 ENDIF
IF [#<_selected_pocket> EQ 5] THEN G0 X0 Y-730 Z-120 ENDIF
IF [#<_selected_pocket> EQ 6] THEN G0 X0 Y-841 Z-120 ENDIF

M64 P0
M64 P1
G4 P1.0
M65 P1
M65 P0
G4 P0.5

G0 X0 Y0 Z0

o<toolchange> endsub
M2

I, too, only see the results, the initial announcement, and a banner that says "You cannot reply to this topic".  I'm not a mod either.  I wonder if ability to reply is tied to ability to vote?
 

Hi Have 1995 Tsugami Swiss that I converted over to.
Linuxcnc, ClearPath, Mesa 6i25,7i76,7i85 closed loop on 1 micron scales.

LinuxCNC going back as far as 2.7 which was tested up to 300 inches a minute.
(Which was too fast for me.)

Never had a problem running 180 inches a minute until 2.9.7 update
Now I can't get more than 130 inches a minute without getting joint errors.
I get  180 inches a minute on LinuxCNC 2.10-pre0 on Mint 22.1 
LinuxCNC 2.9.4 runs  just fine as well.

I never upgraded to 2.9.5 or 2.9.6 but I have used the same config going back to 2.8
Anyone else seeing this?
 

Thanks for the replies.
The solution of increasing the tracking value and resetting the axis is impractical and technically incorrect.

The servos are analog and controlled by Mesa boards.
Isn't there a component that creates the command position = position read by the transducer?
Or is there a way to modify the Trivkins kinematics?

That is NOT the image I'm referring to.
In fact I would be grateful if you would not host any of the images I create. I do not trust the security of you server.
Please remove NOW.

Do you mean like this ?
linuxcnc.org/docs/devel/html/gui/qtvcp-l...ml#_code_action_code

or something like this?
linuxcnc.org/docs/devel/html/man/man1/axis-remote.1.html

I am looking to leverage linuxcnc.org/docs/html/config/python-interface.html to build an API which will be able to perform basic machine functions like homing the axis, measuring tool length and running gcode. Out of curiousity do you guys know of any github repos or any open source projects I can reference to start this project?

Setting 'value-changed' callback functions on output pins is not the thing to do.
'value-changed' only makes sense with input pins.

You should create a STATUS callback for manual and auto mode changes that change the LEDS.
Here is some details:
linuxcnc.org/docs/devel/html/gui/gstat.h...tension_code_pattern

Something like this:

HalloIch habe eine frage ?Welche   *.ngc Dateien und Var Einträge brauche ich wenn ich  ein Rack ATC verwenden möchte.Linuxcnc 2.9.7
Mesa 7i76e


mfg
Hilton

 

I had to move some files around, but i think i have it working. Thank you so much for all of yalls help! Yall are the best!!!!

i would review the stepper motor docs and make sure your timings match what the drives are looking for, this may help resolve your drive side following error, the timings are usually listed in a graph showing the uSec for step and dir and would be entered in the configuration file, yours seem quite big to me from what i am used too seeing.

the first thing I would be looking at is resolving the drive errors to ensure that what linuxcnc is commanding is actually being executed by the drive without faults, otherwise is doesn't matter what linuxcnc is sending. verify your stepper timings are set correctly, then try resetting the config to the basic stepper settings without any "fixes". test and ensure no drive faults and get another test cut measurement, once you have no drive faults you can begin troubleshooting the linuxcnc side of things. I would set any scaling to preliminary settings for the motion components advertised ratios such as lead and transmission reductions for pulleys. remove any fixes here from the equation so you have a good base point to start from. I have found that any deviations here will be very very small and certainly not in the realm of tenths of a mm. also remove any backlash compensation. you really want to run your test cuts without anything except the very base setting requirements to ensure something you did while running with drive faults isn't skewing your results.

other things to verify.  drive settings for microstepping, ensure these are correctly set and not beyond what the drive can handle at 200khz step frequency and linuxcnc output.  sometimes setting these a little more conservatively is better.

I also just saw in your ini config you shared that your step scale is different for x and y axis, but you state you are running the same screws and 2:1 reduction, the step scale here should be the same provided the drive microstepping settings are the same for both axis (and they should be)  both should be set to the systems axis setting test with the least granular microstepping setting for continuity.

I omitted that file and the GUI launched but with a new error.. LOL This thing is driving me crazy.

Traceback (most recent call last):
File "/usr/bin/probe_basic", line 8, in <module>
sys.exit(main())
~~~~^^
File "/usr/lib/python3/dist-packages/probe_basic/__init__.py", line 20, in main
qtpyvcp.run_vcp(opts, VCP_CONFIG_FILE)
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/qtpyvcp/__init__.py", line 26, in run_vcp
run(*args, **kwargs)
~~~^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/qtpyvcp/app/__init__.py", line 129, in run
launch_application(opts, config)
~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/qtpyvcp/app/launcher.py", line 93, in launch_application
raise IOError('The specified POSTGUI_HALFILE does not exist: %s' %
postgui_halfile)
OSError: The specified POSTGUI_HALFILE does not exist: /home/kris/linuxcnc/configs/my_mill/probe_basic_postgui.hal