Advanced Search

Sorry for the late response. If our problem is same, this is what I changed in the sii file from my Inovance driver. I changed that part to ‘04’ and then wrote it back to the driver after making the change.

I did try reversing the input, Does my custom.hal file look correct? I get a joint 0 amplifier fault instantly its the only joint i am trying to figure out at the moment i haven't tried to add the other joints yet. Is there other ways of doing this that might be easier to add in my case ?

Thanks

rodw wrote:

To get a specific kernel you probably need to get the source from kernel.org
www.kernel.org/pub/linux/kernel/v5.x/
Follow a similar process to the attachment but I assume you won't need to patch the real time kernel

If I go that way I will, absolutely, need to patch the kernel. 
But this whole thread seems to say that there was a 5.4.279-rtai kernel that a number of people successfully tested. But which is now nowhere that I have looked. 

I have installed 5.4.290-rtai on a machine here, and it seems to work for me, and I have created a LinuxCNC / Trixie / RTAI package based on it, but I don't want to bake that into an ISO if it's known to be an unreliable kernel. 

I'm using a slightly older version of the probe screen so the gcode() method is in base.py. I haven't upgraded. I suppose I should.

I'm running axis 2.8.1.
I like the idea of the INI file value [TOOLSENSOR]RAPID_SPEED being used for the movement to/from the start search position. I could then even use F50 for example after tool is up above the work piece. Then when it reaches the other end it goes back to self.ps_rapid_speed from the probe screen parameter which I have set at 10.

However somehow although it works on Thonny the

if "G1 " in l:
l += " F#<_ini[TOOLSENSOR]RAPID_SPEED>"

is not working. And setting the box on the probe screen to 50 for rapid has the risk of breaking the probe. Actually anything above about 20 has that risk.

I run Ubuntu 24.04 on my workshop station.
So no problem doing as Tommy suggested, and I will follow that up.

Did some more digging, found out FreeCad will open a GCode file and display the paths.
And, when a path is selected, the readout shows the (nearly) equivalent file line number and x,y,z coordinates.

Already solved the problem that initiated the OP, thanks to all.

John.

LesNewell wrote:

I had a quick play and noticed a few issues.
Are you intending to charge for this? 

It appears so:

www.plasmadesk.com/LE/pricing.html

I had a quick play and noticed a few issues.

1. How do you change the cut settings to use metric?
2. I notice outside corners are just a straight line, cutting across the tip of the corner. This should be an arc or the edges should be projected to form a sharp corner.
3. You don't appear to be able to specify outside or inside offset. All contours get an outside offset. Say for instance you are cutting a washer. The drawing is two concentric circles. When you cut it, both the inner and outer circles have an outside offset, resulting in an incorrect hole diameter. The inner should have an inside offset.
4. Your report a bug link takes you to a 404 page.

I didn't play with the nesting much. Is is based on Deepnest? Is the offsetting your own algorithm or based on an existing library such as Clipper?
Overall it looks like it has potential for simple plasma jobs. Are you intending to charge for this? 

To get a specific kernel you probably need to get the source from kernel.org
www.kernel.org/pub/linux/kernel/v5.x/
Follow a similar process to the attachment but I assume you won't need to patch the real time kernel

Note this example compiles to a Deb file so you can build it on a fast PC and install with dpkg -i
 

A little more information on this: I've added a couple of signals:
-- homing_feed_inhibit: when it's 0, it pauses the homing process, and when it's 1, it resumes it.

- homing_paused: an intermediate and information variable.

A couple of functions have been added for the movements:

static void home_resume_long_move(int jno, double vel)
{
emcmot_joint_t *joint = &joints[jno];

/* If already active, do nothing */

if (joint->free_tp.active) return;

home_start_move(joint, vel);

}

/* helper to resume the final movement to H[jno].home */
static void home_resume_final_move(int jno)
{
emcmot_joint_t *joint = &joints[jno];

/* If already active, do nothing */
if (joint->free_tp.active) return;
/* plan to final move to home position */
joint->free_tp.pos_cmd = H[jno].home;
if (H[jno].home_final_vel > 0) {
joint->free_tp.max_vel = fabs(H[jno].home_final_vel);
if (joint->free_tp.max_vel > joint->vel_limit)
joint->free_tp.max_vel = joint->vel_limit;
} else {
joint->free_tp.max_vel = joint->vel_limit;
}
joint->free_tp.enable = 1;
}

And the most problematic thing, in state 9, in case we set homing_feed_inhibit to 0 and we are very close to the home switch when resuming (homing_feed_inhibit = 1) we would get

rtapi_print_msg(RTAPI_MSG_ERR, _("Home switch inactive before start of backoff move j=%d"), joint_num);

which causes the homing process to be aborted, that's why I make the decision to go to HOME_RISE_SEARCH_START or HOME_FALL_SEARCH_START depending on the search/latch signs

case HOME_FINAL_BACKOFF_START:
/* This state is called once the approximate location of the
switch has been found. It is responsible for starting a
move that will back off of the switch in preparation for a
final slow move that captures the exact switch location. */

/* is the joint already moving? */
if (joint->free_tp.active) {
/* yes, reset delay, wait until joint stops */
H[joint_num].pause_timer = 0;
break;
}
/* have you delayed timed out? */
if (H[joint_num].pause_timer < (HOME_DELAY * servo_freq)) {
/* no, update timer and wait some more */
H[joint_num].pause_timer++;
break;
}
H[joint_num].pause_timer = 0;
/* we should still be on the switch */
if (!home_sw_active) {
// rtapi_print_msg(RTAPI_MSG_ERR,
// _("Home switch inactive before start of backoff move j=%d"),
// joint_num);
// H[joint_num].home_state = HOME_ABORT;

/* Resilient fallback: If the switch bounced just before the backoff,

do not abort; continue fine-tuning the search based on the search/latch signals. */

double tmp2 = H[joint_num].home_search_vel * H[joint_num].home_latch_vel;

if (tmp2 > 0.0) {

/* Expected path: backoff + rising edge search */

H[joint_num].home_state = HOME_RISE_SEARCH_START;

} else {

/* Alternate path: falling edge search */

H[joint_num].home_state = HOME_FALL_SEARCH_START;

}
immediate_state = 1;
break;

}

/* set up a move at '-search_vel' to back off of switch */
home_start_move(joint, - H[joint_num].home_search_vel);

/* next state */
H[joint_num].home_state = HOME_FINAL_BACKOFF_WAIT;
break;

This is a first approach; the idea is to improve it. As I said before, criticism is welcome.

I tested a „clean“ 2.9.7+ setup, without my M64/M65-flipflop solution, but no, the issue was not (completely) fixed.

It kinda improved, but the „probe triggered“ fault is still happening.
I was not able to finish even shorter milling programs (<5 mins).

But the „queue full“ bug did indeed not appear anymore.

Hello everyone, it's always good to be back after some time:
In my latest projects, a client wanted to certify the safety of the machine I had updated for them. Compliance with safety regulations is always important, and this means complying with Royal Decree 1215/1997 here in Spain.

For my projects, I developed a controller based on LIMIT3 with extra joints, but I modified it to add intermediate braking before reaching the target position, depending on a pair of pushbuttons for occupied hands or bimanual operation. I have this implemented and it works correctly.

Now, the homing process is always performed by homing.c, which doesn't have a default pause/resume function. Evidently, according to Royal Decree 1215/1997 and the certification engineer, the machine cannot move on its own. I actually work with double-head miter saws from different brands: FOM Industries, Mecal, Ozgenc Makina, Fenstek, and of all of them, the only one that has bimanual operation implemented in the homing process is the FOM Industries machine. All the others move automatically and only use bimanual operation to perform the cut. Frankly, it never bothered me that the machine only moved during the homing process, but thanks to my dear friend, the certifying engineer, I've taken on the task of making some changes to homing.c to implement this behavior. What's needed is that if the machine moves long distances, closing the gap between the printheads, the moving printhead stops when the bimanual is released. While not a concern, I've also implemented pause/resume functionality for the final movement to the home position. I haven't implemented this behavior in the home states from 9 to 20 because the movements are very small, and I don't want to have measurement issues with the home switch. Without further ado, here's my version of homing.c for you to review. I've seen that the author is jmkasunich. Any feedback would be great. Thanks and regards.

I just did this for my CNC. Here are the HAL bits I used.  Amusingly, I can't find where <axis>-fault is connected, but I *do* get following errors when I hit things.  More testing required...

addf and2.3 servo-thread
addf and2.4 servo-thread
addf and2.5 servo-thread
addf and2.6 servo-thread
addf and2.7 servo-thread
addf timedelay.0 servo-thread

setp timedelay.0.on-delay 1
setp timedelay.0.off-delay 0

net machine-is-on => timedelay.0.in
net enable-faults <= timedelay.0.out

net x-enable  => hm2_7i76e.0.7i76.0.0.output-08 # TB5 leftmost output
net y-enable  => hm2_7i76e.0.7i76.0.0.output-09
net y2-enable => hm2_7i76e.0.7i76.0.0.output-10
net z-enable  => hm2_7i76e.0.7i76.0.0.output-11
net a-enable  => hm2_7i76e.0.7i76.0.0.output-12

# HLFB is true when enabled *and* following
net hlfb_x  hm2_7i76e.0.7i76.0.0.input-16-not # TB5 leftmost
net hlfb_y  hm2_7i76e.0.7i76.0.0.input-17-not
net hlfb_y2 hm2_7i76e.0.7i76.0.0.input-18-not
net hlfb_z  hm2_7i76e.0.7i76.0.0.input-19-not
net hlfb-a  hm2_7i76e.0.7i76.0.0.input-20-not

net hlfb_x        => and2.3.in0
net enable-faults => and2.3.in1
net x-fault       <= and2.3.out

net hlfb_y        => and2.4.in0
net enable-faults => and2.4.in1
net y-fault       <= and2.4.out

net hlfb_y2       => and2.5.in0
net enable-faults => and2.5.in1
net y2-fault      <= and2.5.out

net hlfb_z        => and2.6.in0
net enable-faults => and2.6.in1
net z-fault       <= and2.6.out

net hlfb_a        => and2.7.in0
net enable-faults => and2.7.in1
net a-fault       <= and2.7.out
 

Did you try inverting the input ?

natester wrote:

Did you ever figure this out? I also found this bug in probe screen v2.8: github.com/verser-git/probe_screen_v2.8/...probe_screen.py#L341

Increasing the timeout makes no difference as wait_complete always returns immediately. I'm also on linuxcnc 2.8.4

This line:
                time_in = 1 + (distance / self.ps_rapid_speed ) * 60
github.com/verser-git/probe_screen_v2.8/...probe_screen.py#L338

It doesnt calculate with ramps, so time cant be enough.

I preffer use long time:forum.linuxcnc.org/38-general-linuxcnc-q...ete-timed-out#296683

I dont know if this answers your question, but when i use the machine with amp.fault comment out it works fine as soon as I enable the machine with amp.fault enabled it faults instantly I just wanted to use this feature from my understanding it could be useful.

Thanks