Advanced Search

Aciera wrote:

Not sure if this applies to your setup but classicladder does not seem to work with [HAL] TWOPASS = on

Classic ladder works on both my machines with TWOPASS = ON

2.9.3 on mill, and 2.10 on lathe.

Maybe the loadusr line needs to be in postgui.hal?

One thing to be aware of is that using motion commands with any other axis letter than XYZ causes the motion planner to fall back to one-line-look-ahead. This is not a problem if the motion segments are long enough but can cause jerky movement for short segments.

It's worth noting that immediately after the second touch-off the program aborts. There is no movement for any axis.

The read ahead will start ingesting gcode again as soon as the touch off is completed and as soon as it reaches a command that would violate a limit the program will abort. This is happening well before actual execution of the queued motion commands.

Aha, another informative data/state dump would be:

halcmd show all ini.

 

I have been running gmoccapy with a joypad with RIP tag v2.9.2 for quite a while on my mill, router, and lathe.

When I check out and build branch 2.9 or tag v2.9.3 and RIP with the exact same mill.ini, I am now getting jog Y negative direction (slow/fast) actions whenever I press the btn-joystick and btn-thumb on my joypad. I have these two joypad buttons set up to select speed (wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_Remote_Pendant).  

I used hal watch to look at gmoccapy.jog.axis.joy-y-minus and it stays false when I press the buttons. If I do use the joy-y-minus set control it jogs at the same speeds(depending on turtle/rabbit) as when I press the joypad btn so the joypad buttons seems to be triggering the jog but I don't know how this gets mapped as there is nothing in my config that did that?

Looking at my gmoccapy.preferences
use_keyboard_shortcuts = False

I had to install version 4 of gtk something to get v2.9.3 to run, now I can't run run 2.9.2 anymore. 

Any help/hints would be appreciated.


 

Agreed on the "probe succeeding".

I added this in order to see what is taking place:
'Return to original tool-tip position using new z-offset: ...'

I've noted from the script that:
#<touch_result> = #5063
which equates to 277.16xx in this case. Fairly consistent thru the 3 attempts.

I'm attaching the script as I have it now including the extra debug messages.

It's worth noting that immediately after the second touch-off the program aborts. There is no movement for any axis.


 

You can try this rt kernel for the rk3399:
drive.google.com/drive/folders/12VfNmKC3...feCnnzYX?usp=sharing

For the spi rt patch I'll see if I'm able to do something. For sure it won't be as complete as the "original" patch but maybe it'll be good enough.
Have you already been able to use the spidev driver at all?

A couple of things:

You should use reset mode for all axis/spindle
this should double you maximum step rate

Can you post your current hal/ini files?

maybe it seems need looking for a more complex path , because in the second cycle the diameter of the cylinder already changes for the thickness of the material being rolled (inversely proportional to the thread cutting on the lathe), another possible problem is the material itself, because in theory, A axis or S must make one revolution to move the linear axis for one stepover (material thickness), but as in practice material deviation occurs, I am very skeptical that they can guess the speeds. I used deskproto'' to export gcode for 4 axes with the path ``continues rotary'', where it has the basis of the speed of the linear axis and the stepover, as well as the diameter of the workpiece, so it calculates the speed of the A axis. but this is a hard material and then it is an accurate measure..www.youtube.com/shorts/OOtRMBdZchk

PCW wrote:

Yes, this firmware should work (though would need to be modified to add the fourth axis index input)

Great, thanks.
4th is in the future, no need for it for a while:)

 

Yes i think that is the way to go. but I am curious to find out if it is also possible to do it while configured as an A Axis?

secondly, i have a parallel thread on going the discussion of a spindle, where i am not able to attain the max rotational speed when my motor is configured as a spindle compared to as an A axis (where i get more rpm).

forum.linuxcnc.org/16-stepconf-wizard/54...-par-port-stepconfig

help is much appreciated

Sounds like you should maybe run it as a spindle instead of axis A.

yes, to match the feedrates when two axis are called simultaneously within a single line of code, the gcode calculates a compound feedrate, with the X axis as master, and the A axis as slave. so basically the X axis dictates how fast the A axis would rotate. i do not want this.

i want the A axis to be rotating continously at a given feedrate.
and X to perform back and forth motion (based on the material width that i have, so that i can acheive a side-by-side layup of the material) the material parameters are mentioned on the above reply of mine.

diameter of the mandrel = 100mm
length of the tube to be wound = 300mm
material speed (to be wound per second) = 100mm/s
material width = 6.35mm
material thickness = 0.14mm (lets ignore it at the moment for a simple program)
requirement = side-by-side layup of material without any gaps and overlaps

and how about the other terms,
SCALE = 6400
DIRSETUP = 10000
DIRHOLD = 10000
STEPLEN = 5000
STEPSPACE = 5000

because i noticed that if i keep scale as 800, then the spindle rotates very slowly.
what values should the rest of the terms, dirsetup, dirhold, steplen and stepspace should have to maximise the rpm.

i certainly can see that when the motor is set as A axis(with max values), it turns faster than with my current settings as spindle.