Advanced Search

yes, everything is working well thanks

You get after start another lcec.1. instances with your pins.

I can provide a config later this day.

Greets sven

Hi,
can you please add your .json config.

Have you set the scale for the quad encoder correctly?

and then how will you specify the .hal file for separate masters? 

there will be more lcec. instances? 

do anybody have working config?

Yes, you add a second master in your /etc/ethercat.conf
There is already a line:

# The MASTER<X>_DEVICE variables also determine, how many masters will be
# created: A non-empty variable MASTER0_DEVICE will create one master, adding a
# non-empty variable MASTER1_DEVICE will create a second master, and so on.
#
MASTER0_DEVICE="eno0"
MASTER1_DEVICE="eno1 or mac adress" 

Then you can add a second master in your ethercat-conf.xml

<master idx="1" appTimePeriod="1000000" refClockSyncCycles="5">

And that's it.

I had testet it with 2 Nic's not long ago

It's working fine.

Greetings Sven

My PC has two Ethernet ports. I want to use port 1 to connect to devices A, B, and C, and port 2 to connect to devices D, E, and F because they are in separate locations. Is it possible to configure two EtherCAT ports?

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.