Advanced Search

Hi All,

it seems that i found the issue by accident   : it seemed that some part of motion still checks the home-switch-in even if they don't have a direct influence on my homing-procedure. (that is completely outsourced to pokeys, i just await the home status, the home-switch information is there but more or less for informative purposses. i didn't use these switches at all, but it seems theres some part of motion which checks that in background)

Hi,

this is on Almalinux 9 (RHEL9 clone), kernel 5.14.0-503.23.2.el9_5.x86_64.

Ethercat is from github, release 1.6.3.

Ethercat was built from source, loads correctly and shows something meaningfull with the command "ethercat master". Other than that, nothing was configured yet. 
Ethercat master alone is stable, but when two slaves are present on the same network, it crashes after some time.

Crash:
[  719.621831] BUG: TASK stack guard page was hit at 000000009ee0e10f (stack is 00000000e1d2d8c3..00000000a409be87)
[  719.621834] stack guard page: 0000 [#1] PREEMPT SMP NOPTI
[  719.621837] CPU: 1 PID: 722 Comm: EtherCAT-IDLE Kdump: loaded Tainted: G           OE    

---

 ---  5.14.0-503.23.2.el9_5.x86_64 #1
[  719.621840] Hardware name: ASUSTeK COMPUTER INC. NUC14MNK-B1/NUC14MNB1, BIOS MNADLCPX.0009.2024.1006.0803 10/06/2024
[  719.621841] RIP: 0010:ec_master_calc_topology_rec+0x10/0xa0 [ec_master]
[  719.621885] Code: 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 41 55 49 89 fd 41 54 49 89 d4 55 <53> 8b 2a bb 03 00 00 00 48 69 ed 70 03 00 00 48 03 af 90 07 00 00
[  719.621886] RSP: 0018:ffffc004c0d1c000 EFLAGS: 00010286
[  719.621887] RAX: ffff997f0ae55b90 RBX: 0000000000000003 RCX: 0000000000000004
[  719.621888] RDX: ffffc004c0d1fe7c RSI: ffff997f0ae55820 RDI: ffff997e86d6c000
[  719.621889] RBP: ffff997f0ae55820 R08: 0000000000000000 R09: ffffc004c0d1fd20
[  719.621889] R10: ffffc004c0d1fd18 R11: ffffffffb9de93e8 R12: ffffc004c0d1fe7c
[  719.621890] R13: ffff997e86d6c000 R14: ffff997e86d6c6d8 R15: ffff997e86d6c080
[  719.621891] FS:  0000000000000000(0000) GS:ffff9981ef880000(0000) knlGS:0000000000000000
[  719.621892] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  719.621892] CR2: ffffc004c0d1bff8 CR3: 00000001019e8000 CR4: 0000000000750ef0
[  719.621893] PKRU: 55555554
[  719.621894] Call Trace:
[  719.621895]  <#DF>
[  719.621896]  ? show_trace_log_lvl+0x1c4/0x2df
[  719.621900]  ? show_trace_log_lvl+0x1c4/0x2df
[  719.621902]  ? ec_master_calc_topology_rec+0x6d/0xa0 [ec_master]
[  719.621927]  ? __die_body.cold+0x8/0xd
[  719.621929]  ? die+0x2b/0x50
[  719.621931]  ? handle_stack_overflow+0x49/0x60
[  719.621933]  ? exc_double_fault+0x14b/0x180
[  719.621935]  ? asm_exc_double_fault+0x1f/0x30
[  719.621938]  ? ec_master_calc_topology_rec+0x10/0xa0 [ec_master]
[  719.621961]  </#DF>
[  719.621961]  <TASK>
[  719.621962]  ec_master_calc_topology_rec+0x6d/0xa0 [ec_master]
[  719.621984]  ec_master_calc_topology_rec+0x6d/0xa0 [ec_master]
[  719.622006]  ec_master_calc_topology_rec+0x6d/0xa0 [ec_master]
[  719.622028]  ec_master_calc_topology_rec+0x6d/0xa0 [ec_master]
[  719.622050]  ec_master_calc_topology_rec+0x6d/0xa0 [ec_master]
[  719.622072]  ec_master_calc_topology_rec+0x6d/0xa0 [ec_master]
[  719.622095]  ec_master_calc_topology_rec+0x6d/0xa0 [ec_master]
[  719.622119]  ec_master_calc_topology_rec+0x6d/0xa0 [ec_master]
[  719.622142]  ec_master_calc_topology_rec+0x6d/0xa0 [ec_master]
(many more such lines)

Now i am a newbie to Ethercat and to Linuxcnc, so i may be doing something wrong here.
So i have some basic questions:
- is ethercat master to be used on a separate ethernet port, so do i need two NICs in my linuxcnc computer? Or does it coexist with the rest of Linux/IP ?
- is the "daisy chain" ethernet cabling mandatory for ethercat? During the crash, i had everything connected to a mini-switch.
- how do multiple ethercat slaves get distinguished? Do i have to assign some slave-ID?

 

I've been doing some research but I'm not sure what I'm doing.

Is there any mpg compatible with probe basic?

I edited a post above to indicate that the three BOBs have now been fully tested. Previously I had checked all the paths with an ohm meter, powered up one of the boards and checked some signals.

 

All three boards have been powered up and tested. All inputs were connected to 3.3v or 5v. The corresponding output was checked for a high (5v or 3.3v). The input of the line being tested was then connected to ground, and the corresponding output checked for a low. The input was again connected to 3.3v or 5v, and the corresponding output checked for a high. Every input and output was verified to work correctly.

I have 100% confidence in the BOBs. If anyone purchases all of these components for $500, and the BOBs don't function properly, I'll refund $100.

Best, Gene
This email address is being protected from spambots. You need JavaScript enabled to view it.

ok, i got it to build.
RHEL9 seems to have some stuff backported from kernel 6.x, so ifdef macros go the wrong path.
For me a quick fix was to just remove the ifdefs, like this:

*** cdev.c.orig 2025-03-02 10:05:18.704523437 +0100
--- cdev.c 2025-03-02 10:06:13.589430791 +0100
***************
*** 227,237 ****
EC_MASTER_DBG(priv->cdev->master, 1, "mmap()\n");

vma->vm_ops = &eccdev_vm_ops;
- #if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 3, 0)
vm_flags_set(vma, VM_DONTDUMP);
- #else
- vma->vm_flags |= VM_DONTDUMP; /* Pages will not be swapped out */
- #endif
vma->vm_private_data = priv;

return 0;
--- 227,233 ----

The same problem was in module.c.

Now the driver builds and loads into the kernel.

OK ping times look OK

Make sure the servo thread period is set for 1ms (1000000 ns)

What actual error do you get from LinuxCNC?

 

did you sort it out? the issue i saw with external controls being tied to the ui was a synchronization problem. the only thing i think that would work would be momentary buttons for each increment. a rotary switch such is on most mpg's could not remain synch's with the ui if changed in the ui.

that may be the latest already, if you run sudo apt update doers it update probe basic and qtpyvcp?

Excellent! do you have a build log somewhere on social media?

You should be able to program a 7I95 bit file (or one you created from source) directly
into the flash chip. Then re-program the user firmware and fallback via mesaflash over Ethernet
to fix the fallback/boot sector if you care about that feature.

A: All I/O pins are inputs unless selected for other use in the driver
(man hostmot2) or the hal file.

B: To program the firmware using mesaflash you would
download the firmware and then:

mesaflash --device 7i95t --addr [card_ip_address] --write 7i95t_5abobd.bin --reload

I would ask in the MesaCT section how to do this using MesaCT.

大家好，我正在尝试从 7i92 原理图构建 mesa 7i95。按照 7i95.ucf 的引脚文件进行构建，这是我的原理图  和我的印刷电路板 (PCB)  ,My problem is that there is no JTAG reserved on my PCB, so I can't use the programmer to write the firmware. Can anyone help me extract the firmware from the 25P16 Flash using a CH341?

Hi,

a. Does these have inputs in the firmware for the 5ABoB on p10, p11, p12, p13, p15?

b. Also please guide as how I can update this new firmware on the 7i95t using Mesa CT.
Your help will be truly be appreciated.

so far it looks like some mild rain. I hope it stays that way.
I have the live view going on my computer at work.
I don't log into my Youtube channel at work. So yes I am watching just not from my channel.

Overall it looks like you aren’t blowing the molten material out correctly, or the odd material type you mentioned is really bubbly when it oxidizes.  You really shouldn’t get that kind of dross on either the part or the sheet.

Two thoughts on things to check:

1.  Ive seen this in testing when the torch to material distance becomes too large.

2.  That material looks too thick for fine cut.  Try the same cut with 45amp nozzle using 45amp material speed settings.  Eventually if it works you'll have to re post to account for the different kerf width.  I was like you thinking that “fine cut” = greater precision.  It’s true but only in thin sheet metal.  For anything else, while there may be cut settings in the hypertherm manual, you should steer clear.  I’ve had better success with 45amp consumables and settings in materials similar to what you show.  The kerf width of the arc in conjunction with the thickness doesn’t allow the molten material any place to go.  And thus it can’t blow it away correctly.