Advanced Search

CPU is as follows:
==================================================
raycnc1@debian:~/Desktop$ lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         39 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  2
  On-line CPU(s) list:   0,1
Vendor ID:               GenuineIntel
  Model name:            Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz
    CPU family:          6
    Model:               94
    Thread(s) per core:  1
    Core(s) per socket:  2
    Socket(s):           1
    Stepping:            3
    CPU(s) scaling MHz:  100%
    CPU max MHz:         3200.0000
    CPU min MHz:         800.0000
    BogoMIPS:            6399.96
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mc
                         a cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss
                         ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art
                          arch_perfmon pebs bts rep_good nopl xtopology nonstop_
                         tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cp
                         l vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1
                          sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsav
                         e avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault
                          invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnm
                         i flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1
                          avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflus
                         hopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ara
                         t pln pts hwp hwp_notify hwp_act_window hwp_epp md_clea
                         r flush_l1d arch_capabilities
Virtualization features:
  Virtualization:        VT-x
Caches (sum of all):     
  L1d:                   64 KiB (2 instances)
  L1i:                   64 KiB (2 instances)
  L2:                    512 KiB (2 instances)
  L3:                    3 MiB (1 instance)
NUMA:                    
  NUMA node(s):          1
  NUMA node0 CPU(s):     0,1
Vulnerabilities:         
  Gather data sampling:  Vulnerable: No microcode
  Itlb multihit:         KVM: Mitigation: VMX disabled
  L1tf:                  Mitigation; PTE Inversion; VMX conditional cache flushe
                         s, SMT disabled
  Mds:                   Mitigation; Clear CPU buffers; SMT disabled
  Meltdown:              Mitigation; PTI
  Mmio stale data:       Mitigation; Clear CPU buffers; SMT disabled
  Retbleed:              Mitigation; IBRS
  Spec rstack overflow:  Not affected
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer
                          sanitization
  Spectre v2:            Mitigation; IBRS, IBPB conditional, RSB filling, PBRSB-
                         eIBRS Not affected
  Srbds:                 Mitigation; Microcode
  Tsx async abort:       Not affected
raycnc1@debian:~/Desktop$
=======================================================
I did some  test as follows:
=======================================================
raycnc1@debian:~/Desktop$ lshw -class network
bash: lshw: command not found

raycnc1@debian:~/Desktop$ lspci | egrep -i 'network|ethernet'
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 16)


raycnc1@debian:~/Desktop$ ping -i .2 -c 4 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
64 bytes from 10.10.10.10: icmp_seq=1 ttl=64 time=0.118 ms
64 bytes from 10.10.10.10: icmp_seq=2 ttl=64 time=0.065 ms
64 bytes from 10.10.10.10: icmp_seq=3 ttl=64 time=0.063 ms
64 bytes from 10.10.10.10: icmp_seq=4 ttl=64 time=0.063 ms

--- 10.10.10.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 609ms
rtt min/avg/max/mdev = 0.063/0.077/0.118/0.023 ms
raycnc1@debian:~/Desktop$ sudo chrt 99 ping -i .001 -q 10.10.10.10
[sudo] password for raycnc1:
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.

--- 10.10.10.10 ping statistics ---
246632 packets transmitted, 246631 received, 0.000405462% packet loss, time 248878ms
rtt min/avg/max/mdev = 0.046/0.049/0.102/0.003 ms
^C
raycnc1@debian:~/Desktop$

raycnc1@debian:~/Desktop$ ping 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
64 bytes from 10.10.10.10: icmp_seq=1 ttl=64 time=0.078 ms
64 bytes from 10.10.10.10: icmp_seq=2 ttl=64 time=0.078 ms
64 bytes from 10.10.10.10: icmp_seq=3 ttl=64 time=0.063 ms
64 bytes from 10.10.10.10: icmp_seq=4 ttl=64 time=0.070 ms
64 bytes from 10.10.10.10: icmp_seq=5 ttl=64 time=0.063 ms
64 bytes from 10.10.10.10: icmp_seq=6 ttl=64 time=0.073 ms
64 bytes from 10.10.10.10: icmp_seq=7 ttl=64 time=0.065 ms
64 bytes from 10.10.10.10: icmp_seq=8 ttl=64 time=0.063 ms
64 bytes from 10.10.10.10: icmp_seq=9 ttl=64 time=0.063 ms
64 bytes from 10.10.10.10: icmp_seq=10 ttl=64 time=0.063 ms
^C
--- 10.10.10.10 ping statistics ---
338 packets transmitted, 338 received, 0% packet loss, time 345086ms
rtt min/avg/max/mdev = 0.062/0.066/0.152/0.007 ms
raycnc1@debian:~/Desktop$

============================================================


Please confirm whether this CPU can be used or not.

I need a reliable performance and that is the ultimate goal.

emc/task/emctask.cc 68: interp_error: remap_finished: got -6 - not in cblock.remappings!
remap_finished: got -6 - not in cblock.remappings!
/home/jake/linuxcnc/configs/Lathatron2-9/Lathatron2-9.ini:66: executing 'import sys
sys.path.insert(0,"/home/jake/linuxcnc/python")'
/home/jake/linuxcnc/configs/Lathatron2-9/Lathatron2-9.ini:68: executing 'import sys
sys.path.append("/home/jake/linuxcnc/python")'

Hi all

Just to let you know I have found out how to set the jog speed (well a good good way of doing it at least) by looking at this page...
forum.linuxcnc.org/47-hal-examples/52414...d-joystick-struggles

Does anybody have any ideas on how I can activate the tool touch probe?

Thanks
Alex

compiling should not be necessary. This should do it.
sudo apt update
sudo apt upgrade

2.93 image working just fine with Raspberry Pi 4B 8GB and Mesa 7C80 - right from scratch - great!

Can you measure the voltage from DIR+ to drive common in both spindle directions?

Oh good grief!
In my troubleshooting, I configured the axis limits a few different ways. The Z axis was setup originally with 14 as max, and 0 as min. That worked fine, but to align with convention I switched to 0 as max, and -14 as min. On the X axis, the Search and Latch velocity are both negative, which makes sense as the table moves in the negative direction towards zero to find the switch. The Z and Y axes need to go the other way so the Search and Latch are positive. It kind of made sense looking at it that the Final Velocity should be the opposite direction of the Search and Latch. Kind of thought there might be a configuration out there where this was what you wanted.
I also could have sworn that I tried changing the sign on the final velocity number just to see what it would do.

All works fine now! DOH.

DIR- and ENA- are wired to the spindle common.
NC is wired to spindle foward
NO is wired to spindle reverse

jim

linuxcnc.org/docs/html/config/ini-homing.html#_home_final_vel
It clearly states the value must be positive, you have them negative for both joints/axis in question.

'HOME_FINAL_VEL' must be a positive number.

Velocity in machine units per second from home latch position to home position. If left at 0 or not included in the joint rapid velocity is used. Must be a positive number.

linuxcnc.org/docs/html/config/ini-config...ub:ini:sec:joint-num

I feel we should try to glean some more information about why it fails in the first place.
Not sure if this will work as I cannot test on this machine but in the 'index_lathe_tool_with_wear' function replace:


with this:



Then run again from the terminal and check the output for the above error message, which will hopefully relay the actual error.

On my PM-940V mill  I have the pretty standard single limit/home switch at the top of the column.  The Y axis home/limit switch is placed at the position where the bed is closest to the operator (min Y).  The joints home just fine, however the Y and Z axes move at the joint limit velocity to the final home position.  The X axis does not. So the Z axis for example slowly goes up the column, hits the limit switch, backs off, then slowly approaches the limit switch one final time, then rips into high gear and moves down half an inch to the home position.  Similar with the Y axis.

The documentation mentions that if you do not have HOME_FINAL_VELOCITY declared, it will use the joint limit speed. Mine are all configured the exact same way.  The axes all move the proper directions with the jog plus/minus, code runs fine.  I configured the machine using STEPCNF, and the homing worked right from the beginning. Just an issue with the final velocity.

Attached are the .ini and HAL files.  Your thoughts are welcome!

Jeff

 

forum.linuxcnc.org/27-driver-boards/47739-step-unit-calculator

excel tab for calculate steps`` maybe it can help.

No.
1000PPR is way to much for parallel port, 100PPR might be usable.
If you can, get e Mesa 7i96S, it is really worth every penny.

250 RPM is 4.166 RPS so that's a count period of 60 usec
at 1000 PPR = 4000 counts per turn. This is 1/2 the
maximum possible  count rate at a 30 usec base thread
sample period but:

1. Quadrature is never perfect square waves so the pulses may
be narrower than expected.

2. The 30 usec base thread period has jitter added so the sample
period may be considerably longer when you add latency spikes,

So basically the base thread rate will limit the maximum countable
RPM especially on higher resolution encoders.