I cannot get the isolcpus command line to take effect.  I have set the grub to the following:
savedefault
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
search --no-floppy --fs-uuid --set=root a08bfa77-56e1-4ee2-a80a-ccc22b8725cd
echo    'Loading Linux 6.3.0-rt11-linuxcnc ...'
linux    /boot/vmlinuz-6.3.0-rt11-linuxcnc root=UUID=a08bfa77-56e1-4ee2-a80a-ccc22b8725cd ro initrd=/install/gtk/initrd.gz 
echo    'Loading initial ramdisk ...'
initrd    /boot/initrd.img-6.3.0-rt11-linuxcnc
GRUB_CMDLINE_LINUX_DEFAULT="isocpus=3"

And have changed the last line to 0,1,2 to 0, to 1, and to 2 with no effect.  The histograms show 4 cores no_isolcpus.
This is an intel i5-6500t.
Any ideas?


 

But will it make any sense at all to try to configure the setup as long as I get an “unsupported board”

A little about the background for the project.
I have over time -as a side business - made several retrofits of older (woodworking)cnc machines
Normally I change the driveline to new hybrid steppers controlled by a plc with a control sw developed by ourselves (or in a few projects Mach 3&4), but in this project I have a huge 7ton Homag with very powerful Rexroth motors and drives where i have modified the drives to analog control.
Therefore I went for a LinuxCNC and a mesa 7i97T.
I accept there is a learning curve but it has been far more complex than expected.

I’m surprised about how many YouTubes are found about “LinuxCNC as easy as Mach3” a statement I have hard to believe unless you have 20 years of Linux behind you

NWE wrote:

I'm interested in trying this out. Where can I get the Arduino source code?

You can find everything here: Project Home & Documentation:  bobwolfrst.github.io/io_decoder-linuxCNC/demo_mode.en

Direct Download (.zip):
github.com/bobwolfrst/io_decoder-linuxCN..._decoder_eval-v1.zip

ciao
Roberto

@grandixximo

Very good work!
I've started testing.
I've noticed that the track speed is very low with G2/G3, but significantly higher with G64 Pxx.

More tomorrow.

Here's what I came up with for my Mill's Y-axis saddle.  Much simpler than running grease/oil lines to a central lubrication pump...make them just long enough for easy access.

• Hose is Kynar (PVDF), I believe 4mm OD
  • any fluoro-polymer hose/tube should be fine (PTFE, ETFE, etc), stay away from anything else.
• Fittings are just cheap air-hose push-to-connect (same as 3D printer filament tube size)
  • The cheap push-to-connect o-rings will likely fail after some years, but it'll be obvious when it happens and I have a dozen or so spare fittings
  • Drill out the PTC fitting to remove any unnecessary constrictions (it's surprising how small the ID is)
  • The fittings on the actual trucks are compression w/ferrules, so no o-rings to worry about
• Manifold is a really kludged DIY thing - drilled/tapped for the fittings
  • it's not actually a manifold... each port is separate
• I'm using NLGI #1, no moly.  Any thicker (or much longer hoses) and I'd run the risk of a hose popping out of a fitting.

Z-axis has a similar 'remote fill' system as the Y-axis.

Couple pumps 3-4 times a year (low use machine) and no issues since installed.

As I've 2 lan cards (the onboard and a second PCI board), I tried to launch when connected to both, and this is what I get:
connected to Mesa (onboard card): and pinging  my router:

connected to WEB: and pinging my router:
I've attached a screenshot of my desktop showing the lan connection window

My current version is 3.4.9

What version of mesaflash are you using ?

forum.linuxcnc.org/27-driver-boards/5285...-by-mesaflash#302114

Maybe of some help

Aciera wrote:

Sounds all sensible to me but I really don't feel competent to comment on the proposed path.
I certainly like the structured approach of your initiative, that is something that has been sorely lacking in other attempts.
I think/hope that Rob will be able to give an educated opinion on it and shape it into a concrete roadmap.

Note that Mitsubishi SSCNET requires a servo cycle <= 222us
forum.linuxcnc.org/9-installing-linuxcnc...cnet?start=70#256576
 
defenetly is great to have something faster then 1ms .. ethercat can run at 50us with 16axis but this complex calculations are far slower for now 

I think 250us is very pretty goal (common industrial standard) at any hardware and then reduce it based at used hardware 


Note than many ethercat drives are also limited to 1khz in position mode. lichuan is, stepperonline/jss i think is and Im pretty sure the delta b3 is. My omrons I think are restricted to 2khz in csp mode.

For 4khz or 8khz usually you are restricted to other modes. At least in the drives I have. There definitely are (much) faster ones, but they are more specialised gear vs generic milling cnc applications.

Point being, 250us sounds great, but I don't know it needs to be any sort of priority cause only few people could use it. But then maybe those few people are important (like the people I know wanting to nanometer scale optical things and MUST have the higher "loop" speed so can't entertain linuxcnc right now)
 

You are right, I agree with you 100%, main goal is get lcnc with curves at 1khz ... Timig is very wide and difficult topic but faster code means more play to some latency or timig issues of something, stability, rigidity etc...

I think it is reachable timing .. faster tick means better final result of movement and better regulation feedback with velocity or current control.. 

Then we can say isolated cpu to sleep if it will runs at longer timing then 250us .. finally we can use more masters at other network interface to run it with different timing if it is needed and then let cpu to sleep

I think Luca's goal are very very well definied .. from my point of view there is missing just pos(t+1) or pos(t-1) for position commands to any drivers which is not using the velocity setpoint(its cosmetic to not see the ferror during movement with position setpoint)

We can runs 16khz with beckhoff but there is latency restictions... for now... I am running 0.5khz with profibus equidistant and it works well but with trapeziodal its was pain.. now with scurve its smooth like butter... lower timing than 1khz are for gentelmen which they know what they are doing.. its advanced I think

Here are some (random) results

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.124 ms
64 bytes from 10.10.10.10: icmp_seq=2 ttl=64 time=0.089 ms
64 bytes from 10.10.10.10: icmp_seq=3 ttl=64 time=0.092 ms
64 bytes from 10.10.10.10: icmp_seq=4 ttl=64 time=0.096 ms
^C
--- 10.10.10.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3060ms
rtt min/avg/max/mdev = 0.089/0.100/0.124/0.013 ms

---

mesaflash --device ethernet --addr 10.10.10.10 --readhmid
No ETHERNET board found

---

ls /lib/firmware/hm2/
3x20-1 4i65 4i68 5i20 5i22 5i22-1 5i22-1.5 5i23 7i43 7i43-2 7i43-4 7i97t_d.bin

---

mesaflash --device ethernet --addr 10.10.10.10 --readhmid
Unsupported ethernet device 7I97T at 10.10.10.10
No ETHERNET board found

I'm a little unconvinced how changing to USB would have an affect on the "wiring nightmare or EMI issues".

On my machine, I have a 30ft active USB cable going from the control box to the spindle mount (it's for a camera, but I have other wires up there for other things and the cable chain is getting full).  I could see a use for another going to the tool rack (it's on the far side of the machine wrt the control box) for monitoring the pockets etc .  It's no different than running 24V and RS422 between Mesa cards, or ethernet/ethercat, but with hubs and latency
As for noise, I imagine cases where replacing "home runs" to sensors with a single USB cable with CRCs would prevent some EMI spikes from triggering faults.
As always, we each have different needs and having a wide range of options available is good
 

Correct me if im wrong here but as far as im informed there will be no ini nor hal file before the configuration?
Since im not there yet i have none of them - or at least from what i can see
I can ping the board and mesaflash sees it but thats about it.

I'm really curious to hear if my setup with a Linuxcnc and a mesa 7i97T is a dead end street. If so I would rather stop now and go back to my safe world of PLCs and Mach

baking...