Advanced Search

Hahaha I look stupid, I thought "our solar system" you meant the solar system, some kind of weird google translation. Not a solar inverter as mentioned later.

You have my permission to make as much fun at my expense as you feel necessary. I honestly feel I deserve it.

Sorry if you thought I was making fun of you. Please accept my apologies.

I'm thinking more it's a bad filter cap and a rough infeed from the 3phase fronius solar inverter. It does bump the voltage up.

I'd look at a component heating issue first. Maybe just below "bad things" when it's not sunny outside, and pushed over the edge when it's sunny outside.
TBH honest the sun is huge, like really huge current thinking has it at 99.8% of the TOTAL mass of the solar system, all the planets and sundry matter make up 0.2% of the solar system (and our sun isn't all that big). And whether it's sunny or not outside it's still fusing ~600 million tonnes of Hydrogen per second into ~596 million tonnes of helium, thus fusing continues (element by element) until all that is left is iron, then we die, and being twisted by magnetic fields and the rest. So basically it's always on, doing what the sun does best fussing atoms into other atoms, generating heat and all manner of electromagnetic radiation.

I'm pretty sure if the ripple was being caused by the solar system you'd be noticing many many more items playing up.

But if you really want to check on the cosmic microwave background grab an old CRT tv, turn it on and turn to a channel that has no terrestrial signal, it'll give a reasonable idea of the radiation around. That's what a small part of the static is.

Ripple should not make too much difference, you might plot the bus voltage in halscope
to see if there's anything suspicious.

It should be fixed in that version:

forum.linuxcnc.org/plasmac/53657-holes-3...iour?start=20#308841

But probably you should try updating.

I will try to make some time to have a play with your CAM code.

After many -many many hours of having problems with random following errors in finally have found something that links. 
so, when it's not sunny outside the voltage i read on the 8i20 card is 315v dc. When the sun is in full swing it reads 325v dc. This doesn't seem to relate to anything I know, but I have no errors when the sun isn't doing much,  and  plenty when it is, I'm thinking that there is probably some induced ripple from our solar system,  and the dodgy fanuc power supply im using probably has a bad cap. Any ideas ???

The above link/post does not fix the issue, so try thisStill needs those two lines from the middle of the above linked post.

Could we make this a sticky.

Fix for RPi-firmware errors see this post:
forum.linuxcnc.org/9-installing-linuxcnc...-64?start=110#290282

forum.linuxcnc.org/9-installing-linuxcnc...-64?start=110#290282

Has the fix.

On the 7I96S there are 4 MPG channels built in with any standard firmware
These use the isolated inputs 0..7 but do not interfere with normal input use.

The count pins on the isolated I/O are:

hm2_7i96s.0.inm.00.enc0-count
hm2_7i96s.0.inm.00.enc1-count
hm2_7i96s.0.inm.00.enc2-count
hm2_7i96s.0.inm.00.enc3-count

There is also 7I96S firmware that puts MPG encoders on P1:

7i96sd_mpgp1.bin

Its MPG encoder count pins on P1 are:

hm2_7i96s.0.inm.01.enc0-count
hm2_7i96s.0.inm.01.enc1-count
hm2_7i96s.0.inm.01.enc2-count
hm2_7i96s.0.inm.01.enc3-count

These are additional to the MPG inputs available on the isolated I/O

If you are using buttons/MPG on P1, the  7i96sd_mpgp1.bin
is probably the best as it also uses the INM module so has built-in
debounce on all inputs.

1. What Ethernet chip does the host PC have?

2. What is the result of running:

sudo chrt 99 ping -i .001 -q -c 60000 [fpga_card_ip_address]

[fpga_card_ip_address] = 10.10.10.10 or 192.168.1.121 depending on card setup

The command will run for 1 minute and print Ethernet timing statistics

I ask about the Ethernet chip type because more recent kernels have a Realtek driver
that has terrible real time performance and must typically be replaced by the DKMS
driver.

 I just tried to force back with Synaptic Package Manager, and got an error.see attached.

For some time now I've enjoyed a stable system created using the LinuxCNC 2.8.2 Debian 10 PREEMPT-RT ISO.   But now that I've upgraded to Debian 12 (I wanted to install a package unrelated to LinuxCNC, and the Debian 10 repository is no longer supported), things have fallen apart.  After the transition, LinuxCNC was still present, but it would not launch.  I assumed that this was because it had run in kernel space in my original system and so was treated specially (e.g. executable not in "bin").  Was this so?  In any case I installed linux-uspace.  It launches as expected, but unfortunately produces a string of error pop-ups:  "Smart Serial Port 0: Dolt not cleared from previous servo thread", "Error finishing read", and so on.

The hardware and BIOS are exactly as they were when things worked perfectly. LinuxCNC is 2.9.5 and the kernel is 6.1.0_39_rt_amd64.  Pinging the Mesa card gives consistent times of .125msec.  The latency looks generally  reasonable, but the histograms show a significant number of extreme outliers (???).

 

Can anybody help?  I feel that its probably a case of some option not being set correctly (i.e. the kernel isn't really pre-empting, LinuxCNC doesn't have the highest priority, or something such).  What might be missing somewhere in some configuration file?

There's also a little matter of the Axis window not maximizing, but this is a relatively minor concern.

 

Okay, so would the equivalent allow it to become operational?
Do you have a little more guidance as to what I'm looking for, because I still don't really understand what I'm looking at or for. I have a list of seemingly all of this drives pdos/sdos and their descriptions.
The manual says the drives conform to CiA402, but I don't know what all that standard includes-I assume based on your comment that the registers are separate from the standard?

Thanks Rod

When AI reports info from a post of mine on the forum, you know it at best is only superficial.
There is an example in the docs on a mpg using an encoder. It is easy to convert to a Mesa MPG encoder input but I think on the 7i96s you need extra firmware from mesa web site and forgo some I/O pins.