Advanced Search

Success! Known files run as anticipated.  Did require tweaking several INI parameters and I am sure more refinements will happen as I develop experience with this version. 

I am using to drive a rose engine lathe and thus the reason for the XZC coordinate system.

Thanks again for your patience and assistance.

Nice

The old tp (old old) used to hit the centre of each segment, which is what caused it to become excruciatingly slow and sorta useless for high speed contouring. So we don't want to do that.

With short segments the key is is deviation. if you set a deviation of 10 microns, then the motion simply has to slow down in certain sections to ensure its never more than 10 microns away, and yes you might blend over 20 segments to do this. The current planner is reasonably good at this in terms of keeping speed as high as possible but never deviating too far. It does create a few instances of improper deviation though that it looks like yours would fix. For example a lead into a a facing cut would blend across the long face segment causing it to not cut flat.

Since I can only look at pictures and go "oooh, ahhh", my quesiton is: how does it deal with tangential motion that exceeds acceleration abilities? You only show the helixes perpendicular to the G1 motions. So for example a rounded corner that's a G3 move, but is only 0.5mm radius. You need to basically "blend out" that G3 while adhering to the P value.

I think it was transient and due to  the forum sending too many emails for the quota on whatever email platform is used by the forum.
I did recognise Tommy and Snowgoer from the screen dump you sent me, Both are pretty prolific posters.
I rarely subscribe to threads.

Software stepping = base period
And both look pretty good, so move on to making chips

I'll try setting the update rate to .1 in the hal file
(I've set it later to .1 without any issue)

Setting  the update rate to .1 in the hal file works fine here.

 ( Of course it only  updates the outputs every 10 seconds so you need to wait
from 0 to 10 seconds after you update an output for the physical output to get updated )

loadrt mb25ioc32 ports=hm2_[HOSTMOT2](BOARD).0.pktuart.0
addf mb25ioc32.00 servo-thread
setp mb25ioc32.00.baudrate 9600
#setp mb25ioc32.00.baudrate 115200
setp mb25ioc32.00.parity 0
setp mb25ioc32.00.address 1
setp mb25ioc32.00.update-hz 0.1
#setp mb25ioc32.00.setbaud 7 # 7 is 115200



 

I'm running latency-histogram with nothing else going on. I realize lots should be going on to figure out usable software stepping latency numbers, but I found something odd and wanted to simplify.
I ran these two commands:
latency-histogram --sbins 1000
latency-histogram --nobase --sbins 1000
The second result quickly diverged from the first servo results, and has a different shape:
-14.1 to 13.0
-22.0 to 18.1
It looks to me like there is a difference in the two servo measurements. This is odd.

A question: If I'm using software stepping, which one matters, base or servo (or both)?

No it is not divide by 0 bug.I have tested that fix in mesa_modbus.c.tmpl code but problem not fixed.I have set update-hz 0.1 in hal file and does not work.
Only 0 works but if modbus is working encoder reads crazy data.
Encoder stop read crazy data only if modbus
does not work.
Can't work both encoder and modbus.
But the problem appears when there are 5 encoders not only 4

Are you saying you have the update rate set to 0 in the hal file?

(and 0 is bad as it triggers the divide by 0 bug)

I don't see an issue with .1 second update rate
(I have used that value but probably set it later)

It looks like much of this may be related to the divide by 0 bug in the driver


 

I have start with 0.1 setting and does not work.
Reads only the inputs at startup but can not set outputs neither led in ioc32 blinks.
I was thinking the works but because saw input pin lighting in halshow but when try
to set out pin not works neither
data transfer modbus led blinking in ioc32

The error when setting the update rate to 0 is that you cannot change it
after this has been done:

   "If you ever set the update rate to 0 (maximum), changing to a
    non-zero rate will not work (communication stops)"

I have no issue with the ioc32 running at 9600 baud at a .1 second update rate.

 The bug is in either Mesa modbus or the PKTUART driver, not the VHDL.
Most likely the drivers idea of the amount of read data does not match
the actual amount returned, so data from one module is mixed with the
previous or subsequent modules data.

It could also conceivably be a memory/stack issue in the modbus or PKTUART driver.

 

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.