Advanced Search

Design done, first one in the works, I put some limited earlybird preorders up, wont be too many of those. Just want to iron out the process before it goes full on for sale. This should be fun.

Hello Lcvette,
Thanks for your time and ideas!

The motor on the Y axis is a JMC iHSSC60-36-35-21-38-POCA. The manual says the pulse and pause should not be shorter than 2.5 µs; I have set this in the .ini file to 2,500 ns. This worked fine until now. Today, I changed this to 4000 ns, thinking it would be safer. After that change, an error occurred: 'stepgen.01.maxvel is too big for current step timings and position scale; clipping to maximum possible', so I reduced my Vel settings to 100 mm/s and 125 for overhead. This means that I cannot drive the axis at 7.5 m/min as before, but only at 6 m/min. I would accept this if the axis runs correctly afterwards. I will check this tomorrow.
Indeed, I change the motor-spindle gear in the X-axis a while ago to 20/32 teeth, which gives me a 640-step scale on the X-axis. This is not 1:2 as in the Y-axis, but 1:1.25.
My motor settings are 2000 steps/rev, which is not a problem for the motor or LCNC. The motor can run up to a frequency of 200 kHz, but I did tests with an oscillator and found the limit to be 180 kHz. So, 4000 ns will be safer.
Could the motor be losing steps at the shorter 2500 setting? I mean, it's a closed-loop motor that corrects lost steps. I changed to this motor from a 400 W OMC servo motor to check whether the motor and parametric settings were at fault with regard to my dimensions. That is not the case, as I can see. So I will go back to the servo if I get the problem solved.
The motor settings, especially the step scale, are correct; I measured them and found no deviations on a 400 mm straight line on a steel scale. Straight cuts were very accurate before. The problem was elliptical deviations when cutting circles.

OK, I will do another test cut tomorrow and report back.

Thanks, and have a good Friday!

Hanno

Isn't there a component that creates the command position = position read by the transducer?

LinuxCNC does this (sets commanded position to actual position) when motion is disabled, but it's global (all joints)
It might require a modification of LinuxCNCs motion component to do this correctly on a joint by joint basis

I haven't used my gmoccapy lathe installation for perhaps 18 months due to working on other machines. At last use I was having problems with Andy Pugh's macros (something to do with needing Python 3?) and I'd struggled to finally get it to the point of working as it was (some problem with the RT kernal, which I had to change).

Although I haven't changed anything in the meantime, when I try to run gmoccapy, I now get errors and it bombs out. It seems to be something to do with the 5i25 possibly not loading if I understand the error message.

I'm planning to install the latest version of Linuxcnc and gmoccapy, so I'm not actually focusing on trying to rectify the above problem but the report file lists some of the components installed in the current system.

My question is - if I create a fresh Linux / Linuxcnc installation, what else would I need to port across to get it running? I'm thinking the hal and ini files for starters but is there anything else? Furthermore, are there any additional entries I'd need to put in the files? I think I saw a post mentioning some graphics-related additions to the ini or hal files when I was trawling through the forum yesterday but obvs I can't find it again. It's possible it was actually in the Probe Basic area of the forum - a version I previously set up but decided to stick with gmoccapy.

I'd be very grateful for any guidance to point me in the right direction!


 

The are not Inovance, they are Jssmotors, as you can see in this link:

www.jssmotor.com/servo-system

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?