Advanced Search

My observation is the fastest ioc32 data rate led blicks(more speed)
the numbers of encoder read go more crazy.

try adding to the INI:
[DISPLAY]
GRAPHICAL_MAX_FILE_SIZE = 40

i have options to push the poll rate even further with PIO&DMA + using the W5100s interrupt pin.I won't be bored for a few days.

You can low pass filter the outputs
Also for noise and stability I would

1. Run the pots from the 7I73s 3.3V if you can
(Since this is the 7I73s analog input reference the reading
will be ratiometric, so a change in the 3.3V will not change the reading)

2. Low pass filter the inputs at the 7I73 (say with a 0.1 uF capacitor to 7I73 ground)

3. Low pass filter the analog hal signal (a 1 LSB  dither is expected with almost any
A-D at least at some (halfway between) input levels)

That does not set the rate though, what I did for testing was:

                if (inst->hal->rate > .001) {
                    timer = 1e9 / inst->hal->rate;
                }  else {
                    timer = 1e9 / 1000;  # 1 ms
                }      
 
 

Those *.tmax times are in CPU clock cycles and probably OK
if the CPU is ~3 GHz

First thing, get some thermal paste to put on that processor, and the one before it, both are getting very hot doing not much, some Intel processors will start throttling at 63C, some a bit later, but nearly 70 you are getting seems to high with such medium load.

try this to mesa_modbus.c.tmpl i think works?

Yes, I would test at say a 100 Hz update rate.

I was just checking the 0.1 Hz update rate, as you said
it did not work, but it seems OK.

So if you can change the update rate from 0 to some positive number
while running and it keeps working, that indicates that at least one
divide by zero issue has been fixed.

The bad data error you have may be unrelated but the divide by zero fix
seems to have solved the very similar error finnengineering had with the stepgens


 

Yes works but it is practically unusable with 10sec intervals
also the problem of random data to encoder input it is unknown if resolves
completely or just happens in these long intervals and it is difficult to detect..
With update-hz set to 0.05 does not work.

i do not post it but i compiled my benchmark to windows also with nearly same results, so the pico is the bottleneck here.

i dont think all functions are able to handled with one pico, i have more time now for testing because the first PCB-s are only shipped on mar.23 and the components is in the coming week.

actually not using PIO now, the UDP data transfer runs on core0 and all io handling runs on the second core, i use the W5100s-evb-pico for the project with the wiznet library (using arduino ide) (for PIO testing i make a frequency generator (later stepgen) and send velocity from 1 of linuxcnc joint to it, it makes 2Mhz signal but dont have a fancy scope to find its jittering. Shock settled on my face, and a small smile appeared at the corner of my mouth when I saw the signal on the scope.

Looks promising. Many LinuxCNC hardware interfaces run at 1kHz, and that works fine for most purposes.
Are you using the PIOs to handle the communications? Maybe there are gains to be made there?

Does the Pi-Pico handle UDP natively?

With the new processor, latency seems better. But the test started without internet (I had a problem with the internet).

 

But it seems the main problem is the communication with the mesa card. Please see the attached picture.
I get this as soon as I start LinuxCNC. Why are ping times good, but in LinuxCNC it is so slow?