Advanced Search

If you still get random counts, that suggests a signal integrity issue of some kind (missing grounds?)

Unfortunately our normal analog input card (the 7I87) is out of stock currently

What voltage range, resolution and conversion speed do you need?
 

...small update , crossed wire tested unfortunately it don't help , but for EK1100 is as good as straight wire

System journal gives me huge amount of information so I filtered it a bit.

1), grzesiekzxr@grzesiekzxr:~$ sudo journalctl -k --since "1 hour ago"
lut 05 20:59:00 grzesiekzxr kernel: kauditd_printk_skb: 7 callbacks suppressed
lut 05 20:59:00 grzesiekzxr kernel: audit: type=1400 audit(1770321540.504:19): apparmor="DENIED" operation="capable" profile="/usr/sb>
lut 05 21:13:25 grzesiekzxr kernel: perf: interrupt took too long (2506 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
lines 1-3/3 (END)


2). grzesiekzxr@grzesiekzxr:~$ ip link show ens5f5 | head -1
2: ens5f5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000

 3). grzesiekzxr@grzesiekzxr:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
       
2: ens5f5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 20:cf:30:d0:44:90 brd ff:ff:ff:ff:ff:ff
    altname enp4s0f5
3: wls1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 48:5d:60:38:a0:16 brd ff:ff:ff:ff:ff:ff
    altname wlp2s0
    inet 10.10.0.245/24 brd 10.10.0.255 scope global dynamic noprefixroute wls1
       valid_lft 15791sec preferred_lft 15791sec
    inet6 fe80::9bf3:99e1:ddb1:dff3/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4).
 [    8.551591] ec_master: loading out-of-tree module taints kernel.
[    8.551932] ec_master: module verification failed: signature and/or required key missing - tainting kernel
[    8.585094] EtherCAT: Master driver 1.6.8 1.6.8.g2543cc5-1+27.2
[    8.588193] EtherCAT: 1 master waiting for devices.
[    8.615964] ec_generic: EtherCAT master generic Ethernet device module 1.6.8 1.6.8.g2543cc5-1+27.2
[    8.615982] EtherCAT: Accepting 20:CF:30laugh0:44:90 as main device for master 0.
[    8.615998] ec_generic: Binding socket to interface 2 (ens5f5).
[    8.628532] EtherCAT 0: Starting EtherCAT-IDLE thread.
[    8.851296] NET: Registered PF_QIPCRTR protocol family
[    9.216918] jme 0000:04:00.5 ens5f5: Link is down
[   10.623450] wls1: authenticate with fa:92:bf:2d:84:ad
[   10.623474] wls1: 80 MHz not supported, disabling VHT
[   10.637063] wls1: send auth to fa:92:bf:2d:84:ad (try 1/3)
[   10.642346] wls1: authenticated
[   10.644441] wls1: associate with fa:92:bf:2d:84:ad (try 1/3)
[   10.652255] wls1: RX AssocResp from fa:92:bf:2d:84:ad (capab=0x1431 status=0 aid=3)
[   10.652459] wls1: associated
[   10.652573] ath: EEPROM regdomain: 0x8268
[   10.652575] ath: EEPROM indicates we should expect a country code
[   10.652576] ath: doing EEPROM country->regdmn map search
[   10.652577] ath: country maps to regdmn code: 0x37
[   10.652578] ath: Country alpha2 being used: PL
[   10.652579] ath: Regpair used: 0x37
[   10.652580] ath: regdomain 0x8268 dynamically updated by country element
[   10.732760] wls1: Limiting TX power to 20 (20 - 0) dBm as advertised by fa:92:bf:2d:84:ad
[   10.756660] IPv6: ADDRCONF(NETDEV_CHANGE): wls1: link becomes ready
[   27.921396] systemd-journald[308]: File /var/log/journal/9eae89433bf9430392b319dc655b4150/user-1000.journal corrupted or uncleanly shut down, renaming and replacing.
[  312.070512] kauditd_printk_skb: 7 callbacks suppressed
[  312.070518] audit: type=1400 audit(1770321540.504:19): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=1611 comm="cupsd" capability=12  capname="net_admin"
[ 1177.039546] perf: interrupt took too long (2506 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
[ 1508.389389] perf: interrupt took too long (3140 > 3132), lowering kernel.perf_event_max_sample_rate to 63500
[ 1879.795443] perf: interrupt took too long (3927 > 3925), lowering kernel.perf_event_max_sample_rate to 50750

The most obviousand suprising me  thing is that led closed to rj45 is not lit and not flashing while connect to OrientalMotor but when beckhoff is wired firstly led is lit and when comunication start is flashing what is what I expected.
Maybe I should try on another pc ? 
Thanks a lot for Your patience. 




 

Hi PCW,

The filter is already by default set to true. Suggest any other troubleshoot method for the same. 
Or suggest me a daughter board having analog input output pin

Progress!

You forgot the two first lines from that example cia402.hal

My head is still spinning from all the trouble I went through to revive this board.

Looking back now, I can say it was relatively easy—I just had to learn a lot in a short amount of time.

Thank you for your patience and support.

I truly can’t thank you enough.

Okay so i commented out the 2 1014's then 2 2004 now i get a servo thread not found so i attached all files and the log again

Hakan wrote:

Its definitely a performance parameter for this drive. Maybe it isn't on their matched motors. NWE can confirm on his mother's eventually.
But you have given me a thought. If I changed parameters that I expected to get max velocity from 2000 m/m to 20000 mm/min and only got 8500 mm/min, I should be able to increase the step count from 1000 now without loosing performance.

Another thought I had which we can't do on this drive is on those machines with a torque reduction pdo, we could replicate what my step boost component does which is to reduce the torque (well curent in that case) when the motor is not accellerating to allow the motor to cool when not working hard. I used 50% current reduction but the maths indicates you can go a lot lower perhaps as low as 10-15%) This gives a massive performance improvement

Okay, cool. Let us know if you try it out. Maybe you could check if its the same for you as for me when trying to jog while running gcode prior to updating the xhc-whb04b-6 component. The pendant always disconnects in that situation for me.

IndeeSales wrote:

yes I dont know what keeps happening I have registered 3 times in 72hrs.

Yes, i have noticed that, hence my question, but i think you should be clear from now on, based on what i gather this happens when there is a single post from a member in a certain timeframe and might be due to automation set to disable spammer accounts.

_usually_ CR343 will protect the rest of the card from overvoltages

CR43 is (or was) a SMBJ5V0 TVS diode across the 5V supply
 

You need to install a user configuration (the fallback configuration has no modules except GPIO):

mesaflash --device 7i95t --addr 192.168.1.121 --write  7i95t_d.bin 

(7i95t_d.bin  is from the 7i95t.zip file in configs/hostmot2)

Once this is done, you can set the IP select jumpers to DOWN,DOWN (192.168.1.121)
or DOWN,UP (10.10.10.10)
 

I remember you mention something about the dpll?

I was trying to create a machine to test the borad

Debug file information:
Note: Using POSIX realtime
./main.hal:37: parameter or pin 'hm2_7i95.0.dpll.01.timer-us' not found
22938
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

The computer screen, with the g-code trace. 
I have some user macro buttons, they are on the screen in Man but are removed in Auto and the trace window is resized.
I agree with the too long blocking diagnose, sounds exactly like the problem.
I'll try that tomorrow, it would be great to get a fix.

Do you means when the computer screen re-organizes? Or the pendant screen?

I found that if I try to jog when a g-code program is running, the pendant will disconnect every time. The reason is too long blocking (like I mentioned in the first post) without USB polling. The pendant will request manual/teleop mode (I don't recall which) and wait for minimum 300 ms if the mode does not change. It's these two functions:
github.com/LinuxCNC/linuxcnc/blob/master...6/hal.cc#L1361-L1420
I solved this issue by reducing the "loops" parameters here:
github.com/LinuxCNC/linuxcnc/blob/master...b04b-6/hal.h#L71-L86
Maybe your issue could be because of the same reason?

Still, if I use the mill for an hour or so, the pendant is likely to disconnect. And I have not found any specific reason for that yet.

There it is.

 

The problem is with your slave 5, the EL1014.
Can it be that it is a very old version? They had a different PDO mapping.

Can you temporarily remove or comment out slave idx=5 and see if you 
come any further?
We can come back to how to fix it for the EL1014.
Well, it is to run lcec_configgen with the option, "lcec_configgen --typedb=false"
and then take the info for slave 5 from that output.