Advanced Search

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

See my post on page 6.The slave reports with a completely different configuration. I haven't changed anything; these are the factory settings. I now have two options: either I create a minimal configuration where I activate csp mode, or I do this directly via the servo or software.

Successfully retrofitted!

This is such an improvement.  Qtplasmac has all the features that I liked about the Hypertherm Microedge controller and Phoenix software while being way less clunky and easier to navigate.  

I'm using hypertherms vdc3 board for ohmic and divided voltage. Ohmic is still just as light and can detect alum foil.

Thank you guys so much for the help.  I still need to finish configuring the homing setup for a dual motor gantry setup.  I'll read through the docs some more before I ask questions.

Awesome, and thank you! I'll give this a shot.

abs32 wrote:

There is no point in looking for 279. Both versions of the same program start in the XYZ configuration and work normally. Both versions crash in the same way when working with XXYYZ.

This is a different question/issue. 

I was looking for the 279 kernel because I want to make a new 2.9.7 deb package (and possibly an ISO)

I am looking at your f-error and probe issues too, but I thought that a new package might be relatively easy. 

That's how it's done. You really don't tell us much.
Isn't the problem that the slave is not available in the current configuration then?

There is no point in looking for 279. Both versions of the same program start in the XYZ configuration and work normally. Both versions crash in the same way when working with XXYYZ.

Hi AlexMagToast,I’ve been following your Arduino IO-Expansion project for a while now and I just wanted to say thank you, really great work! Thanks for sharing!I’m currently planning a control panel for my lathe and your project looks like it could be a good fit even though my setup is a bit different from yours. I won’t need the matrix keyboard because I’m planning to use a StreamDeck for most of the button functions (there’s a tool for LinuxCNC support here: forum.linuxcnc.org/show-your-stuff/52628...for-linuxcnc?start=0 ).  For the panel itself I would still need some hardware I/Os:
-> 8–10 digital inputs/outputs (joystick, rapid, spindle, LEDs, etc.)
-> 3 analog inputs for potentiometers (feed override, spindle override, handfeed)
-> 2 encoder inputs for handwheelsI wanted to use the Heidenhain ROD450 with 500 lines on the handwheels the lathe came with through Beckhoff EtherCAT hardware, but the 11µA sinus signals are a bit of a nightmare to read out. So I’m now considering a simpler approach with two inexpensive TTL encoders from China, which your Arduino setup should handle much more easily.My questions:
How stable has your Arduino solution been for you so far? Are you still happy with it? Especially on the same USB cable with the StreamDeck.
Which board would you recommend for what I’m trying to do? Uno, Mega, ESP32 or something else? Does someone recommend a different hardware setup?Thanks again for sharing your project. It’s cool to see alternatives to the usual hardware solutions, and I’d appreciate any advice before I start buying components. Greetings Tom

There are lots of comments here abut running the 5.4.279 kernels, but I don't seem to be able to find them anywhere. Any clues?

The link in the first post of the thread says 5.4.279 but leads to 5.4.290 debs.