Advanced Search

Yes, buying the 7i76e might be a good idea, but its difficult to get (out of stock everywhere) and i would wish to not need to rewire anything and configure.

Of course I could ask or look for a pc setup that works 100% with the newest rtai kernel and buy the same hardware, but its just strange that I cannot get that machine that worked really well with wheezy not working on debian 12.

On tomorrow i will try a couple more bios settings but all energy saving functions are disabled and I know I didn't had to fix so many things to get a jitter of about 8000.

@tommylight: this I have solved already and the machine sounds and works by jogging perfectly fine now, but I still get unexpected realtime error on task 1 on start up.

Currently I mostly do changes in the cpu ratio and other cpu settings like cpu bus frequency and if I setup a wrong value, lets say, cpu frequency 165 instead of 120 then the machine might make that strange movement, smooth but not all the time.

I attach 2 pictures of one windows screen (tweaker), so that you see the options. That are not anymore the current settings. Tomorrow I can show pictures of the other options available but I am sure it's setup correct.

In grub config I have only what was already there: "quiet" and I added "isolcpus=5" to it. I believe with wheezy I had isolcpus=1,2,34,5, but I am not sure anymore.
The cpu is a amd phenom ii x6 1055t.

Thanks for chiming in. I'm hopeful that this is not the solution I'm after. My goal is to convert these signals within LinuxCNC using something like the BLDC HAL component or something of that nature then spitting out the results via some of my available outputs on my Mesa cards. Surely Hopefully it can be done in HAL and not need an external converter board. These PICO boards would hurt the wallet too much as well, 600USD for 4 that's 850CAD and that's about half of my net worth

#machineShopOnAShoestring

I would recommend your 7i76e option you mentioned in your first post.

Wheezy is far too old to expect stuff to still work. its well past end of life
Whilst the linuxcnc guys have done an amazing job keeping RTAI working for all these years its also past end of life.
Without the Linuxcnc devs, RTAI would not exist today.
Preempt_RT has won the real time wars.
If the default Linuxcnc ISO works reliably for you, it will work with a 7i76e

But like any modern OS, things are more complicated today and there are a number of optimisations I cover here
docs.google.com/document/d/1jeV_4VKzVmOI...diY/edit?usp=sharing
 

Hello PCW,
I checked the hm2_7i76e.0.packet-error-total and got 57 errors about 45 minutes. Is this too much?

I don't understand these packet losses - (my PC is a lenovo ThinkCentre M92p Mini-PC, Intel Core i5-3470T 2.90 GHz 8GB Ram, in the latency Test I get readings as shown in the photos, first at start, Servo 4000, Base 5608, after 30 minutes surfing, coding in Vcode, doing sth else: servo 82040, Base 24542, I set servo thread in the INI file to 1.600.000.
Kernel release 6.1.0-29-rt-amd64, Kernel Version #1 SMP PREEMPT_RT Debian 6.1.123-1 (2025-01-02)
What do you think?

I did the most Latency tips in this thread: forum.linuxcnc.org/38-general-linuxcnc-q...ead-and-irq-affinity - I disabled hyperthreading, power saving, virtualisation, TPM, turbo mode, ACPI, APM, Audio,, kernel isolate core 0 for interrupts - quiet irqaffinity=0 isolcpus=0. I bought a new network controller with RTL_8125 chip,  optimize my network connection with sudo ethtool -C eno1 rx-usecs 0 at any system start. Kernel release 6.1.0-29-rt-amd64, Kernel Version #1 SMP PREEMPT_RT Debian 6.1.123-1 (2025-01-02)

Anyways, I dont have servo motors with encoders wired to the MEsa 7i76e, so I cannot calibrate in live mode. I just set the FF2 to 0.0003 as you said. Same results as yesterday, not often but sometimes i get that motor-0-position errors.
Maybe my PC is too slow for a Linux system? Any suggestions?
Thank you so much for your support!
Hanno
(For some reason, I cannot put photos <1MB in this thread...)

The 7I76EU (and 7I76U) have 3 new parameters and the 7I84U has 2 new parameters

The main 2 added parameters are 7i76.[port].[chan].output_source and 7i76.[port].[chan].output_sink. or
7i84.[port].[chan].output_source and 7I84.[port].[chan].output_sink. These are 16 bit masks
that control the field output mode. Each xxxx.output_source  bit controls the source attribute
of the corresponding output bit and each xxxx.output_sink bit controls the sink attribute. The
default setting is for all source mode (xxxx.output_source = 65535 or 0xFFFF, xxxx.output_sink
= 0 or 0x0000) which means a 7I76EU, 7I76U or 7I84U behave like a 7I76E,7I76 or 7I84.

So for example:

xxxx.output_sink = 0 = 0x0000
xxxx.output_source = 65535 =0xFFFF
 = normal all sourcing mode (like 7I76E, 7I76,7I84, this is the default)

xxxx.output_sink = 65536 =0xFFFF
xxxx.output_source = 0 = 0x0000
 =  all sinking mode  (like 7I76ED,7I76D,7I84D)

xxxx.output_sink = 65280 =0xFF00
xxxx.output_source = 255 = 0x00FF
= outputs 0..7 are sourcing mode, outputs 8..15 are sinking mode

xxxx.output_sink = 65535 =0xFFFF
xxxx.output_source = 65535 = 0xFFFF
= all outputs are in push-pull mode

Note that each of the 16 output bits can be individually setup for
sourcing, sinking, or push-pull mode.

The 7I76EU and 7I76U also have a spinmode parameter to set the spindle output
bit mode when this is 0 (default) the isolated spindle output bits are ENA and DIR as before.
If the spindle mode bit is set to 1 , the isolated spindle output bits now function
as FWD and REV.


 

bnet wrote:

My other option would be to output TTL incremental encoder pulses from LinuxCNC (is this conversion from absolute serial encoder data to TTL incremental possible?)
 

Yes, Pico Systems makes a board that converts most Fanuc serial pulse coders to quadrature with index and commutation signals.  One detail to note is that with high-resolution encoders, the quadrature count rate can become very high.  Another detail is that these encoders can't be interrogated faster than 8 KHz.  See : picosystems.store/product/fanuc-serial-e...nverter-pulse-coder/  for more details.
Jon

I've added support for the 7i76EU, just need to figure out what features it has over the 7i76E. Good to know the pin names are the same.

JT

My other option would be to output TTL incremental encoder pulses from LinuxCNC (is this conversion from absolute serial encoder data to TTL incremental possible?) out via the 7i84 into the Allen-Bradley Ultra3000s.. I'm starting to think that this is more of a failsafe path because its unclear if the drives will run motors on commutation signals alone. Here's a look at the manual pages regarding [standard] feedback into the Ultra3000s.  

 


Thoughts and speculations welcomed and encouraged. 

Yes, 7I76E hal and ini files will work with a 7I76EU.

The added 7I76EU features (output modes and spindle mode)
would not be supported, but these are just controlled by parameters
that  can be setp'ed in the hal file.

The firmware files are however different

Appreciate the prompt action, I also got a reply from the Mesa folks that you can select and build configs with 7i76E as well.

-Aren

Thanks for that.
I believe that what Rodw wrote is the reason why i could not anymore open the shared folder, but its funny that in short time this stopped working, as well as the internet browser and also OneDrive setup on wheezy.

The solution is to edit the SMB policy on your windows box and it works perfectly.

I am not expecting that you write me a tutrorial how to get it work, but if you have a simple tutorial, please send me a link. If the new radeon vga will not solve the latency problem, but i will know that i can setup samba on wheezy, then i will do it. If not, i buy the mesa 7i92TF or 7i76e.

7i76EU has been added to Mesa CT just now. I've not tested the configuration yet.

JT

Is there any readme on how to add .bin files for a new board to this? I have the Mesa 7i76eu, successor to the 7i76e, and have downloaded the firmware files from the mesa site but am unsure of how to add them to the configuration tool.

Any help is appreciated,
-Aren

I think its unlikely that you would need so much DPLL pre-trigger so I don't think
increasinh this timr to 250 usec is going to help

I would check hm2_7i76e.0.packet-error-total to see if you have dropped any packets

You might try plotting the following error and perhaps tuning by adding a little
FF2 (say .0003 to start) to the PID loop (using the calibrate menu so you can do this live)

Hello again!
Today, I tried my machine out with a new .ngc file for a part to mill, and while testing in the air, although with reduced G0 to 5500mm/min, I got the "motor-0-position error" again.
So, I changed the setp hm2_7i76e.0.dpll.01.timer-us -200 to 250. The next run comes without the error. But i am sceptical - how far can I go with this or should I change othere settings too?
WHat about the min Ferror - i had 0,01mm is this too much, should i go to 0,1?

Thanks for any answer!
Kind regards,
Hanno