Advanced Search

Understood, Here's the lines where I suspect may be problematic, these are all after the touch-off:
#<touch_result> = #5063
#<calculated_offset> = [#<touch_result> - #<_hal[qtversaprobe.probeheight]> + #<_hal[qtversaprobe.blockheight]>]
G10 L1 P#<tool> Z[#<calculated_offset>]
G43
(DEBUG, Return to original tool-tip position using new z-offset: #<local_start_x> , #<local_start_y> , #<local_start_z>)
G53 G0 Z[#<_ini[VERSA_TOOLSETTER]Z_MAX_CLEAR>]
G0 X[#<local_start_x>] Y[#<local_start_y>]
G0 Z[#<local_start_z>]       <

---

LINE 244

The last line above is line 244.

The G53 call I have as -5 in my ini file. Which is an absolute call as I understand. The local variables are just that and
do not change when the sub runs.
The calculated_offset is consistent throughout the sub so that can be ruled out, I believe?
That leaves these two lines:
G10 L1 P#<tool> Z[#<calculated_offset>]
G43



 

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:)