Advanced Search

I start with 0.1 in hal file setting and does not work
if change it to 0 from halshow starts working but encoder reads crazy data.
Also if change functions order in vhdl pin file changes affected encoder number and pins.
Seems to be bug in vhdl because the functions order affects the encoder that is affected
in one config affected encoder.00.input-a and b
and in other config encoder.04.velocity and count.
Also when modbus device working the encoder reads crazy data when not working
by removing power supply/unwiring or stop it by setting update-hz to non zero
the same time stops the problem to encoder.
Seems like electric noise problem internaly in fpga
The same module works ok with mb2hal so it is not the module

Sure, no problem

Hi Pierre,

Thanks for your contribution. It's alway's nice to get a few compliments so now and then.

Hi Fabian,

this is awsome, good work.
Thanks Fabian. Coding is going in the good direction.

Regarding the ringbuffer, did you already try a code with lots of tiny segments?
Yes we have a file with tiny segments : spiral_on_surface_0001.ngc
This file is the extreme example of tiny segments.

Concern 1:
When running this file, indeed there is a velocity point where the cnc can't keep up when using endvel>0.
But i have to test this when the codebase is ready to do this.
When using tiny clothoid fits, it will take less time to fit then 25ms. I will report fit times using a low G64 P[x] value.

Concern 2:
The concern is that the motion can just ignore (jumps over) tiny segments at high speeds.
The speeds are so high, one servo cycle moves more distance then the underlying segments.
Wich result in for example passing 4 segments at one servo cycle.

But also this concern has to be tested when code is ready to rock and roll.
In theory we could calculate if we are dealing with scenario's as above and propose a solution for this.

You could set conditions like : the planner should at least pass each segment for minimal 1 servo cycle.

In general, soon we can test above concern's and find a solution.

Ringbuffer info:
Regarding the ringbuffer, the lowest working size i now use is 10 segments.
The expected size to use is around 40 or 50 segments.

1. At program start the ringbuffer is allowed to add segments up to 5 at once.
2. Then with every move a new segment is added. These new added segments are in this case 5 segments in the future The clothoid fit is done when the segment is added.
3. Now the ringbuffer is rotating around 10 segments. So it was important to get it work correctly. To not
   overwrite non executed segments for example. And it must run until program is completed.
4. When the ringbuffer is working at runtime, there is no "tpIsDone" anymore during the gcode run.
   The tpIsDone clear's the buffer. And this results in delay's.
   Gladly we have ruled this behaviour out.
   It just run's without any delay's trough a program with 50K+ lines.
5. The ringbuffer is memory effiecient and needs no copy, remove, etc. in relation to a c++ std::vector

HouseKeeping:
The codebase is now using submodules.
It's worth to take a look at the readme files off the submodules.

1. main linuxcnc scurve repository: codeberg.org/skynet/linuxcnc_scurve_compact
2. submodule : codeberg.org/skynet/libclothoid3d
3. submodule : codeberg.org/skynet/libscurve

The submodules can now easely be used by other developpers to use in their projects.
Today i worked mainly to get this submodules and readme files up to date.

Note, the scurve is 8x faster then Ruckig.

For the people who want to do a financial contribution to our work,
there is a donation button at the end of the readme files.
A donation support's a non-profit organisation related to retired donkey's in the US, located above San Fransisco.

Codebase clone & runtest:

This worked ok!
 

I installed a PCIe board on debian 12 linuxcnc 2.9.4 and even though it works perfectly I get this error at the start of linuxcnc.
Is there a way to delete the message?
thanks 

It looked like forum admin emails, hence the reason I xxx them out.

I sent Andy & Rod an email with a screenshot, hoping that they may be able to forward it on to someone that knows about the forum.
It happened before all the "crack spam" was removed and was concerned that something "bad" may have happened.

I think it was the wording "reset". To actually reset a 7I95T
you need to cycle the power (or issue a reset command but
LinuxCNC never does this)

If this is a real time error, it may be that the servo thread period
needs to be increased to say 2 ms as 1 ms is marginal on a RPI4.

Hi everyone,
I recently ran a benchmark test on my LinuxCNC setup to measure the data request speed, and I thought I’d share the results with you all. I’d love to hear your thoughts or any suggestions for further optimization!
The setup was connected as follows: [Linux 4.19.0-27-rt-amd (core i5) PC (3 byte send 5 byte receive)] -> [switch (TL-SG1005D)] -> [W5100S-Pico]. This was a non-realtime throughput measurement, and the result I got was a stable 2500 requests/second, which I think is pretty solid. I’m curious about your experiences—has anyone else done similar benchmarks, and what do you think of this performance?

Thanks in advance for your input!

 

If you ever set the update rate to 0, you can never change it again or the driver will hang (this is a known bug)

Hi shellcrash,
I'm trying to get an X6 1090T working with a biostar A880GZ motherboard (which I think is just one generation newer). I'm so far unable to get as low a jitter as you got, and I was wondering if you remembered any bios, kernel, etc settings that enabled you to get such low jitter numbers.


I've only gotten below 40us jitter so far: forum.linuxcnc.org/38-general-linuxcnc-q...it-of-jitter?start=0

Hallo,

ich habe mich entschlossen meine Systeme mal auf neuen Stand zu bringen. Ich habe dazu LinuxCNC 2.9.4 parallel installiert und möchte nun die Konfiguration erstellen. Die alte Konfiguration von der Version 2.8.4 (mit gmoccapy und einigen Macros und WHB04B-4andrad ) funktioniert so natürlich nicht. Was kann ich von der alten Konfiguration weiter verwenden, was muss ich anpassen und was muss neu erstellt werden? 

Danke für eure Hilfe.

Norbert


 

Hi Grotius,

this is awsome, good work.
Regarding the ringbuffer, did you already try a code with lots of tiny segments? In your example there is propably plenty of time between the g code lines to calculate the next clothoid. With lots of smaller sections we could test if it works in general.
If the calculation takes 25ms then running a g code with F6000 with sections shorter than 2.5mm might already be the limit.
Would be an interesting test what happens with a modern g code with lots of tiny moves.

Best regards,
Fabian

No, total was 170000$, the price of the included XPR300 was 84000$.

e-mail?

Fixed title.

tommylight wrote:

Last i checked, something that comes close to QtPlasmaC in functionality (not in usability by far, much harder to use) was over 170000$ with a 300A plasma source that costs 84000$, leaving the machine price at 86000$ for 6X2.5M cut envelope!

Are you saying that plasma table you checked was about a quarter million? USD? 170 000 + 80 000 ?