Advanced Search

We (mods and admins) get e-mail notifications for every post, always, so from 50 to over 100 daily.

I think that you should enable HPC (High Performance Computing) to prevent it from lowering the cpu frequency. Possibly also core performance boost. And to see if the kernel parameter works: cat /sys/devices/system/cpu/smt/active

my only contact is the sales lady

Sure, but can you please expain what you would like to do?

I've sent an email. We'll see. If anyone has a contact, please let me know.

Yes. What's holding me up is having blown up my parallel port :<
So I'm getting lost in details while waiting for the card (well, I bought two of them) to show up.
For other people's reference, the Dell Sunix 0GP385 cards work fine with LinuxCNC and are readily available on ebay.

About 8-10 years ago we looked at an entry level hi definition plasma table and it was AUD $130k direct from the manufacturer.

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